天天看點

從單體到混亂的微服務,阿裡雲托管式服務網格是如何誕生的?服務治理的能力 Sidecar 化服務網格 ASM 産品架構多種類型計算服務統一管理的基礎設施服務網格實踐之成熟度模型

從單體到混亂的微服務,阿裡雲托管式服務網格是如何誕生的?服務治理的能力 Sidecar 化服務網格 ASM 産品架構多種類型計算服務統一管理的基礎設施服務網格實踐之成熟度模型

作者 | 王夕甯  阿裡巴巴進階技術專家

參與阿裡巴巴雲原生文末留言互動,即有機會獲得贈書福利!

在服務網格技術使用之前,為了更快更靈活地進行業務創新, 我們常常會把現有應用進行現代化改造, 把單體應用程式分拆為分布式的微服務架構。通常來說,  在微服務架構模式的變遷過程中, 最初都是面向代碼庫的模式。

對這些微服務治理的實作, 往往是以代碼庫的方式把這些服務治理的邏輯建構在應用程式本身中,這些代碼庫中包括了流量管理、熔斷、重試、用戶端負載均衡、安全以及可觀測性等這樣的一些功能。這些代碼庫随着功能的不斷增強, 版本也随之變更,因為版本不同導緻的沖突問題處處可見。此外,庫的版本一旦變更,即使你的應用邏輯并沒有任何變化,整個應用也要随之全部變更。由此可見, 随着應用的增長和團隊數量的增加,跨服務一緻地使用這些服務治理功能會變得非常複雜。

從單體到混亂的微服務,阿裡雲托管式服務網格是如何誕生的?服務治理的能力 Sidecar 化服務網格 ASM 産品架構多種類型計算服務統一管理的基礎設施服務網格實踐之成熟度模型

服務治理的能力 Sidecar 化

通過把這些服務治理的能力 Sidecar 化,就能夠把服務治理的能力與應用程式本身進行了解耦,可以較好地支援多種程式設計語言、同時這些 Sidecar 能力不需要依賴于某種特定技術架構。這就是我們常說的面向 Sidecar proxy 的架構模式。

随着這些 Sidecar 代理功能的增強,原本需要在代碼庫中實作的服務治理功能被抽象化為一個個通用元件, 并被逐漸地下沉到代理中。這些服務治理能力的标準化、統一化,可以解決複雜系統微服務實作中面臨的差異大、缺少共性的問題,可以很好地支援不同的程式設計語言、不同的架構。

通過把應用服務通信能力抽象下沉到基礎設施,   使得開發人員可以更加聚焦于業務應用本身開發,  而讓基礎設施來提供這些通用的能力。

與此同時, 容器編排技術的更加成熟,也加速了 Sidecar 代理的普及與使用的便捷。Kubernetes 作為一個出色的容器部署和管理平台、Istio 作為應用服務治理的平台,兩者的結合成為了将這些應用服務通信能力下沉到基礎設施的載體。

在雲原生應用模型中,一個應用程式可能會包含數百個服務,每個服務又有數百個執行個體構成,那麼這些成百上千個應用程式的 Sidecar 代理如何統一管理,這就是服務網格中定義的控制平面部分要解決的問題。作為代理,Envoy 非常适合服務網格的場景,但要發揮 Envoy 的最大價值,就需要使它很好地與底層基礎設施或元件緊密配合。

從單體到混亂的微服務,阿裡雲托管式服務網格是如何誕生的?服務治理的能力 Sidecar 化服務網格 ASM 産品架構多種類型計算服務統一管理的基礎設施服務網格實踐之成熟度模型

這些 Sidecar 代理形成一個網狀的資料平面,通過該資料平面處理和觀察所有服務間的流量。資料平面扮演了一個用來建立、保護和控制通過網格的流量的角色。

負責資料平面如何執行的管理元件稱為控制平面。控制平面是服務網格的大腦,并為網格使用人員提供公開 API,以便較容易地操縱網絡行為。

啟用服務網格之後,  開發人員、運維人員以及 SRE 團隊将以統一的、聲明的方式解決應用服務管理問題。

從單體到混亂的微服務,阿裡雲托管式服務網格是如何誕生的?服務治理的能力 Sidecar 化服務網格 ASM 産品架構多種類型計算服務統一管理的基礎設施服務網格實踐之成熟度模型

服務網格 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 元件,  可以支援動态加載插件、簡單易用、以及支援熱更新等能力。

從單體到混亂的微服務,阿裡雲托管式服務網格是如何誕生的?服務治理的能力 Sidecar 化服務網格 ASM 産品架構多種類型計算服務統一管理的基礎設施服務網格實踐之成熟度模型

通過這種過濾器擴充機制,可以輕松擴充 Envoy 的功能并将其在服務網格中的應用推向了新的高度。

服務網格實踐之成熟度模型

從單體到混亂的微服務,阿裡雲托管式服務網格是如何誕生的?服務治理的能力 Sidecar 化服務網格 ASM 産品架構多種類型計算服務統一管理的基礎設施服務網格實踐之成熟度模型

服務網格作為應用服務通信的統一基礎設施,  可以(并且應該)逐漸采用。在此, 我們推出了它的實踐之成熟度模型, 分為了 5 個層次, 分别為一鍵啟用、可觀測提升、安全加強、多種基礎設施的支援, 以及多叢集混合管理。這 5 個方面分别涵蓋了前面講述的統一流量管理、統一可觀測性、統一服務安全以及支援不同的計算基礎設施和多叢集非容器化應用的混合管理。

《Istio 服務網格技術解析與實戰》讀者可免費體驗 ASM 産品進行學習!點選了解阿裡雲服務網格産品 ASM:

www.aliyun.com/product/servicemesh

作者簡介

王夕甯 阿裡雲進階技術專家,阿裡雲服務網格産品 ASM 及 Istio on ACK 技術負責人,關注 Kubernetes、雲原生、服務網格等領域。之前曾在 IBM 中國開發中心工作,曾擔任專利技術評審委員會主席,作為架構師和主要開發人員負責參與了一系列在 SOA 中間件、雲計算等領域的工作,擁有 50 多項相關領域的國際技術專利。著有《Istio 服務網格技術解析與實踐》。[email protected]

8 月 14 日 11:00 前在阿裡巴巴雲原生公衆号留言區歡迎大家讨論交流對服務網格技術 Istio 的疑惑,精選留言點贊前 3 名各送出《Istio 服務網格技術解析與實踐》圖書一本!

阿裡巴巴雲原生 關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐,做最懂雲原生開發者的公衆号。”

繼續閱讀