這份文件是該組三份文件中的第二份。本文將探討通用的混合式雲端和多雲端架構模式。並說明這些模式最適合的情境。最後，本文還提供在 Google Cloud中部署這類架構時可採用的最佳做法。
混合式雲端和多雲端架構模式的文件集包含下列部分：
- 建構混合式和多雲端架構： 說明如何規劃策略，使用 Google Cloud建構混合式和多雲端設定。
- 混合式雲端和多雲端架構模式：討論可做為混合式雲端和多雲端策略一部分的常見架構模式 (本文)。
- 混合式雲端和多雲端安全網路架構模式：從網路角度探討混合式雲端和多雲端網路架構模式。
每家企業都有獨特的應用程式工作負載組合，會對混合式雲端或多雲端設定的架構設有相關需求與限制。雖然您必須精心設計並打造出符合這些限制與需求的架構，您仍可仰賴一些常用的模式來定義基礎架構。
架構模式是一種可重複使用的方法，用於建構技術解決方案、應用程式或服務的多個功能元件，以建立可重複使用的解決方案，滿足特定需求或用途。雲端技術解決方案通常由多項分散式雲端服務組成。這些服務會協同運作，提供必要功能。在此情況下，每項服務都視為技術解決方案的功能元件。同樣地，應用程式可以由多個功能層級、模組或服務組成，每個層級、模組或服務都可以代表應用程式架構的功能元件。這類架構可標準化，以解決特定業務應用實例，並做為可重複使用的基礎模式。
如要大致定義應用程式或解決方案的架構模式，請找出並定義下列項目：
- 解決方案或應用程式的元件。
- 每個元件的預期功能，例如提供圖形使用者介面的前端功能，或提供資料存取的後端功能。
- 元件如何彼此通訊，以及如何與外部系統或使用者通訊。在現代應用程式中，這些元件會透過明確定義的介面或 API 互動。通訊模型種類繁多，例如非同步和同步、要求/回應或以佇列為基礎。
混合雲和多雲端架構模式主要分為以下兩類：
- 分散式架構模式： 這類模式仰賴工作負載或應用程式元件的分散式部署。也就是說，他們會在最適合模式的運算環境中執行應用程式 (或該應用程式的特定元件)。這樣一來，模式就能善用分散式互連運算環境的不同屬性和特徵。
- 備援架構模式： 這些模式是以工作負載的備援部署為基礎。在這些模式中，您會在多個運算環境中部署相同的應用程式及其元件，目標是提高應用程式的效能容量或彈性，或是複製現有環境以進行開發和測試。
實作所選架構模式時，您必須使用合適的部署原型。部署原型包括可用區、區域、多區域或全球。這項選擇會成為建構應用程式專屬部署架構的基礎。每個部署原型都會定義一組故障網域，應用程式可在這些網域中運作。這些故障網域可涵蓋一或多個Google Cloud 區域或地區，並可擴充至其他雲端服務供應商的地端部署資料中心或故障網域。
本系列包含下列頁面：
貢獻者
作者：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中，您可以跨單一區域中的多個區域1，或跨多個區域部署應用程式的備援元件，並具備切換功能，藉此提高應用程式的復原能力。冗餘是提高應用程式整體可用性的重要元素之一。對於在混合雲和多雲端環境中分散式設定的應用程式，維持一致的可用性層級非常重要。
如要提升地端環境或其他雲端環境中系統的可用性，請考量應用程式及其元件需要哪些硬體或軟體備援 (搭配容錯移轉機制)。理想情況下，您應考量所有環境中各個元件和支援基礎架構 (包括混合式連線可用性) 的服務或應用程式可用性。這個概念也稱為應用程式或服務的綜合可用性。
視元件或服務之間的依附元件而定，應用程式的綜合可用性可能高於或低於個別服務或元件。詳情請參閱「複合可用性：計算雲端基礎架構的整體可用性」。
如要達到所需的系統可靠性，請定義明確的可靠性指標，並設計應用程式，以便在不同環境中有效自我修復及應對中斷情況。如要瞭解如何適當評估服務的顧客體驗，請參閱「根據使用者體驗目標定義可靠性」。
混合雲與多雲端連線
分散式應用程式元件之間的通訊需求，應會影響您選擇混合式網路連線選項。每種連線選項都有優缺點，以及需要考量的特定因素，例如成本、流量、安全性等。詳情請參閱「連線設計注意事項」一節。
易管理性
無論是否可攜式工作負載，一致且統一的管理和監控工具，都是成功設定混合雲和多雲環境的必要條件。短期內，這些工具可能會增加開發、測試和營運成本。從技術層面來看，採用的雲端服務供應商越多，環境管理就會變得越複雜。大多數的公有雲供應商不僅具備不同的功能/特色，還會提供各種管理雲端服務的工具、服務水準協議和 API。因此，請根據所選架構的策略優勢，權衡短期複雜度與長期效益。
費用
在多雲環境中，每個雲端服務供應商都有自己的帳單指標和工具。為提供更清楚的資訊和統一的資訊主頁，建議使用多雲成本管理和最佳化工具。舉例來說，在多個雲端環境中建構雲端優先解決方案時，各供應商的產品、價格、折扣和管理工具可能會導致這些環境之間的成本不一致。
建議您採用定義明確的單一方法，計算雲端資源的總成本，並提供成本資訊。掌握費用是成本最佳化的必要條件。舉例來說，您可以合併所用雲端服務供應商的帳單資料，並使用 Google Cloud Looker Cloud Cost Management Block，集中查看多雲費用。這個檢視畫面可協助您集中查看多個雲端的支出報表。詳情請參閱「有效最佳化雲端帳單費用管理的策略」。
此外，我們也建議採用 FinOps 做法，讓費用一目瞭然。 在健全的 FinOps 實務中，中央團隊可將資源最佳化決策權委派給專案中的任何其他團隊，以鼓勵個人擔起責任。在這個模型中，中央團隊應標準化成本最佳化程序、報表和工具。如要進一步瞭解應考量的不同成本最佳化層面和建議，請參閱「Google Cloud 架構完善架構：成本最佳化」。
資料遷移
資料移動是混合式和多雲端策略與架構規劃的重要考量因素，特別是分散式系統。企業需要找出不同的業務用途、支援這些用途的資料，以及資料的分類方式 (適用於受監管產業)。此外，他們也應考量環境中分散式系統的資料儲存、共用和存取方式，可能對應用程式效能和資料一致性造成的影響。這些因素可能會影響應用程式和資料管道架構。Google Cloud提供多種資料移動選項，可滿足企業的特定需求，並採用混合式和多雲端架構，同時兼顧簡便性、效率和效能。
安全性
將應用程式遷移至雲端時，請務必考量雲端優先的安全功能，例如一致性、可觀測性及統一的安全可視性。每家公有雲供應商都有自己的安全防護方法、最佳做法和功能。分析並調整這些功能，有助於建構標準且實用的安全架構。此外，嚴格的 IAM 控制項、資料加密、安全漏洞掃描，以及遵守業界法規，也是雲端安全的重要環節。
規劃遷移策略時，建議您分析先前提及的考量事項。隨著應用程式或流量增加，這些模式可協助您盡量避免架構變得複雜。此外，設計及建構登陸區幾乎是將企業工作負載部署至雲端環境的先決條件。登陸區可協助企業在多個領域更安全地部署、使用及擴展雲端服務，並包含身分識別、資源管理、安全性及網路等不同元素。詳情請參閱「 Google Cloud 中的登陸區設計」。
本系列的其他文件說明瞭其他分散式架構模式：
分級混合模式
應用程式的架構元件可分為「前端」或「後端」。在某些情況下，這些元件可以託管在不同的運算環境中運作。在分層混合架構模式中，運算環境位於地端部署的私人運算環境和 Google Cloud。
前端應用程式元件會直接向使用者或裝置公開。因此，這些應用程式通常高度重視效能表現。為開發新功能及改良現有功能，軟體更新頻率可能會較高。由於前端應用程式通常仰賴後端應用程式來儲存及管理資料，以及處理商業邏輯和使用者輸入內容，因此通常為無狀態，或只管理有限的資料量。
如要確保前端應用程式易於存取和使用，您可以運用各種架構和技術建構應用程式。前端應用程式的成功關鍵因素包括應用程式效能、回應速度和瀏覽器相容性。
後端應用程式元件通常專注於儲存及管理資料。在某些架構中，商業邏輯可能會併入後端元件。後端應用程式推出新版本的速度通常不會像前端應用程式那麼頻繁。後端應用程式在管理方面面臨下列挑戰：
- 處理大量要求
- 處理大量資料
- 保護資料安全
- 在所有系統副本中維護最新資料
三層式網頁應用程式解決方案是建構商務網頁應用程式最常見的實作方式之一，例如包含不同應用程式元件的電子商務網站。這個架構包含下列層級。每個層級都是獨立運作，但彼此緊密相連，共同發揮作用。
- 網頁前端和展示層
- 應用程式層
- 資料存取或後端層
將這些層放入容器中，可區隔技術需求 (例如擴充需求)，並協助分階段遷移。此外，您還能將這些應用程式部署至與平台無關的雲端服務，以便在不同環境之間移植、使用自動化管理功能，以及透過雲端管理平台 (例如 Cloud Run 或 Google Kubernetes Engine (GKE) Enterprise 版) 進行擴充。此外，Google Cloud代管資料庫 (例如 Cloud SQL) 可做為資料庫層提供後端服務。
分級混合架構模式的重點是將現有的前端應用程式元件部署至公有雲。在這個模式中，您會將所有現有的後端應用程式元件保留在私人運算環境中。您可以根據應用程式的規模和特定設計，依個案情況遷移前端應用程式元件。詳情請參閱「遷移至 Google Cloud」。
如果您現有的應用程式在內部部署環境中託管後端和前端元件，請考量目前架構的限制。舉例來說，隨著應用程式擴展，對效能和穩定性的要求也會提高，這時您就應開始評估是否要重構應用程式的部分內容，或是移至更合適的架構。「分級混合」架構模式可讓您先將部分應用程式工作負載和元件移至雲端，再進行全面轉換。此外，也請務必考量這類遷移作業的成本、時間和風險。
下圖顯示典型的分層混合架構模式。
在上圖中，用戶端要求會傳送至 Google Cloud中託管的應用程式前端。接著，應用程式前端會將資料傳回應用程式後端所在的內部部署環境 (最好是透過 API 閘道)。
採用分層混合式架構模式時，您可以運用Google Cloud 基礎架構和全球服務，如下圖的範例架構所示。應用程式前端可透過 Google Cloud存取。此外，您也可以使用自動調整資源配置功能，動態且有效率地因應資源調度需求，不必過度佈建基礎架構，為前端增加彈性。您可以使用不同的架構，在 Google Cloud上建構及執行可擴充的網頁應用程式。每種架構各有優缺點，適合不同的需求。
如需更多資訊，請觀看 YouTube 上的「在 Google 上執行可擴充網路應用程式的三種方式 Google Cloud」。如要進一步瞭解在Google Cloud上翻新電子商務平台的各種方式，請參閱「如何在 Google Cloud上建構數位商務平台」。
在上圖中，應用程式前端託管於Google Cloud ，透過全域負載平衡、自動調度資源和 Google Cloud Armor 的 DDoS 防護功能，提供全球最佳化的多區域使用者體驗。
過了一段時間之後，您部署至公用雲端的應用程式數量可能會增加，直到您考慮將後端應用程式元件遷移至公用雲端。如果您預期會處理大量流量，選擇雲端代管服務或許有助於您管理自己的基礎架構，進而節省工程資源。除非限制或需求規定必須在本機代管後端應用程式元件，否則請考慮這個選項。舉例來說，如果您的後端資料受到法規限制，可能需要將該資料保留在內部部署環境。不過，在適用且符合規範的情況下，使用私密資料保護功能 (例如去識別化技術)，有助於在必要時移動這類資料。
在分層混合架構模式中，您也可以在某些情境中使用 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 流量。搭配 API 閘道使用 Cloud Load Balancing 可讓您達成下列目標：
- 使用 Apigee 和 Cloud CDN 提供高效能 API，縮短延遲時間、在全球代管 API，並在流量尖峰季節提高可用性。詳情請觀看 YouTube 上的「透過 Apigee 和 Cloud CDN 提供高效能 API」影片。
- 實作進階流量管理。
- 使用 Cloud Armor 做為 DDoS 防護和網路安全服務，保護您的 API。
- 在多個區域中，有效管理閘道之間的負載平衡。如需更多資訊，請觀看 YouTube 上的「Securing APIs and Implementing multi-region failover with Private Service Connect and Apigee」。
使用 API 管理和服務網格，透過微服務架構保護及控管服務通訊和曝光。
- 使用 Cloud Service Mesh，在由分散式服務組成的系統中，促成服務之間的通訊，並維持服務品質，同時管理服務之間的驗證、授權和加密作業。
- 使用 Apigee 等 API 管理平台，將這些服務以 API 的形式公開，方便貴機構和外部實體使用。
在環境之間建立通用身分識別，讓系統能夠跨越環境界線以安全的方式進行驗證。
在公有雲中部署 CI/CD 和設定管理系統。詳情請參閱鏡像網路架構模式。
為提高作業效率，請在各個環境間使用一致的工具和 CI/CD 管道。
個別工作負載和應用程式架構的最佳做法
- 雖然這個模式的重點在於前端應用程式，但仍請注意對後端應用程式進行現代化的需求。如果後端應用程式的開發步調比前端應用程式慢相當多，這項差異可能會導致額外的複雜情況。
- 將 API 視為後端介面，可簡化整合、前端開發、服務互動，並隱藏後端系統的複雜性。為解決這些挑戰，Apigee 可協助您開發及管理混合式和多雲端部署作業的 API 閘道/Proxy。
- 根據內容 (靜態與動態)、搜尋引擎最佳化成效，以及網頁載入速度的期望，為前端網頁應用程式選擇轉譯方法。
- 為內容導向的網路應用程式選取架構時，有多種選項可供選擇，包括單體式、無伺服器、事件導向和微服務架構。如要選取最合適的架構，請根據目前和未來的應用程式需求，徹底評估這些選項。如要根據業務和技術目標做出架構決策，請參閱內容導向網頁應用程式後端的不同架構比較，以及網頁後端的重要考量事項。
採用微服務架構後，您可以使用容器化應用程式，並以 Kubernetes 做為通用執行階段層。使用分層混合式架構模式，您可以在下列任一情境中執行：
跨雲端和地端環境 (Google Cloud 和您的地端環境)。
- 在不同環境中使用容器和 Kubernetes 時，您可以彈性地將工作負載現代化，然後在不同時間遷移至 Google Cloud 。當工作負載大量取決於另一個工作負載且無法個別遷移時，這會非常有幫助，或者您也可以使用混合式工作負載可攜性，在每個環境中使用最佳資源。在所有情況下，GKE Enterprise 都是重要的啟用技術。詳情請參閱 GKE Enterprise 混合式環境。
在 Google Cloud 遷移及現代化應用程式元件的環境中。
- 如果您的舊版後端位於內部部署環境，且不支援容器化，或短期內需要大量時間和資源才能完成現代化，請使用這種方法。
如要進一步瞭解如何設計單體式應用程式，並重構為微服務架構，以實現網路應用程式架構現代化，請參閱微服務簡介。
您可以根據網路應用程式的需求，合併使用資料儲存技術。使用 Cloud SQL 儲存結構化資料，並使用 Cloud Storage 儲存媒體檔案，是滿足各種資料儲存需求的常見做法。不過，選擇哪種方式主要取決於您的用途。如要進一步瞭解內容導向應用程式後端的資料儲存空間選項和有效模式，請參閱「內容導向網頁應用程式的資料儲存空間選項」。另請參閱「資料庫選項說明」。 Google Cloud
分區多雲端模式
「分區多雲端」架構模式結合由不同雲端服務供應商營運的多個公有雲環境。這個架構可讓您彈性地在最佳運算環境中部署應用程式，並考量本系列第一部分討論的多雲驅動因素和考量事項。
下圖顯示分區多雲端架構模式。
這個架構模式有兩種不同的建構方式。第一種方法是根據在不同公有雲環境中部署應用程式元件。這種方法也稱為「複合式架構」，與「分層混合式架構模式」相同。不過，多雲端環境並非使用公有雲的內部部署環境，而是至少使用兩個雲端環境。在複合式架構中，單一工作負載或應用程式會使用多個雲端的元件。第二種方法是在不同的公有雲環境中部署不同的應用程式。以下列舉部分採用第二種做法的業務驅動因素：
- 在兩家企業合併和收購期間，全面整合不同雲端環境中代管的應用程式。
- 為了提升彈性，並滿足貴機構內不同的雲端偏好。採用這種做法，鼓勵機構單位選擇最符合自身需求和偏好的雲端供應商。
- 在多區域或全球雲端部署環境中運作。如果企業必須遵守特定地區或國家/地區的資料落地法規，且主要雲端服務供應商在該地區沒有雲端區域，則企業必須從該地區的可用雲端服務供應商中選擇。
採用分區多雲端架構模式時，您可以選擇保留移轉工作負載的功能，在必要時將工作負載從原本的公用雲端環境移轉到另一個環境。在這種情況下，工作負載可攜性就變成了關鍵性的必要條件。當您將工作負載部署至多個運算環境，並且想要保有在不同環境之間移轉工作負載的功能時，就必須去除這些環境之間的差異。使用 GKE Enterprise，您可以設計及建構解決方案，透過一致的管理、作業和安全防護機制，解決多雲環境的複雜問題。詳情請參閱「GKE Multi-Cloud」。
如前所述，在某些情況下，基於業務和技術原因，可能需要結合 Google Cloud 其他雲端服務供應商，並在這些雲端環境中劃分工作負載。多雲端解決方案可讓您靈活地遷移、建構及最佳化應用程式，在多雲端環境中輕鬆攜帶應用程式，同時將受制於單一廠商的風險降至最低，並協助您符合法規要求。舉例來說，您可以連線 Google Cloud 至 Oracle Cloud Infrastructure (OCI)，建構多雲端解決方案，善用各平台的獨特功能，透過專屬 Cloud Interconnect 結合在 OCI 中執行的元件，以及在 Google Cloud中執行的資源。詳情請參閱「Google Cloud 和 Oracle Cloud Infrastructure：充分發揮多雲端的優勢」。此外，Cross-Cloud Interconnect 可在 Google Cloud 與其他支援的雲端服務供應商之間建立高頻寬專用連線，方便您設計及建構多雲端解決方案，處理大量雲端間流量。 Google Cloud
優點
如「驅動因素、考量事項、策略和方法」一文所述，採用多雲端架構可帶來多項業務和技術優勢，但務必詳細評估每項潛在優勢的可行性。評估時應仔細考量任何相關的直接或間接挑戰或潛在障礙，以及您有效克服這些問題的能力。此外，請考慮應用程式或服務的長期成長可能會帶來複雜性，而這些複雜性可能超過初始效益。
以下是分區多雲端架構模式的一些重要優點：
在需要盡量避免受限於單一雲端服務供應商的情況下，您可以將應用程式分散於多個雲端服務供應商之間。因此，您可以在雲端服務供應商之間 (在某種程度上) 變更方案，相對減少供應商鎖定。開放式雲端有助於將 GKE Enterprise 等 Google Cloud 功能帶到不同的實體位置。透過擴充 Google Cloud 地端、多個公有雲和邊緣的運算能力，提供彈性、敏捷性，並推動轉型。
基於法規考量，您應針對 Google Cloud 尚未供應雲端區域的國家/地區，提供特定的使用者與資料市場區隔。
分割式多雲架構模式有助於減少延遲，並在主要雲端供應商沒有雲端區域或存在點的位置，提升整體使用者體驗品質。使用高容量和低延遲的多雲連線時，這個模式特別實用，例如搭配分散式 CDN 使用 Cross-Cloud Interconnect 和 CDN Interconnect。
您可在多個雲端服務供應商間部署應用程式，這樣就能選擇各供應商提供的最佳服務。
分割式多重雲端架構模式有助於促進及加速合併與收購情境，因為兩家企業的應用程式和服務可能託管在不同的公有雲環境中。
最佳做法
- 請先部署非任務關鍵型工作負載。次要雲端中的這項初始部署作業，可做為日後部署或遷移作業的模式。不過，如果特定工作負載在法律或法規上必須位於特定雲端區域，且主要雲端供應商在必要地區沒有區域，這種做法可能就不適用。
- 將在不同公用雲端環境執行的系統之間的依附元件減至最少，尤其是在同步處理通訊時。這些依附元件會降低效能、整體可用性，且可能產生額外的輸出資料傳輸費用。
- 如要去除不同環境之間的差異，請考慮在應用程式支援且可行的情況下，使用容器和 Kubernetes。
- 確保雲端環境間採用一致的 CI/CD 管道及用於部署和監控的工具。
- 選取最佳網路架構模式，為您使用的應用程式提供最有效率的通訊解決方案。
- 為達到可用性和效能期望，請設計端對端高可用性 (HA)、低延遲和適當的總處理量等級。
為保護私密資訊，建議您加密所有傳輸中的通訊內容。
- 如果需要在連線層進行加密，您可以根據所選的混合式連線解決方案，使用各種選項。這些選項包括 VPN 通道、採用 Cloud Interconnect 的高可用性 VPN，以及 Cross-Cloud Interconnect 的 MACsec。
如果您使用多個 CDN 做為多雲分割架構模式的一部分，並要用來自 Google Cloud的大量資料檔案填入其他 CDN，建議使用 CDN 互連網路連結 (位於 Google Cloud 和支援的供應商之間)，最佳化這類流量，並可能降低費用。
在環境之間擴充身分管理解決方案，讓系統能夠跨越環境界線以安全的方式進行驗證。
如要有效平衡 Google Cloud 和其他雲端平台之間的要求，可以使用 Cloud Load Balancing。詳情請參閱將流量轉送至內部部署位置或其他雲端。
- 如果從 Google Cloud 其他環境傳出的資料量很高，建議使用 Cross-Cloud Interconnect。
為解決不同後端間通訊協定、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 儲存體中的自有資料。這項多雲端分析功能可協助資料團隊打破資料孤島，如要進一步瞭解如何查詢儲存在 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。
在環境間使用一致的工具和程序。在分析混合情境中，雖然這個做法並非必要條件，但可協助提高作業效率。
邊緣混合模式
在雲端中執行的工作負載會要求用戶端在某些情況下，具有快速且穩定的網際網路連線能力。倘若是現今的網路，這項需求很少對採用的雲端技術造成挑戰。不過，在某些情境下，您無法仰賴持續連線，例如：
- 海運船隻和其他車輛可能只能間歇地連線，或只能存取高延遲的衛星連結。
- 工廠或發電廠可能會連線至網際網路。這些設施可能有超過網際網路供應商可用性聲明的可靠性需求。
- 零售商店和超市可能只會偶爾連線，或使用的連結不提供處理重要業務交易需要的可靠性或總處理量。
「邊緣混合」架構模式會在網路邊緣從本機執行與時間和業務息息相關的工作負載，以處理這些挑戰，並同時將雲端用於所有其他類型的工作負載。在邊緣混合架構中，網際網路連結是用於管理用途的一般元件，且經常非同步地用來同步處理或上傳資料，但並非用於與時間或業務息息相關的交易。
優點
在邊緣或雲端中的其他位置執行某些工作負載可提供下列多項優點：
- 輸入流量 (將資料從邊緣移動到Google Cloud) 可能免付費。
- 在邊緣執行與時間和業務息息相關的工作負載，可協助確保低延遲和自給自足的情況。如果網際網路連線中斷或暫時無法使用，你仍可執行所有重要交易。同時，您可因將雲端用於大部分的工作負載而受益。
- 您可在運算和儲存設備中重複使用現有的投資。
- 過了一段時間之後，可透過漸進方式，無論是修改某些應用程式，或是讓一些邊緣位置具備更可靠的網際網路連結，以減少在邊緣執行的部分工作負載，並將其移至雲端。
- 執行本機資料運算可提高物聯網 (IoT) 相關專案的成本效益。企業可在邊緣執行及處理部分服務，更靠近資料來源。企業也能選擇性地將資料傳送至雲端，有助於減少 IoT 解決方案的容量、資料移轉、處理和整體成本。
- 邊緣運算可做為舊版和現代化服務之間的中介通訊層。舉例來說，服務可能會執行容器化 API 閘道，例如 Apigee Hybrid。這可讓舊版應用程式和系統與現代化服務 (例如 IoT 解決方案) 整合。
最佳做法
實作邊緣混合架構模式時，請考慮採用下列建議：
- 如果通訊為單向，請使用閘道式輸入模式。
- 如果是雙向通訊，請考慮採用閘道式輸出和閘道式輸入模式。
- 如果解決方案包含許多透過公用網際網路連線的邊緣遠端網站，可以使用軟體定義的 WAN (SD-WAN) 解決方案。Google Cloud 您也可以搭配Google Cloud 合作夥伴支援的第三方 SD-WAN 路由器使用 Network Connectivity Center，簡化大規模安全連線的佈建和管理作業。
- 盡可能減少在邊緣執行的系統與在雲端環境執行的系統之間的依附元件。每個依附元件都會減損邊緣混合設定的可靠性和低延遲優點。
- 如要有效率地管理和運作多個邊緣位置，請在雲端中設立集中式的管理層和監控解決方案。
- 確保雲端和邊緣環境間採用一致的持續整合/持續推送軟體更新管道與用於部署和監控的工具。
- 如適用且可行，請考慮使用容器和 Kubernetes，抽取出各種邊緣位置間的差異，以及邊緣位置和雲端間的差異。由於 Kubernetes 提供通用的執行階段層，因此您可以在運算環境間一致地開發、執行及管理工作負載。您也可以在邊緣和雲端之間移動工作負載。
- 如要簡化混合式設定和作業，您可以使用GKE Enterprise 進行這項架構 (如果容器用於不同環境)。請考慮可用的連線選項，將在地端或邊緣環境中執行的 GKE Enterprise 叢集連線至 Google Cloud。
- 在這個模式中，雖然部分 GKE Enterprise 元件可能會在暫時中斷與Google Cloud的連線時維持運作，但請勿在與 Google Cloud 中斷連線時使用 GKE Enterprise，因為這不是正常運作模式。詳情請參閱「暫時中斷與 Google Cloud的連線會造成什麼影響」。
- 為克服各種後端和邊緣服務的通訊協定、API 和驗證機制不一致的問題，建議您視情況部署 API 閘道或 Proxy 做為統一的表面。
這個閘道或 Proxy 會做為集中控制點，並執行下列措施：
- 導入額外的安全措施。
- 保護用戶端應用程式和其他服務，避免受到後端程式碼變更的影響。
- 方便稽核所有跨環境應用程式及其分離式元件之間的通訊。
- 做為舊版和現代化服務之間的中介通訊層。
- Apigee 和 Apigee Hybrid 可讓您在內部部署環境、邊緣、其他雲端和Google Cloud 環境中，代管及管理企業級和混合式閘道。
- 在環境之間建立通用身分識別，讓系統能夠跨越環境界線以安全的方式進行驗證。
- 由於環境之間交換的資料可能是機密資料，請使用 VPN 通道、TLS 或同時使用這兩者，以確保所有通訊在傳輸過程中都經過加密。
環境混合模式
採用環境混合架構模式時，您可以將工作負載的實際工作環境保留在現有資料中心，然後將公有雲用於開發和測試環境，或其他環境。這個模式仰賴多個運算環境間的相同應用程式備援部署。部署目標是協助提高容量、靈活度和韌性。
評估要遷移哪些工作負載時，您可能會發現在公用雲端執行特定應用程式的情況存有困難：
- 管轄區或法規限制可能會要求您將資料保存在特定國家。
- 第三方授權條款可能會禁止您在雲端環境中執行某些軟體。
- 應用程式可能會要求只能在本機使用的硬體裝置存取權。
在這種情況下，請同時考量實際工作環境與應用程式生命週期內涉及的所有環境，包括開發、測試及暫存系統。這些限制通常適用於實際工作環境及其資料。這些規則可能不適用於未使用實際資料的其他環境。請洽詢貴機構的法規遵循部門或同等團隊。
下圖顯示典型的環境混合架構模式：
在不同於實際工作環境系統的環境中執行開發與測試系統似乎是冒險的做法，而且可能與現有的最佳做法或嘗試盡可能縮小環境差異的做法背道而馳。雖然這類考量是合理的，但如果您區隔開發與測試程序的各個階段，則不適用。
雖然每個應用程式的開發、測試和部署程序互不相同，通常包含下列階段的變化：
- 開發：建立候選版本。
- 功能測試或使用者接受度測試：確認候選版本符合功能性需求。
- 效能與可靠性測試：確認候選版本符合非功能性需求。也稱為負載測試。
- 暫存或部署測試：確認部署程序是否有效。
- 正式環境：發布新應用程式或更新應用程式。
在單一環境中同時執行上述多個階段幾乎是不切實際的，因此每個階段通常需要一或多個專屬環境。
測試環境的主要用途在於執行功能測試。暫存環境的主要用途是測試應用程式部署程序是否如預期般運作。等到版本到達暫存環境時，功能性測試應該已經完成。這是將軟體部署到正式版部署環境前的最後一個步驟。
為了確保測試結果有意義且可套用到實際工作環境部署，您在整個應用程式的生命週期內使用的環境組合必須盡可能符合下列規則：
- 所有環境都具有「功能相等性」。也就是說，架構、API 以及作業系統版本和程式庫都是相等的，而且環境間的系統都有相同的運作方式。這樣的相等性可避免發生應用程式可在某個環境運作但卻在其他環境失敗的情況，或無法重現瑕疵的情況。
- 用於效能與可靠性測試、暫存及實際工作的環境具有非功能相等性。也就是說，其效能、規模及設定，以及運作和維護方式都是相同的，或只在某些細微的方面有所不同。否則，效能與暫存測試就會變得沒有意義。
一般來說，用於開發和功能測試的環境可以與其他環境有非功能性的差異。
如下圖所示，測試和開發環境是建構在 Google Cloud上。代管資料庫 (例如 Cloud SQL) 可做為 Google Cloud的開發和測試選項。開發和測試作業可以在地端環境中使用相同的資料庫引擎和版本、功能相同的引擎和版本，或是在測試階段後推出至實際工作環境的新版本。不過，由於這兩個環境的基礎架構並不相同，因此這種效能負載測試方法無效。
下列情況很適合環境混合模式：
- 在適用且可行的情況下，仰賴 Kubernetes 做為通用執行階段層，讓所有環境具備功能相等性。Google Kubernetes Engine (GKE) Enterprise 版是這項做法的關鍵技術。
- 確保工作負載可攜性，並抽取出運算環境之間的差異。透過零信任服務網格，您可以控管及維護不同環境之間所需的通訊隔離。
- 在公用雲端中執行開發和功能測試環境。這些環境與其餘環境具有功能相等性，但可能在效能等非功能層面有所不同。如上圖所示。
- 在私人運算環境中，執行用於正式作業、中繼測試作業及效能 (負載測試) 與可靠性測試的環境，確保功能面和非功能面的相等性。
設計注意事項
- 業務需求：每種應用程式部署和發布策略都有各自的優缺點。為確保所選方法符合特定需求，請根據業務需求和限制進行全面評估，然後再做出選擇。
- 環境差異：這個模式的主要目標是使用雲端環境進行開發和測試。最終狀態是在私有內部部署環境 (實際工作環境) 中代管測試的應用程式。為避免開發及測試功能時，在雲端環境中運作正常，但在生產環境 (內部部署) 中失敗，技術團隊必須瞭解這兩個環境的架構和功能。這包括對其他應用程式和硬體基礎架構的依附元件，例如執行流量檢查的安全系統。
- 控管：如要控管貴公司可在雲端開發的內容，以及可供測試的資料，請使用核准和控管程序。這個程序也能協助貴公司確保開發和測試環境中使用的雲端功能，與內部部署正式環境中的功能一致。
- 成功條件：必須有明確、預先定義且可衡量的測試成功條件，並符合貴機構的軟體品質保證標準。請將這些標準套用至您開發及測試的任何應用程式。
- 備援：雖然開發和測試環境可能不需要像正式環境一樣的可靠性，但仍需要備援功能，以及測試不同失敗情境的能力。失敗情境需求可能會促使設計在開發和測試環境中納入備援機制。
優點
在公用雲端中執行開發和功能測試工作負載可提供下列多項優點：
- 您可以在需要的時候自動啟動及停止環境。舉例來說，您可以為每個修訂或提取要求佈建整個環境，允許執行測試，然後再次將它關閉。這種做法也有以下優點：
- 您可以在虛擬機器 (VM) 閒置時停止執行個體，或僅於需要時佈建環境，藉此減少費用。
- 您可以為每個提取要求啟動暫時性環境，加快開發和測試速度。這樣做也能減少維護負擔，並降低建構環境中的不一致性。
- 在公有雲中執行這些環境，有助於熟悉雲端和相關工具，並建立信心，這可能也有助於遷移其他工作負載。如果您決定使用容器和 Kubernetes 探索工作負載可攜性，例如在各個環境中使用 GKE Enterprise，這個方法就特別實用。
最佳做法
如要成功實作環境混合式架構模式，請考慮採用下列建議：
- 定義應用程式通訊需求，包括最佳網路和安全防護設計。然後使用鏡像網路模式，設計網路架構，避免不同環境的系統直接通訊。如果需要跨環境通訊，則必須以受控方式進行。
您選擇的應用程式部署和測試策略應符合業務目標和需求。這可能包括在不中斷服務的情況下推出變更，或是在廣泛發布前，逐步向特定環境或使用者群組實作功能。
為了讓工作負載可以移轉到他處，並去除不同環境之間的差異，您可能會使用容器和 Kubernetes。詳情請參閱 GKE Enterprise 混合式環境參考架構。
建立可在各個運算環境間使用的通用工具鍊，以部署、設定及管理工作負載。使用 Kubernetes 可為您帶來這樣的一致性。
確保運算環境間採用一致的持續整合/持續推送軟體更新管道，並將同一組二進位檔、套件或容器部署至各種環境。
使用 Kubernetes 時，請使用 Tekton 等持續整合系統來實作部署管道，部署至叢集並在各個環境間使用。詳情請參閱 Google Cloud上的開發運作解決方案。
為協助您持續發布安全可靠的應用程式，請將安全性納入 DevOps 流程 (DevSecOps) 的重要環節。詳情請參閱「使用 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 Well-Architected Framework 的可靠性支柱，以及 Google Cloud中的可靠性建構區塊。
這個架構模式仰賴多個運算環境間的應用程式備援部署。在這個模式中，您會在多個運算環境中部署相同的應用程式，以提高可靠性。業務持續性可定義為：組織在發生中斷事件後，能以預先定義的可接受程度，繼續提供重要業務功能或服務的能力。
災難復原 (DR) 被認為是業務持續性計畫的一部分，明確著重於確保支援重要業務功能的 IT 系統在發生中斷事件後能盡快恢復正常運作。一般來說，災難復原策略和計畫通常有助於制定更廣泛的業務持續性策略。從技術角度來看，開始制定災難復原策略時，業務影響分析應定義兩個重要指標：復原點目標 (RPO) 和復原時間目標 (RTO)。如要進一步瞭解如何使用 Google Cloud 解決災難復原問題，請參閱「災難復原規劃指南」。
RPO 和 RTO 目標值越小，服務從中斷事件復原的速度就越快，資料遺失量也越少。但這表示必須建構備援系統，因此成本較高。如果系統發生故障，能夠以相同規模運作並近乎即時地複製資料的備援系統，會增加複雜度、行政負擔和成本。
選擇 DR 策略 或模式的決策，應以業務影響分析為依據。舉例來說，金融服務機構停機幾分鐘造成的財務損失，可能遠遠超過導入 DR 系統的成本。不過，其他產業的商家可能停機數小時，也不會對業務造成重大影響。
在內部部署資料中心執行關鍵任務系統時，DR 的一種做法是在位於不同地區的第二個資料中心維護待命系統。不過，更符合成本效益的做法是將以公用雲端為基礎的運算環境用於容錯移轉。這種做法是業務持續性混合模式的主要推動因素。從成本角度來看，雲端特別有吸引力，因為您可以在未使用的情況下關閉部分 DR 基礎架構。如要降低災難復原解決方案的成本，企業可透過雲端解決方案接受 RPO 和 RTO 值可能增加的情況。
上圖說明如何將雲端做為容錯移轉或災害復原環境，用於地端環境。
這個模式的較不常見 (很少需要) 的子類為「業務持續性多雲端」模式。在該模式中，實際工作環境會使用一個雲端服務供應商，而 DR 環境會使用另一個雲端服務供應商。您可以將工作負載複本部署至多個雲端服務供應商，提高的可用性勝過多地區部署提供的可用性。
評估跨多個雲端的 DR 與使用單一雲端供應商的不同區域，需要全面分析多項考量因素，包括：
- 易管理性
- 安全性
- 整體可行性。
- 費用
- 如果持續進行跨雲端通訊，您可能需要支付多個雲端服務供應商的資料轉出費用，這筆費用可能相當可觀。
- 複製資料庫時，可能會產生大量流量。
- TCO，以及管理跨雲端網路基礎架構的成本。
如果資料必須留在國內，才能符合法規要求，可以考慮使用位於國內的第二個雲端供應商做為 DR。使用第二個雲端服務供應商的前提是，無法使用內部部署環境建構混合式設定。為避免重新設計雲端解決方案架構，理想情況下，第二個雲端供應商應在區域內提供您所需的所有功能和服務。
設計須知
- 災難復原期望：貴商家希望達成的 RPO 和 RTO 目標，應能推動災難復原架構和建構規劃。
- 解決方案架構：採用這種模式時，您需要複製現有內部部署環境的功能和功能，才能達到 DR 期望。因此，您需要評估重新託管、重構或重新架構應用程式的可行性和可行性，以便在雲端環境中提供相同 (或更優化) 的功能和效能。
- 設計及建構：在雲端環境中部署企業工作負載時，幾乎一律需要先建構登陸區。詳情請參閱 Google Cloud 中的登陸區設計。
啟動 DR：DR 設計和程序必須考量下列問題：
- 什麼情況會觸發災難復原情境？舉例來說，主要網站中特定功能或系統發生故障，可能會觸發 DR。
- 如何叫用容錯移轉至 DR 環境？是手動核准程序，還是可以自動化，以達到低 RTO 目標？
- 應如何設計系統故障偵測和通知機制，以根據預期的復原時間目標 (RTO) 叫用容錯移轉？
- 偵測到故障後，流量如何重新導向至 DR 環境？
透過測試驗證這些問題的答案。
測試：徹底測試及評估容錯移轉至 DR 的情況，確保符合 RPO 和 RTO 預期。這樣做有助於您在需要時更有把握地叫用 DR。每當程序或技術解決方案有任何新變更或更新，請再次進行測試。
團隊技能：除非您的環境是由第三方管理，否則一或多個技術團隊必須具備相關技能和專業知識，才能在雲端環境中建構、運作及排解生產工作負載的問題。
優點
使用 Google Cloud 確保業務持續性可帶來多項優勢：
- 由於 Google Cloud 在全球各地有許多地區可供選擇，因此您可使用它將資料備份或複製到同一個大陸內的不同站點。您也可以將資料備份或複製到不同大陸的站點。
- Google Cloud 可將資料儲存在 Cloud Storage 的雙區域或多區域值區。資料會以備援的形式儲存在最少兩個不同地理區域。儲存在雙區域和多區域值區的資料會使用預設複製功能，在不同地理區域間複製。
- 提供下列一或多個選項，以減少資本支出和營運費用，進而建構災難復原機制：
- 已停止的 VM 執行個體只會產生儲存空間費用，而且比正在執行的 VM 執行個體便宜相當多。因此您可以將維護冷待命系統的費用降至最低。
- 採用「用多少付多少」的收費模型，確保您只需要針對實際使用的儲存空間和運算能力進行付費。 Google Cloud
- 彈性功能 (例如自動調度資源) 可讓您視需要自動擴充或縮減 DR 環境。
舉例來說，下圖顯示在內部部署環境 (生產環境) 中執行的應用程式，該應用程式使用Google Cloud 的復原元件，搭配 Compute Engine、Cloud SQL 和 Cloud Load Balancing。在這個情境中，資料庫是使用以 VM 為基礎的資料庫或 Google Cloud 代管資料庫 (例如 Cloud SQL) 預先佈建，以便透過持續複製資料加快復原速度。您可以從預先建立的快照啟動 Compute Engine VM，在正常作業期間降低成本。完成這項設定後，如果發生故障事件，DNS 必須指向 Cloud Load Balancing 外部 IP 位址。
如要讓應用程式在雲端運作，您需要佈建網路和應用程式 VM。視目標 RTO 級別和公司政策而定，您可以手動或自動完成整個程序，包括叫用 DR、在雲端佈建工作負載，以及重新導向流量。
如要加快基礎架構的佈建速度並自動執行這項作業，請考慮將基礎架構視為程式碼進行管理。您可以使用 Cloud Build (持續整合服務)，自動將 Terraform 資訊清單套用至環境。詳情請參閱「使用 Terraform、Cloud Build 和 GitOps 管理基礎架構式程式碼」。
最佳做法
使用業務持續性模式時，請考慮下列最佳做法：
- 建立記載基礎架構以及容錯移轉和復原程序的災難復原計劃。
- 根據業務影響分析和已識別的必要 RPO 和 RTO 目標，考慮採取下列動作：
- 如果您只備份資料，請考慮使用轉換模式。否則，網格模式可能是不錯的選擇，可複製現有環境的網路架構。
- 盡可能減少在不同環境中執行的系統之間的依附元件，尤其是在同步處理通訊時。這些依附元件會降低效能及整體可用性。
避免核心分裂問題。如果您在環境間雙向複製資料，可能會遇到「Split Brain 問題」。如果兩個雙向複製資料的環境失去彼此的通訊連線，就會發生「Split Brain 問題」。這種分割可能會導致兩個環境中的系統斷定對方環境無法使用，且自己擁有資料的專屬存取權。這可能會導致資料修改衝突。避免腦裂問題的常見方法有兩種：
- 使用第三個運算環境。這個環境可讓系統在修改資料前檢查群數。
允許在連線復原後，調解產生衝突的資料修改。
使用 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 或 Cross-Cloud Interconnect。Cloud Interconnect 有助於提升連線效能，且如果流量符合特定條件，還可降低傳出資料的移轉費用。詳情請參閱 Cloud Interconnect 定價。
建議您在 Google Cloud Marketplace 上使用偏好的合作夥伴解決方案，協助進行資料備份、複製和其他符合您需求的作業，包括 RPO 和 RTO 目標。
測試及評估 DR 叫用情境，瞭解與目標 RTO 值相比，應用程式從災難事件中復原的難易度。
加密傳輸中的通訊內容。為保護機密資訊，建議您加密所有傳輸中的通訊內容。如果需要在連線層進行加密，您可以根據所選的混合式連線解決方案，選擇各種選項。這些選項包括 VPN 通道、採用 Cloud Interconnect 的高可用性 VPN，以及 Cloud Interconnect 的 MACsec。
雲端爆發模式
網際網路應用程式的使用量可能會有極端的波動。雖然大多數企業應用程式不會面臨這項挑戰，許多企業仍必須處理不同的爆發工作負載：批次或 CI/CD 工作。
這個架構模式仰賴多個運算環境間的應用程式備援部署。目標是提高容量、彈性或兩者皆是。
雖然您可超額佈建資源，在以資料中心為基礎的運算環境中配合爆發的工作負載，這種方法可能並不符合成本效益。當工作有時效性的限制時，延遲工作是不切實際的做法，但透過批次工作，您可以將其執行項目延長到較長的時間範圍來最佳化使用率。
「雲端爆發」模式的概念是將私人運算環境用於基準負載，並在需要額外的能力時，暫時爆發至雲端。
在上圖中，當內部部署私有環境的資料容量達到上限時，系統可視需要從Google Cloud 環境取得額外容量。
這種模式的主要推動因素是節省金錢，以及減少因應規模需求變化所需的時間和精力。採用這種做法，您只需支付處理額外負載時使用的資源費用。也就是說，您不必過度佈建基礎架構。您可以改用隨選雲端資源，並根據需求和任何預先定義的指標調整資源規模。因此，貴公司或許能避免在需求高峰期發生服務中斷。
雲端爆發情境的潛在需求是工作負載可攜性。 當您允許將工作負載部署至多個環境時，必須去除不同環境之間的差異。舉例來說，Kubernetes 可讓您在不同基礎架構的各種環境中，達到工作負載層級的一致性。詳情請參閱 GKE Enterprise 混合式環境參考架構。
設計須知
雲端爆發模式適用於互動式和批次工作負載。不過，當您處理互動式工作負載時，必須判定如何將要求分散到多個環境：
您可以將傳入使用者要求轉送至現有資料中心內執行的負載平衡器，然後讓該負載平衡器將要求分散到本機和雲端資源。
這個方法需要負載平衡器或在現有資料中心內執行的另一個系統，也追蹤雲端中配置的資源。負載平衡器或其他系統也必須啟動資源的自動擴充或縮減。使用這個方法，您可以在活動量低時停用所有雲端資源。不過，實作機制來追蹤資源可能會超過負載平衡器解決方案的能力，因而增加整體複雜度。
您可以使用 Cloud Load Balancing，搭配混合式連線網路端點群組 (NEG) 後端，不必實作追蹤資源的機制。您可以使用這個負載平衡器，根據不同的指標 (例如以權重為準的流量分配)，將內部用戶端要求或外部用戶端要求轉送至位於內部部署環境和Google Cloud 的後端。此外，您也可以根據 Google Cloud中工作負載的負載平衡服務規模，調度後端資源。詳情請參閱「全域外部應用程式負載平衡器的流量管理總覽」。
這種做法還有其他優點，例如可運用 Google Cloud Armor 的 DDoS 防護功能、網路應用程式防火牆，以及使用 Cloud CDN 在雲端邊緣快取內容。不過，您需要調整混合式網路連線的大小，才能處理額外流量。
如「工作負載可攜性」一節所述，應用程式可在進行最小幅度變更的情況下攜帶至不同的環境，以確保工作負載一致性，但這並不表示應用程式在兩種環境中的效能一樣好。運算、基礎架構安全防護功能或網路基礎架構的差異，以及與相依服務的距離遠近，通常會決定效能。透過測試，您可以更準確地掌握曝光度，並瞭解預期成效。
您可以使用雲端基礎架構服務建構環境，以便託管應用程式，但無法移植。在需求量高峰期間重新導向流量時，請使用下列方法處理用戶端要求：
- 使用一致的工具監控及管理這兩個環境。
- 確保工作負載版本一致，且資料來源為最新版本。
- 當需求增加，且雲端工作負載預計會接受應用程式的用戶端要求時，您可能需要新增自動化功能，以佈建雲端環境並重新導向流量。
如果您打算在低需求期間關閉所有 Google Cloud 資源，主要使用 DNS 轉送政策進行流量負載平衡可能不是最佳做法。主要原因如下：
- 資源可能需要一段時間才能初始化，之後才能為使用者提供服務。
- DNS 更新通常會在網路上緩慢傳播。
因此：
- 即使沒有資源可處理要求，使用者也可能會轉送至雲端環境。
- 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 變更能快速套用，請設定 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 為基礎的動態網頁應用程式。