從單體到混亂的微服務，阿里云托管式服務網(wǎng)格是如何誕生的？

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

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

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

服務治理的能力Sidecar化

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

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

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

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

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

這些Sidecar代理形成一個網(wǎng)狀的數(shù)據(jù)平面，通過該數(shù)據(jù)平面處理和觀察所有服務間的流量。數(shù)據(jù)平面扮演了一個用來建立、保護和控制通過網(wǎng)格的流量的角色。

負責數(shù)據(jù)平面如何執(zhí)行的管理組件稱為控制平面。控制平面是服務網(wǎng)格的大腦，并為網(wǎng)格使用人員提供公開API，以便較容易地操縱網(wǎng)絡行為。

啟用服務網(wǎng)格之后,開發(fā)人員、運維人員以及SRE團隊將以統(tǒng)一的、聲明的方式解決應用服務管理問題。

服務網(wǎng)格ASM產(chǎn)品架構

作為業(yè)內(nèi)首個全托管Istio兼容的服務網(wǎng)格產(chǎn)品ASM，一開始從架構上就保持了與社區(qū)、業(yè)界趨勢的一致性，控制平面的組件托管在阿里云側，與數(shù)據(jù)面?zhèn)鹊挠脩艏邯毩?。ASM產(chǎn)品是基于社區(qū)開源的Istio定制實現(xiàn)的，在托管的控制面?zhèn)忍峁┝擞糜谥尉毣牧髁抗芾砗桶踩芾淼慕M件能力。通過托管模式，解耦了Istio組件與所管理的K8s集群的生命周期管理，使得架構更加靈活，提升了系統(tǒng)的可伸縮性。

在深入分析服務網(wǎng)格方面，提供了網(wǎng)格診斷能力，把過去一年多來客戶遇到的問題以及如何解決這些問題的手段變成產(chǎn)品能力,幫助用戶快速定位遇到的問題；

在擴展與集成方面，ASM產(chǎn)品整合阿里云服務包括可觀測性服務鏈路追蹤/日志服務/Prometheus監(jiān)控等、跨VPC網(wǎng)絡互連CEN能力等，同時也優(yōu)化整合了社區(qū)開源軟件包括OPA的支持、授權服務的定制化能力、限流服務等。

此外，隨著Istio新架構的優(yōu)化，將WebAssembly技術引入服務網(wǎng)格，解決代理擴展的問題。這樣一來,ASM架構就變成了“托管的高可用彈性控制平面+可擴展的插件式的數(shù)據(jù)平面“的模式。

在數(shù)據(jù)平面的支持上，ASM產(chǎn)品可以支持多種不同的計算基礎設施，這包括了阿里云提供的公有云ACK集群（其中包括了托管的K8s集群和專有K8s集群）、也包括對的無服務器Kubernetes容器服務ASK集群的支持。同時,對非容器化應用例如運行在ECS虛擬機上的應用服務網(wǎng)格化的支持。

此外，ASM也推出了一個支持多云混合云的能力，能夠針對外部的非阿里云K8s集群進行支持，不論這個集群是在用戶自建的IDC機房，還是在其他的公有云之上，都可以通過ASM進行統(tǒng)一的服務治理。

多種類型計算服務統(tǒng)一管理的基礎設施

接下來,將會介紹托管式服務網(wǎng)格在成為多種類型計算服務統(tǒng)一管理的基礎設施中,如何提供了統(tǒng)一的流量管理能力、統(tǒng)一的服務安全能力、統(tǒng)一的服務可觀測性能力、以及如何基于WebAssembly實現(xiàn)統(tǒng)一的數(shù)據(jù)面可擴展能力。

1.統(tǒng)一的流量管理能力

關于統(tǒng)一的流量管理能力方面,重點講述2個方面。

第一個是基于位置實現(xiàn)流量路由請求。在大規(guī)模服務場景下,成千上萬個服務運行在不同地域的多種類型計算設施上,這些服務需要相互調(diào)用來完成完整的功能。為了確保獲得最佳性能，應當將流量路由到最近的服務，使得流量盡可能在同一個區(qū)域內(nèi)，而不是只依賴于Kubernetes默認提供的輪詢方式進行負載均衡。服務網(wǎng)格應當提供這樣的基于位置的路由能力，一方面,可以將流量路由到最靠近的容器,實現(xiàn)本地優(yōu)先的負載均衡能力,并在主服務出現(xiàn)故障時可以切換到備用服務。另一方面,提供局部加權的負載平衡能力,能夠根據(jù)實際需要,將流量按比例拆分到不同的地域。

第二個是關于非K8s工作負載的網(wǎng)格化統(tǒng)一管理。在一個托管的服務網(wǎng)格實例中,我們可以添加若干個K8s集群,并在控制面定義路由規(guī)則的配置,也可以定義網(wǎng)關服務等。為了能夠統(tǒng)一地管理非K8s工作負載,我們通過一個WorkloadEntry的CRD來定義工作負載的標簽以及該工作負載運行的IP地址等信息。然后通過ServiceEntry CRD將這個工作負載注冊到服務網(wǎng)格中,并提供類似于K8s Pod的處理機制來處理這些非K8s工作負載。譬如可以通過selector機制路由到對應的Pod或者這個非容器應用上。

2.統(tǒng)一的服務安全能力

關于統(tǒng)一的服務安全能力,托管服務網(wǎng)格為多種不同計算基礎設施上的應用服務提供統(tǒng)一的主子賬戶支持/RAM授權支持。在此基礎上,提供統(tǒng)一的TLS認證與JWT認證,支持啟用與禁用TLS認證的簡易切換、支持以漸進方式逐步實現(xiàn)雙向TLS認證;支持以細粒度的認證范圍,包括namespace與workload級別。此外,服務網(wǎng)格也提供對JWT認證能力的支持,使得這種TOKEN認證機制不再依賴于某種特定實現(xiàn)框架就可以統(tǒng)一透出。

在RBAC授權方面,針對不同協(xié)議提供了統(tǒng)一的授權策略,可以在不同粒度上支持,包括namespace/service/port級別的授權；

在審計方面,可以靈活開啟網(wǎng)格審計功能,并可以查看審計報表、查看日志記錄以及設置告警規(guī)則等；

在策略管理方面，提供了開放策略代理（OPA）的集成,用戶可以使用描述性策略語言定義相應的安全策略。此外也提供了自定義授權服務external_auth grpc的對接。只要遵循這一接口定義,任意授權服務都可以集成到服務網(wǎng)格中。

3.統(tǒng)一的服務可觀測性

統(tǒng)一的服務可觀測性,分為3個方面。

一是日志分析能力：通過對數(shù)據(jù)平面的AccessLog采集分析,特別是對入口網(wǎng)關日志的分析,可以分析出服務請求的流量情況、狀態(tài)碼比例等,從而可以進一步優(yōu)化這些服務間的調(diào)用；

二是分布式追蹤能力：為分布式應用的開發(fā)者提供了完整的調(diào)用鏈路還原、調(diào)用請求量統(tǒng)計、鏈路拓撲、應用依賴分析等工具，可以幫助開發(fā)者快速分析和診斷分布式應用架構下的性能瓶頸，提高微服務時代下的開發(fā)診斷效率；

三是監(jiān)控能力：根據(jù)監(jiān)視的四個維度（延遲，流量，錯誤和飽和度）生成一組服務指標,來了解、監(jiān)視網(wǎng)格中服務的行為。

4.統(tǒng)一的數(shù)據(jù)面可擴展能力

盡管sidecar代理已經(jīng)把服務治理過程中常用的一些功能進行了封裝實現(xiàn)，但它的可擴展能力一定是必須具備的，譬如如何與已有的后端系統(tǒng)做對接，如何解決用戶的一些特定需求。這個時候，一個Sidecar代理的可擴展性顯得尤為重要，而且在一定程度上會影響Sidecar代理的普及。

在Istio之前的架構中，對Sidecar能力的擴展主要集中在Mixer組件上。Sidecar代理的每個服務到服務連接都需要連接到Mixer，以進行指標報告和授權檢查，這樣會導致服務之間的調(diào)用延遲更長，伸縮性也變差。同時，Envoy要求使用代理程序的編程語言C++編寫，然后編譯為代理二進制文件。對于大多Istio用戶而言，這種擴展能力具有一定的挑戰(zhàn)性。

而在采用了新架構之后，Istio把代理的擴展能力從Mixer下移到了數(shù)據(jù)平面的Envoy本身中,并且使用WebAssembly技術將其擴展模型與Envoy進行了合并。WebAssembly支持幾種不同語言的開發(fā)，然后將擴展編譯為可移植字節(jié)碼格式。這種擴展方式既簡化了向Istio添加自定義功能的過程，又通過將決策過程轉移到代理中而不是將其種植到Mixer上來減少了延遲。使用WebAssembly（WASM）實現(xiàn)過濾器Filter的擴展,可以獲得以下好處：

敏捷性：過濾器Filter可以動態(tài)加載到正在運行的Envoy進程中，而無需停止或重新編譯；

可維護性：不必更改Envoy自身基礎代碼庫即可擴展其功能；

多樣性：可以將流行的編程語言（例如C/C++和Rust）編譯為WASM，因此開發(fā)人員可以使用他們選擇的編程語言來實現(xiàn)過濾器Filter；

可靠性和隔離性：過濾器Filter會被部署到VM沙箱中，因此與Envoy進程本身是隔離的；即使當WASM Filter出現(xiàn)問題導致崩潰時，它也不會影響Envoy進程；

安全性：過濾器Filter通過預定義API與Envoy代理進行通信，因此它們可以訪問并只能修改有限數(shù)量的連接或請求屬性。

阿里云服務網(wǎng)格ASM產(chǎn)品中提供了對WebAssembly（WASM）技術的支持，服務網(wǎng)格使用人員可以把擴展的WASM Filter通過ASM部署到數(shù)據(jù)面集群中相應的Envoy代理中。通過自研的ASMFilterDeployment組件,可以支持動態(tài)加載插件、簡單易用、以及支持熱更新等能力。

通過這種過濾器擴展機制，可以輕松擴展Envoy的功能并將其在服務網(wǎng)格中的應用推向了新的高度。

服務網(wǎng)格實踐之成熟度模型

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

《Istio服務網(wǎng)格技術解析與實戰(zhàn)》讀者可免費體驗ASM產(chǎn)品進行學習！點擊了解阿里云服務網(wǎng)格產(chǎn)品ASM：www.aliyun.com/product/servicemesh

作者簡介

王夕寧阿里云高級技術專家，阿里云服務網(wǎng)格產(chǎn)品ASM及Istio on ACK技術負責人，關注Kubernetes、云原生、服務網(wǎng)格等領域。之前曾在IBM中國開發(fā)中心工作，曾擔任專利技術評審委員會主席，作為架構師和主要開發(fā)人員負責參與了一系列在SOA中間件、云計算等領域的工作，擁有50多項相關領域的國際技術專利。著有《Istio服務網(wǎng)格技術解析與實踐》。xining.wxn alibaba-inc.com