作者 | 王夕寧 阿里巴巴高級技術專家
在服務網格技術使用之前，爲了更快更靈活地進行業務創新, 我們常常會把現有應用進行現代化改造, 把單體應用程序分拆爲分佈式的微服務架構。通常來說, 在微服務架構模式的變遷過程中, 最初都是面向代碼庫的模式。
對這些微服務治理的實現, 往往是以代碼庫的方式把這些服務治理的邏輯構建在應用程序本身中，這些代碼庫中包括了流量管理、熔斷、重試、客戶端負載均衡、安全以及可觀測性等這樣的一些功能。這些代碼庫隨着功能的不斷增強, 版本也隨之變更，因爲版本不同導致的衝突問題處處可見。此外，庫的版本一旦變更，即使你的應用邏輯並沒有任何變化，整個應用也要隨之全部變更。由此可見, 隨着應用的增長和團隊數量的增加，跨服務一致地使用這些服務治理功能會變得非常複雜。
服務治理的能力 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 個方面分別涵蓋了前面講述的統一流量管理、統一可觀測性、統一服務安全以及支持不同的計算基礎設施和多集羣非容器化應用的混合管理。