背景

阿里雲服務網格 ASM 於 2020 年 2 月公測，近 2 年的時間，已有大量使用者採用其作為生產應用的服務治理平臺。阿里雲服務網格 ASM 基於開源 Istio 構建。同時，Istio 仍然年輕，2021 年我們看到 Istio 不少新的進展，eBPF、Multi-buffer、Proxyless 等，每一次 Istio 的變化都牽動人們的神經——是時候採用服務網格了嗎？

本文不打算回顧 Istio 或是阿里雲服務網格 ASM 的變化或趨勢，我們來聊一聊阿里雲 ASM 服務網格，它的終端使用者是如何使用服務網格的。

為什麼採用服務網格

服務網格的理念是將服務治理能力下沉到基礎設施，讓業務更加專注於業務邏輯。我們可以很輕鬆地舉出服務網格帶來的服務治理能力，比如流量管理、可觀測性、服務安全通訊、策略增強如限流和訪問控制等。但是，終端使用者真的需要這些功能嗎？Istio 的這些能力真的滿足生產要求嗎？為了一兩個功能引入服務網格是否值得大費周章？

比如說流量管理，最受關注的是 Traffic Splitting，常用於灰度釋出或者 A/B 測試。Istio 的功能設計非常簡潔，但是預設無法實現全鏈路流量管理。如果沒有在所有微服務拓撲節點裡透傳自定義的 Header 或標籤，具有關聯性的服務流量切割則完全不可能。

比如是安全能力，採用傳統手段進行大量微服務 TLS 認證幾乎是 Impossible Mission，而 Envoy 提供的 mTLS 加密則非常輕鬆地完成了服務間加密通訊，或者說零信任安全。但是，使用者是否真的關心服務間安全，畢竟這些微服務大多執行在雲上的一個 VPC 的一個 Kubernetes 集群裡。

比如可觀測性，Istio 將 Metrics、Logging、Tracing 統一起來，可以很方便地獲取微服務拓撲結構，快速地定位微服務問題。但是，Sidecar 無法深入程序級別，相關的 Metrics 和 Tracing 相比經典的 APM 軟體實在相形見絀，無法真正有效地定位程式碼級別問題。

最後策略增強比如限流能力，Istio 提供 Global Rate Limit 和 Local Rate Limit 限流能力，確實是大量面向 C 端使用者應用的強需求。但是它真的能滿足複雜的生產應用限流降級需求嗎？

真正的生產環境各式各樣，服務網格在落地過程中又會遭遇各種各樣的挑戰。終端使用者最關心的服務網格的能力是什麼，在落地過程中又有怎麼的實踐經驗？

使用者主要採用服務網格什麼能力？

我先暫時不回答上面提出的疑問。我們來看看阿里雲服務網格 ASM 使用者主要使用服務網格的哪些能力，我相信讀者會形成自己的答案。

流量管理

首先當然是流量管理，這是 Istio 最顯著地提升應用釋出幸福感的能力。阿里雲服務網格 ASM 大部分的使用者出於流量管理的需求選擇了 ASM 服務網格。而流量管理主要應用在灰度釋出或 A/B 測試。最常見的應用場景如下：

上圖的灰度流量切換髮生在 Ingress 閘道器上，服務內部在各自的 Namespace 裡閉環，方案簡單有效。缺點是每次灰度需要在灰度的 Namespace 裡部署全量微服務。 另外一種樸素的想法是希望實現全鏈路灰度釋出，我有時候喜歡稱之為 Dark Release。什麼是全鏈路灰度釋出？如下圖所示：

可以任意地灰度其中的一個或多個服務而不需要高成本地部署全量微服務。基於社群 Istio 的 Header-based traffic routing，可以實現全鏈路灰度釋出，前提是在全鏈的每一個服務中，開發透傳規定的自定義 Header。

這種方式顯得稍費工夫，每個服務都需要侵入式的修改，落地過程中往往只有新的專案和應用能在一開始便如此設計。有沒有替代方案？阿里雲服務網格 ASM 提供了一種基於 Tracing 的全鏈路灰度釋出方案。原理並不複雜，既然全鏈微服務需要有一個 header 或標籤將服務請求關聯性串聯起來，traceid 顯然是個現成的“聯結器”。

這跟自定義 header 透傳相比似乎有點顯得“換湯不換藥”，Tracing 接入一樣需要程式碼侵入。但 Tracing 有開源的標準，實現 Tracing 的同時賦能了全鏈路流量管理能力，這是開源標準的力量。另外，如果是 Java 應用，阿里雲 ARMS 提供了無程式碼浸入的 Tracing 接入能力，與 阿里雲服務網格 ASM 配合即可實現完全無程式碼修改的全鏈路灰度釋出。

我們再回到落地場景，ASM 使用者裡常常是中小規模的企業或應用能夠建立完整的 Tracing 跟蹤，反而是大公司應用眾多，Tracing 鏈路斷得稀碎，實在讓人頭疼。好在關聯服務的灰度往往發生在“區域性”內，區域性內的服務鏈路完整已經可以滿足灰度的要求。

南北流量管理

我們在上面討論的主要還是東西向流量管理，而南北向流量管理是一個具有更豐富生態的領域。Solo 公司在這一領域的 Gloo Edge 和 Gloo Portal 堪稱楷模，國內也有不少的基於 Envoy 或面向 Mesh 的 API 閘道器。Istio-ingressgateway 與 Lagacy API Gateway 有什麼區別和聯絡？社群有非常多的討論，我個人的觀點是，原子能力上沒有明顯差別，只是面向的操作介面不同和目前生態不同。

有些使用者採用阿里雲服務網格ASM的原因其實並不是需要服務治理，而是借用 Istio-ingressgateway 的增強能力。Istio 的 Gateway、VirtualService 和 DestinationRule 定義顯然比 Kubernetes Ingress 模型更加清晰，分層明確，再加上 Envoy 強大的擴充套件能力，Envoy 和 Istio-ingressgateway 在閘道器選型中逐漸受到青睞。舉個簡單的例子—— gRPC 負載均衡，Envoy/Istio 輕而易舉實現，很多使用者的 Istio 選型則由此出發。例如對 AI Serving 推理服務場景，服務鏈路不長，Sidecar 帶來的延遲幾可忽略。

Istio/Envoy 在閘道器上的擴充套件目前大多基於 Lua 或者 WASM，透過 Envoyfilter 可以實現非常多的自定義能力擴充套件。落地挑戰也非常簡單直接，使用者說，臣妾不會寫 Lua，更不會寫 WASM 啊。雲廠商說沒關係，我來寫啊，根據場景的擴充套件的東西寫多了，就可以放在一塊做個外掛市場，按需選擇。從今年的使用者視角來看，WASM 知道的頗多，但應用起來仍然比較複雜。

舉一個常見的應用場景——入口流量打標，或者流量染色。根據入口流量的特徵，比如來源的私網或網際網路、登入使用者資訊等進行流量打標。打標後的再進行流量分流或灰度釋出。

還有一個場景值得補充，Egress 流量控制，不少對應用安全要求高的使用者採用 Istio Egress 閘道器來控制應用七層可訪問的範圍。Network Policy 三四層易做，七層控制可考慮採用服務網格。

多語言服務治理

我們上面聊了一通 Istio 流量管理，似乎問題已經基本解決。但是人們經常忽略了一個潛藏的前提 —— 流量管理能力生效是需要服務採用 Kubernetes 服務發現的，或者說，服務間呼叫需要帶上 Host 的 Header 或訪問 Kubernetes clusterIP。現實世界中，ACK 上執行著大量採用註冊中心作為服務發現的微服務應用，並且存在多語言。我們發現多語言越來越普遍，而這往往是業務快速發展的結果。為了快速滿足需求，不同專案不同團隊選擇了不同的語言開發，服務治理需求隨後才提上日程。這些微服務可能是採用 ZK、Eureka、Nacos 的 Dubbo 或 Spring Cloud 微服務，或者是採用 Consul、ETCD 和 Nacos 的 Go、C++ 、Python 和 PHP 微服務應用。這些服務從註冊中心獲取例項 Pod IP 列表，透過 Envoy是成為 PassthroughCluster，直接繞過了 Envoy filter chain，流量管理和其他 Istio 能力則無從談起。

於是，Istio 從誕生之日起許諾的多語言無侵入微服務治理在現實世界中落地之路中佈滿荊棘。不同註冊中心的微服務和註冊到 Kubernetes 和 Pilot 的微服務如何能愉快地玩耍？

一個簡單樸素的方案是，把註冊中心拆掉，採用 Kubernetes CoreDNS 服務發現，全面用 Service Mesh。ASM 使用者中採用這種方案的常常是新開發的應用或者老應用重構、服務鏈路較短的應用。但非常多的應用如果採用這種方案，將要考慮開發的侵入修改，應用的平滑遷移等挑戰，在實際推行中會面臨較多的阻礙。

應該保留原來的應用架構還是面向 Kubernetes 設計？向左走，向右走？It’s a Question。

對於需要保留註冊中心的場景，阿里雲設計了 2 個方案：服務發現同步和服務發現攔截。

什麼是服務發現同步？既然問題根源在同時存在 Nacos/Consul 註冊中心和 Pilot 註冊，那就把它們互相同步一下就好了嘛，Nacos/Consul 透過 MCP over xDS 同步到 Pilot，讓 Mesh 側服務能發現左側的服務。如果左側的服務希望以保持原來的方式訪問 Mesh 服務，再增加同步元件將 Pilot 註冊資訊同步到 Nacos。這個方案稍顯複雜，好處是儘量保持原有的架構和開發方式。結合阿里雲 MSE 可以實現對 Java 側微服務的服務治理。

我們再來看另外一個方案——服務註冊攔截，或者稱之為全 Mesh 方案。

原理非常簡單，將如 Nacos 的返回註冊例項 IP 資訊由 Sidecar 攔截篡改為 Kubernetes clusterIP，使得 Envoy filter 鏈重新生效。或者可以總結為 “Keep it, But ignore it”。全 Mesh 方案好處也顯而易見，透過統一的 Mesh 技術棧(包括資料面和控制面)管理所有的微服務，方案清晰，對開發無感。

目前這 2 個方案都在阿里雲使用者中獲得了落地實踐，到底哪一個更適合你的應用，可能就得具體分析了。

服務安全

提到 Istio 提供的安全能力，首先便是 mTLS 證書加密。Istio 預設 Permissive 策略下，同一個網格內的所有服務都自動獲得 mTLS 加密能力(有些使用者似乎沒有意識到已經預設開啟了)。國內使用者幾乎不太關注這項能力，但 ASM 海外使用者對 mTLS 卻是強需求。一位海外使用者的理解是，一個 Istio 或 Kubernetes 叢集的節點可能分佈在雲上多個 AZ 中，而公有云的 AZ 分佈在不同機房中，跨機房流量就可能暴露在非雲的管理者裡而被嗅探到，同時也可能面臨來自機房管理者和運維人員的竊取風險。海外使用者普便更重視安全，這也算是中外的“文化”差異了。

另外一個被較多使用者提及的是自定義外部授權。Istio 預設支援的認證授權比較簡單，比如基於 sourceIP、JWT 等，更復雜的授權則透過 Istio 的自定義外部授權能力進行擴充套件支援。入口閘道器處的認證授權容易理解，Mesh 範圍內任意服務的授權這項複雜的工程在 Istio 的條件下輕鬆簡化了很多。

多叢集服務網格

Istio 原生支援多 Kubernetes 叢集，阿里雲服務網格 ASM 產品在多叢集上做了簡化接入。為什麼採用多叢集？從目前 ASM 使用者來看，主要是 2 種：一是多個業務中臺的統一 Mesh 管理，業務中臺分別部署在不同的 Kubernetes 叢集，相對來說比較獨立，業務中臺之間存在直接相互呼叫。透過 Mesh 能進行跨業務中臺的服務治理；其二是跨 AZ 或 Region 的雙叢集應用容災。透過 Istio 的 Locality Load Balancing 可以實現跨 AZ 或 Region 的容災切換。

可觀測性

可觀測性指涉監控，當然可觀測性在雲原生語境下含義更加豐富，更強調提前感知和主動干預。Istio 對可觀測性的增強主要在提供了豐富的協議層 metrics 和服務 sidecar 日誌。舉個例子，circuit breaking，有使用者會覺得網格的 sidecar 是個黑盒，裡面發生了什麼也不太清楚，但其實 Envoy 對熔斷過程都透出了清晰的指標。不過我們發現大量使用者對 Istio 和 ASM 提供的豐富的 metrics 感知不多，也經常沒有很好地利用起來。這可能是使用者 Istio 採用階段或功能優先順序導致的，更可能的原因是作為雲廠商沒有把產品可觀測性做好。我們仍需努力。

另外，Mesh 在應用層面統一了 Metrics、Logging 和 Tracing，越來越多使用者採用 Grafana 接入這 3 類資料來源進行統一的可觀測性分析。

策略增強

策略增強部分我們主要來看看限流能力。社群 Istio 提供 Global Rate Limit 和 Local Rate Limit，Global Rate Limit 需要提供統一的 Rate Limit Server，Local Rate Limit 則透過 EnvoyFilter 下發到 Sidecar 本地配置。Global Rate Limit 的問題在於依賴集中式限流服務，並在每一個服務 Sidecar 攔截過程中引入新的延遲，而 Local Rate Limit 則缺乏全域性判斷，並且配置 EnvoyFilter 不便。我們認為 EnvoyFilter 在生產環境的引入是應該非常謹慎的，Envoy 版本更新很容易造成不相容。

阿里雲服務網格 ASM 基於 Envoy filter 機制集成了 sentinel filter，sentinel 本是阿里巴巴開源的限流熔斷專案，如今被整合到 Envoy 中，提供了更加豐富且面向生產的效能和策略增強。支援流控，排隊等待，熔斷，降級，自適應過載保護，熱點流控和可觀測能力。

服務網格生產實踐

從生產化應用來看，Envoy 和 Pilot 的效能都不錯，在中小規模場景(1000 pod)下問題不大。中大規模(1000 pod 以上)則對相應配置細節需要做相應的最佳化。可觀測性的接入，Envoy Sidecar logging 對效能消耗不大，metrics 開啟在大規模下可能引發 Sidecar 記憶體升高，tracing 取樣率在生產環境中需要有一定控制。

大規模下的 xDS 配置載入需要有一定的手段控制，開源有一些方案，ASM 也提供了基於訪問日誌分析自動推薦的 Sidecar 配置方案，使對應工作負載上的 Sidecar 將僅關注與自己有呼叫依賴關係的服務資訊。

在 Istio 的一些功能性配置上，也有一些需要注意的內容，比如重試策略的 timeout 和 backoff delay 的關係，以及驚群效應的避免。

另外一些需要注意的是 Istio-ingressgateway 在高併發場景下的專有部署和配置最佳化，Sidecar 的優雅上線和下線等。這裡就不再細述。

服務網格的未來？

阿里雲服務網格 ASM 作為託管服務網格的先行者，已經收穫了大量的使用者落地，這些使用者更加堅定了我們做這個產品的信心。服務網格不再是成堆的 buzzword，而是真真實實的生產化應用，處理一個又一個的瑣碎的技術問題。回到本質，服務網格還是要解決業務問題。

服務網格社群在蓬勃發展，ASM 產品仍有需要完善的地方，但它已經在市場驗證中獲得了前行的力量。服務網格的史詩故事才剛剛開始。

作者：葉劍宏

原文連結：http://click.aliyun.com/m/1000323922/

本文為阿里雲原創內容，未經允許不得轉載。