採用混合式雲端或多雲端架構的架構方法

Last reviewed 2025-01-23 UTC

本文件將針對將工作負載遷移至雲端的常見且已驗證的方法和考量事項提供指引。這篇文章將進一步說明「設計混合式和多雲端架構策略」一文中的指引，該文討論了幾個可能的步驟 (也是建議步驟)，協助您設計採用混合式或多雲端架構的策略。

注意： 「將工作負載遷移至雲端」一詞是指混合雲和多雲端情境，而非完整的雲端遷移。

雲端優先

「雲端優先」是開始使用公用雲端的常見方法。在這種方法中，您將新的工作負載部署到公用雲端，而現有的工作負載則維持原狀。除非技術或機構原因導致公用雲端部署不可行時，才建議您考慮在私人運算環境中進行傳統部署作業。

雲端優先策略有優點也有缺點。從好的一面來看，雲端優先策略是具有前瞻性的策略，您可以以現代化的方式部署新的工作負載，減少或免除遷移現有工作負載的麻煩。

雖然雲端優先方法可提供特定優勢，但可能會錯失改善或使用現有工作負載的機會。新的工作負載可能只佔整體 IT 環境的一小部分，對 IT 支出和效能的影響可能有限。相較於嘗試在雲端環境中容納新工作負載，將時間和資源用於遷移現有工作負載，可能會帶來更多實質效益或節省更多成本。

採用嚴謹的雲端優先做法還可能使您的整體 IT 環境變得更為複雜，因為這種做法可能會造成冗餘、效能不彰 (跨環境通訊過多所致)，或是運算環境不適用於個別工作負載。此外，遵循產業法規和資料隱私權法律，可能會限制企業遷移含有機密資料的特定應用程式。

考慮到這些風險，建議您只針對特定工作負載採用雲端優先方法，採用雲端優先方法，您就能將心力放在可從雲端部署或遷移中獲益最多的工作負載上。此方法也考量了現有工作負載的現代化。

雲端優先混合型架構的常見例子是，當含有重要資料的舊版應用程式和服務必須與新資料或應用程式整合時。如要完成整合，您可以使用混合式架構，透過 API 介面翻新舊版服務，讓舊版服務發揮效益，供新款雲端服務和應用程式使用。有了雲端 API 管理平台 (例如 Apigee)，您就能在不大幅修改應用程式的情況下實作這類用途，並為舊版服務增加安全性、數據分析和擴充性。

遷移和現代化

混合式多雲端和 IT 現代化這兩種不同的概念彼此相關，並可形成良性循環。使用公用雲端可以促進及簡化 IT 工作負載的現代化。將 IT 工作負載現代化可讓您充分運用雲端服務。

將工作負載現代化的主要目標是：

• 提高靈活度，以因應不斷變化的需求。
• 降低基礎架構和營運成本。
• 提高可靠度和彈性，盡量降低風險。

不過，同時在遷移程序中翻新每個應用程式可能不切實際。如遷移至 Google Cloud 所述，您可以實作下列任一遷移類型，甚至視需要合併多種類型：

• 重新託管 (隨即轉移)
• 更換平台 (轉移並最佳化)
• 重構 (遷移與改善)
• 重新架構 (持續翻新)
• 重建 (移除並更換，有時稱為「淘汰並更換」)
• Repurchase

在制定混合和多雲架構的策略時，請務必從成本和時間的角度考量策略的可行性。建議您採用分階段遷移方法，先從移除及轉移或重新建構平台開始，然後再進行重構或重構作業。通常，升級及轉移有助於從基礎架構角度最佳化應用程式。應用程式在雲端執行後，您就能更輕鬆地使用及整合雲端服務，進一步運用雲端優先架構和功能來進行最佳化。此外，這些應用程式仍可透過混合網路連線與其他環境通訊。

舉例來說，您可以根據雲端式微服務架構，重構或重新設計大型的 VM 單體式應用程式，並將其轉換成數個獨立的微服務。在這個範例中，微服務架構會使用 Google Cloud 代管容器服務，例如 Google Kubernetes Engine (GKE) 或 Cloud Run。不過，如果目標雲端環境不支援應用程式的架構或基礎架構，您可以考慮先重新建構平台、重構或重新建構遷移策略，以便在可行情況下克服這些限制。

使用任何一種遷移方法時，請考慮翻新應用程式 (如果可行且可行)。現代化可能需要採用並導入網站可靠性工程 (SRE) 或開發運作工程師原則，因此您可能也需要將應用程式現代化作業擴展至混合式設定中的私人環境。雖然實施 SRE 原則的核心是工程，但這項工作更像是轉型過程，而非技術挑戰。因此，您可能需要進行程序和文化上的變更。如要進一步瞭解在機構中導入 SRE 的第一步是取得主管的支持，請參閱「在 SRE 中，未規劃即是計畫失敗」。

混用及採行適合的遷移方法

這裡提到的每種遷移方法各有優缺點。混合式雲端和多雲端策略的最大優勢就是不用拘泥於一種方法，您可以為每個工作負載或應用程式堆疊決定最適合的做法，如下圖所示。

這張概念圖表說明各種遷移和現代化路徑或方法，可同時套用於不同的工作負載，並根據各工作負載或應用程式的獨特業務、技術需求和目標進行調整。

此外，相同的應用程式堆疊元件不必採用相同的遷移方法或策略。例如：

• 您可以使用 Google Cloud中的 Cloud SQL，將應用程式後端的內部部署資料庫從自行代管的 MySQL 重新平台化為代管資料庫。
• 應用程式前端虛擬機器可透過 GKE Autopilot 重構，以便在容器上執行，Google 會管理叢集設定，包括節點、資源調度、安全性和其他預先設定。
• 您可以使用 Cloud Load Balancing 和 Google Cloud Armor 取代內部部署的硬體負載平衡解決方案和網路應用程式防火牆 WAF 功能。

如果工作負載符合下列任一條件，請選擇重新託管 (隨即轉移)：

• 對本身所處環境的依賴程度相對較低。
• 不值得進行重構，或在遷移前進行重構。
• 架構在第三方軟體之上。

如為以下類型的工作負載，請考慮重構 (遷移及改善)：

• 有必須解除的依賴關係。
• 依賴雲端無法提供的作業系統、硬體或資料庫系統。
• 無法有效利用運算或儲存空間資源。
• 您必須花費一些心力，才能以自動化方式部署這些項目。

請考量重建 (移除及取代) 是否符合下列工作負載類型的需求：

• 已無法滿足目前的需求。
• 這些應用程式可與提供類似功能的其他應用程式整合，同時不影響業務需求。
• 以終止服務的第三方技術為基礎。
• 需支付已不符合成本效益的第三方授權費。

快速遷移計畫說明 Google Cloud 如何協助客戶運用最佳做法、降低風險、控管成本，以及簡化順利邁向雲端的過程。