背景

阿里云服務(wù)網(wǎng)格 ASM 于 2020 年 2 月公測，近 2 年的時(shí)間，已有大量用戶(hù)采用其作為生產(chǎn)應用的服務(wù)治理平臺。阿里云服務(wù)網(wǎng)格 ASM 基于開(kāi)源 Istio 構建。同時(shí)，Istio 仍然年輕，2021 年我們看到 Istio 不少新的進(jìn)展，eBPF、Multi-buffer、Proxyless 等，每一次 Istio 的變化都牽動(dòng)人們的神經(jīng)——是時(shí)候采用服務(wù)網(wǎng)格了嗎？

本文不打算回顧 Istio 或是阿里云服務(wù)網(wǎng)格 ASM 的變化或趨勢，我們來(lái)聊一聊阿里云 ASM 服務(wù)網(wǎng)格，它的最終用戶(hù)是如何使用服務(wù)網(wǎng)格的。

為什么采用服務(wù)網(wǎng)格

服務(wù)網(wǎng)格的理念是將服務(wù)治理能力下沉到基礎設施，讓業(yè)務(wù)更加專(zhuān)注于業(yè)務(wù)邏輯。我們可以很輕松地舉出服務(wù)網(wǎng)格帶來(lái)的服務(wù)治理能力，比如流量管理、可觀(guān)測性、服務(wù)安全通信、策略增強如限流和訪(fǎng)問(wèn)控制等。但是，最終用戶(hù)真的需要這些功能嗎？Istio 的這些能力真的滿(mǎn)足生產(chǎn)要求嗎？為了一兩個(gè)功能引入服務(wù)網(wǎng)格是否值得大費周章？

比如說(shuō)流量管理，最受關(guān)注的是 Traffic Splitting，常用于灰度發(fā)布或者 A/B 測試。Istio 的功能設計非常簡(jiǎn)潔，但是默認無(wú)法實(shí)現全鏈路流量管理。如果沒(méi)有在所有微服務(wù)拓撲節點(diǎn)里透傳自定義的 Header 或標簽，具有關(guān)聯(lián)性的服務(wù)流量切割則完全不可能。

比如是安全能力，采用傳統手段進(jìn)行大量微服務(wù) TLS 認證幾乎是 Impossible Mission，而 Envoy 提供的 mTLS 加密則非常輕松地完成了服務(wù)間加密通信，或者說(shuō)零信任安全。但是，用戶(hù)是否真的關(guān)心服務(wù)間安全，畢竟這些微服務(wù)大多運行在云上的一個(gè) VPC 的一個(gè) Kubernetes 集群里。

比如可觀(guān)測性，Istio 將 Metrics、Logging、Tracing 統一起來(lái)，可以很方便地獲取微服務(wù)拓撲結構，快速地定位微服務(wù)問(wèn)題。但是，Sidecar 無(wú)法深入進(jìn)程級別，相關(guān)的 Metrics 和 Tracing 相比經(jīng)典的 APM 軟件實(shí)在相形見(jiàn)絀，無(wú)法真正有效地定位代碼級別問(wèn)題。

最后策略增強比如限流能力，Istio 提供 Global Rate Limit 和 Local Rate Limit 限流能力，確實(shí)是大量面向 C 端用戶(hù)應用的強需求。但是它真的能滿(mǎn)足復雜的生產(chǎn)應用限流降級需求嗎？

真正的生產(chǎn)環(huán)境各式各樣，服務(wù)網(wǎng)格在落地過(guò)程中又會(huì )遭遇各種各樣的挑戰。最終用戶(hù)最關(guān)心的服務(wù)網(wǎng)格的能力是什么，在落地過(guò)程中又有怎么的實(shí)踐經(jīng)驗？

用戶(hù)主要采用服務(wù)網(wǎng)格什么能力？

我先暫時(shí)不回答上面提出的疑問(wèn)。我們來(lái)看看阿里云服務(wù)網(wǎng)格 ASM 用戶(hù)主要使用服務(wù)網(wǎng)格的哪些能力，我相信讀者會(huì )形成自己的答案。

流量管理

首先當然是流量管理，這是 Istio 最顯著(zhù)地提升應用發(fā)布幸福感的能力。阿里云服務(wù)網(wǎng)格 ASM 大部分的用戶(hù)出于流量管理的需求選擇了 ASM 服務(wù)網(wǎng)格。而流量管理主要應用在灰度發(fā)布或 A/B 測試。最常見(jiàn)的應用場(chǎng)景如下：

上圖的灰度流量切換發(fā)生在 Ingress 網(wǎng)關(guān)上，服務(wù)內部在各自的 Namespace 里閉環(huán)，方案簡(jiǎn)單有效。缺點(diǎn)是每次灰度需要在灰度的 Namespace 里部署全量微服務(wù)。 另外一種樸素的想法是希望實(shí)現全鏈路灰度發(fā)布，我有時(shí)候喜歡稱(chēng)之為 Dark Release。什么是全鏈路灰度發(fā)布？如下圖所示：

可以任意地灰度其中的一個(gè)或多個(gè)服務(wù)而不需要高成本地部署全量微服務(wù)?；谏鐓^ Istio 的 Header-based traffic routing，可以實(shí)現全鏈路灰度發(fā)布，前提是在全鏈的每一個(gè)服務(wù)中，開(kāi)發(fā)透傳規定的自定義 Header。

這種方式顯得稍費工夫，每個(gè)服務(wù)都需要侵入式的修改，落地過(guò)程中往往只有新的項目和應用能在一開(kāi)始便如此設計。有沒(méi)有替代方案？阿里云服務(wù)網(wǎng)格 ASM 提供了一種基于 Tracing 的全鏈路灰度發(fā)布方案。原理并不復雜，既然全鏈微服務(wù)需要有一個(gè) header 或標簽將服務(wù)請求關(guān)聯(lián)性串聯(lián)起來(lái)，traceid 顯然是個(gè)現成的連接器。

這跟自定義 header 透傳相比似乎有點(diǎn)顯得換湯不換藥，Tracing 接入一樣需要代碼侵入。但 Tracing 有開(kāi)源的標準，實(shí)現 Tracing 的同時(shí)賦能了全鏈路流量管理能力，這是開(kāi)源標準的力量。另外，如果是 Java 應用，阿里云 ARMS 提供了無(wú)代碼浸入的 Tracing 接入能力，與 阿里云服務(wù)網(wǎng)格 ASM 配合即可實(shí)現完全無(wú)代碼修改的全鏈路灰度發(fā)布。

我們再回到落地場(chǎng)景，ASM 用戶(hù)里常常是中小規模的企業(yè)或應用能夠建立完整的 Tracing 跟蹤，反而是大公司應用眾多，Tracing 鏈路斷得稀碎，實(shí)在讓人頭疼。好在關(guān)聯(lián)服務(wù)的灰度往往發(fā)生在局部?jì)?，局部?jì)鹊姆?wù)鏈路完整已經(jīng)可以滿(mǎn)足灰度的要求。

南北流量管理

我們在上面討論的主要還是東西向流量管理，而南北向流量管理是一個(gè)具有更豐富生態(tài)的領(lǐng)域。Solo 公司在這一領(lǐng)域的 Gloo Edge 和 Gloo Portal 堪稱(chēng)楷模，國內也有不少的基于 Envoy 或面向 Mesh 的 API 網(wǎng)關(guān)。Istio-ingressgateway 與 Lagacy API Gateway 有什么區別和聯(lián)系？社區有非常多的討論，我個(gè)人的觀(guān)點(diǎn)是，原子能力上沒(méi)有明顯差別，只是面向的操作界面不同和目前生態(tài)不同。

有些用戶(hù)采用阿里云服務(wù)網(wǎng)格ASM的原因其實(shí)并不是需要服務(wù)治理，而是借用 Istio-ingressgateway 的增強能力。Istio 的 Gateway、VirtualService 和 DestinationRule 定義顯然比 Kubernetes Ingress 模型更加清晰，分層明確，再加上 Envoy 強大的擴展能力，Envoy 和 Istio-ingressgateway 在網(wǎng)關(guān)選型中逐漸受到青睞。舉個(gè)簡(jiǎn)單的例子—— gRPC 負載均衡，Envoy/Istio 輕而易舉實(shí)現，很多用戶(hù)的 Istio 選型則由此出發(fā)。例如對 AI Serving 推理服務(wù)場(chǎng)景，服務(wù)鏈路不長(cháng)，Sidecar 帶來(lái)的延遲幾可忽略。

Istio/Envoy 在網(wǎng)關(guān)上的擴展目前大多基于 Lua 或者 WASM，通過(guò) Envoyfilter 可以實(shí)現非常多的自定義能力擴展。落地挑戰也非常簡(jiǎn)單直接，用戶(hù)說(shuō)，臣妾不會(huì )寫(xiě) Lua，更不會(huì )寫(xiě) WASM 啊。云廠(chǎng)商說(shuō)沒(méi)關(guān)系，我來(lái)寫(xiě)啊，根據場(chǎng)景的擴展的東西寫(xiě)多了，就可以放在一塊做個(gè)插件市場(chǎng)，按需選擇。從今年的用戶(hù)視角來(lái)看，WASM 知道的頗多，但應用起來(lái)仍然比較復雜。

舉一個(gè)常見(jiàn)的應用場(chǎng)景——入口流量打標，或者流量染色。根據入口流量的特征，比如來(lái)源的私網(wǎng)或互聯(lián)網(wǎng)、登錄用戶(hù)信息等進(jìn)行流量打標。打標后的再進(jìn)行流量分流或灰度發(fā)布。

還有一個(gè)場(chǎng)景值得補充，Egress 流量控制，不少對應用安全要求高的用戶(hù)采用 Istio Egress 網(wǎng)關(guān)來(lái)控制應用七層可訪(fǎng)問(wèn)的范圍。Network Policy 三四層易做，七層控制可考慮采用服務(wù)網(wǎng)格。

多語(yǔ)言服務(wù)治理

我們上面聊了一通 Istio 流量管理，似乎問(wèn)題已經(jīng)基本解決。但是人們經(jīng)常忽略了一個(gè)潛藏的前提 —— 流量管理能力生效是需要服務(wù)采用 Kubernetes 服務(wù)發(fā)現的，或者說(shuō)，服務(wù)間調用需要帶上 Host 的 Header 或訪(fǎng)問(wèn) Kubernetes clusterIP?，F實(shí)世界中，ACK 上運行著(zhù)大量采用注冊中心作為服務(wù)發(fā)現的微服務(wù)應用，并且存在多語(yǔ)言。我們發(fā)現多語(yǔ)言越來(lái)越普遍，而這往往是業(yè)務(wù)快速發(fā)展的結果。為了快速滿(mǎn)足需求，不同項目不同團隊選擇了不同的語(yǔ)言開(kāi)發(fā)，服務(wù)治理需求隨后才提上日程。這些微服務(wù)可能是采用 ZK、Eureka、Nacos 的 Dubbo 或 Spring Cloud 微服務(wù)，或者是采用 Consul、ETCD 和 Nacos 的 Go、C 、Python 和 PHP 微服務(wù)應用。這些服務(wù)從注冊中心獲取實(shí)例 Pod IP 列表，通過(guò) Envoy是成為 PassthroughCluster，直接繞過(guò)了 Envoy filter chain，流量管理和其他 Istio 能力則無(wú)從談起。

于是，Istio 從誕生之日起許諾的多語(yǔ)言無(wú)侵入微服務(wù)治理在現實(shí)世界中落地之路中布滿(mǎn)荊棘。不同注冊中心的微服務(wù)和注冊到 Kubernetes 和 Pilot 的微服務(wù)如何能愉快地玩耍？

一個(gè)簡(jiǎn)單樸素的方案是，把注冊中心拆掉，采用 Kubernetes CoreDNS 服務(wù)發(fā)現，全面用 Service Mesh。ASM 用戶(hù)中采用這種方案的常常是新開(kāi)發(fā)的應用或者老應用重構、服務(wù)鏈路較短的應用。但非常多的應用如果采用這種方案，將要考慮開(kāi)發(fā)的侵入修改，應用的平滑遷移等挑戰，在實(shí)際推行中會(huì )面臨較多的阻礙。

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

對于需要保留注冊中心的場(chǎng)景，阿里云設計了 2 個(gè)方案：服務(wù)發(fā)現同步和服務(wù)發(fā)現攔截。

什么是服務(wù)發(fā)現同步？既然問(wèn)題根源在同時(shí)存在 Nacos/Consul 注冊中心和 Pilot 注冊，那就把它們互相同步一下就好了嘛，Nacos/Consul 通過(guò) MCP over xDS 同步到 Pilot，讓 Mesh 側服務(wù)能發(fā)現左側的服務(wù)。如果左側的服務(wù)希望以保持原來(lái)的方式訪(fǎng)問(wèn) Mesh 服務(wù)，再增加同步組件將 Pilot 注冊信息同步到 Nacos。這個(gè)方案稍顯復雜，好處是盡量保持原有的架構和開(kāi)發(fā)方式。結合阿里云 MSE 可以實(shí)現對 Java 側微服務(wù)的服務(wù)治理。

我們再來(lái)看另外一個(gè)方案——服務(wù)注冊攔截，或者稱(chēng)之為全 Mesh 方案。

原理非常簡(jiǎn)單，將如 Nacos 的返回注冊實(shí)例 IP 信息由 Sidecar 攔截篡改為 Kubernetes clusterIP，使得 Envoy filter 鏈重新生效?；蛘呖梢钥偨Y為 Keep it, But ignore it。全 Mesh 方案好處也顯而易見(jiàn)，通過(guò)統一的 Mesh 技術(shù)棧(包括數據面和控制面)管理所有的微服務(wù)，方案清晰，對開(kāi)發(fā)無(wú)感。

目前這 2 個(gè)方案都在阿里云用戶(hù)中獲得了落地實(shí)踐，到底哪一個(gè)更適合你的應用，可能就得具體分析了。

服務(wù)安全

提到 Istio 提供的安全能力，首先便是 mTLS 證書(shū)加密。Istio 默認 Permissive 策略下，同一個(gè)網(wǎng)格內的所有服務(wù)都自動(dòng)獲得 mTLS 加密能力(有些用戶(hù)似乎沒(méi)有意識到已經(jīng)默認開(kāi)啟了)。國內用戶(hù)幾乎不太關(guān)注這項能力，但 ASM 海外用戶(hù)對 mTLS 卻是強需求。一位海外用戶(hù)的理解是，一個(gè) Istio 或 Kubernetes 集群的節點(diǎn)可能分布在云上多個(gè) AZ 中，而公有云的 AZ 分布在不同機房中，跨機房流量就可能暴露在非云的管理者里而被嗅探到，同時(shí)也可能面臨來(lái)自機房管理者和運維人員的竊取風(fēng)險。海外用戶(hù)普便更重視安全，這也算是中外的文化差異了。

另外一個(gè)被較多用戶(hù)提及的是自定義外部授權。Istio 默認支持的認證授權比較簡(jiǎn)單，比如基于 sourceIP、JWT 等，更復雜的授權則通過(guò) Istio 的自定義外部授權能力進(jìn)行擴展支持。入口網(wǎng)關(guān)處的認證授權容易理解，Mesh 范圍內任意服務(wù)的授權這項復雜的工程在 Istio 的條件下輕松簡(jiǎn)化了很多。

多集群服務(wù)網(wǎng)格

Istio 原生支持多 Kubernetes 集群，阿里云服務(wù)網(wǎng)格 ASM 產(chǎn)品在多集群上做了簡(jiǎn)化接入。為什么采用多集群？從目前 ASM 用戶(hù)來(lái)看，主要是 2 種：一是多個(gè)業(yè)務(wù)中臺的統一 Mesh 管理，業(yè)務(wù)中臺分別部署在不同的 Kubernetes 集群，相對來(lái)說(shuō)比較獨立，業(yè)務(wù)中臺之間存在直接相互調用。通過(guò) Mesh 能進(jìn)行跨業(yè)務(wù)中臺的服務(wù)治理；其二是跨 AZ 或 Region 的雙集群應用容災。通過(guò) Istio 的 Locality Load Balancing 可以實(shí)現跨 AZ 或 Region 的容災切換。

可觀(guān)測性

可觀(guān)測性指涉監控，當然可觀(guān)測性在云原生語(yǔ)境下含義更加豐富，更強調提前感知和主動(dòng)干預。Istio 對可觀(guān)測性的增強主要在提供了豐富的協(xié)議層 metrics 和服務(wù) sidecar 日志。舉個(gè)例子，circuit breaking，有用戶(hù)會(huì )覺(jué)得網(wǎng)格的 sidecar 是個(gè)黑盒，里面發(fā)生了什么也不太清楚，但其實(shí) Envoy 對熔斷過(guò)程都透出了清晰的指標。不過(guò)我們發(fā)現大量用戶(hù)對 Istio 和 ASM 提供的豐富的 metrics 感知不多，也經(jīng)常沒(méi)有很好地利用起來(lái)。這可能是用戶(hù) Istio 采用階段或功能優(yōu)先級導致的，更可能的原因是作為云廠(chǎng)商沒(méi)有把產(chǎn)品可觀(guān)測性做好。我們仍需努力。

另外，Mesh 在應用層面統一了 Metrics、Logging 和 Tracing，越來(lái)越多用戶(hù)采用 Grafana 接入這 3 類(lèi)數據源進(jìn)行統一的可觀(guān)測性分析。

策略增強

策略增強部分我們主要來(lái)看看限流能力。社區 Istio 提供 Global Rate Limit 和 Local Rate Limit，Global Rate Limit 需要提供統一的 Rate Limit Server，Local Rate Limit 則通過(guò) EnvoyFilter 下發(fā)到 Sidecar 本地配置。Global Rate Limit 的問(wèn)題在于依賴(lài)集中式限流服務(wù)，并在每一個(gè)服務(wù) Sidecar 攔截過(guò)程中引入新的延遲，而 Local Rate Limit 則缺乏全局判斷，并且配置 EnvoyFilter 不便。我們認為 EnvoyFilter 在生產(chǎn)環(huán)境的引入是應該非常謹慎的，Envoy 版本更新很容易造成不兼容。

阿里云服務(wù)網(wǎng)格 ASM 基于 Envoy filter 機制集成了 sentinel filter，sentinel 本是阿里巴巴開(kāi)源的限流熔斷項目，如今被集成到 Envoy 中，提供了更加豐富且面向生產(chǎn)的性能和策略增強。支持流控，排隊等待，熔斷，降級，自適應過(guò)載保護，熱點(diǎn)流控和可觀(guān)測能力。

服務(wù)網(wǎng)格生產(chǎn)實(shí)踐

從生產(chǎn)化應用來(lái)看，Envoy 和 Pilot 的性能都不錯，在中小規模場(chǎng)景(1000 pod)下問(wèn)題不大。中大規模(1000 pod 以上)則對相應配置細節需要做相應的優(yōu)化?？捎^(guān)測性的接入，Envoy Sidecar logging 對性能消耗不大，metrics 開(kāi)啟在大規模下可能引發(fā) Sidecar 內存升高，tracing 采樣率在生產(chǎn)環(huán)境中需要有一定控制。

大規模下的 xDS 配置加載需要有一定的手段控制，開(kāi)源有一些方案，ASM 也提供了基于訪(fǎng)問(wèn)日志分析自動(dòng)推薦的 Sidecar 配置方案，使對應工作負載上的 Sidecar 將僅關(guān)注與自己有調用依賴(lài)關(guān)系的服務(wù)信息。

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

另外一些需要注意的是 Istio-ingressgateway 在高并發(fā)場(chǎng)景下的專(zhuān)有部署和配置優(yōu)化，Sidecar 的優(yōu)雅上線(xiàn)和下線(xiàn)等。這里就不再細述。

服務(wù)網(wǎng)格的未來(lái)？

阿里云服務(wù)網(wǎng)格 ASM 作為托管服務(wù)網(wǎng)格的先行者，已經(jīng)收獲了大量的用戶(hù)落地，這些用戶(hù)更加堅定了我們做這個(gè)產(chǎn)品的信心。服務(wù)網(wǎng)格不再是成堆的 buzzword，而是真真實(shí)實(shí)的生產(chǎn)化應用，處理一個(gè)又一個(gè)的瑣碎的技術(shù)問(wèn)題?；氐奖举|(zhì)，服務(wù)網(wǎng)格還是要解決業(yè)務(wù)問(wèn)題。

服務(wù)網(wǎng)格社區在蓬勃發(fā)展，ASM 產(chǎn)品仍有需要完善的地方，但它已經(jīng)在市場(chǎng)驗證中獲得了前行的力量。服務(wù)網(wǎng)格的史詩(shī)故事才剛剛開(kāi)始。

作者：葉劍宏

原文鏈接：http://click.aliyun.com/m/1000323922/

本文為阿里云原創(chuàng )內容，未經(jīng)允許不得轉載。