​簡介：多年來，隨著雲端計算技術的蓬勃發展和落地，越來越多的企業選擇採用雲端計算技術來幫助自己快速完成業務數字化轉型，以便能更好地適應市場變化，進而贏得更大的市場空間。

作者|郝樹偉

Flexera 的《RightScale2021 雲狀態報告》中指出 92% 的大型企業採用混合雲戰略。Gartner 也在一份報告中稱未來 90% 中大型企業將利用混合雲架構管理基礎設施。

多年來，隨著雲端計算技術的蓬勃發展和落地，越來越多的企業選擇採用雲端計算技術來幫助自己快速完成業務數字化轉型，以便能更好地適應市場變化，進而贏得更大的市場空間。其中有很大一部分企業基於降低技術開發和運維成本、享受隨時隨地的即時服務等原因，選擇將自己的業務部署在雲端；還有一部分企業由於資料主權和安全隱私方面的考慮，會選擇在自己內部資料中心環境中搭建自己的專有云平臺；對於公共雲和專有云都有需求的企業使用者會選擇搭建混合雲架構。

​

為什麼需要混合雲架構

企業自身業務安全性考慮

對於企業使用者，特別是大型企業使用者來說，把公司的關鍵“生命線”業務完全託付給一個外部雲廠商來保障，是有一定的風險的。雖然公共雲廠商通常都提供了安全可靠的冗餘方案來保證企業使用者服務的不間斷性，但也並不是沒有意外發生。使用混合雲方案可以保證企業使用者同時具有 A B 兩套方案選擇和切換，最大限度保證業務穩定性。

資料主權和安全隱私方面的監管要求

一些法律法規或者公司自身的安全策略對其企業資料所儲存或駐留的地點有硬性要求，比如歐盟的“通用資料保護條例”（GDRP）等對資料控制者和資料處理者的數字監管措施，比如企業政策要求資料只能駐留在指定地點，目的是為了保護資料隱私和安全性等等。混合云云架構可以幫助企業使用者滿足這一類的需求。

享受雲廠商的服務特性

本地雲與公共雲廠商提供的服務質量是有一定的差異性的，這種差異性體現在方方面面，取決於使用者的實際需求和考量。比如地域覆蓋面的差異性，企業使用者通常在本地雲中自提供的服務，在某個特定的區域內雲廠商提供的服務在訪問延遲上更優，企業使用者在此區域有重要客戶且對雲服務的訪問延遲有較高要求，則企業使用者會選擇將此區域的業務部署在公共雲上，其他業務繼續部署在本地雲上。

成本優化

本地雲在基礎設施上缺乏靈活的擴縮容能力，無法在業務高峰和低谷期根據實際需求合理安排基礎計算資源，造成很大程度上的資源浪費和成本增加，而云上彈性敏捷、按需擴縮容的特性，可以彌補本地雲的這一缺陷。

追隨技術革新

對與一些類似人工智慧、機器學習、物聯網等高精尖技術的技術革新和演進上，通常雲廠商能夠第一時間提供與之相對應的雲服務，企業使用者可以以更小的成本使用這些雲服務，並推動企業自身的技術革新和發展，混合雲架構可以讓企業隨時隨地採用最好的雲服務。

雲原生如何助力混合雲架構演進

公共雲和本地雲本身就是兩朵不同的雲，它們有不同的基礎設施、不同的能力特性以及不同的 API 介面，構建混合雲架構，一方面需要雲提供商耗費大量精力在適配和整合雲平臺的能力上，另一方面，使用者在這種架構下也無法真正按需切換雲服務提供商，反而是另一種形式的繫結。傳統混合雲的種種缺陷，導致這種雲架構無法形成標準化的生態體系，也是一直以來我們無法針對這種雲架構構建統一管理、統一交付的原因。

Kubernetes 的出現讓混合云云架構進入 2.0 時代，Kubernetes 的多項特性及其相關生態體系為混合雲的標準化提供了可能性：

• 以 Kubernetes 為代表的雲原生技術遮蔽了基礎設施的差異性，目前各個雲廠商以及大量的資料中心都已經落地這些技術，使得應用“一次定義，到處部署”成為可能。
• Kubernetes 標準化、宣告式的 API，簡化了應用的部署，讓應用交付變得越來越標準化和統一化，支援在不同的雲上使用相同的方式描述和編排應用。
• 網格服務技術可以跨越多個 Kubernetes 叢集，實現統一的流量管理和服務治理，使得混合云云架構下的應用服務統一到一個控制平面進行管理。

在雲原生時代，以 Kubernetes 為代表的雲原生技術推動了以應用為中心的混合雲架構的到來，Kubernetes 已經成為企業多叢集管理的事實基礎。

雲原生混合雲多叢集的典型使用場景

異地多活——跨地域容災

雖然從基礎設施服務和 Kubernetes 容器平臺兩個維度來看，使用者可以低成本搭建一個高可用應用業務架構，但對於容災能力要求更高的一些業務，還需要通過異地多活這樣的地域級容災能力來實現。

使用者可以在單一雲廠商的不同區域搭建多個叢集，也可以分別線上下 IDC 和線上雲廠商的不同區域搭建多個叢集來實現業務應用的異地多活部署。下圖展示了混合雲場景下 IDC 內的容器叢集和公共雲上的容器叢集 Active-Active 部署，在異地多活架構下，應用的業務負載同時部署在多個叢集上，然後使用一個全域性的 DNS 服務將請求轉發到對應的後端叢集，當其中一個叢集發生故障無法處理請求時，DNS 服務會自動處理並只轉發請求到健康的叢集。

​

低延時——就近訪問

對於開展全球化國際業務的使用者來說，服務的訪問者分佈廣泛，如果伺服器部署在某個特定的區域，勢必會造成其他部分地區網路體驗差的問題。

在這種場景下，我們就可以選擇在多個地域分別部署叢集，通過智慧 DNS 解析將使用者請求轉發至距離最近的叢集處理，最大限度減少網路帶來的延遲。例如下圖中，某應用服務分別部署於北京，成都，香港三個地域的 Kubernetes 叢集，來自華北區域的使用者請求會被智慧解析到北京的 Kubernetes 叢集，來自西南區域的使用者請求會被智慧解析到成都的 Kubernetes 叢集，來自海外的使用者請求則會被智慧解析到香港的 Kubernetes 叢集，這樣可以最大限度地減少地理距離帶來的網路延遲，為各地使用者帶來一致的服務體驗。

​

降低爆炸半徑

通常情況下，多個小規模的叢集要比一個大規模的叢集更容易進行故障隔離。叢集有可能因為磁碟、網路等故障導致無法處理請求，使用多個叢集可以將故障限制和隔離在某個叢集，避免引起更大的連鎖反應。

業務隔離

不同的業務通常需要做好業務隔離，雖然 Kubernetes 本身也有名稱空間的機制來幫助使用者做安全隔離，但這只是邏輯上的軟隔離，不同 namespace 之間依然可以網路互通，而且也還存在資源搶佔的問題，需要進一步配置網路隔離策略和資源限額等。

選擇將不同的業務部署在不同的 Kubernetes 叢集中，可以在物理上實現業務的徹底隔離，安全性和可靠性相比使用 namespace 隔離更高。例如企業內部不同部門部署各自獨立的叢集、使用多個叢集來分別部署開發/測試/生產環境等。

小結

上雲已是大勢所趨，有些企業客戶基於資料主權和安全隱私的考慮，會採用混合雲架構；還有一些企業客戶基於資料主權、成本優化、提升地域覆蓋性等需求，會選擇混合雲加多叢集架構。混合雲和多叢集的架構已經成為企業上雲的新常態。

原文連結
本文為阿里雲原創內容，未經允許不得轉載。

​