![CC188EA0-61E2-4deb-89F6-C3D89D13655A.png](https://ucc.alicdn.com/pic/developer-ecology/7edd1f47f1ec4a3a971f907dec3587b4.png)

作者 | 王夕寧  阿里巴巴高階技術專家

**參與阿里巴巴雲原生文末留言互動，即有機會獲得贈書福利！**

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

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

![1.png](https://ucc.alicdn.com/pic/developer-ecology/c860fc163bf3496d84a018beb0dd2eb0.png)

# 服務治理的能力 Sidecar 化

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

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

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

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

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

![2.png](https://ucc.alicdn.com/pic/developer-ecology/6f61609d7c614ede9f43970a457b7b5f.png)

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

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

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

![3.png](https://ucc.alicdn.com/pic/developer-ecology/11ade6ea61934601ae212d589def4bfc.png)
 
# 服務網格 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 元件,  可以支援動態載入外掛、簡單易用、以及支援熱更新等能力。

![4.png](https://ucc.alicdn.com/pic/developer-ecology/a20387f08fd64a778f3d54542079b1c3.png)

透過這種過濾器擴充套件機制，可以輕鬆擴充套件 Envoy 的功能並將其在服務網格中的應用推向了新的高度。

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

![5.png](https://ucc.alicdn.com/pic/developer-ecology/fde97406195c4f9aa2b8185955272e15.png)

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

**《Istio 服務網格技術解析與實戰》讀者可免費體驗 ASM 產品進行學習！點選瞭解阿里雲服務網格產品 ASM：**[**www.aliyun.com/product/servicemesh**](http://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 服務網格技術解析與實踐》圖書一本！

> “[阿里巴巴雲原生](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247490471&idx=1&sn=10dbb21fc15076626b34e1a2bec5d6dc&chksm=fae51068cd92997ef0eb8da091998bfdd45c86b85161f29917531d81adb8ce1d11b778060cfb&token=850285981&lang=zh_CN#rd)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”

從單體到混亂的微服務，阿里雲託管式服務網格是如何誕生的？

相關文章