閘道式輸出和閘道式輸入

Last reviewed 2025-01-23 UTC

閘道式輸出和輸入模式會在需要在工作負載之間雙向使用所選 API 的情況下,使用閘道式輸出和輸入的組合。工作負載可在 Google Cloud、私人內部部署環境或其他雲端環境中執行。在這個模式中,您可以使用 API 閘道、Private Service Connect 端點或負載平衡器來公開特定 API,並視需要提供驗證、授權和 API 呼叫稽核。

這個模式與網狀模式的主要差異在於,這個模式適用於僅需要使用雙向 API 或與特定 IP 位址來源和目的地進行通訊的情況,例如透過 Private Service Connect 端點發布的應用程式。由於通訊僅限於公開的 API 或特定 IP 位址,因此您不需要在設計中將各環境的網路對齊。常見的適用情境包括但不限於:

  • 併購與收購。
  • 與合作夥伴整合的應用程式。
  • 整合機構的應用程式和服務,這些機構單位會管理自己的應用程式,並在不同的環境中代管這些應用程式。

通訊的運作方式如下:

  • 部署在 Google Cloud 中的工作負載可以使用內部 IP 位址,與 API 閘道 (或特定目的地 IP 位址) 通訊。但無法連線至部署在私人運算環境中的其他系統。
  • 相反地,部署在其他運算環境中的工作負載,可以使用內部 IP 位址與 Google Cloud端的 API 閘道 (或特定發布的端點 IP 位址) 通訊,但無法連線至部署在 Google Cloud 中的其他系統。

架構

下圖顯示閘道式輸出和閘道式輸入模式的參考架構:

在 Google Cloud 與地端或其他雲端網路之間輸出和輸入資料。

上圖中的設計方法包含下列元素:

  • 在 Google Cloud 端,您可以在 VPC (或共用虛擬私有雲) 中部署工作負載,但不要直接向網際網路公開。
  • Google Cloud 環境網路會擴展至其他運算環境。該環境可以是內部部署或其他雲端。如要擴充環境,請使用適當的混合雲和多雲端連線通訊模式,以利環境之間的通訊,讓環境能夠使用內部 IP 位址。
  • 您可以選擇啟用對特定目標 IP 位址的存取權,藉此使用傳遞 VPC 在應用程式 VPC 外部新增範圍安全層。
    • 您可以在傳輸虛擬私人雲端中,使用 Cloud Next Generation Firewall 或網路虛擬設備 (NVA) 搭配下一代防火牆 (NGFW),檢查流量,並在流量抵達應用程式虛擬私人雲端前,允許或禁止存取特定來源的特定 API。
  • 您應透過 API Gateway 或負載平衡器存取 API,以便提供 Proxy 層,並為服務 API 提供抽象或外觀。
  • 如果應用程式是以 API 形式使用,您也可以使用 Private Service Connect 為已發布的應用程式提供內部 IP 位址。
  • 所有環境都使用不重疊的 RFC 1918 IP 位址空間。

這個模式的常見應用包括在 Google Cloud 部署應用程式後端 (或應用程式後端的子集),同時在地端環境或其他雲端中代管其他後端和前端元件 (分層混合式模式分割多雲端模式)。隨著應用程式演進並遷移至雲端,通常會出現特定雲端服務的依附元件和偏好設定。

有時這些依附元件和偏好設定會導致應用程式和後端分散在不同的雲端服務供應商。此外,某些應用程式可能會結合內部部署環境和多個雲端環境中的資源和服務來建構。

針對分散式應用程式,您可以使用 外部 Cloud Load Balancing 混合型多雲端連線 的功能,終止使用者要求並將其轉送至其他環境的前端或後端。這項路由會透過混合式網路連線進行,如下圖所示。這項整合可讓您在不同環境中逐步發布應用程式元件。從前端到在 Google Cloud 中代管的後端服務的請求,會透過內部負載平衡器 (圖表中的 ILB) 協助建立的混合式網路連線,安全地進行通訊。

資料會在內部部署或其他雲端環境中的應用程式前端,以及 Google Cloud 環境中的應用程式後端之間流入和流出。資料會透過 Google Cloud中的內部負載平衡器 (ILB) 流動。

使用上圖中的 Google Cloud 設計可協助完成下列工作:

  • 使用雙方預先定義的 API,符合此模式的通訊模型,方便 Google Cloud、內部部署和其他雲端環境之間進行雙向通訊。
  • 如要為面向網際網路的應用程式提供全球前端,並搭配分散式應用程式元件 (前端或後端) 達成下列目標,您可以使用 Google Cloud 分散在服務點 (PoP) 的進階負載平衡和安全性功能:
  • 使用無伺服器代管服務,降低資本支出並簡化作業流程。
  • 針對全球應用程式後端最佳化連線,以提升速度和降低延遲。
    • Google Cloud Cross-Cloud Network 可透過最佳私人連線,讓應用程式元件之間進行多雲端通訊。
  • 提供 Cloud CDN 存取權,快取需求量高的靜態內容,並改善使用全球 Cloud Load Balancing 的應用程式效能。
  • 使用 Google Cloud Armor 功能,提供全球分散式網頁應用程式防火牆 (WAF) 和分散式阻斷服務緩解服務,保護面向網際網路的應用程式全球前端。
  • 您可以選擇將 Private Service Connect 納入設計。這樣一來,您就能在其他環境中,針對 Google Cloud 服務 API 或已發布的服務,啟用私人、精細的存取權,而無須穿越公開網際網路。

變化版本

閘控出口和閘控入口架構模式可與其他方法搭配使用,以滿足不同的設計需求,同時考量此模式的通訊需求。這些模式提供下列選項:

分散式 API 閘道

在某些情況下 (例如以分割多雲端模式為基礎),應用程式 (或應用程式元件) 可在不同的雲端環境中建構,包括私人內部部署環境。常見的要求是將用戶端要求直接轉送至應用程式前端,並轉送至代管應用程式 (或前端元件) 的環境。這類通訊需要本機負載平衡器或 API 閘道。這些應用程式及其元件可能也需要特定的 API 平台功能才能整合。

下圖說明 Apigee 和 Apigee Hybrid 如何在各個環境中提供本地化 API 閘道,以滿足這類需求。API 平台管理功能已集中在 Google Cloud中。這項設計有助於實施嚴格的存取控制措施,只有預先核准的 IP 位址 (目標和目的地 API 或 Private Service Connect 端點 IP 位址) 才能在 Google Cloud 和其他環境之間通訊。

資料在內部部署或其他雲端環境與 Google Cloud 環境之間流入和流出。應用程式前端的用戶端要求會直接傳送至應用程式 (或前端元件) 代管的環境。

下表說明上圖中使用 Apigee API 閘道的兩個不同的通訊路徑:

  • 用戶端要求會直接傳送至應用程式前端,並在代管應用程式 (或前端元件) 的環境中執行。
  • 每個環境中的 API 網關和 Proxy 會處理跨多個環境的不同方向的用戶端和應用程式 API 要求。
    • Google Cloud(Apigee) 中的 API 網關功能會公開在 Google Cloud中代管的應用程式 (前端或後端) 元件。
    • 其他環境 (Hybrid) 中的 API 閘道功能會公開該環境中代管的應用程式前端 (或後端) 元件。

您也可以考慮使用傳輸 VPC。轉接 VPC 可提供彈性,讓您分開處理不同問題,並在不同的 VPC 網路中執行安全檢查和混合式連線。從 IP 位址可達性角度來看,傳遞 VPC (已連結混合式連線) 可滿足下列需求,以維持端對端可達性:

  • 目標 API 的 IP 位址必須宣傳至託管用戶端/要求者的其他環境。
  • 需要與目標 API 通訊的主機 IP 位址,必須宣傳至目標 API 所在的環境,例如 API 要求者 (用戶端) 的 IP 位址。例外狀況是透過負載平衡器、Proxy、Private Service Connect 端點或 NAT 執行個體進行通訊。

為了擴充至遠端環境的連線,此設計會使用直接虛擬私有雲對等互連功能,搭配客戶路由交換功能。這項設計可讓來自 Google Cloud 應用程式 VPC 中代管工作負載的特定 API 要求,透過轉接 VPC 轉送。或者,您也可以在應用程式 VPC 中使用 Private Service Connect 端點,該端點與轉接 VPC 中的混合式網路端點群組後端負載平衡器相關聯。下一節將說明該設定:使用 Private Service Connect 進行雙向 API 通訊。

使用 Private Service Connect 進行雙向 API 通訊

有時,企業可能不需要立即使用 API Gateway (例如 Apigee),或可能想稍後再新增。不過,您可能需要滿足某些業務需求,才能在不同環境中啟用特定應用程式之間的通訊和整合。舉例來說,如果貴公司收購了另一家公司,您可能需要向該公司公開特定應用程式。他們可能需要向貴公司提供應用程式。兩家公司可能各自有在不同環境 (Google Cloud、內部部署或其他雲端) 中代管的工作負載,因此必須避免 IP 位址重疊。在這種情況下,您可以使用 Private Service Connect 進行有效的通訊。

如果應用程式是以 API 形式使用,您也可以使用 Private Service Connect 為已發布的應用程式提供私人地址,在私人網路中跨區域和混合式連線安全存取。這項抽象化功能可透過混合式雲和多雲端連線模型,簡化來自不同雲端和內部部署環境的資源整合作業。也能讓您在多雲端和內部部署環境中組合應用程式。這可滿足不同的通訊需求,例如在未使用或未規劃使用 API 閘道的安全應用程式中整合。

如以下圖表所示,您可以使用 Private Service Connect 搭配 Cloud Load Balancing,實現兩個不同的通訊路徑。每個路徑都會從不同的方向啟動,用於不同的連線用途,最好是透過 API 呼叫。

  • 本指南中討論的 Private Service Connect 設計考量和建議,都適用於這項設計。
  • 如果需要額外的第 7 層檢查,您可以將 NVA 與此設計 (在轉接 VPC 中) 整合。
  • 無論是否搭配 API Gateway,都能使用這項設計。

內部部署或其他雲端環境和 Google Cloud 環境會透過不同的路徑,以及各種負載平衡器、VPC 端點和子網路傳輸資料。

上圖所示的兩個連線路徑代表獨立的連線,並未說明單一連線或流量的雙向通訊。

使用 Private Service Connect 端點和介面進行雙向通訊

控管的入站連線模式所述,啟用用戶端與服務通訊的選項之一,就是使用 Private Service Connect 端點,將供應者虛擬私有雲中的服務公開給消費者虛擬私有雲。這項連線功能可透過混合式連線擴展至地端部署環境,甚至是其他雲端供應商環境。不過,在某些情況下,代管服務也可能需要私人通訊。

如要存取特定服務 (例如從可在用戶虛擬私有雲內或外部署的資料來源擷取資料),這類私人通訊可以是應用程式 (供應者) 虛擬私有雲與遠端環境 (例如內部部署環境) 之間的通訊。

在這種情況下,Private Service Connect 介面可讓服務供應商 VM 執行個體存取消費者的網路。方法是共用網路介面,同時維持生產端和消費端角色的分離。有了消費者 VPC 中的這個網路介面,應用程式 VM 就能存取消費者資源,就好像這些資源位於供應者 VPC 的本機一樣。

Private Service Connect 介面是連結至用戶 (轉接) VPC 的網路介面。您可以連線至可從附加 Private Service Connect 介面的消費者 (轉接) VPC 存取的外部目的地。因此,這項連線可透過混合式連線 (例如內部部署環境) 延伸至外部環境,如下圖所示:

在 Google Cloud 中的應用程式與地端部署系統或其他雲端網路中的負載之間,資料輸出和輸入。

如果用戶虛擬私有雲是外部機構或實體 (例如第三方機構),您通常無法保護與用戶虛擬私有雲中 Private Service Connect 介面的通訊。在這種情況下,您可以在 Private Service Connect 介面 VM 的來賓作業系統中定義安全性政策。詳情請參閱「為 Private Service Connect 介面設定安全性」。如果不符合貴機構的安全性法規遵循或標準,您可以考慮其他方法。

最佳做法

  • 如果需要在本地端接收來自網路的用戶端要求,而前端是託管在私人內部部署或其他雲端環境中,請考慮使用 Hybrid 做為 API 閘道解決方案。

    • 這種做法還可協助將解決方案遷移至完全由 Google Cloud代管的環境,同時維持 API 平台 (Apigee) 的一致性。
  • 如要將大量外出資料傳輸至其他環境的延遲時間降到最低,並降低成本,請在這些環境採用長期或永久的混合式或多雲端設定時,考慮以下事項:

    • 使用 Cloud Interconnect 或 Cross-Cloud Interconnect。
    • 如要在適當環境中,在指定前端終止使用者連線,請使用Hybrid
  • 在符合您的需求和架構的情況下,請使用 Envoy 專用的 Apigee 轉接器,搭配使用 Kubernetes 的混合式部署

  • 在設計連線和路由路徑之前,您必須先找出需要將流量或 API 要求導向至本機或遠端 API Gateway 的來源和目標環境。

  • 使用 VPC Service Controls 保護 Google Cloud 專案中的服務,並在專案或 VPC 網路層級指定服務範圍,以降低資料竊取風險。

  • 使用虛擬私有雲 (VPC) 防火牆規則防火牆政策,透過 Private Service Connect 端點控管對 Private Service Connect 資源的網路層級存取權。舉例來說,應用程式 (消費者) 虛擬私有雲的出站防火牆規則可限制 VM 執行個體存取端點的 IP 位址或子網路。

  • 使用 Private Service Connect 介面時,您必須為 Private Service Connect 介面設定安全性,以保護與該介面的通訊。

  • 如果私人子網路中的工作負載需要存取網際網路,請使用 Cloud NAT,避免將外部 IP 位址指派給工作負載,並將其公開給網際網路。

  • 請參閱混合式雲端和多雲端網路模式的一般最佳做法