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

作者|郝樹偉

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

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

為什么需要混合云架構

企業自身業務安全性考慮

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

數據主權和安全隱私方面的監管要求

一些法律法規或者公司自身的安全策略對其企業數據所存儲或駐留的地點有硬性要求，比如歐盟的“通用數據保護條例”（GDRP）等對數據控制者和數據處理者的數字監管措施，比如企業政策要求數據只能駐留在指定地點，目的是為了保護數據隱私和安全性等等?；旌显圃萍軜嬁梢詭椭髽I用戶滿足這一類的需求。

享受云廠商的服務特性

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

成本優化

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

追隨技術革新

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

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

公共云和本地云本身就是兩朵不同的云，它們有不同的基礎設施、不同的能力特性以及不同的 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 隔離更高。例如企業內部不同部門部署各自獨立的集群、使用多個集群來分別部署開發/測試/生產環境等。

小結

上云已是大勢所趨，有些企業客戶基于數據主權和安全隱私的考慮，會采用混合云架構；還有一些企業客戶基于數據主權、成本優化、提升地域覆蓋性等需求，會選擇混合云加多集群架構?；旌显坪投嗉旱募軜嬕呀洺蔀槠髽I上云的新常態。

原文鏈接
本文為阿里云原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的当云原生遇到混合云：如何实现“求变”与“求稳”的平衡的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。