从单体到混乱的微服务,阿里云托管式服务网格是如何诞生的?
作者 | 王夕寧 ?阿里巴巴高級技術專家
參與阿里巴巴云原生文末留言互動,即有機會獲得贈書福利!
在服務網格技術使用之前,為了更快更靈活地進行業務創新, 我們常常會把現有應用進行現代化改造, 把單體應用程序分拆為分布式的微服務架構。通常來說, ?在微服務架構模式的變遷過程中, 最初都是面向代碼庫的模式。
對這些微服務治理的實現, 往往是以代碼庫的方式把這些服務治理的邏輯構建在應用程序本身中,這些代碼庫中包括了流量管理、熔斷、重試、客戶端負載均衡、安全以及可觀測性等這樣的一些功能。這些代碼庫隨著功能的不斷增強, 版本也隨之變更,因為版本不同導致的沖突問題處處可見。此外,庫的版本一旦變更,即使你的應用邏輯并沒有任何變化,整個應用也要隨之全部變更。由此可見, 隨著應用的增長和團隊數量的增加,跨服務一致地使用這些服務治理功能會變得非常復雜。
服務治理的能力 Sidecar 化
通過把這些服務治理的能力 Sidecar 化,就能夠把服務治理的能力與應用程序本身進行了解耦,可以較好地支持多種編程語言、同時這些 Sidecar 能力不需要依賴于某種特定技術框架。這就是我們常說的面向 Sidecar proxy 的架構模式。
隨著這些 Sidecar 代理功能的增強,原本需要在代碼庫中實現的服務治理功能被抽象化為一個個通用組件, 并被逐漸地下沉到代理中。這些服務治理能力的標準化、統一化,可以解決復雜系統微服務實現中面臨的差異大、缺少共性的問題,可以很好地支持不同的編程語言、不同的框架。
通過把應用服務通信能力抽象下沉到基礎設施, ? 使得開發人員可以更加聚焦于業務應用本身開發, ?而讓基礎設施來提供這些通用的能力。
與此同時, 容器編排技術的更加成熟,也加速了 Sidecar 代理的普及與使用的便捷。Kubernetes 作為一個出色的容器部署和管理平臺、Istio 作為應用服務治理的平臺,兩者的結合成為了將這些應用服務通信能力下沉到基礎設施的載體。
在云原生應用模型中,一個應用程序可能會包含數百個服務,每個服務又有數百個實例構成,那么這些成百上千個應用程序的 Sidecar 代理如何統一管理,這就是服務網格中定義的控制平面部分要解決的問題。作為代理,Envoy 非常適合服務網格的場景,但要發揮 Envoy 的最大價值,就需要使它很好地與底層基礎設施或組件緊密配合。
這些 Sidecar 代理形成一個網狀的數據平面,通過該數據平面處理和觀察所有服務間的流量。數據平面扮演了一個用來建立、保護和控制通過網格的流量的角色。
負責數據平面如何執行的管理組件稱為控制平面。控制平面是服務網格的大腦,并為網格使用人員提供公開 API,以便較容易地操縱網絡行為。
啟用服務網格之后, ?開發人員、運維人員以及 SRE 團隊將以統一的、聲明的方式解決應用服務管理問題。
服務網格 ASM 產品架構
作為業內首個全托管 Istio 兼容的服務網格產品 ASM,一開始從架構上就保持了與社區、業界趨勢的一致性,控制平面的組件托管在阿里云側,與數據面側的用戶集群獨立。ASM 產品是基于社區開源的 Istio 定制實現的,在托管的控制面側提供了用于支撐精細化的流量管理和安全管理的組件能力。通過托管模式,解耦了 Istio 組件與所管理的 K8s 集群的生命周期管理,使得架構更加靈活,提升了系統的可伸縮性。
-
在深入分析服務網格方面,提供了網格診斷能力,把過去一年多來客戶遇到的問題以及如何解決這些問題的手段變成產品能力, 幫助用戶快速定位遇到的問題;
-
在擴展與集成方面,ASM 產品整合阿里云服務包括可觀測性服務鏈路追蹤/日志服務/Prometheus 監控等、跨 VPC 網絡互連 CEN 能力等,同時也優化整合了社區開源軟件包括 OPA 的支持、授權服務的定制化能力、限流服務等。
此外,隨著 Istio 新架構的優化,將 WebAssembly 技術引入服務網格,解決代理擴展的問題。這樣一來, ?ASM 架構就變成了“托管的高可用彈性控制平面 + 可擴展的插件式的數據平面“的模式。
在數據平面的支持上,ASM 產品可以支持多種不同的計算基礎設施,這包括了阿里云提供的公有云 ACK 集群(其中包括了托管的 K8s 集群和專有 K8s 集群)、也包括對的無服務器 Kubernetes 容器服務 ASK 集群的支持。同時, 對非容器化應用例如運行在 ECS 虛擬機上的應用服務網格化的支持。
此外,ASM 也推出了一個支持多云混合云的能力,能夠針對外部的非阿里云 K8s 集群進行支持,不論這個集群是在用戶自建的 IDC 機房,還是在其他的公有云之上,都可以通過 ASM 進行統一的服務治理。
多種類型計算服務統一管理的基礎設施
接下來, ?將會介紹托管式服務網格在成為多種類型計算服務統一管理的基礎設施中, 如何提供了統一的流量管理能力、統一的服務安全能力、統一的服務可觀測性能力、以及如何基于 WebAssembly 實現統一的數據面可擴展能力。
1. 統一的流量管理能力
關于統一的流量管理能力方面, 重點講述 2 個方面。
**第一個是基于位置實現流量路由請求。**在大規模服務場景下, 成千上萬個服務運行在不同地域的多種類型計算設施上, 這些服務需要相互調用來完成完整的功能。為了確保獲得最佳性能,應當將流量路由到最近的服務,使得流量盡可能在同一個區域內,而不是只依賴于 Kubernetes 默認提供的輪詢方式進行負載均衡。服務網格應當提供這樣的基于位置的路由能力,一方面, 可以將流量路由到最靠近的容器, 實現本地優先的負載均衡能力, 并在主服務出現故障時可以切換到備用服務。另一方面, 提供局部加權的負載平衡能力, 能夠根據實際需要, 將流量按比例拆分到不同的地域。
第二個是關于非 K8s 工作負載的網格化統一管理。在一個托管的服務網格實例中, 我們可以添加若干個 K8s 集群, 并在控制面定義路由規則的配置, 也可以定義網關服務等。為了能夠統一地管理非 K8s 工作負載, 我們通過一個 WorkloadEntry 的 CRD 來定義工作負載的標簽以及該工作負載運行的 IP 地址等信息。然后通過 ServiceEntry CRD 將這個工作負載注冊到服務網格中, 并提供類似于 K8s Pod 的處理機制來處理這些非 K8s 工作負載。譬如可以通過 selector 機制路由到對應的Pod或者這個非容器應用上。
2. 統一的服務安全能力
關于統一的服務安全能力, 托管服務網格為多種不同計算基礎設施上的應用服務提供統一的主子賬戶支持 / RAM 授權支持。在此基礎上, 提供統一的 TLS 認證與 JWT 認證, ?支持啟用與禁用 TLS 認證的簡易切換、支持以漸進方式逐步實現雙向 TLS 認證; 支持以細粒度的認證范圍, 包括 namespace 與 workload 級別。此外, 服務網格也提供對 JWT 認證能力的支持, 使得這種 TOKEN 認證機制不再依賴于某種特定實現框架就可以統一透出。
-
在 RBAC 授權方面, 針對不同協議提供了統一的授權策略, 可以在不同粒度上支持, 包括 namespace / service / port 級別的授權;
-
在審計方面, 可以靈活開啟網格審計功能, 并可以查看審計報表、查看日志記錄以及設置告警規則等;
-
在策略管理方面,提供了開放策略代理(OPA)的集成, 用戶可以使用描述性策略語言定義相應的安全策略。此外也提供了自定義授權服務 external_auth grpc 的對接。只要遵循這一接口定義, 任意授權服務都可以集成到服務網格中。
3. 統一的服務可觀測性
統一的服務可觀測性, 分為 3 個方面。
-
一是日志分析能力:通過對數據平面的 AccessLog 采集分析, 特別是對入口網關日志的分析, 可以分析出服務請求的流量情況、狀態碼比例等, 從而可以進一步優化這些服務間的調用;
-
二是分布式追蹤能力:為分布式應用的開發者提供了完整的調用鏈路還原、調用請求量統計、鏈路拓撲、應用依賴分析等工具,可以幫助開發者快速分析和診斷分布式應用架構下的性能瓶頸,提高微服務時代下的開發診斷效率;
-
三是監控能力:根據監視的四個維度(延遲,流量,錯誤和飽和度)生成一組服務指標, 來了解、監視網格中服務的行為。
4. 統一的數據面可擴展能力
盡管 sidecar 代理已經把服務治理過程中常用的一些功能進行了封裝實現,但它的可擴展能力一定是必須具備的,譬如如何與已有的后端系統做對接,如何解決用戶的一些特定需求。這個時候,一個 Sidecar 代理的可擴展性顯得尤為重要,而且在一定程度上會影響 Sidecar 代理的普及。
在 Istio 之前的架構中,對 Sidecar 能力的擴展主要集中在 Mixer 組件上。Sidecar 代理的每個服務到服務連接都需要連接到 Mixer,以進行指標報告和授權檢查,這樣會導致服務之間的調用延遲更長,伸縮性也變差。同時,Envoy 要求使用代理程序的編程語言 C++ 編寫,然后編譯為代理二進制文件。對于大多 Istio 用戶而言,這種擴展能力具有一定的挑戰性。
而在采用了新架構之后,Istio 把代理的擴展能力從 Mixer 下移到了數據平面的 Envoy 本身中, 并且使用 WebAssembly 技術將其擴展模型與 Envoy 進行了合并。WebAssembly 支持幾種不同語言的開發,然后將擴展編譯為可移植字節碼格式。這種擴展方式既簡化了向 Istio 添加自定義功能的過程,又通過將決策過程轉移到代理中而不是將其種植到 Mixer 上來減少了延遲。使用 WebAssembly(WASM)實現過濾器 Filter 的擴展, 可以獲得以下好處:
- 敏捷性:過濾器 Filter 可以動態加載到正在運行的 Envoy 進程中,而無需停止或重新編譯;
- 可維護性:不必更改 Envoy 自身基礎代碼庫即可擴展其功能;
- 多樣性:可以將流行的編程語言(例如 C / C ++ 和 Rust)編譯為 WASM,因此開發人員可以使用他們選擇的編程語言來實現過濾器 Filter;
- 可靠性和隔離性:過濾器 Filter 會被部署到 VM 沙箱中,因此與 Envoy 進程本身是隔離的;即使當 WASM Filter 出現問題導致崩潰時,它也不會影響 Envoy 進程;
- 安全性:過濾器 Filter 通過預定義 API 與 Envoy 代理進行通信,因此它們可以訪問并只能修改有限數量的連接或請求屬性。
阿里云服務網格 ASM 產品中提供了對 WebAssembly(WASM)技術的支持,服務網格使用人員可以把擴展的 WASM Filter 通過 ASM 部署到數據面集群中相應的 Envoy 代理中。通過自研的 ASMFilterDeployment 組件, ?可以支持動態加載插件、簡單易用、以及支持熱更新等能力。
通過這種過濾器擴展機制,可以輕松擴展 Envoy 的功能并將其在服務網格中的應用推向了新的高度。
服務網格實踐之成熟度模型
服務網格作為應用服務通信的統一基礎設施, ?可以(并且應該)逐步采用。在此, 我們推出了它的實踐之成熟度模型, 分為了 5 個層次, 分別為一鍵啟用、可觀測提升、安全加固、多種基礎設施的支持, 以及多集群混合管理。這 5 個方面分別涵蓋了前面講述的統一流量管理、統一可觀測性、統一服務安全以及支持不同的計算基礎設施和多集群非容器化應用的混合管理。
《Istio 服務網格技術解析與實戰》讀者可免費體驗 ASM 產品進行學習!點擊了解阿里云服務網格產品 ASM:www.aliyun.com/product/servicemesh
作者簡介
王夕寧 阿里云高級技術專家,阿里云服務網格產品 ASM 及 Istio on ACK 技術負責人,關注 Kubernetes、云原生、服務網格等領域。之前曾在 IBM 中國開發中心工作,曾擔任專利技術評審委員會主席,作為架構師和主要開發人員負責參與了一系列在 SOA 中間件、云計算等領域的工作,擁有 50 多項相關領域的國際技術專利。著有《Istio 服務網格技術解析與實踐》。xining.wxn@alibaba-inc.com
8 月 14 日 11:00 前在阿里巴巴云原生公眾號留言區**歡迎大家討論交流對服務網格技術 Istio 的疑惑,**精選留言點贊前 3 名各送出《Istio 服務網格技術解析與實踐》圖書一本!
“阿里巴巴云原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦云原生流行技術趨勢、云原生大規模的落地實踐,做最懂云原生開發者的公眾號。”
總結
以上是生活随笔為你收集整理的从单体到混乱的微服务,阿里云托管式服务网格是如何诞生的?的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 阿里张磊:如何构建以应用为中心的“Kub
- 下一篇: 重磅发布 | 30+ 阿里巴巴云原生「顶