這份文件是三份文件中的第二份，本文將探討常見的混合式雲端和多雲端架構模式。並說明這些模式最適合用於哪些情境。最後，它提供在 Google Cloud中部署這類架構時可使用的最佳做法。

混合式雲端和多雲端架構模式的文件組合包含以下部分：

• 建構混合式雲端和多雲端架構：說明如何規劃使用 Google Cloud建構混合式雲端和多雲端設定的策略。
• 混合式雲端和多雲端架構模式：說明混合式雲端和多雲端策略 (本文) 中採用的常見架構模式。
• 混合式雲端和多雲端安全網路架構模式：從網路角度探討混合式雲端和多雲端網路架構模式。

每家企業都有獨特的應用程式工作負載組合，會對混合式雲端或多雲端設定的架構設有相關需求與限制。雖然您必須精心設計並打造出符合這些限制與需求的架構，您仍可仰賴一些常用的模式來定義基礎架構。

架構模式是一種可重複使用的方法，可用於建構技術解決方案、應用程式或服務的多個功能元件，以便建立可滿足特定需求或使用情境的可重複使用解決方案。雲端技術解決方案通常由多個獨立且分散的雲端服務組成。這些服務會協同合作，提供必要的功能。在這個情況下，每項服務都視為技術解決方案的功能元件。同樣地，應用程式可由多個功能層級、模組或服務組成，每個層級、模組或服務都代表應用程式架構的功能元件。這類架構可標準化，以便處理特定商家應用實例，並做為可重複使用的基礎模式。

如要為應用程式或解決方案一般定義架構模式，請找出並定義下列項目：

• 解決方案或應用程式的元件。
• 每個元件的預期函式，例如前端函式可提供圖形使用者介面，或後端函式可提供資料存取權。
• 元件如何彼此通訊，以及與外部系統或使用者通訊。在現代應用程式中，這些元件會透過明確定義的介面或 API 進行互動。通訊模型的種類繁多，例如非同步和同步、要求/回應或佇列式。

以下是混合雲和多雲端架構模式的兩個主要類別：

• 分散式架構模式：這些模式仰賴分散式部署的工作負載或應用程式元件。也就是說，它們會在最適合該模式的運算環境中執行應用程式 (或該應用程式的特定元件)。這樣一來，模式就能善加利用分散式和互連運算環境的不同屬性與特性。
• 備援架構模式：這些模式以工作負載的備援部署為基礎。在這些模式中，您會在多個運算環境中部署相同的應用程式及其元件。目標是提高應用程式的效能容量或彈性，或是複製現有開發和測試環境。

實作所選架構模式時，您必須使用適當的部署原型。部署原型可分為可用區、區域、多區域或全球。這項選項是建構應用程式專屬部署架構的基礎。每個部署原型都會定義應用程式可運作的失敗網域組合。這些失敗區域可以涵蓋一或多個Google Cloud 可用區或區域，並可擴展至納入您在其他雲端服務供應商的內部部署資料中心或失敗區域。

本系列包含以下頁面：

• 分散式架構模式

  • 分級混合模式

  • 分區多雲端模式

  • Analytics 混合式雲端與多雲端模式

  • Edge 混合模式

• 備援架構模式

  • 環境混合模式
  • 業務持續性混合模式和多雲端模式
  • 雲端爆發模式

貢獻者

作者：Marwan Al Shawi | 合作夥伴客戶工程師

其他貢獻者：

• Saud Albazei | 應用程式現代化客戶工程師
• Anna Berenberg | 工程研究員
• Marco Ferrari | 雲端解決方案架構師
• Victor Moreno | 雲端網路產品經理
• Johannes Passing | 雲端解決方案架構師
• Mark Schlagenhauf | 網路技術文件撰稿人
• Daniel Strebel | 應用程式現代化歐洲、中東和非洲地區解決方案主管
• Ammett Williams | 開發人員關係工程師

分散式架構模式

從非混合式或非多雲端運算環境遷移至混合式或多雲端架構時，請先考量現有應用程式的限制，以及這些限制如何導致應用程式失敗。如果應用程式或應用程式元件以分散方式在不同環境中運作，這項考量就更加重要。考量完限制條件後，請擬定避免或克服這些限制的計畫。請務必考量分散式架構中每個運算環境的獨特功能。

設計須知

以下設計考量適用於分散式部署模式。根據目標解決方案和業務目標，每項考量的優先順序和效果可能會有所不同。

延遲時間

在任何架構模式中，如果要在不同運算環境中分散應用程式元件 (前端、後端或微服務)，就可能發生通訊延遲。這項延遲時間會受到混合式網路連線 (Cloud VPN 和 Cloud Interconnect) 的影響，以及內部部署站點與雲端區域之間，或多雲設定中雲端區域之間的地理距離。因此，評估應用程式的延遲要求，以及應用程式對網路延遲的敏感度，十分重要。在混合式或多雲端環境中，可容許延遲的應用程式更適合初始分散式部署作業。

暫時狀態與最終狀態架構

為了明確瞭解預期結果，以及費用、規模和效能可能產生的任何影響，在規劃階段，請務必分析所需的架構類型和預期的執行時間。舉例來說，如果您打算長期或永久使用混合式或多雲架構，建議您考慮使用 Cloud Interconnect。為降低傳出資料傳輸費用，並提升混合式連線網路效能，Cloud Interconnect 會針對符合資料傳輸費率折扣條件的傳出資料傳輸費用提供折扣。

可靠性

在建構 IT 系統時，可靠性是主要考量因素。正常運作時間是系統可靠性的關鍵要素。在 Google Cloud中，您可以利用切換功能，在單一區域的多個區域¹或跨多個區域，部署該應用程式的備援元件，藉此提高應用程式的彈性。冗餘性是提高應用程式整體可用性的關鍵要素之一。如果應用程式在混合式雲端和多雲端環境中採用分散式設定，就必須維持一致的可用性。

如要提升系統在內部環境或其他雲端環境中的可用性，請考量應用程式及其元件需要哪些硬體或軟體備援機制，並搭配備援機制。理想情況下，您應考量在所有環境中，各項元件和支援基礎架構 (包括混合連線功能) 的服務或應用程式可用性。這項概念也稱為應用程式或服務的複合可用性。

根據元件或服務之間的依附元件，應用程式的綜合可用性可能高於或低於個別服務或元件。詳情請參閱「複合可用性：計算雲端基礎架構的整體可用性」一文。

如要達到所需的系統可靠度，請明確定義可靠度指標，並設計應用程式，讓應用程式能在不同環境中有效地自我修復及耐受中斷。如要瞭解如何定義評估服務客戶體驗的適當方式，請參閱「根據使用者體驗目標定義可靠性」一文。

混合雲與多雲端連線

分散式應用程式元件之間的通訊需求，應會影響您選擇混合式網路連線選項。每個連線選項都有優缺點，以及需要考量的特定因素，例如成本、流量量、安全性等。詳情請參閱「連線設計注意事項」一節。

易管理性

如要成功設定混合雲和多雲端 (不論是否具備工作負載可攜性)，就必須使用一致且統一的管理和監控工具。短期來說，這些工具可能會增加開發、測試和營運成本。從技術層面來說，採用的雲端服務供應商越多，管理環境 就會變得越複雜。大多數的公有雲供應商不僅具備不同的功能/特色，還會提供各種管理雲端服務的工具、服務水準協議和 API。因此，請根據所選架構的策略優點、潛在的短期複雜度和長期效益，權衡利弊。

費用

在多雲環境中，每個雲端服務供應商都有自己的帳單指標和工具。如要提供更佳的資訊掌握度和統一資訊主頁，建議您使用多雲成本管理和最佳化工具。舉例來說，在多個雲端環境中建構雲端優先解決方案時，每個供應商的產品、價格、折扣和管理工具，都可能導致這些環境之間的成本不一致。

建議您採用單一明確的計算方法，計算雲端資源的總成本，並提供費用資訊。掌握成本資訊是成本最佳化的關鍵。舉例來說，您可以結合所用雲端服務供應商的帳單資料，並使用 Google Cloud Looker Cloud Cost Management Block，建立多雲端費用的集中檢視畫面。這個檢視畫面可提供多個雲端服務的合併報表檢視畫面。詳情請參閱「有效改善雲端帳單成本管理的策略」。

我們也建議您採用 FinOps 做法，讓成本一目瞭然。在健全的 FinOps 實務中，中央團隊可以將資源最佳化決策委派給任何參與專案的其他團隊，以鼓勵個人負起責任。在這個模式中，中央團隊應將程序、報表和工具標準化，以便進行成本最佳化。如要進一步瞭解不同的成本最佳化面向，以及應考慮的最佳化建議，請參閱Google Cloud 「Well-Architected Framework：成本最佳化」。

資料遷移

資料移轉是混合式雲端和多雲端策略與架構規劃的重要考量，特別是對於分散式系統。企業需要找出不同的業務用途、相關資料，以及資料的分類方式 (適用於受管制產業)。他們也應考量在各環境中，資料儲存、分享和分散式系統存取權可能對應用程式效能和資料一致性造成的影響。這些因素可能會影響應用程式和資料管道架構。Google Cloud提供多種資料移轉選項，可滿足企業的特定需求，並採用混合雲和多雲架構，同時兼顧簡易性、效率和效能。

安全性

將應用程式遷移至雲端時，請務必考量雲端優先的安全功能，例如一致性、可觀察性和統一安全性資訊。每家公用雲端服務供應商都有自己的安全性做法、最佳做法和功能。因此，您必須分析並調整這些功能，才能建立標準的功能性安全架構。強大的 IAM 控管、資料加密、安全漏洞掃描，以及遵循業界法規，也是雲端安全的重要環節。

規劃遷移策略時，建議您分析先前提及的考量事項。這類架構可協助您盡量減少在應用程式或流量量增加時，引入架構複雜度的機會。此外，在雲端環境中部署企業工作負載時，幾乎都必須先設計及建構登錄區。登陸區可協助企業在多個領域中，以更安全的方式部署、使用及擴充雲端服務，並包含身分、資源管理、安全性和網路等不同元素。詳情請參閱「 Google Cloud中的登陸區設計」。

本系列的其他文件會說明其他分散式架構模式：

• 分級混合模式
• 分區多雲端模式
• Analytics 混合式雲端與多雲端模式
• Edge 混合模式

分級混合模式

應用程式的架構元件可劃分為「前端」或「後端」。在某些情況下，這些元件可託管在不同的運算環境中運作。在分層混合型架構模式中，運算環境位於地端私人運算環境和 Google Cloud中。

前端應用程式元件會直接向使用者或裝置公開。因此，這些應用程式通常高度重視效能表現。為了開發新功能及改善現有功能，我們可能會頻繁發布軟體更新。由於前端應用程式通常仰賴後端應用程式來儲存及管理資料 (以及可能的商業邏輯和使用者輸入處理作業)，因此通常為無狀態或只管理少量資料。

您可以使用各種架構和技術建構前端應用程式，以便使用者存取及使用。成功的前端應用程式需要具備一些關鍵要素，包括應用程式效能、回應速度和瀏覽器相容性。

後端應用程式元件通常專注於儲存及管理資料。在某些架構中，商業邏輯可能會整合至後端元件。後端應用程式推出新版本的速度通常不會像前端應用程式那麼頻繁。後端應用程式必須處理下列挑戰：

• 處理大量要求
• 處理大量資料
• 保護資料安全
• 維護所有系統備援機制中的最新資料

三層式應用程式架構是最常見的建構商用網頁應用程式實作方式之一，例如含有不同應用程式元件的電子商務網站。這個架構包含下列層級。每個層級都會獨立運作，但彼此緊密相連，且都能一起運作。

• 網路前端和呈現層
• 應用程式層
• 資料存取或後端層

將這些層放入容器，可分離技術需求 (例如調整需求)，並有助於分階段遷移。此外，您還可以將這些應用程式部署至不限平台的雲端服務，以便在各環境中移植、使用自動化管理功能，並隨著雲端管理平台 (例如 Cloud Run 或 Google Kubernetes Engine (GKE) 企業版) 擴充規模。此外，Cloud SQL 等 Google Cloud代管資料庫可提供後端做為資料庫層。

分級混合架構模式著重於將現有的前端應用程式元件部署至公用雲端。在這個模式中，您會將任何現有的後端應用程式元件保留在其私人運算環境中。您可以根據應用程式的規模和具體設計，視情況遷移前端應用程式元件。詳情請參閱「遷移至 Google Cloud」。

如果您有現有應用程式，且其中的後端和前端元件皆託管於內部部署環境，請考量目前架構的限制。舉例來說，隨著應用程式規模擴大，其效能和可靠性需求也會增加，因此您應該開始評估應用程式部分是否應進行重構，或移至其他更理想的架構。您可以先將部分應用程式工作負載和元件轉移至雲端，再進行完整轉換，這就是分級混合架構模式。您也必須考量這類遷移作業的成本、時間和風險。

下圖顯示典型的分層混合架構模式。

在上述圖表中，用戶端要求會傳送至託管於 Google Cloud的應用程式前端。應用程式前端會將資料傳回應用程式後端的內部環境 (最好是透過 API 閘道)。

您可以使用分層混合型架構模式，充分利用Google Cloud 基礎架構和全球服務，如下圖所示架構範例所示。應用程式前端可透過 Google Cloud存取。您也可以使用自動調整資源配置功能，動態且有效率地回應資源調度需求，為前端增加彈性，而無須過度配置基礎架構。您可以使用不同的架構，在 Google Cloud上建構及執行可擴充的網頁應用程式。每種架構都有不同的優缺點，可滿足不同的需求。

如需更多資訊，請前往 YouTube 觀看「Three ways to run scalable web apps on Google Cloud」影片。如要進一步瞭解如何在Google Cloud中將電子商務平台改造成新式平台，請參閱「如何在 Google Cloud中建構數位商務平台」。

在上述圖表中，應用程式前端會在Google Cloud 上代管，以便透過全球Google Cloud Armor 提供多地區和全球最佳化使用者體驗，並使用全球負載平衡、自動調度資源，以及 DDoS 防護機制。

隨著時間過去，您部署至公用雲端的應用程式數量可能會增加，到時您可能會考慮將後端應用程式元件遷移至公用雲端。如果您預期會提供大量流量，選擇雲端代管服務可能有助於在管理自有基礎架構時節省工程作業。除非限制或規定必須在內部代管後端應用程式元件，否則請考慮使用這個選項。舉例來說，如果您的後端資料受到法規限制，您可能需要將該資料保存在 on-premises 環境。不過，在適用且符合法規的情況下，您可以使用私密資料保護功能 (例如去識別化技術)，在必要時移動這些資料。

在分層混合型架構模式中，您也可以在某些情況下使用 Google Distributed Cloud。您可以透過 Distributed Cloud，在 Google 提供及維護的專屬硬體上執行 Google Kubernetes Engine 叢集，且不受 Google Cloud 資料中心影響。為確保 Distributed Cloud 滿足您目前和未來的需求，請瞭解 Distributed Cloud 與傳統雲端 GKE 區域的差異。

優點

先專注於前端應用程式有以下幾項優點：

• 前端元件會仰賴後端資源，偶爾也會仰賴其他前端元件。
• 後端元件不會依附前端元件。因此，區隔及遷移前端應用程式比較不會像遷移後端應用程式那麼複雜。
• 由於前端應用程式通常為無狀態，而且本身並不管理資料，因此遷移通常沒那麼困難。
  • 您可以將前端元件納入遷移作業，以便使用無狀態架構，進而進行最佳化。如需更多資訊，請前往 YouTube 觀看「如何將具狀態的網頁應用程式移植至 Cloud Run」。

將現有或新開發的前端應用程式部署至公用雲端可提供下列多項優點：

• 許多前端應用程式受限於頻繁的變更。在公用雲端執行這些應用程式可簡化持續整合/持續部署 (CI/CD) 程序的設定作業。您可以使用 CI/CD，以有效率且自動化的方式傳送更新。詳情請參閱「在 Google Cloud上進行 CI/CD」。
• 效能敏感型前端的流量負載會有所變化，因此可大幅受益於負載平衡、多地區部署、Cloud CDN 快取、無伺服器和自動調度資源等雲端部署啟用的功能 (最好搭配無狀態架構)。

• 採用使用雲端管理平台 (例如 GKE) 的微服務容器，即可使用微前端等新式架構，將微服務擴充至前端元件。

  擴充微服務通常會與前端搭配使用，前端涉及多個團隊在同一個應用程式上協同合作。這種團隊架構需要採用迭代式做法和持續維護。使用微前端的好處如下：

  • 您可以將其做為獨立的微服務模組，用於開發、測試和部署。
  • 這項功能可讓個別開發團隊選擇偏好的技術和程式碼，以便進行區隔。
  • 這可促進快速的開發和部署週期，且不會影響其他團隊可能管理的前端元件。

• 無論是實作使用者介面或 API，或是處理物聯網 (IoT) 資料擷取，前端應用程式都可以受益於 Firebase、Pub/Sub、Apigee、Cloud CDN、App Engine 或 Cloud Run 等雲端服務提供的功能。

• 雲端管理的 API Proxy 可協助您：

  • 將應用程式導向的 API 與後端服務 (例如微服務) 分離。
  • 保護應用程式免受後端程式碼變更的影響。
  • 支援現有的 API 驅動前端架構，例如前端後端 (BFF)、微前端和其他架構。
  • 在 Apigee 上實作 API Proxy，在 Google Cloud 或其他環境中公開 API。

您也可以反向套用分層混合模式，將後端部署在雲端，同時將前端保留在私人運算環境。雖然這種做法較少見，但處理重量級單體式前端時，最適合運用這種方法。在這種情況下，反覆擷取後端功能並將這些新的後端部署在雲端，可能會比較簡單。

本系列的第三部分將探討可能的網路模式，以便啟用這類架構。Apigee Hybrid 可做為平台，協助您在混合式部署模型中建構及管理 API Proxy。詳情請參閱鬆散結合架構，包括分層的單體和微服務架構。

最佳做法

規劃分層混合式架構時，請參考本節的資訊。

減少複雜度的最佳做法

套用分層混合式架構模式時，請考慮採用下列最佳做法，有助於降低整體部署和作業的複雜度：

• 根據所識別應用程式的通訊模式評估結果，為這些應用程式選取最有效率且有效的通訊解決方案。

由於大部分的使用者互動包含跨多個運算環境連結的系統，因此這些系統之間快速且低延遲的連結至關重要，為滿足可用性和效能預期，您應採用高可用性、低延遲和適當的總處理量等級設計。從安全性角度來看，通訊必須細緻且受控。理想情況下，您應使用安全的 API 公開應用程式元件。詳情請參閱「閘控外連」。

• 為了盡量減少環境之間的通訊延遲，請選取地理位置靠近應用程式後端元件代管位置的 Google Cloud 區域。詳情請參閱「選擇 Compute Engine 地區的最佳做法」。
• 盡可能減少在不同環境中執行的系統之間的高度依附元件，尤其是在同步處理通訊時。這些依附元件會降低效能、降低整體可用性，並可能產生額外的傳出資料傳輸費用。
• 採用分層混合架構模式時，Google Cloud 的內部部署環境輸入流量量可能會大於輸出流量量。 Google Cloud不過，您應該要瞭解 Google Cloud的預期資料傳輸量。如果您打算長期使用此架構，且傳出資料量高，建議您使用 Cloud Interconnect。Cloud Interconnect 可協助您改善連線效能，並可能降低符合特定條件的傳出資料傳輸費用。詳情請參閱「Cloud Interconnect 定價」。
• 為保護機密資訊，建議您對所有傳輸中的通訊內容進行加密。如果連線層需要加密，您可以使用 VPN 通道、採用 Cloud Interconnect 的高可用性 VPN 和 Cloud Interconnect 的 MACsec。

• 為克服不同後端的通訊協定、API 和驗證機制不一致的問題，建議您在適用情況下，將 API 閘道或 Proxy 部署為統一的外觀。這個閘道或 Proxy 會做為集中式控制點，執行下列措施：

  • 導入額外安全措施。
  • 保護用戶端應用程式和其他服務，不受後端程式碼變更的影響。
  • 協助稽核追蹤，針對所有跨環境應用程式與其解耦元件之間的通訊進行稽核。
  • 做為舊版和現代化服務之間的中介通訊層。
    • Apigee 和 Apigee hybrid 可讓您在內部部署環境、邊緣、其他雲端和Google Cloud 環境中代管及管理企業級和混合式閘道。

• 為簡化混合式設定的建立作業，請使用支援混合式連線的 Cloud Load Balancing。也就是說，您可以將雲端負載平衡的優點擴展至在內部部署的運算環境中代管的服務。這種做法可讓您以最少或不中斷服務的方式，分階段遷移工作負載，確保分散式服務順利轉移。 Google Cloud 詳情請參閱混合式連線網路端點群組總覽。

• 有時，使用 API Gateway 或 Proxy 和 Application Load Balancer 搭配使用，可以提供更強大的解決方案，用於大規模管理、保護及分發 API 流量。使用 Cloud Load Balancing 搭配 API Gateway，可讓您達成以下目標：

  • 透過 Apigee 和 Cloud CDN 提供高效能的 API，以減少延遲時間、在全球代管 API，並提高尖峰流量季節的可用性。如需更多資訊，請前往 YouTube 觀看「使用 Apigee 和 Cloud CDN 提供效能優異的 API」一文。
  • 實施進階流量管理。
  • 使用 Google Cloud Armor 做為 DDoS 防護和網路安全防護服務，保護您的 API。
  • 管理多個地區中閘道的有效負載平衡。如需更多資訊，請觀看 YouTube 上的使用 Private Service Connect 和 Apigee 保護 API 並實作多區域故障轉移。

• 使用API 管理和服務網格，透過微服務架構保護及控管服務通訊和暴露情形。

  • 使用 Cloud Service Mesh 可促成服務之間的通訊，進而在由分散式服務組成的系統中維持服務品質，並管理服務之間的驗證、授權和加密作業。
  • 使用 Apigee 等 API 管理平台，讓貴機構和外部實體以 API 的形式使用這些服務。

• 在環境之間建立通用身分識別，讓系統能夠跨越環境界線以安全的方式進行驗證。

• 在公用雲端中部署 CI/CD 和設定管理系統。詳情請參閱鏡像式網路架構模式。

• 為提高作業效率，請在各個環境中使用一致的工具和 CI/CD 管道。

個別工作負載和應用程式架構的最佳做法

• 雖然這個模式的重點在於前端應用程式，但仍請注意對後端應用程式進行現代化的需求。如果後端應用程式的開發步調比前端慢相當多，這項差異可能會導致額外的複雜情況。
• 將 API 視為後端介面可簡化整合、前端開發、服務互動，並隱藏後端系統的複雜性。為解決這些挑戰，Apigee 可協助您在混合式雲端和多雲端部署中開發及管理 API 閘道/Proxy。
• 根據內容 (靜態與動態)、搜尋引擎最佳化成效，以及網頁載入速度的預期，為前端網頁應用程式選擇轉譯方法。
• 在為內容導向網頁應用程式選取架構時，您可以選擇多種選項，包括單體式、無伺服器、事件導向和微服務架構。如要選取最合適的架構，請根據目前和未來的應用程式需求，徹底評估這些選項。如要協助您做出符合業務和技術目標的架構決策，請參閱「比較內容導向網頁應用程式後端的不同架構」和「網頁後端的重要考量事項」。

• 透過微服務架構，您可以使用容器化應用程式，並將 Kubernetes 做為通用的執行階段層。您可以使用分層混合型架構模式，在下列任一情況下執行：

  • 在兩個環境 (Google Cloud 和您的內部部署環境) 中。

    • 在各環境中使用容器和 Kubernetes 時，您可以靈活地將工作負載現代化，然後在不同時間點遷移至 Google Cloud 。當工作負載大量取決於另一個工作負載且無法個別遷移時，這會非常實用。您也可以使用混合工作負載可攜性，利用各個環境中可用的最佳資源。無論如何，G KE Enterprise 都是重要的輔助技術。詳情請參閱「GKE Enterprise 混合式環境」。

  • 在 Google Cloud 已遷移且已改良的應用程式元件環境中。

    • 如果您有缺乏容器化支援的舊版後端，或是需要大量時間和資源才能在短期內進行現代化，請採用這種方法。

    如要進一步瞭解如何設計及重構單體式應用程式，以便將其改為微服務架構，進而改良網路應用程式架構，請參閱「微服務簡介」。

• 您可以根據網頁應用程式的需求，結合多種資料儲存技術。使用 Cloud SQL 儲存結構化資料，並將 Cloud Storage 用於媒體檔案，是滿足各種資料儲存需求的常見做法。不過，這項選擇很大程度上取決於您的用途。如要進一步瞭解內容導向應用程式後端和有效模式的資料儲存空間選項，請參閱「內容導向網頁應用程式的資料儲存空間選項」。另請參閱「您的資料庫選項說明 Google Cloud 」。

分區多雲端模式

「分區多雲端」架構模式結合由不同雲端服務供應商營運的多個公用雲端環境。這項架構可讓您靈活地在最佳運算環境中部署應用程式，考量到本系列第一部分所討論的多雲驅動因素和考量事項。

下圖顯示分區多雲架構模式。

這個架構模式可透過兩種方式建構。第一個方法是根據在不同公用雲端環境中部署應用程式元件。這種方法也稱為複合式架構，與分層混合式架構模式相同。不過，它會使用至少兩個雲端環境，而非搭配公用雲端使用內部部署環境。在複合式架構中，單一工作負載或應用程式會使用多個雲端的元件。第二種方法是在不同的公用雲端環境中部署不同的應用程式。以下列舉部分第二種方法的業務動機，但不包含所有內容：

• 在兩家企業合併或收購的情況下，全面整合在不同雲端環境中代管的應用程式。
• 為了提升彈性，並滿足貴機構內部各種雲端偏好設定的需求。採用這種做法，鼓勵各個機構單位選擇最符合其特定需求和偏好的雲端服務供應商。
• 在多區域或全球雲端部署中運作。如果企業必須遵守特定區域或國家/地區的資料居住地法規，且主要雲端服務供應商在該地區沒有雲端區域，則需要從該地區的可用雲端服務供應商中選擇。

透過分區多雲架構模式，您可以視需要保有移轉工作負載的功能，在必要時將工作負載從原本的公用雲端環境移轉到另一個環境。在這種情況下，工作負載的可攜性就變成了關鍵性的必要條件。當您將工作負載部署至多個運算環境，並且想要保有在不同環境之間移轉工作負載的功能時，就必須去除這些環境之間的差異。使用 GKE Enterprise 時，您可以設計及建構解決方案，透過一致的管理、作業和安全防護機制，解決多雲環境的複雜問題。詳情請參閱 GKE 多雲。

如前所述，在某些情況下，您可能基於商業和技術層面的原因，將 Google Cloud 與其他雲端服務供應商結合，並在這些雲端環境中劃分工作負載。多雲端解決方案可讓您在多雲端環境中靈活地遷移、建構及最佳化應用程式的可攜性，同時將受制於單一廠商的情況降至最低，並協助您遵守法規要求。舉例來說，您可以連線至 Oracle 雲端基礎架構 (OCI)，藉由使用私人 Cloud Interconnect 連線，結合在 OCI 中執行的元件，以及在 Google Cloud上執行的資源，建構多雲端解決方案，善用各個平台的功能。 Google Cloud 詳情請參閱「Google Cloud 和 Oracle 雲端基礎架構 - 充分發揮多雲端的優勢」。此外，Cross-Cloud Interconnect 可在 Google Cloud 與其他支援的雲端服務供應商之間提供高頻寬專用連線，讓您建構及建立多雲端解決方案，以處理大量的雲端間流量。

優點

雖然使用多雲架構可帶來多項業務和技術優點，但如驅動因子、考量事項、策略和方法所述，您必須對每項潛在優點進行詳細的可行性評估。評估時，請仔細考量任何相關的直接或間接挑戰或潛在的阻礙，以及您有效解決這些問題的能力。此外，請考量應用程式或服務的長期成長可能會帶來複雜性，而這可能會超過最初的好處。

以下是分區多雲架構模式的一些重要優點：

• 如果您可能需要盡量減少對單一雲端服務供應商的承諾，可以將應用程式分散至多個雲端服務供應商。因此，您可以透過雲端服務供應商 (在某種程度上) 變更方案，相對減少供應商鎖定。開放式雲端可將 Google Cloud GKE Enterprise 等功能部署在不同的實體位置。擴充 Google Cloud 功能，可在內部、多個公用雲端和邊緣環境中提供彈性、靈活性，並推動轉型。

• 基於法規考量，您可以針對尚未供應雲端地區的國家/地區，提供特定的使用者與資料市場區隔。 Google Cloud

• 在主要雲端服務供應商沒有雲端區域或服務據點的地區，分割多雲端架構模式有助於降低延遲時間，並改善整體使用者體驗品質。這個模式在使用高容量、低延遲的多雲連線時特別實用，例如跨雲互連網路和CDN Interconnect 搭配分散式 CDN。

• 您可在多個雲端服務供應商間部署應用程式，這樣就能選擇各供應商提供的最佳服務。

• 分割多雲架構模式有助於簡化及加速合併與收購情境，因為兩家企業的應用程式和服務可能會託管在不同的公用雲環境中。

最佳做法

• 請先部署非關鍵工作負載。在次要雲端中進行的初始部署作業，可做為日後部署或遷移作業的模式。不過，如果特定工作負載在法律或法規上必須位於特定雲端區域，而主要雲端供應商在所需地區並未設有區域，這項做法可能就不適用。
• 將在不同公用雲端環境執行的系統之間的依附元件減至最少，尤其是在同步處理通訊時。這些依附元件會降低效能、降低整體可用性，並可能產生額外的資料傳輸費用。
• 如要去除不同環境之間的差異，請考慮在應用程式支援且可行的情況下使用容器和 Kubernetes。
• 確保雲端環境間採用一致的持續整合/持續推送軟體更新管道及用於部署和監控的工具。
• 請選取最適合的網路架構模式，為您使用的應用程式提供最有效率且有效的通訊解決方案。
  • 通訊必須精細且受控。使用安全的 API 公開應用程式元件。
  • 請根據您的特定業務和技術需求，考慮使用網狀架構模式或閘道網路模式。
• 為了滿足可用性和效能預期，請設計端對端高可用性 (HA)、低延遲和適當的總處理量等級。

• 為保護機密資訊，建議您對所有傳輸中的通訊內容進行加密。

  • 如果連線層需要加密，您可以根據所選的混合式連線解決方案，選擇各種選項。這些選項包括 VPN 隧道、採用 Cloud Interconnect 的高可用性 VPN，以及Cross-Cloud Interconnect 的 MACsec。

• 如果您使用多個 CDN 作為多雲分割架構模式的一部分，並且要用來自 Google Cloud的大量資料檔案填入其他 CDN，建議您考慮使用 CDN Interconnect 連結，連結 Google Cloud 和支援的供應商，以便最佳化這類流量，並可能降低成本。

• 在環境之間延伸身分管理解決方案，讓系統能夠跨越環境界線以安全的方式進行驗證。

• 如要有效地在 Google Cloud 和其他雲端平台之間平衡要求，您可以使用 Cloud Load Balancing。如需更多資訊，請參閱「將流量轉送至內部部署位置或其他雲端」。

  • 如果從 Google Cloud傳往其他環境的資料傳輸量很高，建議您使用跨雲互連網路。

• 為克服不同後端的通訊協定、API 和驗證機制不一致的問題，建議您在適用情況下，將 API 閘道或 Proxy 部署為統一的外觀。這個閘道或 Proxy 會做為集中式控制點，執行下列措施：

  • 導入額外安全措施。
  • 保護用戶端應用程式和其他服務，不受後端程式碼變更的影響。
  • 協助稽核追蹤，針對所有跨環境應用程式與其解耦元件之間的通訊進行稽核。
  • 做為舊版和現代化服務之間的中介通訊層。
    • Apigee 和 Apigee hybrid 可讓您在內部部署環境、邊緣、其他雲端和Google Cloud 環境中代管及管理企業級和混合式閘道。

• 在下列部分情況下，使用搭配 API Gateway 的 Cloud Load Balancing 可提供可靠且安全的解決方案，在多個區域中大規模管理、保護及分發 API 流量：

  • 為位於不同區域的 Apigee API 執行階段部署多區域容錯機制。

  • 使用 Cloud CDN 提升效能。

  • 透過 Google Cloud Armor 提供 WAF 和 DDoS 防護機制。

• 盡可能在各個雲端環境中使用一致的記錄和監控工具。您可以考慮使用開放原始碼監控系統。詳情請參閱混合雲和多雲端的監控及記錄模式。

• 如果您以分散方式部署應用程式元件，也就是將單一應用程式的元件部署至多個雲端環境，請參閱分層混合型架構模式的最佳做法。

數據分析混合式雲端與多雲端模式

這份文件說明，混合式雲端與多雲端分析模式的目標是善用交易和分析工作負載之間的分工。

在企業系統中，大多數的工作負載可以分成下列各類型：

• 「交易」工作負載，包括互動式應用程式，例如銷售、財務處理、企業資源規劃或通訊。
• 「分析」工作負載，包括轉換、分析、修正或以視覺化方式呈現資料，來輔助決策程序。

分析系統可透過查詢 API 或存取資料庫來從交易系統取得資料。在大多數企業中，分析與交易系統往往是彼此隔開並以鬆散的方式組合在一起。「分析混合/多雲端」模式的目標是在兩種不同的運算環境中執行交易和分析工作負載，以善加利用這個現有的分組。系統會先從私人運算環境中執行的工作負載擷取原始資料，然後將原始資料載入至Google Cloud，用於分析處理。接著，某些結果可能會傳回交易系統中。

下圖顯示潛在資料管道，說明概念上可行的架構。每個路徑/箭頭代表可能的資料移轉和轉換管道選項，可根據可用的ETL 或 ELT 進行，具體取決於可用的資料品質和指定用途。

如要將資料移入 Google Cloud 並從中獲得價值，請使用資料移轉服務，這是一套完整的資料攝入、整合和複製服務。

如上圖所示， Google Cloud 與地端部署環境和其他雲端環境連線後，就能執行各種資料分析用途，例如資料串流和資料庫備份。為了支援需要大量資料傳輸的混合型和多雲分析模式的基本傳輸作業，Cloud Interconnect 和 Cross-Cloud Interconnect 會提供專屬連線，連線至內部部署和其他雲端服務供應商。

優點

以下是在雲端中執行分析工作負載的多項重要優點：

• 輸入流量：將資料從私人運算環境或其他雲端服務移動到Google Cloud時，可能免費。
• 分析工作負載通常需要處理大量資料，而且可能暴增，因此尤其適合部署在公用雲端環境中。透過動態調度運算資源，即可迅速處理大型資料集，同時避免預先投資或超額佈建運算設備的必要。
• Google Cloud 提供一套豐富的服務，讓您在資料的整個生命週期中都能妥善管理資料，包括一開始的取得，經過處理與分析，一直到最終的視覺化。
  • Google Cloud 上的資料移動服務提供完整的產品組合，可透過不同方式順暢地移動、整合及轉換資料。
  • Cloud Storage 非常適合建構資料湖泊。

• Google Cloud 可協助您翻新及最佳化資料平台，以打破資料孤島。使用資料湖倉有助於在不同儲存格式之間實現標準化。資料湖倉也能提供彈性、擴充性和靈活性，確保資料能為貴公司創造價值，而非效率低落。詳情請參閱 BigLake。

• BigQuery Omni 提供運算能力，可在 AWS 或 Azure 的儲存空間中執行本機運算作業。這項功能還可協助您查詢儲存在 Amazon Simple Storage Service (Amazon S3) 或 Azure Blob Storage 中的資料。這項多雲端分析功能可讓資料團隊打破資料孤島。如要進一步瞭解如何查詢儲存在 BigQuery 外部的資料，請參閱「外部資料來源簡介」。

最佳做法

如要實作分析混合式雲端和多雲端架構模式，請考慮採用下列一般最佳做法：

• 使用轉換網路模式啟用資料擷取。如果需要將分析結果傳回交易系統，您可以結合轉換和閘道式輸出模式。
• 使用 Pub/Sub 佇列或 Cloud Storage 值區，將資料從私人運算環境中執行的交易系統轉移至 Google Cloud 。那麼這些佇列或值區就可以做為資料處理管道和工作負載的來源。
• 如要部署 ETL 和 ELT 資料管道，請根據特定用途需求考慮使用 Cloud Data Fusion 或 Dataflow。這兩項服務都是全代管的雲端優先資料處理服務，可用於建構及管理資料管道。
• 如要找出、分類及保護寶貴的資料資產，建議您使用 Google Cloud Sensitive Data Protection 功能，例如去識別化技術。這些技術可讓您在適用且符合規定的情況下，使用隨機產生或預先決定的金鑰遮蔽、加密及取代個人識別資訊 (PII) 等機密資料。

• 當您執行從私人運算環境到 Google Cloud的初始資料移轉作業時，請選擇最適合您的資料集大小和可用頻寬的移轉方法。詳情請參閱「遷移至 Google Cloud：轉移大型資料集」一文。

• 如果需要長期在 Google Cloud 和其他雲端之間傳輸或交換大量流量資料，建議您評估使用 Google Cloud Cross-Cloud Interconnect，以便在Google Cloud 和其他雲端服務供應商之間建立高頻寬專屬連線 (適用於特定地點)。

• 如果連線層需要加密，您可以根據所選的混合式連線解決方案，選擇各種選項。這些選項包括 VPN 通道、採用 Cloud Interconnect 的高可用性 VPN 和 Cross-Cloud Interconnect 的 MACsec。

• 在環境間使用一致的工具和程序。在分析混合情境中，雖然這個做法並非必要條件，但可協助提高作業效率。

Edge 混合模式

在雲端中執行的工作負載會要求用戶端在某些情況下具有快速且穩定的網際網路連線能力。倘若是現今的網路，這項需求很少對採用的雲端技術造成挑戰。不過，在某些情境下，您無法仰賴持續連線，例如：

• 海上船隻和其他車輛可能只能間歇地連線，或只能存取高延遲的衛星連結。
• 工廠或發電廠可能會連線至網際網路。這些設施可能有超過網路供應商可用性聲明的可靠性需求。
• 零售商店和超市可能只會偶爾連線，或使用的連結不提供處理重要業務交易需要的可靠性或總處理量。

「邊緣混合」架構模式會在網路邊緣從本機執行與時間和業務息息相關的工作負載，以處理這些挑戰，並同時將雲端用於所有其他類型的工作負載。在邊緣混合架構中，網際網路連結是用於管理用途的一般元件，且經常非同步地用來同步處理或上傳資料，但並非用於與時間或業務息息相關的交易。

優點

在邊緣執行某些工作負載，並在雲端中執行其他工作負載，可提供下列多項優點：

• 輸入流量 (將資料從邊緣移動到Google Cloud) 可能免付費。
• 在邊緣執行與時間和業務息息相關的工作負載，可協助確保低延遲和自給自足的情況。如果網際網路連線中斷或暫時無法使用，您仍可執行所有重要交易。同時，您可因將雲端用於大部分的工作負載而受益。
• 您可在運算和儲存設備中重複使用現有的投資。
• 過了一段時間之後，可透過漸進方式，無論是修改某些應用程式，或是讓一些邊緣位置具備更可靠的網際網路連結，以減少在邊緣執行的部分工作負載，並將其移至雲端。
• 物聯網 (IoT) 相關專案可在本機執行資料運算，提高成本效益。這可讓企業在邊緣執行及處理部分服務，更靠近資料來源。這項功能還可讓企業選擇性地將資料傳送至雲端，有助於降低 IoT 解決方案的容量、資料傳輸、處理和整體成本。
• 邊緣運算可做為舊版和現代化服務之間的中介通訊層。舉例來說，可能會執行容器化 API 閘道 (例如 Apigee hybrid) 的服務。這可讓舊版應用程式和系統與 IoT 解決方案等現代化服務整合。

最佳做法

實作邊緣混合架構模式時，請考慮採用下列建議：

• 如果通訊為單向，請使用閘道式輸入模式。
• 如果通訊是雙向，請考慮採用閘道式輸出和閘道式輸入模式。
• 如果解決方案包含許多邊緣遠端網站，透過公用網際網路連線至Google Cloud ，您可以使用軟體定義 WAN (SD-WAN) 解決方案。您也可以搭配Network Connectivity Center 使用Google Cloud 合作夥伴支援的第三方 SD-WAN 路由器，簡化大規模安全連線的佈建及管理作業。
• 盡可能減少在邊緣執行的系統與在雲端環境執行的系統之間的依附元件。每個依附元件都會減損邊緣混合設定的可靠性和低延遲優點。
• 如要有效率地管理和運作多個邊緣位置，請在雲端中設立集中式管理層和監控解決方案。
• 確保雲端和邊緣環境間採用一致的持續整合/持續推送軟體更新管道與用於部署和監控的工具。
• 在適用且可行的情況下，請考慮使用容器和 Kubernetes，以便抽取各種邊緣位置間的差異，以及邊緣位置和雲端間的差異。由於 Kubernetes 提供通用的執行階段層，因此您可以在運算環境間一致地開發、執行及管理工作負載。您也可以在邊緣和雲端之間移動工作負載。
  • 如要簡化混合型設定和運作，您可以使用 GKE Enterprise 架構 (如果在各環境中使用容器)。請考量可能的連線選項，以便將在內部部署或邊緣環境中執行的 GKE Enterprise 叢集連線至 Google Cloud。
• 在這種模式下，雖然部分 GKE Enterprise 元件可能會在Google Cloud的連線暫時中斷期間持續運作，但請勿在 GKE Enterprise 與 Google Cloud 的連線中斷時，將其用作正常工作模式。詳情請參閱「暫時中斷與 Google Cloud的連線會造成的影響」。
• 為克服不同後端和邊緣服務的通訊協定、API 和驗證機制不一致的問題，建議您在適用情況下，部署 API 閘道或 Proxy 做為統一的外觀。這個閘道或 Proxy 會做為集中式控制點，執行下列措施：
  • 導入額外安全措施。
  • 保護用戶端應用程式和其他服務，不受後端程式碼變更的影響。
  • 協助稽核追蹤，針對所有跨環境應用程式與其解耦元件之間的通訊進行稽核。
  • 做為舊版和現代化服務之間的中介通訊層。
    • Apigee 和 Apigee Hybrid 可讓您在內部部署環境、邊緣、其他雲端和Google Cloud 環境中代管及管理企業級和混合式閘道。
• 在環境之間建立通用身分識別，讓系統能夠跨越環境界線以安全的方式進行驗證。
• 由於環境之間交換的資料可能是機密資料，請使用 VPN 通道、TLS 或同時使用這兩者，確保所有通訊在傳輸期間都經過加密。

環境混合模式

採用環境混合模式架構模式，可將工作負載的實際工作環境保留在現有的資料中心。然後將公開雲用於開發和測試環境，或其他環境。這個模式仰賴在多個運算環境中備援部署相同的應用程式。部署目的是協助提高容量、靈活性和復原能力。

評估要遷移哪些工作負載時，您可能會發現在公用雲端執行特定應用程式的情況存有困難：

• 管轄區或法規限制可能會要求您將資料保存在特定國家。
• 第三方授權條款可能會禁止您在雲端環境中執行某些軟體。
• 應用程式可能會要求只能在本機使用的硬體裝置存取權。

在這種情況下，請同時考量實際工作環境與應用程式生命週期內涉及的所有環境，包括開發、測試及暫存系統。這些限制通常適用於實際工作環境及其資料。但可能不適用於不使用實際資料的其他環境。請洽詢貴機構的法規遵循部門或同等團隊。

下圖顯示典型的環境混合架構模式：

在不同於實際工作環境系統的環境中執行開發與測試系統似乎是冒險的做法，而且可能會偏離現有的最佳做法，或嘗試盡可能縮小這類環境之間的差異。雖然這類考量是合理的，但如果您區隔開發與測試程序的各個階段，則不適用。

雖然每個應用程式的開發、測試和部署程序互不相同，通常包含下列階段的變化：

• 開發：建立候選版本。
• 功能測試或使用者接受度測試：確認候選版本符合功能性需求。
• 效能與可靠性測試：確認候選版本符合非功能性需求。這也稱為負載測試。
• 暫存或部署測試：確認部署程序是否有效。
• 正式版：發布新版或更新版應用程式。

在單一環境中同時執行上述多個階段幾乎是不切實際的，因此每個階段通常需要一或多個專屬環境。

測試環境的主要用途在於執行功能性測試。暫存環境的主要用途在於測試應用程式部署程序是否如預期般運作。等到版本到達暫存環境時，功能性測試應該已經完成。在將軟體部署到正式環境之前，您必須先進行這項最後步驟。

為了確保測試結果有意義且可套用到實際工作環境部署，您在整個應用程式的生命週期內使用的環境組合必須盡可能符合下列規則：

• 所有環境都具有「功能相等性」。也就是說，架構、API 以及作業系統版本和程式庫都是相等的，而且環境間的系統都有相同的運作方式。這樣的相等性可避免發生應用程式可在某個環境運作但卻在其他環境失敗的情況，或無法重現瑕疵的情況。
• 用於效能與可靠性測試、暫存及實際工作的環境具有非功能相等性。也就是說，其效能、規模及設定，以及運作和維護方式都是相同的，或只在某些細微的方面有所不同。否則，效能與暫存測試就會變得沒有意義。

一般來說，用於開發和功能性測試的環境可以與其他環境有非功能性的差異。

如下圖所示，測試和開發環境都是建構在 Google Cloud上。在 Google Cloud中，您可以使用 Cloud SQL 等代管資料庫來開發及測試。開發和測試作業可在內部部署環境中使用相同的資料庫引擎和版本，或是功能上等同的版本，或是在測試階段後於實際工作環境中推出的新版本。不過，由於這兩個環境的基礎架構不盡相同，因此這種效能負載測試方法並不適用。

下列情況很適合環境混合模式：

• 在適用且可行的情況下，仰賴 Kubernetes 做為通用執行階段層，以達到在所有環境間具有功能相等性。Google Kubernetes Engine (GKE) Enterprise 版可做為這項做法的重要技術。
  • 確保工作負載可攜性，並抽取運算環境之間的差異。透過零信任服務網格，您可以控制並維持不同環境之間所需的通訊隔離。
• 在公用雲端中執行開發和功能測試環境。這些環境與其餘環境具有功能相等性，但可能在效能等非功能層面有所不同。上述概念如下圖所示。
• 在私人運算環境中執行用於實際運作、暫存及效能 (負載測試) 和可靠性測試的環境，確保功能和非功能的相等性。

設計考量

• 業務需求：每種應用程式部署和發布策略都有各自的優缺點。為確保所選方法符合您的特定需求，請先徹底評估業務需求和限制，再做出選擇。
• 環境差異：在這個模式中，使用雲端環境的主要目的是用於開發和測試。最終狀態是在私人內部環境 (實際工作環境) 中代管測試應用程式。為避免開發和測試的功能在雲端環境中運作正常，但在實際環境 (內部部署環境) 中失敗，技術團隊必須瞭解這兩種環境的架構和功能。這包括對其他應用程式和硬體基礎架構的依附元件，例如執行流量檢查的安全系統。
• 治理：如要控管貴公司在雲端開發的內容，以及可用於測試的資料，請使用核准和治理程序。這個程序還可協助貴公司確保在開發和測試環境中，不會使用內部部署實際工作環境中不存在的任何雲端功能。
• 成功條件：必須有明確、預先定義且可衡量的測試成功條件，且符合貴機構的軟體品質保證標準。將這些標準套用至您開發和測試的任何應用程式。
• 備援功能：雖然開發和測試環境不像實際工作環境需要那麼高的可靠性，但仍需要備援功能，以及測試不同失敗情境的能力。您的失敗情境需求可能會促使設計納入備援機制，做為開發和測試環境的一部分。

優點

在公用雲端中執行開發和功能測試工作負載可提供下列多項優點：

• 您可以在需要的時候自動啟動及停止環境。舉例來說，您可以為每個修訂或提取要求佈建整個環境，允許執行測試，然後再次關閉。這項做法也有下列優點：
  • 您可以在虛擬機器 (VM) 非活動狀態時停止執行個體，或僅於需要時佈建環境，藉此減少費用。
  • 您可以為每個拉取要求啟動暫時性環境，加快開發和測試作業。這樣做也能減少維護負擔，並減少建構環境中的不一致性。
• 在公用雲端中執行這些環境可協助您培養對雲端和相關工具的熟悉度及安心感，這可能也有助於遷移其他工作負載。如果您決定使用容器和 Kubernetes 探索工作負載可攜性，這種做法就特別實用，例如在各個環境中使用 GKE Enterprise。

最佳做法

如要成功實作環境混合架構模式，請考慮採用下列建議：

• 定義應用程式通訊需求，包括最佳網路和安全性設計。接著，請使用鏡像網路模式來設計網路架構，避免不同環境的系統直接通訊。如果需要在不同環境之間進行通訊，則必須以受控方式進行。

• 您選擇的應用程式部署和測試策略應與業務目標和需求一致。這可能包括在未停機的情況下推出變更，或是在更廣泛發布前，逐步在特定環境或使用者群組中實作功能。

• 為了讓工作負載可以移轉到他處，並抽取出環境之間的差異，您可以使用容器和 Kubernetes。詳情請參閱 GKE Enterprise 混合式環境參考架構。

• 建立可在各個運算環境間使用的通用工具鍊，用於部署、設定和管理工作負載。使用 Kubernetes 可為您帶來這樣的一致性。

• 確保運算環境間採用一致的持續整合/持續推送軟體更新管道，並在這些環境中部署相同的二進位檔、套件或容器。

• 使用 Kubernetes 時，請使用 Tekton 等持續整合系統來實作部署管道，部署至叢集並在各個環境間使用。詳情請參閱「 Google Cloud上的開發運作解決方案」。

• 為協助您持續發布安全可靠的應用程式，請將安全性納入 DevOps 流程 (開發安全性運作) 的必要元素。如需更多資訊，請參閱「使用 Dev(Sec)Ops Toolkit 在短短一小時內打造並保護面向網際網路的應用程式」。

• 將相同的工具用於 Google Cloud與現有雲端環境間的記錄和監控。請考慮使用開放原始碼監控系統。詳情請參閱混合雲和多雲端的監控及記錄模式。

• 如果測試和實際工作環境的工作負載是由不同的團隊管理，使用不同的工具也許是可接受的做法。不過，使用相同工具搭配不同的檢視權限，有助於減少訓練工作和複雜度。

• 選擇資料庫、儲存空間及訊息傳遞服務進行功能測試時，請使用在 Google Cloud上具有代管對應項目的產品。仰賴代管服務可協助減少維護開發和測試環境的管理工作。

• 為保護機密資訊，建議您將傳輸中的所有通訊加密。如果連線層需要加密，您可以根據所選的混合式連線解決方案，選擇各種選項。這些選項包括 VPN 隧道、採用 Cloud Interconnect 的高可用性 VPN，以及 Cloud Interconnect 的 MACsec。

下表顯示哪些 Google Cloud 產品與常見 OSS 產品相容。

OSS 產品	與 Google Cloud 產品相容
Apache HBase	Bigtable
Apache Beam	Dataflow
CDAP	Cloud Data Fusion
Apache Hadoop	Dataproc
MySQL、PostgreSQL	Cloud SQL
Redis 叢集、Redis、Memcached	Memorystore
網路檔案系統 (NFS)	Filestore
JMS、Kafka	Pub/Sub
Kubernetes	GKE Enterprise

業務持續性混合式雲端和多雲端模式

考量關鍵任務系統的業務持續性的主要原因，是為了協助機構在故障事件發生時和之後，維持彈性並繼續業務營運。您可以將系統和資料複製到多個地理區域，並避免單一故障點，盡可能降低影響當地基礎架構的天災風險。其他失敗情況包括嚴重的系統故障、網路安全攻擊，甚至是系統設定錯誤。

為了確保業務持續性，您必須將系統最佳化，以便在發生故障時能繼續運作。系統可靠性會受到多項因素影響，包括但不限於效能、彈性、正常運作時間、安全性和使用者體驗。如要進一步瞭解如何在Google Cloud上建構及操作可靠的服務，請參閱Google Cloud 良好架構架構的可靠性支柱，以及 Google Cloud的可靠性構成要素。

這個架構模式仰賴多個運算環境間的應用程式備援部署。在這個模式中，您會在多個運算環境中部署相同的應用程式，以提高可靠性。業務持續性可定義為組織在發生中斷事件後，能以預先定義的接受程度持續執行重要業務功能或服務的能力。

災難復原 (DR) 被認為是業務持續性計畫的一部分，明確著重於確保支援重要業務功能的 IT 系統在發生中斷事件後能盡快恢復正常運作。一般來說，災難復原策略和計畫通常有助於制定更廣泛的業務持續性策略。從技術角度來說，當您開始制定災難復原策略時，業務影響分析應定義兩個重要指標：復原點目標 (RPO) 和復原時間目標 (RTO)。如要進一步瞭解如何使用 Google Cloud 解決災難復原問題，請參閱災難復原規劃指南。

RPO 和 RTO 目標值愈小，服務就能愈快從中斷事件中復原，且資料損失量也愈少。不過，這表示需要建立備援系統，因此成本會更高。備援系統可在發生失敗事件後，以相同規模執行近乎即時的資料複製作業，但會增加複雜度、管理額外負擔和成本。

選擇DR 策略 或模式時，應以業務影響分析為依據。舉例來說，金融服務機構即使停機幾分鐘，所造成的財務損失可能遠超過導入 DR 系統的成本。不過，其他產業的企業可能會持續停機數小時，但不會對業務造成重大影響。

在內部部署資料中心執行關鍵任務系統時，DR 的一種做法是在位於不同地區的第二個資料中心維護待命系統。不過，更符合成本效益的做法是將以公用雲端為基礎的運算環境用於容錯移轉。這種做法是業務持續性混合模式的主要驅動力。從成本的角度來看，雲端服務特別吸引人，因為您可以在 DR 基礎架構未使用時將其關閉。為了實現成本較低的 DR 解決方案，雲端解決方案可讓企業接受 RPO 和 RTO 值的潛在增加。

上圖說明如何將雲端做為備援或災難復原環境，用於內部部署環境。

這個模式的較不常見 (很少需要) 的子類為「業務持續性多雲端」模式。在這個模式中，實際工作環境會使用一個雲端服務供應商，而 DR 環境會使用另一個雲端服務供應商。您可以將工作負載複本部署至多個雲端服務供應商，提高的可用性勝過多地區部署提供的可用性。

評估跨多個雲端的 DR 與使用單一雲端服務供應商的不同區域，需要徹底分析多項考量因素，包括：

• 易管理性
• 安全性
• 整體可行性。
• 費用
  • 在持續進行雲端間通訊的情況下，來自多個雲端供應商的潛在傳出資料移轉費用可能會相當昂貴。
  • 複製資料庫時，可能會產生大量流量。
  • 總擁有成本 (TCO) 和管理跨雲網路基礎架構的成本。

如果您的資料必須留在您所在國家/地區，才能符合法規要求，則可以使用位於您所在國家/地區的第二家雲端供應商做為 DR。使用第二個雲端服務供應商的做法假設無法使用內部部署環境建構混合式設定。為避免重新建構雲端解決方案，建議您選擇的第二家雲端服務供應商應在區域內提供所有必要的功能和服務。

設計須知

• DR 預期：貴業務想要達成的 RPO 和 RTO 目標，應會影響 DR 架構和建構規劃。
• 解決方案架構：使用這個模式時，您必須複製內部環境的現有功能，才能滿足 DR 預期。因此，您需要評估重新代管、重構或重新架構應用程式的可行性，以便在雲端環境中提供相同 (或更優化) 的功能和效能。
• 設計及建構：在雲端環境中部署企業工作負載時，幾乎都需要先建立登陸區。詳情請參閱「 Google Cloud中的登陸區設計」。

• DR 叫用：在 DR 設計和程序中，請務必考慮下列問題：

  • 什麼會觸發 DR 情況？舉例來說，DR 可能會因為主要網站中的特定功能或系統發生故障而觸發。
  • 如何叫用 DR 環境的容錯移轉機制？這是手動核准程序，還是可以自動化，以便達成低 RTO 目標？
  • 系統故障偵測和通知機制應如何設計，才能根據預期的 RTO 叫用備援機制？
  • 在偵測到失敗後，如何將流量重新導向至 DR 環境？

  透過測試驗證您對這些問題的答案。

• 測試：徹底測試及評估備援至 DR 的異動，確保符合 RPO 和 RTO 預期值。這樣一來，您就能更有信心在需要時叫用 DR。每當程序或技術解決方案有新的變更或更新時，請再次執行測試。

• 團隊技能：除非環境由第三方管理，否則一或多個技術團隊必須具備在雲端環境中建構、運作及排解實際工作負載問題的專業技能。

優點

將 Google Cloud 用於業務持續性可提供下列多項優點：

• 由於 Google Cloud 有許多地區可供選擇，因此您可以使用它將資料備份或複製到同一個大陸內的不同站點。您也可以將資料備份或複製到不同大陸的站點。
• Google Cloud 可將資料儲存在 Cloud Storage 的雙區域或多區域值區中。資料會以備援的形式儲存在至少兩個不同的地理區域。儲存在雙區域和多區域值區中的資料會使用預設複製功能，在各個地理區域中複製。
  • 雙區域值區提供異地備援機制，可支援業務持續性和災難復原計畫。此外，為了加快複製速度並降低 RPO，儲存在雙區域中的物件可選擇在這些區域中使用強化型複製功能。
  • 同樣地，多地區複製功能會在多個地區提供備援機制，將資料儲存在多地區的地理邊界內。
• 提供下列一或多個選項，以降低資本支出和營運費用，建構災難復原機制：
  • 已停止的 VM 執行個體只會產生儲存空間費用，而且比正在執行的 VM 執行個體便宜相當多。因此，您可以將維護冷待命系統的費用降至最低。
  • Google Cloud 採用「用多少付多少」的收費模型，表示您只需要針對實際使用的儲存空間和運算能力付費。
  • 彈性功能 (例如自動調度資源) 可讓您視需要自動擴充或縮減 DR 環境。

舉例來說，下圖顯示在內部部署環境 (實際環境) 中執行的應用程式，該應用程式會使用Google Cloud 上的復原元件，搭配 Compute Engine、Cloud SQL 和 Cloud Load Balancing。在這種情況下，系統會使用虛擬機器為基礎的資料庫或 Google Cloud 管理資料庫 (例如 Cloud SQL) 預先佈建資料庫，以便透過持續資料複製功能加快復原作業。您可以從先前建立的快照啟動 Compute Engine VM，以便在正常運作期間降低成本。在這種設定下，發生失敗事件後，DNS 需要指向 Cloud Load Balancing 外部 IP 位址。

如要讓應用程式在雲端運作，您必須佈建網頁和應用程式 VM。視目標 RTO 等級和公司政策而定，您可以手動或自動完成叫用 DR、在雲端佈建工作負載，以及重新路由流量的整個程序。

如要加快及自動化基礎架構的佈建作業，請考慮以程式碼管理基礎架構。您可以使用持續整合服務 Cloud Build，將 Terraform 資訊清單自動套用至環境。詳情請參閱「使用 Terraform、Cloud Build 和 GitOps 管理基礎架構式程式碼」。

最佳做法

使用業務持續性模式時，請考慮下列最佳做法：

• 建立記載基礎架構以及容錯移轉和復原程序的災難復原計劃。
• 根據業務影響分析結果和所需的 RPO 和 RTO 目標，考慮採取下列行動：
  • 決定是否將資料備份到 Google Cloud 即可，或是需要考慮其他 DR 策略 (冷、暖或熱待命系統)。
  • 定義可做為 DR 計畫構成要素的服務和產品。
  • 在所選 DR 策略中，為應用程式和資料建立適用的 DR 情境。
• 如果您只備份資料，建議使用轉換模式。否則，網狀模式可能是複製現有環境網路架構的好選擇。
• 盡可能減少在不同環境中執行的系統之間的依附元件，尤其是在同步處理通訊時。這些依附元件會降低效能及整體可用性。

• 避免核心分裂問題。如果您在環境間雙向複製資料，可能會遇到核心分裂問題。當兩個環境以雙向方式複製資料，但彼此之間的通訊中斷時，就會發生核心分裂問題。這種分割方式可能會導致兩個環境中的系統斷定另一個環境無法使用，且它們擁有資料的專屬存取權。這可能會導致資料發生衝突的修改。有兩種常見方法可以避免分割腦問題：

  • 使用第三方運算環境。這個環境可讓系統在修改資料前檢查群數。

  • 允許產生衝突的資料修改在連線復原後進行調解。

    在 SQL 資料庫中，您可以避免分割腦問題，方法是在用戶端開始使用新的主執行個體之前，讓原始主執行個體無法存取。詳情請參閱「Cloud SQL 資料庫災難復原」一文。

• 確保持續整合/持續推送軟體更新系統和成果存放區不會變成單點故障。當一個環境無法使用時，您仍然必須要能部署新版本或套用設定變更。

• 使用待命系統時，請讓所有工作負載皆可移植。所有工作負載都應可遷移 (在應用程式支援且可行時)，這樣系統才能在環境間保持一致。您可以考慮使用容器和 Kubernetes 來實現這種做法。使用 Google Kubernetes Engine (GKE) Enterprise 版，您就能簡化建構和作業。

• 將待命系統的部署作業整合至 CI/CD 管道。這項整合可協助確保環境間採用一致的應用程式版本和設定。

• 使用合理簡短的存留時間值設定 DNS，確保 DNS 變更能快速套用，這樣一來，萬一發生災難時，您就能將使用者重新轉送至待命系統。

• 選取符合架構和解決方案行為的 DNS 政策和路由政策。此外，您也可以結合多個區域負載平衡器和 DNS 轉送政策，為各種用途 (包括混合式設定) 建立全球負載平衡架構。

• 使用多個 DNS 供應商。使用多個 DNS 供應商時，您可以：

  • 提升應用程式和服務的可用性和彈性。

  • 使用多供應商 DNS 設定，簡化在內部部署環境和雲端環境中具有依附元件的混合應用程式部署或遷移作業。

    Google Cloud 提供以 octoDNS 為基礎的開放原始碼解決方案，協助您設定及操作多個 DNS 供應器的環境。詳情請參閱「使用 Cloud DNS 設定多供應商公用 DNS」。

• 使用待命系統時，請使用負載平衡器建立自動容錯移轉。請注意，負載平衡器硬體可能會發生故障。

• 使用 Cloud Load Balancing 而非硬體負載平衡器，以便在使用這個架構模式時支援某些情境。內部用戶端要求或外部用戶端要求可以根據不同的指標 (例如以權重為準的流量分配) 重新導向至主要環境或 DR 環境。如需更多資訊，請參閱「全域外部應用程式負載平衡器的流量管理總覽」。

• 如果從 Google Cloud 傳往其他環境的資料傳輸量很高，建議您使用 Cloud Interconnect 或跨雲互連網路。Cloud Interconnect 可協助您提升連線效能，並可能降低符合特定條件的傳出資料移轉費用。詳情請參閱「Cloud Interconnect 定價」。

• 建議您在 Google Cloud Marketplace 中使用偏好的合作夥伴解決方案，以便執行符合您需求的資料備份、複製作業和其他任務，包括 RPO 和 RTO 目標。

• 測試及評估 DR 叫用情境，瞭解應用程式從災難事件中復原的難易度，並與目標 RTO 值進行比較。

• 傳輸中資料加密。為保護機密資訊，建議您加密所有傳輸中的通訊內容。如果連線層需要加密，您可以根據所選的混合式連線解決方案，選擇各種選項。這些選項包括 VPN 隧道、採用 Cloud Interconnect 的高可用性 VPN，以及 Cloud Interconnect 的 MACsec。

雲端爆發模式

網際網路應用程式在使用量上可能會有極端的波動。雖然大多數企業應用程式不會面臨這項挑戰，許多企業仍必須處理不同的爆發工作負載：批次或持續整合/持續推送軟體更新工作。

這個架構模式仰賴多個運算環境間的應用程式備援部署。目標是提高容量和/或彈性。

雖然您可超額佈建資源，在以資料中心為基礎的運算環境中配合爆發的工作負載，這種方法可能不符合成本效益。當工作有時效性的限制時，延遲工作是不切實際的做法，但透過批次工作，您可以將其執行項目延長到較長的時間範圍來最佳化使用率。

「雲端爆發」模式的概念是將私人運算環境用於基準負載，並在需要額外的能力時，暫時爆發至雲端。

在上述圖表中，當資料容量在內部私人環境中達到上限時，系統可在需要時從Google Cloud 環境取得額外容量。

這類模式的主要驅動因素是節省成本，以及減少因應規模需求變更所需的時間和工作量。採用這種做法，您只需為處理額外負載時使用的資源付費。也就是說，您不需要過度配置基礎架構。您可以改為利用隨選雲端資源，並根據需求和任何預先定義的指標調整資源。因此，貴公司可能可避免在需求量高的時段發生服務中斷情形。

雲端爆發情境的潛在需求是工作負載可攜性。當您允許將工作負載部署至多個環境時，必須去除不同環境之間的差異。舉例來說，Kubernetes 可讓您在使用不同基礎架構的各種環境中，達到工作負載層級的一致性。詳情請參閱 GKE Enterprise 混合式環境參考架構。

設計須知

雲端爆發模式適用於互動式和批次工作負載。不過，當您處理互動式工作負載時，必須判定如何將要求分散到多個環境：

• 您可以將傳入使用者要求轉送至現有資料中心內執行的負載平衡器，然後讓該負載平衡器將要求分散到本機和雲端資源。

  這個方法需要負載平衡器或在現有資料中心內執行的另一個系統也追蹤雲端中配置的資源。負載平衡器或其他系統也必須啟動自動擴充或縮減資源規模。您可以使用這個方法在低活動量期間停用所有雲端資源。不過，實作追蹤資源的機制可能會超出負載平衡器解決方案的能力，因而增加整體複雜度。

• 您可以使用 Cloud Load Balancing 搭配混合式連線網路端點群組 (NEG) 後端，而非實作追蹤資源的機制。您可以使用這個負載平衡器，將內部用戶端要求或外部用戶端要求，轉送至位於內部和Google Cloud 的後端，並根據不同的指標 (例如以重量為依據的流量分配) 進行轉送。此外，您也可以根據 Google Cloud中工作負載的負載平衡服務規模，調整後端。如需更多資訊，請參閱「全域外部應用程式負載平衡器的流量管理總覽」。

  這種做法還有其他好處，例如可充分運用 Google Cloud Armor 的分散式阻斷服務防護機制、網路應用程式防火牆，以及使用 Cloud CDN 在雲端邊緣快取內容。不過，您需要調整混合式網路連線的大小，才能處理額外的流量。

• 如工作負載可攜性所述，應用程式可在進行最小幅度變更的情況下攜帶至不同的環境，以便達到工作負載一致性，但這並不表示應用程式在兩種環境中的效能一樣好。運算或網路基礎架構的差異，以及與相依服務的距離遠近，通常會決定效能。透過測試，您可以更準確地掌握成效，並瞭解成效預期。

• 您可以使用雲端基礎架構服務，建構可代管應用程式的環境，而無須考量可攜性。在流量在尖峰需求期間重新導向時，請使用下列方法處理用戶端要求：

  • 使用一致的工具監控及管理這兩個環境。
  • 確保工作負載版本一致，且資料來源為最新版本。
  • 當需求增加，且雲端工作負載預期會接受應用程式的用戶端要求時，您可能需要新增自動化功能來佈建雲端環境，並重新導向流量。

• 如果您打算在低需求期間關閉所有 Google Cloud 資源，使用 DNS 轉送政策主要用於流量負載平衡，可能並非最佳做法。這主要是因為：

  • 資源可能需要一些時間才能完成初始化，才能為使用者提供服務。
  • DNS 更新通常會在網際網路上緩慢傳播。

  因此：

  • 即使沒有資源可處理使用者的要求，系統仍可能將使用者轉送至 Cloud 環境。
  • 在 DNS 更新在網際網路上全面生效之前，使用者可能會暫時持續被路由至內部環境。

您可以使用 Cloud DNS 選擇符合解決方案架構和行為的DNS 政策和轉送政策，例如地理位置 DNS 轉送政策。Cloud DNS 也支援內部直通式網路負載平衡器和內部應用程式負載平衡器的健康狀態檢查。在這種情況下，您可以將其納入以此模式為基礎的整體混合 DNS 設定。

在某些情況下，您可以使用 Cloud DNS 將用戶端要求分配給 Google Cloud的健康狀態檢查，例如使用內部應用程式負載平衡器或跨區域內部應用程式負載平衡器時。在這種情況下，Cloud DNS 會檢查內部應用程式負載平衡器的整體健康狀態，而後者會檢查後端執行個體的健康狀態。如需更多資訊，請參閱「管理 DNS 轉送政策和健康狀態檢查」。

您也可以使用 Cloud DNS 水平分割。Cloud DNS 水平分割是一種方法，可針對相同網域名稱的 DNS 查詢來源，設定 DNS 回應或記錄的特定位置或網路。這種做法通常用於滿足應用程式設計提供私人和公開體驗的需求，每種體驗各自具有獨特功能。這項做法也有助於在各環境中分配流量負載。

考量這些因素，雲端爆發模式一般而言比較適合批次工作負載，而非互動式工作負載。

優點

雲端爆發式執行架構模式的主要優點包括：

• 雲端爆發可讓您在資料中心和私人運算環境中重複使用現有的投資。這個重複使用的機制可以是永久的，或是直到現有設備到了替換的期限時才失效，這也是您可能會考慮完整遷移的時間點。
• 您不再需要維護額外的能力來滿足尖峰需求，因此可能可以提高私人運算環境的使用率和成本效益。
• 雲端爆發可讓您適時地執行批次工作，無須超額佈建運算資源。

最佳做法

實作雲端爆發模式時，請考慮採用下列最佳做法：

• 為確保在雲端中執行的工作負載能夠與在內部部署環境中執行的工作負載採用相同的方式存取資源，請使用網狀式模式，並採用最低權限的安全存取原則。如果工作負載設計允許，您可以僅允許從雲端存取內部運算環境，反之亦然。
• 如要盡量減少環境之間的通訊延遲，請挑選地理位置靠近您的私人運算環境的 Google Cloud 區域。詳情請參閱「選擇 Compute Engine 地區的最佳做法」。
• 僅將雲端爆發模式用於批次工作負載時，可將所有 Google Cloud 資源設為私人資源，藉此縮小資安防護網的受攻擊面。禁止外界透過網際網路直接存取這些資源，即使您使用 Google Cloud 外部負載平衡功能提供工作負載的進入點，也一樣。

• 選取符合架構模式和指定解決方案行為的DNS 政策和路由政策。

  • 在這個模式中，您可以永久套用 DNS 政策的設計，或是在尖峰使用期間需要使用其他環境的額外容量時套用。
  • 您可以使用地理位置 DNS 路由政策，為區域負載平衡器提供全域 DNS 端點。這項策略適用於許多地理位置 DNS 路由政策用途，包括在 Google Cloud 區域內部署 Google Cloud 的混合應用程式。

  • 如果您需要為相同的 DNS 查詢提供不同的記錄，可以使用水平分割 DNS，例如來自內部和外部用戶端的查詢。

    詳情請參閱混合式 DNS 適用的參考架構

• 為確保 DNS 變更能快速套用，請設定合理簡短的存留時間值，以便在需要使用雲端環境的額外容量時，將使用者重新導向至待命系統。

• 針對時間上不是很緊急且不會在本機儲存資料的工作，請考慮使用Spot VM 執行個體，這會比一般 VM 執行個體便宜相當多。不過，有個必要條件是，如果 VM 工作遭到先佔，系統必須能夠自動重新啟動工作。

• 在適用情況下，使用容器來移轉工作負載。此外，GKE Enterprise 也是這類設計的關鍵技術。詳情請參閱 GKE Enterprise 混合式環境參考架構。

• 監控從 Google Cloud 傳送至不同運算環境的任何流量。這種流量會有傳出資料移轉費用。

• 如果您打算長期使用此架構，且傳出資料量高，建議您考慮使用 Cloud Interconnect。Cloud Interconnect 可協助您提升連線效能，並可能降低符合特定條件的傳出資料移轉費用。詳情請參閱「Cloud Interconnect 定價」。

• 使用 Cloud Load Balancing 時，請在適用情況下使用其應用程式容量最佳化功能 。這麼做有助於解決全球分散式應用程式可能發生的部分容量問題。

• 在環境之間建立通用身分識別，讓系統能夠跨越環境界線以安全的方式進行驗證，進而驗證使用系統的使用者。

• 為保護機密資訊，強烈建議您對傳輸中的所有通訊進行加密。如果連線層需要加密，您可以根據所選的混合連線解決方案，選擇各種選項。這些選項包括 VPN 隧道、採用 Cloud Interconnect 的高可用性 VPN，以及 Cloud Interconnect 的 MACsec。

混合式雲端和多雲端架構模式：後續發展

• 瞭解如何採用混合式雲端和多雲端架構，以及如何選擇適合的工作負載。
• 進一步瞭解適合所選混合式雲端和多雲端架構模式的網路架構模式。
• 進一步瞭解雲端應用程式的部署原型。
• 瞭解如何使用不同架構設計及部署電子商務網頁應用程式，包括使用 GKE 的微服務型電子商務網頁應用程式，以及以無伺服器 API 為基礎的動態網頁應用程式。