作者 | 至簡(jiǎn)? 阿里云高級(jí)技術(shù)專(zhuān)家

隨著微服務(wù)軟件架構(gòu)在互聯(lián)網(wǎng)企業(yè)的廣泛實(shí)踐，新一代微服務(wù)軟件架構(gòu)技術(shù)悄然興起，Service Mesh 便是其中之一。

根據(jù) Linkerd CEO Willian Morgan 對(duì) Service Mesh 的定義，Service Mesh 是一層處理服務(wù)間通信的基礎(chǔ)設(shè)施。云原生應(yīng)用有著復(fù)雜的服務(wù)拓?fù)?#xff0c;Service Mesh 保證請(qǐng)求可以在這些拓?fù)渲邪踩铱煽康卮┧?#xff0c;對(duì)整個(gè)服務(wù)網(wǎng)絡(luò)進(jìn)行觀測(cè)和高效查錯(cuò)，以及通過(guò)靈活的流量治理能力為新功能上線提供高效的驗(yàn)證手段。在實(shí)際應(yīng)用當(dāng)中，Service Mesh 通常是由一系列輕量級(jí)的網(wǎng)絡(luò)代理（又被稱(chēng)為 Sidecar）組成的，它們部署在應(yīng)用進(jìn)程的邊上且對(duì)應(yīng)用進(jìn)程完全無(wú)感。

國(guó)內(nèi) Service Mesh 早期實(shí)踐基本分為先建設(shè)數(shù)據(jù)層后建設(shè)控制層和同時(shí)建設(shè)兩類(lèi)，從后續(xù)發(fā)展看，隨著對(duì)服務(wù)運(yùn)營(yíng)能力要求的提高，控制層會(huì)越來(lái)越重要。在實(shí)際落地方面，眾多企業(yè)都在積極探索 Service Mesh 在大規(guī)模場(chǎng)景下的應(yīng)用。

阿里巴巴高級(jí)技術(shù)專(zhuān)家至簡(jiǎn)在 KubeCon 2020 阿里巴巴云原生專(zhuān)場(chǎng)分享了《Service Mesh 在超大規(guī)模場(chǎng)景下的落地挑戰(zhàn)》，基于阿里巴巴的落地實(shí)踐，分享一些經(jīng)驗(yàn)和思路。以下是部分內(nèi)容整理。

分布式應(yīng)用架構(gòu)在阿里巴巴的現(xiàn)狀

阿里巴巴圍繞電商業(yè)務(wù)構(gòu)建了龐大的微服務(wù)軟件架構(gòu)應(yīng)用生態(tài)，包括了天貓、淘寶、菜鳥(niǎo)、高德等。其次，整個(gè)微服務(wù)體系是通過(guò) Dubbo RPC 連接在一起，MetaQ 用于服務(wù)之間的異步解耦。

目前阿里巴巴主要的技術(shù)棧還是 Java，圍繞 Java 構(gòu)建了相當(dāng)健全的微服務(wù)治理能力，其他技術(shù)棧的微服務(wù)治理能力相對(duì)弱很多。在服務(wù)可見(jiàn)性這塊，阿里巴巴是完全沒(méi)有隔離的。Dubbo RPC 仍是接口級(jí)服務(wù)發(fā)現(xiàn)，1 個(gè)應(yīng)用如果提供 10 個(gè)接口，那么就會(huì)有 10 個(gè)服務(wù)是可以被發(fā)現(xiàn)的，如果這個(gè)應(yīng)用有 n 臺(tái)機(jī)器，那么 10 個(gè)服務(wù)就會(huì)產(chǎn)生 10*n 個(gè)服務(wù)端點(diǎn)元信息，這種重復(fù)數(shù)據(jù)導(dǎo)致規(guī)模問(wèn)題被放大。

另外一點(diǎn)值得跟大家分享的是，目前阿里巴巴也正經(jīng)歷著應(yīng)用的 SDK 升級(jí)之痛，SDK 中包含了中間件和應(yīng)用層的一些公共模塊，由中間件統(tǒng)一以 Pandora 包的形式交付給業(yè)務(wù)方使用。在應(yīng)用數(shù)非常龐大的情形下，SDK 升級(jí)是一份相當(dāng)繁重的工作，甚至涉及到集團(tuán)層面的大協(xié)同。為此，我們希望通過(guò) Service Mesh 先將中間件的那些能力下沉到 Sidecar，將這塊升級(jí)工作從 Pandora 中剝離出來(lái)，借助 Service Mesh 的流量無(wú)損熱升級(jí)能力讓業(yè)務(wù)對(duì)中間件升級(jí)完全無(wú)感。

Service Mesh 面臨的挑戰(zhàn)

• Service Mesh 面臨的第一個(gè)挑戰(zhàn)就是新技術(shù)如何平滑演進(jìn)；

Service Mesh 在大規(guī)模場(chǎng)景下的落地在業(yè)界的案例還相當(dāng) 少，根源在于該技術(shù)本身還沒(méi)有完全成熟。在技術(shù)走向成熟的持續(xù)迭代過(guò)程中，如何平滑演進(jìn)是一個(gè)很有挑戰(zhàn)的任務(wù)。挑戰(zhàn)在于需要以終為始地規(guī)范技術(shù)架構(gòu)的演進(jìn)，一步一步地向終態(tài)架構(gòu)演進(jìn)。

• 第二個(gè)挑戰(zhàn)是發(fā)展的過(guò)程中如何協(xié)調(diào)好技術(shù)和業(yè)務(wù)的平衡；

技術(shù)團(tuán)隊(duì)希望快速迭代向前發(fā)展兌現(xiàn)價(jià)值，而業(yè)務(wù)團(tuán)隊(duì)每年有自己的業(yè)務(wù)目標(biāo)，如何協(xié)調(diào)好兩者的發(fā)展關(guān)系是個(gè)不小的挑戰(zhàn)。代表新技術(shù)的團(tuán)隊(duì)其發(fā)展思路通常會(huì)更激進(jìn)，而業(yè)務(wù)團(tuán)隊(duì)會(huì)因?yàn)椤胺€(wěn)定壓倒一切”而偏保守，短期內(nèi)調(diào)和好這一矛盾或許需要自頂向下的決策力量，否則業(yè)務(wù)挑戰(zhàn)年年有而可能擠壓技術(shù)的發(fā)展空間，導(dǎo)致技術(shù)發(fā)展緩慢而無(wú)法更好地服務(wù)于業(yè)務(wù)的發(fā)展。

• 第三個(gè)挑戰(zhàn)是技術(shù)向前演進(jìn)時(shí)如何處置歷史包袱；

每一次技術(shù)的演進(jìn)都意味著對(duì)原有技術(shù)體系的升級(jí)，這就不可避免地需要處置過(guò)往累積下來(lái)的技術(shù)債。新技術(shù)發(fā)展的難點(diǎn)往往不在于其“新”，而在于包袱太重而導(dǎo)致新技術(shù)演進(jìn)困難，很可能因?yàn)檠葸M(jìn)太慢而嚴(yán)重影響了新技術(shù)的發(fā)展。

• 第四個(gè)挑戰(zhàn)就是克服超大規(guī)模所帶來(lái)的問(wèn)題；

前面講到的 Dubbo 因?yàn)槭墙涌诩?jí)服務(wù)發(fā)現(xiàn)，使得服務(wù)發(fā)現(xiàn)的數(shù)據(jù)規(guī)模非常大，給控制平面的端點(diǎn)數(shù)據(jù)推送能力帶去了巨大挑戰(zhàn)。

• 最后一個(gè)挑戰(zhàn)是 Sidecar 的規(guī)模化運(yùn)維。

在超大規(guī)模場(chǎng)景下，大量的應(yīng)用機(jī)器意味著有等量的 Sidecar 需要運(yùn)維，如何在部署、灰度、升級(jí)以及保障安全生產(chǎn)是一個(gè)很大的挑戰(zhàn)。

新技術(shù)在架構(gòu)上平滑演進(jìn)是關(guān)鍵

新技術(shù)的不成熟很可能在相當(dāng)長(zhǎng)的一段時(shí)間內(nèi)是常態(tài)，演進(jìn)的關(guān)鍵在于如何實(shí)現(xiàn)新技術(shù)架構(gòu)的平滑演進(jìn)，避免出現(xiàn)推倒重來(lái)這種勞命傷財(cái)之事。為此，基于這一考量，我們一共經(jīng)歷了“起步”、“三位一體”和“規(guī)模化落地”三大階段，而每一個(gè)階段采用了不同的軟件架構(gòu)或部署方案。

在起步階段，Istio 控制平面的 Pilot 組件放在一個(gè)單獨(dú)的容器中，同時(shí)當(dāng)作一個(gè)獨(dú)立的進(jìn)程和 Sidecar 部署在一個(gè) Pod 里。采用這樣的方式，使得對(duì)開(kāi)源的 Envoy 和 Pilot 可以做最小的改動(dòng)而加速落地，也方便我們基于開(kāi)源的版本做能力增強(qiáng)和反哺。這一方案的缺點(diǎn)在于，每個(gè) Pod 中都包含了一個(gè) Pilot 進(jìn)程，增大了應(yīng)用所在機(jī)器上的資源消耗，因在服務(wù)規(guī)模并不大的情形下資源消耗相對(duì)小而可以忽視這一缺點(diǎn)。

在三位一體階段，Pilot 進(jìn)程從業(yè)務(wù) Pod 中抽離了出來(lái)變成了一個(gè)獨(dú)立的集群，在 Sidecar 和 Pilot 之間仍是 xDS 協(xié)議。這一架構(gòu)雖節(jié)省了應(yīng)用所在機(jī)器的資源消耗，但必須正視規(guī)模化落地的問(wèn)題。xDS 中有一個(gè)叫 EDS（Endpoint Discovery Service）的協(xié)議，Pilot 通過(guò) EDS 向 Sidecar 推送服務(wù)發(fā)現(xiàn)所需使用到的機(jī)器 IP（又被稱(chēng)之為 Endpoint）信息，在阿里的大規(guī)模場(chǎng)景下因?yàn)橛写罅康亩它c(diǎn)需要通過(guò) Pilot 推送給 Sidecar，導(dǎo)致 Sidecar 的 CPU 消耗相當(dāng)大，讓人擔(dān)心業(yè)務(wù)進(jìn)程因?yàn)?Sidecar 對(duì)資源的爭(zhēng)搶而受影響。這一規(guī)模化問(wèn)題并非在起步階段的技術(shù)方案中不存在，只不過(guò)因?yàn)槟菚r(shí)落地應(yīng)用的服務(wù)規(guī)模小而沒(méi)有成為瓶頸。

為了解決規(guī)模化落地的問(wèn)題，我們?cè)O(shè)計(jì)出了規(guī)模化落地的技術(shù)架構(gòu)。

在這一架構(gòu)中，雖然還是 Sidecar 對(duì)接 Pilot 集群，但是 Pilot 集群只提供 xDS 中的 LDS/CDS/RDS 這些標(biāo)準(zhǔn)的服務(wù)，而 EDS 采用 Sidecar 直接對(duì)接服務(wù)注冊(cè)中心解決。值得強(qiáng)調(diào)，雖然Sidecar直接對(duì)服務(wù)接注冊(cè)中心，但是它仍然沿用了 Envoy 里面對(duì) EDS 所抽象的數(shù)據(jù)結(jié)構(gòu)和服務(wù)模型，只是在數(shù)據(jù)的獲取上對(duì)接注冊(cè)中心來(lái)實(shí)現(xiàn)。之所以 Sidecar 直接對(duì)接服務(wù)注冊(cè)中心能解決走 EDS 所存在的規(guī)模化問(wèn)題，根源在于阿里巴巴的服務(wù)注冊(cè)中心具備了增量推送的能力。

在這三種架構(gòu)中，未來(lái)的終態(tài)一定是采用三位一體的架構(gòu)，且數(shù)據(jù)平面和控制平面也一定是并重發(fā)展。由于阿里巴巴今天的服務(wù)規(guī)模非常龐大而沒(méi)辦法一步到位做到三位一體。通過(guò)規(guī)模化落地這一過(guò)渡方案，仍然有助于我們更好地反哺開(kāi)源社區(qū)，通過(guò)盡早大規(guī)模落地會(huì)讓我們清楚地知道開(kāi)源方案仍存在的問(wèn)題，從而讓我們能為開(kāi)源方案的完善做出更大的貢獻(xiàn)。

業(yè)務(wù)與技術(shù)協(xié)同發(fā)展 —— 飛行中更換引擎

業(yè)務(wù)與技術(shù)的協(xié)同發(fā)展首先要回答好一個(gè)問(wèn)題，即新技術(shù)帶給業(yè)務(wù)的價(jià)值是什么。從業(yè)務(wù)的角度，采納新技術(shù)最開(kāi)始考慮的一定是短期價(jià)值，然后才是放眼看長(zhǎng)遠(yuǎn)價(jià)值。

Service Mesh 對(duì)于業(yè)務(wù)所帶去的短期價(jià)值是：

• 中間件能力下沉，下沉的過(guò)程中去除歷史包袱輕裝上陣；

• 業(yè)務(wù)對(duì)中間件升級(jí)無(wú)感，中間件資源消耗可量化、優(yōu)化可度量。

從長(zhǎng)遠(yuǎn)來(lái)看，完全解決阿里巴巴面臨的 Pandora/SDK 升級(jí)之痛是需要相當(dāng)長(zhǎng)的一段時(shí)間，而 Service Mesh 在流量治理這塊的新價(jià)值也需要規(guī)模化落地達(dá)到一定水平后才能兌現(xiàn)，基礎(chǔ)技術(shù)對(duì)業(yè)務(wù)的價(jià)值需要具備長(zhǎng)遠(yuǎn)的眼光。Service Mesh 的長(zhǎng)遠(yuǎn)價(jià)值有：

• 業(yè)務(wù)與基礎(chǔ)技術(shù)全面解耦，業(yè)務(wù)更聚集于自身而加速創(chuàng)新，基礎(chǔ)技術(shù)獨(dú)立演進(jìn)而加速迭代；

• 對(duì)微服務(wù)生態(tài)完成標(biāo)準(zhǔn)化、體系化的收口與治理，收斂故障和促進(jìn)安全生產(chǎn)，加速應(yīng)用功能正確性的驗(yàn)證效率；

• 為多種編程語(yǔ)言的應(yīng)用提供微服務(wù)治理能力，完善并豐富云原生多編程語(yǔ)言的應(yīng)用生態(tài)；

• 共建全球事實(shí)標(biāo)準(zhǔn)，通過(guò)阿里云的產(chǎn)品落實(shí)客戶(hù) IT 設(shè)施的多云和混合云戰(zhàn)略，加速中國(guó)社會(huì)乃至全球的數(shù)字化轉(zhuǎn)型。

明確了技術(shù)的價(jià)值之后，業(yè)務(wù)與技術(shù)協(xié)同發(fā)展接下來(lái)的挑戰(zhàn)在于，需要技術(shù)演進(jìn)的過(guò)程中完全不影響業(yè)務(wù)，這好比給一架高速運(yùn)行的飛機(jī)換引擎。為此，新技術(shù)的落地方案需要考慮對(duì)業(yè)務(wù)無(wú)侵入，換句話說(shuō)規(guī)避業(yè)務(wù)應(yīng)用新技術(shù)的改造成本。

為了應(yīng)用 mesh 化時(shí)對(duì)業(yè)務(wù)無(wú)感，在以 RPC 流量做 mesh 化為切入點(diǎn)的背景下，我們?cè)O(shè)計(jì)了動(dòng)態(tài)流量無(wú)損透明攔截的技術(shù)方案。上圖示例說(shuō)明了應(yīng)用 mesh 化前后的三種狀態(tài)。在“過(guò)去”，流量是直接通過(guò) RPC SDK 在 Provider 和 Consumer 之間互通的，SDK 直接跟中間件的服務(wù)注冊(cè)中心、配置中心對(duì)接。

到了“現(xiàn)在”，Service Mesh 直接被插入到了應(yīng)用和中間件之間，SDK 不做任何的變化，但通過(guò) iptables 將 SDK 的流量攔截到 Sidecar 中。由于 iptables 是否開(kāi)啟和關(guān)閉流量攔截是可以通過(guò)運(yùn)維控制臺(tái)從應(yīng)用或機(jī)器維度進(jìn)行控制的，這就使得在 mesh 技術(shù)自身出現(xiàn)問(wèn)題的情形下可以方便禁用，讓?xiě)?yīng)用回退到通過(guò) SDK 直連的方式互通。

面向“未來(lái)”，當(dāng) Service Mesh 技術(shù)完全成熟時(shí)，SDK 需要從“胖”變“瘦”，那時(shí)并不需要 SDK 中存在下沉到 Sidecar 的那些能力，從而節(jié)約重復(fù)功能所導(dǎo)致的資源開(kāi)銷(xiāo)。

下圖示例說(shuō)明了打開(kāi)和關(guān)閉流量透明攔截功能的關(guān)鍵流程。其中應(yīng)用進(jìn)程中包含了 RPC SDK 而沒(méi)有區(qū)分表達(dá)，Traffic Interceptor、Pilot Agent 和 Envoy 三個(gè)組件在同一個(gè)容器中，所有組件共享同一個(gè) Pod。OneOps Core 是基于 K8s 所構(gòu)建的中心化 mesh 運(yùn)維 Operator，收到控制臺(tái)（圖中標(biāo)識(shí)為小人的 Operator 指代）調(diào)用開(kāi)啟或關(guān)閉流量透明攔截的接口后，通過(guò)調(diào)用 Pilot Agent 所提供的接口完成對(duì) Pod 中應(yīng)用流量的操作。

為了保證打開(kāi)和關(guān)閉透明攔截功能時(shí)無(wú)業(yè)務(wù)流量的調(diào)用損失，請(qǐng)注意圖中紅色標(biāo)識(shí)出的二大塊流程。開(kāi)啟流量攔截時(shí)：Pilot Agent 將調(diào)用 RPC SDK 的 offline 接口（消息 2.1.1），間接完成從服務(wù)注冊(cè)中心對(duì)本機(jī)做去注冊(cè)摘除流量；然后調(diào)用 Traffic Interceptor 組件所提供的接口開(kāi)啟流量攔截功能（消息 2.1.2）；最后再調(diào)用 RPC SDK 的 online 接口將本機(jī)注冊(cè)到服務(wù)注冊(cè)中心（消息 2.1.3）。

關(guān)閉流量攔截時(shí)：Pilot Agent 將調(diào)用 Envoy 的優(yōu)雅關(guān)閉接口（消息 4.1.1），Envoy 會(huì)在 RPC SDK 與 Envoy 建立的連接上透?jìng)鬟@一消息（即 Envoy 會(huì)調(diào)用 RPC SDK 的優(yōu)雅關(guān)閉接口，上圖并沒(méi)有表達(dá)出），告訴 RPC SDK 不要再向已建立的這一長(zhǎng)連接上發(fā)送任何 RPC 請(qǐng)求；隨后 Pilot Agent 調(diào)用 Traffic Interceptor 接口關(guān)閉流量攔截功能（消息 4.1.2）；最后，Envoy 的優(yōu)雅關(guān)閉接口被調(diào)用時(shí)會(huì)啟動(dòng)一個(gè)延時(shí) 15 秒的定時(shí)器，確保 RPC SDK 與 Envoy 間已建立的長(zhǎng)連接上還沒(méi)有完成處理的請(qǐng)求有足夠的時(shí)間處理完以免出現(xiàn)流量有損，當(dāng)定時(shí)器到期后 Envoy 會(huì)主動(dòng)關(guān)閉與 RPC SDK 所建立的連接（消息 6）。

為了讓 mesh 技術(shù)自身的迭代對(duì)業(yè)務(wù)無(wú)感，我們?cè)O(shè)計(jì)了流量無(wú)損熱升級(jí)方案，確保 Sidecar 可以隨時(shí)對(duì)業(yè)務(wù)無(wú)感升級(jí)。設(shè)計(jì)流量無(wú)損熱升級(jí)方案的核心考量是投入產(chǎn)出比，以最小的工程成本構(gòu)建一個(gè)容易做到穩(wěn)定的技術(shù)方案，下圖示例了站在 Consumer 視角（即 Consumer 側(cè)的 Envoy 進(jìn)行升級(jí)，Consumer 代表流量調(diào)用的發(fā)起方）所觀測(cè)到的熱升級(jí)流程。

當(dāng) Envoy 有一個(gè)新版本需要升級(jí)時(shí)（圖中標(biāo)識(shí)為 v2），通過(guò)運(yùn)維控制臺(tái)可以設(shè)置這個(gè)新版本的鏡像信息，通過(guò) OpenKruise 的 SidecarSet 可以拉到這一鏡像并將鏡像中的新版本 Envoy 二進(jìn)制程序拉起。隨后，新版本 Envoy 會(huì)向老版本 Envoy（路中標(biāo)識(shí)為v1）發(fā)起熱升級(jí)流程。

熱升級(jí)大致包含如下幾個(gè)流程：老版本進(jìn)程中所有的偵聽(tīng) fd 通過(guò)進(jìn)程間通訊的方式交給新版本進(jìn)程（消息 5.1），由新版本進(jìn)程繼續(xù)在之上進(jìn)行偵聽(tīng)（消息 5.1.1），換句話說(shuō)，之后所有在這些被偵聽(tīng)端口上新建的連接都會(huì)發(fā)生在新版本進(jìn)程中；老版本進(jìn)程調(diào)用 RPC SDK 的優(yōu)雅關(guān)閉接口（消息 5.3），告訴 RPC SDK 不要再已建立的連接上發(fā)起新的調(diào)用，如果要發(fā)起新調(diào)用則必須重新建立連接，顯然新連接將與新版本進(jìn)程建立，隨后的調(diào)用流量將全部進(jìn)到新版本進(jìn)程；老版本進(jìn)程向 RPC SDK 發(fā)起優(yōu)雅關(guān)閉接口調(diào)用的同時(shí)會(huì)建立一個(gè)時(shí)延 15 秒的定時(shí)器，確保與 RPC SDK 所建立的連接在這 15 秒中都處理完，定時(shí)器到期后關(guān)閉這一連接并退出老版本進(jìn)程（消息 5.4），從而結(jié)束整個(gè)熱升級(jí)流程。

下圖是從 Provider 視角（即 Provider 側(cè)的 Envoy 進(jìn)行升級(jí)，Provider 代表提供相應(yīng)服務(wù)能力的被調(diào)用方）所觀察到的升級(jí)流程。不難看出，紅色標(biāo)識(shí)出的部分與前一張圖是完全一樣的，熱升級(jí)流程完全無(wú)需基于 Envoy 的 Consumer 或 Provider 身份做特殊的處理。畢竟，現(xiàn)實(shí)中每個(gè)應(yīng)用大多會(huì)同時(shí)承擔(dān) Consumer 和 Provider 兩種角色。

上圖有一個(gè)點(diǎn)值得特別指出，Envoy 需要實(shí)現(xiàn)序號(hào)為 5.3 的優(yōu)雅關(guān)閉消息，并將這一消息透?jìng)鹘o RPC SDK（圖中并沒(méi)有表達(dá)）。

發(fā)展新技術(shù)是償還技術(shù)債的重要契機(jī)

不少新技術(shù)的出現(xiàn)多少會(huì)引發(fā)我們的糾結(jié)，在新技術(shù)所創(chuàng)造的短期價(jià)值不那么有吸引力的情形下，似乎舊技術(shù)不改變就不會(huì)帶來(lái)風(fēng)險(xiǎn)。但經(jīng)驗(yàn)表明，不改變的后果是包袱會(huì)越積越重，由此所帶來(lái)的技術(shù)債的潛在風(fēng)險(xiǎn)最終都不可忽視。

技術(shù)債是軟件的本質(zhì)屬性，因?yàn)闊o(wú)法做到已有架構(gòu)能一直百分百優(yōu)雅實(shí)現(xiàn)新需求。換句話說(shuō)，技術(shù)債對(duì)于一個(gè)長(zhǎng)期提供服務(wù)的軟件來(lái)說(shuō)是一直存在的，只不過(guò)存在大小之別和何時(shí)償還的問(wèn)題。

阿里巴巴對(duì)分布式系統(tǒng)的探索有超過(guò)十年的積累，為了做應(yīng)用的服務(wù)化改造提出了 HSF RPC 開(kāi)發(fā)框架并將之開(kāi)源為 Dubbo。基于框架思維所構(gòu)建的 RPC 協(xié)議為了更好地滿(mǎn)足不同業(yè)務(wù)對(duì)服務(wù)路由的定制化訴求，提供了通過(guò) Groovy 腳本進(jìn)行定制的能力。然而，這種靈活的手段在向 Service Mesh 這一平臺(tái)技術(shù)演進(jìn)時(shí)將帶來(lái)流量治理隱患。

我們認(rèn)為，平臺(tái)思維下構(gòu)建的 Service Mesh 得限制過(guò)于靈活的定制能力，避免平臺(tái)出現(xiàn)“窟窿”而無(wú)法有效、有力地完成全局最優(yōu)的治理。為此，我們將去除 Groovy 腳本當(dāng)作是一項(xiàng)技術(shù)債加以?xún)斶€。Groovy 腳本帶來(lái)的問(wèn)題主要有兩個(gè)：

• 過(guò)于靈活且導(dǎo)致了開(kāi)發(fā)框架與應(yīng)用代碼的耦合；

• 給流量治理能力下沉留下了潛在隱患。

為了去除 Groovy 腳本，我們擴(kuò)展了 Istio 的 VirtualService 和 DestinationRule，抽象出按應(yīng)用名、方法和參數(shù)路由的能力。下圖示例說(shuō)明了某應(yīng)用基于應(yīng)用名做路由在 Groovy 腳本和 Service Mesh 下的具體實(shí)現(xiàn)。

由于單個(gè)應(yīng)用的 Service Mesh 化并非一刀切的一次性完成，存在一個(gè)應(yīng)用的部分機(jī)器先 mesh 化做灰度的場(chǎng)景。為此，需要在去 Groovy 腳本這件事上，讓新舊技術(shù)方案能同時(shí)無(wú)縫工作，背后是兩種形式的路由表達(dá)如何做好同步，背后就涉及控制臺(tái)收口和格式轉(zhuǎn)化等問(wèn)題需要妥善解決。

系統(tǒng)性解決超大規(guī)模問(wèn)題

為了最終解決阿里巴巴在 Service Mesh 落地過(guò)程中所面臨的大規(guī)模問(wèn)題，我們從三個(gè)方面著手：

• Service Mesh 技術(shù)自身的持續(xù)優(yōu)化：需要從 CPU 開(kāi)銷(xiāo)、內(nèi)存占用和時(shí)延三大維度進(jìn)行持續(xù)優(yōu)化，通過(guò)軟硬件結(jié)合等技術(shù)手段做到應(yīng)用 Service Mesh 化前后零新增成本甚至下降；

• Dubbo 實(shí)現(xiàn)應(yīng)用級(jí)服務(wù)發(fā)現(xiàn)而非接口級(jí)：通過(guò)應(yīng)用級(jí)服務(wù)發(fā)現(xiàn)將使得控制平面向數(shù)據(jù)平面推送的服務(wù)元數(shù)據(jù)有數(shù)量級(jí)下降，讓 Service Mesh 的控制平面向數(shù)據(jù)平面推送的數(shù)據(jù)急劇下降。

• 服務(wù)注冊(cè)數(shù)據(jù)進(jìn)行單元封閉并分級(jí)治理：動(dòng)機(jī)依然是降低 Service Mesh 控制平面向數(shù)據(jù)平面推送的數(shù)據(jù)量，通過(guò)單元封閉讓全局服務(wù)元數(shù)據(jù)通過(guò)局部化而減少。

這三方面在阿里巴巴分別有相應(yīng)的團(tuán)隊(duì)在探索解決，這里主要分享 Service Mesh 技術(shù)本身。阿里巴巴對(duì) Service Mesh 技術(shù)的探索策略是“借力開(kāi)源，反哺開(kāi)源”。

• “借力”體現(xiàn)于整體技術(shù)方案采納的是開(kāi)源的 Istio（控制平面） + Envoy（數(shù)據(jù)平面），在工程實(shí)踐中特別注意自有代碼與開(kāi)源代碼做充分的解耦，以及頻繁跟進(jìn)開(kāi)源社區(qū)發(fā)布的新版本；

• “反哺”表現(xiàn)在我們積極將性能優(yōu)化、bugfix 等代碼提交給開(kāi)源社區(qū)。

至今，在 Istio 開(kāi)源社區(qū)我們提交了 9 個(gè) PR，解決性能問(wèn)題和 bugfix；在 Envoy 開(kāi)源社區(qū)我們提交了 14 個(gè) PR，包含內(nèi)存開(kāi)銷(xiāo)下降 50% 的優(yōu)化、新增對(duì) Dubbo 和 RocketMQ 協(xié)議的支持等內(nèi)容。此外，我們?cè)c Istio 社區(qū)共同探索實(shí)現(xiàn)了 EGDS (Endpoint Group Discovery Service），作為 EDS 的增強(qiáng)，但由于 Envoy 社區(qū)擔(dān)心該 feature 通用性不足而最終沒(méi)能接受而完成這次反哺。這一“失敗”不只體現(xiàn)了我們反哺社區(qū)的意愿和熱情，也是更好融入開(kāi)源社區(qū)的一次很好的學(xué)習(xí)機(jī)會(huì)。

在 EGDS 并不能很好解決在“三位一體”方案下的大規(guī)模落地問(wèn)題的情形下，我們重新調(diào)整了落地方案，形成了本文前面所講到的讓 Envoy 直接對(duì)接服務(wù)注冊(cè)中心的“規(guī)模化落地”方案。下圖展示了兩個(gè)方案的 CPU 開(kāi)銷(xiāo)數(shù)據(jù)比較。

圖中深藍(lán)色代表的是規(guī)模化落地方案，橙色代表的是三位一體的方案，測(cè)試數(shù)據(jù)表明三位一體方案在設(shè)定的越大規(guī)模壓測(cè)場(chǎng)景下因服務(wù)元數(shù)據(jù)推送給 Envoy 所帶去的 CPU 開(kāi)銷(xiāo)是規(guī)模化落地方案的三倍。

進(jìn)一步地，我們比對(duì)了非 mesh 方案和規(guī)模化落地 mesh 方案因服務(wù)元數(shù)據(jù)推送所導(dǎo)致的 CPU 開(kāi)銷(xiāo)（如下圖所示）。數(shù)據(jù)表明，非 mesh 方案（圖中橙色表示）因 Java 進(jìn)程在數(shù)據(jù)推送場(chǎng)景下存在 GC 而使得 CPU 開(kāi)銷(xiāo)要顯著地高于規(guī)模化落地 mesh 方案（圖中深藍(lán)色表示），這是因 Envoy 采用 C++ 編程語(yǔ)言而獲得的優(yōu)勢(shì)。

后續(xù)我們會(huì)考慮參與共建 Envoy 社區(qū)所提出的 LEDS 協(xié)議，讓 Istio + Envoy 的三位一體方案天然地能運(yùn)用于阿里巴巴的大規(guī)模場(chǎng)景。

除了 CPU 開(kāi)銷(xiāo)的優(yōu)化，我們?cè)趦?nèi)存優(yōu)化方面也取得了巨大的進(jìn)展。同樣服務(wù)規(guī)模的情形下，Envoy 的內(nèi)存開(kāi)銷(xiāo)從之前超過(guò) 3G 優(yōu)化至 500M 左右。此外，壓測(cè)數(shù)據(jù)表明應(yīng)用 mesh 化完成后整體內(nèi)存開(kāi)銷(xiāo)比 mesh 化前更低。

Sidecar 的規(guī)模化運(yùn)維

Sidecar 的規(guī)模化運(yùn)維也是很具挑戰(zhàn)的一件事，內(nèi)容包含 Sidecar 的部署、灰度、升級(jí)，以及需要構(gòu)建相應(yīng)的監(jiān)控和報(bào)警設(shè)施。

Sidecar 的部署、灰度、升級(jí)我們?nèi)婊谟砂⒗锇桶烷_(kāi)源的 OpenKruise 中的 SidecarSet 實(shí)現(xiàn)。SidecarSet 提供了對(duì) Sidecar 進(jìn)行部署、灰度和升級(jí)的通用能力，能很好地運(yùn)用于 Service Mesh 而省去了重復(fù)建設(shè)。

當(dāng)然，流量無(wú)損熱升級(jí)這樣的能力并非 SidecarSet 原生提供的，需要從 Service Mesh 層面去增強(qiáng)。在 Sidecar 的運(yùn)維和流量治理這塊，監(jiān)控和報(bào)警全面采用了阿里云上的 Prometheus 和 ARMS 兩大云產(chǎn)品，一旦當(dāng)下服務(wù)于阿里巴巴內(nèi)部的 Service Mesh 技術(shù)將來(lái)要通過(guò)產(chǎn)品化輸送給阿里云上的客戶(hù)時(shí)會(huì)更加方便。

在運(yùn)維管控上，我們?nèi)聵?gòu)建了云原生 OneOps 運(yùn)維系統(tǒng)。OneOps 包含控制臺(tái)和 OneOps Core 兩大子系統(tǒng)。后者是基于 K8s 構(gòu)建的運(yùn)維 Operator，通過(guò) CRD 的形式暴露給控制臺(tái)調(diào)用接口。OneOps Core 可以多區(qū)域部署，而控制臺(tái)是全局集中部署的，這樣方便運(yùn)維人員在同一個(gè)控制臺(tái)上能無(wú)縫地管理多個(gè)區(qū)域的 Service Mesh。目前 OneOps 已具備管理包含了 Sidecar 和 Ingress Gateway在內(nèi)的東西南北向流量的能力。

總結(jié)

本文總結(jié)了阿里巴巴大規(guī)模落地 Service Mesh 所面臨并克服的技術(shù)挑戰(zhàn)，希望這些內(nèi)容對(duì)行業(yè)同仁在這一技術(shù)的探索和學(xué)習(xí)有所幫助。現(xiàn)階段，阿里巴巴對(duì)于 Service Mesh 的探索更多停留于解決歷史包袱和完成應(yīng)用與中間件的解耦，仍沒(méi)有在服務(wù)流量治理方面做出新價(jià)值和新體驗(yàn)，期待未來(lái)能盡早給大家分享這方面的內(nèi)容。

Service Mesh 是云原生的關(guān)鍵技術(shù)，對(duì)于阿里巴巴來(lái)說(shuō)，我們篤定這是分布式應(yīng)用微服務(wù)軟件架構(gòu)的未來(lái)。正因如此，CTO 魯肅也站臺(tái) Service Mesh 技術(shù)，并做出了未來(lái)整個(gè)經(jīng)濟(jì)體全面走 Istio + Envoy 方案的技術(shù)決策。在構(gòu)建阿里巴巴全球商業(yè)操作系統(tǒng)的道路上，Service Mesh 是面向未來(lái)五年、甚至十年的技術(shù)。

期待更多對(duì)分布式應(yīng)用相關(guān)技術(shù)挑戰(zhàn)有熱情的志同道合之士加入共建與共創(chuàng)，在創(chuàng)變的道路上我們共同成長(zhǎng)、共同收獲。如果您有意向，請(qǐng)將簡(jiǎn)歷發(fā)送至 zhijian.ly@alibaba-inc.com，我們?cè)谏钲凇⑸虾：秃贾荻加?Service Mesh 的職位長(zhǎng)期開(kāi)放。

另外，業(yè)界首個(gè)兼容 Istio 全托管云產(chǎn)品的阿里云服務(wù)網(wǎng)格（ASM）已對(duì)外發(fā)布，可免費(fèi)體驗(yàn)：https://servicemesh.console.aliyun.com/

課程推薦

去年，CNCF 與 阿里云聯(lián)合發(fā)布了《云原生技術(shù)公開(kāi)課》已經(jīng)成為了 Kubernetes 開(kāi)發(fā)者的一門(mén)“必修課”。

今天，阿里云再次集結(jié)多位具有豐富云原生實(shí)踐經(jīng)驗(yàn)的技術(shù)專(zhuān)家，正式推出《云原生技術(shù)實(shí)踐公開(kāi)課》。課程內(nèi)容由淺入深，專(zhuān)注講解“ 落地實(shí)踐”。還為學(xué)習(xí)者打造了真實(shí)、可操作的實(shí)驗(yàn)場(chǎng)景，方便驗(yàn)證學(xué)習(xí)成果，也為之后的實(shí)踐應(yīng)用打下堅(jiān)實(shí)基礎(chǔ)。點(diǎn)擊鏈接查看課程：https://developer.aliyun.com/learning/roadmap/cloudnative2020

“阿里巴巴云原生關(guān)注微服務(wù)、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢(shì)、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開(kāi)發(fā)者的公眾號(hào)。”

總結(jié)

以上是生活随笔為你收集整理的Service Mesh 在超大规模场景下的落地挑战的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。