本文整理自 GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）全球互聯(lián)網(wǎng)架構(gòu)大會(huì)，螞蟻科技平臺(tái)數(shù)據(jù)技術(shù)事業(yè)群技術(shù)專家石建偉（花名：卓與）的分享。分享基于 Service Mesh 的理念，結(jié)合螞蟻科技內(nèi)部實(shí)際場景，將中間件、數(shù)據(jù)層、安全層等能力從應(yīng)用中剝離出來后下沉至獨(dú)立的 Sidecar SOFAMosn 中，結(jié)合 Kubernetes 運(yùn)維體系，提供應(yīng)用無感知的情況下升級基礎(chǔ)設(shè)施層能力的案例。

本次分享將從以如下次序展開進(jìn)行：

| 螞蟻科技當(dāng)前的服務(wù)化現(xiàn)狀

在看螞蟻科技的服務(wù)化架構(gòu)之前我們先從一個(gè)簡單的服務(wù)化調(diào)用示例說起，下圖是 SOFARPC 基本原理：

圖1. SOFARPC 基本原理

我們從上圖可以看出，構(gòu)建一個(gè)服務(wù)化框架需要有服務(wù)注冊中心，有服務(wù)定義，調(diào)用方和服務(wù)提供方使用相同的服務(wù)定義來互相通訊。通過服務(wù)注冊中心，調(diào)用方可以直接訂閱到服務(wù)提供方的地址，采用點(diǎn)對點(diǎn)的方式直接發(fā)起請求。客戶端內(nèi)可實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)、路由尋址、負(fù)載均衡、限流熔斷等能力來增強(qiáng)服務(wù)通訊能力。通過我們開源的 SOFARPC、SOFARegistry、SOFABoot，用戶已經(jīng)可以直接構(gòu)建起微服務(wù)體系，助力業(yè)務(wù)發(fā)展。

螞蟻科技發(fā)展至今，雙 11 系統(tǒng)需要應(yīng)對的交易洪峰逐年遞增：

圖2. 歷年雙 11 交易額與峰值數(shù)據(jù)

每秒 26.5 萬筆交易是 2017 年雙 11 的峰值數(shù)據(jù)，這個(gè)數(shù)據(jù)背后有非常復(fù)雜的架構(gòu)支持，LDC 單元化架構(gòu)是螞蟻科技沉淀多年的核心架構(gòu)，依靠這個(gè)架構(gòu)實(shí)現(xiàn)每年峰值交易量飛速增長下系統(tǒng)依然能平滑渡過。我們來簡要看下 LDC 架構(gòu)：

圖3. LDC 架構(gòu)示例

上圖摘自 金融級分布式架構(gòu) 中的?素描單元化?一文，這里不詳細(xì)展開。LDC 的單元化架構(gòu)給應(yīng)用的服務(wù)化帶來更多的規(guī)范與抽象，服務(wù)路由中需要考慮單元間的調(diào)用，跨機(jī)房調(diào)用等更多場景。這里主要希望表達(dá)的是 LDC 架構(gòu)給 RPC 調(diào)用帶來更高的復(fù)雜度。

| 服務(wù)化痛點(diǎn)

中間件版本升級

在上面介紹背景時(shí)，有介紹到目前 LDC 架構(gòu)下服務(wù)調(diào)用的復(fù)雜度，這些復(fù)雜度目前是直接體現(xiàn)在應(yīng)用的代碼中。對于業(yè)務(wù)同學(xué)來講，一個(gè)應(yīng)用的關(guān)注重點(diǎn)是如何實(shí)現(xiàn)業(yè)務(wù)邏輯，至于高可用、容災(zāi)等能力更多是整體架構(gòu)層面會(huì)考慮的點(diǎn)。應(yīng)用內(nèi)通過引入 RPC 的 jar 包即可獲得 LDC 架構(gòu)下服務(wù)調(diào)用各種能力的支撐，帶來便利的同時(shí)也可以看到這種模式的缺點(diǎn)：

圖4. APP 業(yè)務(wù)與 SDK 組成部分

應(yīng)用內(nèi)除業(yè)務(wù)邏輯之外，由中間件的 SDK 引入大量外部依賴，來完成服務(wù)發(fā)現(xiàn)、路由尋址、負(fù)載均衡、限流熔斷、序列化、通訊等能力，每個(gè)組件的引入都可能帶來穩(wěn)定性風(fēng)險(xiǎn)，以及更高的升級成本。

圖5. SDK 內(nèi)不同能力對應(yīng)的依賴

根據(jù)目前 SOFARPC 在內(nèi)部的版本舉例，服務(wù)發(fā)現(xiàn)依賴 SOFARegistry 的客戶端做 IDC 內(nèi)的服務(wù)發(fā)現(xiàn)，依賴 Antvip 做跨 IDC 的服務(wù)發(fā)現(xiàn)，ZoneClient 集成 LDC 架構(gòu)的單元化信息，路由尋址需要根據(jù)請求的入?yún)⒂?jì)算目前 Zone 然后確定調(diào)用目標(biāo)，限流熔斷依賴 Guardian 組件，通訊協(xié)議與序列化協(xié)議相對穩(wěn)定，變更較少。僅為了完成服務(wù)調(diào)用，應(yīng)用需要額外引入 7+ 客戶端包。

每年雙 11 需要涉及到架構(gòu)調(diào)整時(shí)：比如支持彈性架構(gòu)，需要做很多中間件客戶端的版本升級來支撐更優(yōu)的架構(gòu)，對于業(yè)務(wù)同學(xué)來講，這些升級是很耗費(fèi)精力的，拿 200 個(gè)核心應(yīng)用舉例，每個(gè)應(yīng)用升級中間件版本經(jīng)過研發(fā)、測試、再到部署預(yù)發(fā)、灰度、生產(chǎn)等環(huán)境需要 5個(gè)人日的話，200 個(gè)核心應(yīng)用中間件升級需要耗費(fèi) 1000 人日，如果這部分時(shí)間可以節(jié)省出來，每年架構(gòu)升級可以節(jié)約大量人力資源。

跨語言通訊

螞蟻科技發(fā)展至今，內(nèi)部業(yè)務(wù)百花齊放，搜索推薦、人工智能、安全等各種業(yè)務(wù)使用到的技術(shù)棧非常多樣化，跨語言的服務(wù)通訊能力也十分重要。早在幾年前，Java 之外規(guī)模最大的就是 NodeJS 應(yīng)用，為了讓 Java 和 NodeJS 應(yīng)用之間可以復(fù)用螞蟻科技內(nèi)部的各種中間件和基礎(chǔ)設(shè)施，前端團(tuán)隊(duì)使用 NodeJS 逐步重寫了各種中間件客戶端，讓整個(gè) NodeJS 和 Java 體系可以完美互通。

圖6. Java 與 NodeJS 互調(diào)

中間件 SDK 跨語言重寫與維護(hù)成本極高，隨著語言種類的增多，跨語言通訊的訴求也越來越多。

圖7. 多語言場景

Java, NodeJS, Go, Python, C++ 等，5+ 語言，中間件 SDK 全部重寫成本極高。這些問題不得不激勵(lì)我們尋找更優(yōu)的解法。

| 解決痛點(diǎn)

SDK 能力下沉

圖8. SDK 瘦身并下沉能力至 Sidecar

依然以上述 RPC SDK 舉例，SDK 中的能力我們可以根據(jù)穩(wěn)定性與不可剝離等特性來看，哪些是可以從應(yīng)用中抽出來的，盡量把 SDK 做薄，做的足夠穩(wěn)定無需變更，那么升級成本將不復(fù)存在。

圖9. SDK 與 Sidecar 對應(yīng)的依賴

RPC SDK 中的服務(wù)發(fā)現(xiàn)、路由尋址、限流熔斷等特性，是更易于變更的，我們將這部分能力下沉至獨(dú)立的 Sidecar 中，可以復(fù)用這部分能力，讓多語言的 SDK 只實(shí)現(xiàn)最基本的序列化與通訊協(xié)議，而這些能力是很輕量且易于實(shí)現(xiàn)的。這里的 Sidecar 我們是希望它作為獨(dú)立進(jìn)程存在，和業(yè)務(wù)應(yīng)用的進(jìn)程剝離，并和業(yè)務(wù)應(yīng)用的升級解耦開來，實(shí)現(xiàn)業(yè)務(wù)和基礎(chǔ)設(shè)施并行發(fā)展，互不干擾的愿景。

圖10. RPC 消息與數(shù)據(jù)源能力下沉

除了 RPC 通訊，我們還可以下沉消息、數(shù)據(jù)源等能力至 Sidecar 中，業(yè)務(wù)應(yīng)用可以越來越薄，SDK 實(shí)現(xiàn)成本也降低到可接受的程度，基礎(chǔ)設(shè)施層與業(yè)務(wù)剝離，雙方均可獨(dú)立演進(jìn)。

| 落地架構(gòu)

整體架構(gòu)

圖11. Mesh 落地架構(gòu)

不同于開源的 Istio 體系，螞蟻科技內(nèi)部版 Service Mesh 落地優(yōu)先考慮數(shù)據(jù)面的實(shí)現(xiàn)與落地，控制面在逐步建設(shè)中，整體的架構(gòu)上看，我們使用數(shù)據(jù)面直接和內(nèi)部的各種中間件服務(wù)端對接，來完成 RPC、消息等能力的下沉，給業(yè)務(wù)應(yīng)用減負(fù)。由上圖可以看出，我們將不同的 Sidecar 與業(yè)務(wù)應(yīng)用編排在同一個(gè) Pod 中，App 與 SOFAMosn 直接通訊，SOFAMosn 來負(fù)責(zé)目標(biāo)接口的服務(wù)發(fā)現(xiàn)、路由尋址，并且由 SOFAMosn 內(nèi)置的安全模塊來做應(yīng)用間調(diào)用的加密鑒權(quán)。通過 DBMesh 的 Sidecar 來實(shí)現(xiàn)數(shù)據(jù)層的下沉，App 不在需要與多個(gè)數(shù)據(jù)源建立連接，只需要連接本 Pod 內(nèi)的 DBMesh 即可完成數(shù)據(jù)層調(diào)用，數(shù)據(jù)庫的用戶名、密碼、分庫分表規(guī)則等均不再需要關(guān)心。

圖中名詞解析：

• ConfigServer：配置中心，負(fù)責(zé)各種元數(shù)據(jù)配置、動(dòng)態(tài)開關(guān)等

• Registry：服務(wù)注冊中心，負(fù)責(zé) IDC 內(nèi)服務(wù)發(fā)現(xiàn)

• AntVip：類 DNS 解析的產(chǎn)品，可通過域名解析一組目標(biāo)地址，用于跨 IDC 服務(wù)發(fā)現(xiàn)

• MQ：消息中心服務(wù)端，用于收發(fā)消息

落地?cái)?shù)據(jù)

圖12. 落地 CPU 數(shù)據(jù)

目前這套架構(gòu)已經(jīng)在支付核心鏈路中做試點(diǎn)，618 大促 Mesh 化應(yīng)用對比無 Mesh 化應(yīng)用 CPU 損耗增長 1.7%，單筆交易整體耗時(shí)增長 5ms。CPU 增長是由于多出一個(gè)進(jìn)程，請求增加一條之后，RT 會(huì)有穩(wěn)定的小幅增長，但這些成本相比于整體架構(gòu)帶來的紅利，微乎其微，并且針對整個(gè)數(shù)據(jù)面的持續(xù)優(yōu)化是有望逐步減少資源占用，提升資源利用率。

降低打擾度

中間件能力下沉在架構(gòu)上看是可行的，實(shí)際落地如何做到無打擾的在奔跑的火車上換輪子，低打擾是一個(gè)非常重要的考量點(diǎn)。借助于 Kubernetes 的優(yōu)秀實(shí)踐，將業(yè)務(wù)容器與 Sidecar 容器編排在同一個(gè) Pod 中是比較合理的架構(gòu)，Sidecar 與業(yè)務(wù)容器互不干擾，互相升級均可做到雙方無感。

圖13. 落地方式

我們?yōu)榱俗寴I(yè)務(wù)應(yīng)用升級盡可能如絲般順滑，主要做了如下優(yōu)化方案：

1. 無感鏡像化

螞蟻科技內(nèi)部還有部分應(yīng)用未完成鏡像化，或者說以富容器的方式來使用鏡像化，這種方式也是在逐步淘汰的過程中，為了讓業(yè)務(wù)更順滑的鏡像化，PAAS 平臺(tái)聯(lián)動(dòng)整個(gè)研發(fā)體系，將應(yīng)用的打包過程通過自動(dòng)生成 Dockerfile 的方式主動(dòng)幫用戶完成鏡像化。做到用戶無感知鏡像化改造。

2. 低感 Mesh 化

鏡像化完成之后，想要借助 Pod 模型將應(yīng)用的容器和 SOFAMosn 的容器部署在一起，我們需要將底層資源管理與調(diào)度全部替換到 Kubernetes 體系。然后在 PAAS 上給 Mesh 化的應(yīng)用增加標(biāo)識，通過 Kubernetes 識別這些標(biāo)識并主動(dòng)注入 SOFAMosn sidecar 來完成應(yīng)用的 Mesh 化接入。

3. 無感 Sidecar 升級

Sidecar 與業(yè)務(wù)進(jìn)程獨(dú)立后，還有一個(gè)核心的訴求就是希望 Sidecar 可以獨(dú)立升級，為了讓 Sidecar 的升級盡量對生產(chǎn)做到無打擾，我們實(shí)現(xiàn)了 SOFAMosn 平滑升級的 Operator，通過對運(yùn)行中 SOFAMosn 的連接遷移，實(shí)現(xiàn)整個(gè)升級過程應(yīng)用完全無感知。當(dāng)然這里面包含著很多挑戰(zhàn)，后面我們會(huì)詳細(xì)介紹。

| 落地挑戰(zhàn)

Sidecar 平滑升級

目前我們已經(jīng)實(shí)現(xiàn) SOFAMosn 的平滑升級能力，SOFAMosn 的主要能力是 RPC 和 消息的通訊代理，平滑升級的目的是業(yè)務(wù) App 進(jìn)程不重啟，業(yè)務(wù)請求不中斷，完成 SOFAMosn 的版本升級。

圖14. SOFAMosn 平滑升級

由于SOFAMosn 與應(yīng)用是獨(dú)立的 container，如上圖描述，SOFAMosn 的升級是需要做到 Pod 內(nèi)鏡像的熱替換，這種熱替換能力必須要保障幾點(diǎn)：

Pod 不會(huì)被重建，應(yīng)用進(jìn)程始終正常運(yùn)行

鏡像的替換不會(huì)影響運(yùn)行中的流量

鏡像替換后整個(gè) Pod 描述需要進(jìn)行更新

為了達(dá)成以上目標(biāo)，我們通過對 Kubernetes 的改造以及自定義 Operator 來完成以上升級的處理。處理流程如下：

圖15. SOFAMosn 平滑升級流程

在不考慮多鏡像間做平滑升級的場景下，通過 Fork 進(jìn)程，可以繼承父進(jìn)程的 FD 來完成長連接的遷移，實(shí)現(xiàn)無損熱升級。SOFAMosn 以鏡像化的方式運(yùn)行后，平滑升級的難度極大增加。整個(gè)平滑升級的難點(diǎn)在于如何讓不同容器內(nèi)的SOFAMosn 進(jìn)程可互相感知并可完成連接遷移。

下面我們來看下SOFAMosn 升級過程中，如何保障流量無損：

圖16. 正常流量走向

SOFAMosn 處理的正常流量分為入口流量和出口流量，Client 可以看成和SOFAMosn 部署在同 Pod 內(nèi)的 App，Server 可以是請求調(diào)用的目標(biāo)服務(wù)提供方，可以是一個(gè) App 也可以是被調(diào)用 App 側(cè)的SOFAMosn。當(dāng)一筆請求從 Client 發(fā)至 Server 時(shí)，中間會(huì)經(jīng)過兩條長連接：TCP1 和 TCP2，SOFAMosn 會(huì)記錄這筆請求對應(yīng)的 ConnectionID，來完成請求的發(fā)起與響應(yīng)。

圖16. 正向流量遷移

當(dāng)新的 Mosn 容器被啟動(dòng)時(shí)，Mosn 會(huì)根據(jù)本地的 Domain Socket 來嘗試發(fā)送請求，當(dāng)另一個(gè) Mosn 進(jìn)程存在時(shí)，Mosn V1 和 Mosn V2 進(jìn)入熱升級模式，Mosn V1 會(huì)將已存在連接的 FD 和已讀出的數(shù)據(jù)包 通過 Domain Socket 發(fā)送至 Mosn V2 同時(shí) V1 將不會(huì)再從已遷移的 FD 中讀取數(shù)據(jù)，FD 遷移完成所有流量將會(huì)直接由 Mosn V2 來處理。

圖17. 逆向流量遷移

Mosn V1 和 Mosn V2 進(jìn)入熱升級模式之后，可能會(huì)存在 Mosn V1 已經(jīng)將請求發(fā)給 Server 后 Server 還沒有來得及響應(yīng)的情況，這種場景 Mosn V1 在遷移 FD 給 Mosn V2 時(shí)，Mosn V2 會(huì)在 FD 接管到之后的 ConnectionID 返回給 Mosn V1，當(dāng) Mosn V1 收到 Server 返回的 Response 之后，會(huì)將這筆請求通過 Domain Socket 發(fā)送給 Mosn V2，然后 Mosn V2 根據(jù) ConnectionId 即可找到 TCP1 的連接，然后響應(yīng)給 Client。

極致性能優(yōu)化

圖18. 請求合并寫

SOFAMosn 的核心網(wǎng)絡(luò)模型是完全自實(shí)現(xiàn)的，我們在整個(gè)網(wǎng)絡(luò)層做了非常多的優(yōu)化，通過 golang 的 writev 我們把多筆請求合并成一次寫，降低 sys.call 的調(diào)用，提升整體的性能與吞吐。同時(shí)在使用 writev 的過程中，有發(fā)現(xiàn) golang 對 writev 的實(shí)現(xiàn)有 bug，會(huì)導(dǎo)致部分內(nèi)存無法回收，我們給 golang 提交 PR 修復(fù)此問題，已被接受：https://github.com/golang/go/pull/32138?

其他優(yōu)化點(diǎn)還有很多，不再一一詳細(xì)描述，僅供思路參考，如：

• SOFAMosn 日志異步化，避免磁盤問題對 SOFAMosn 轉(zhuǎn)發(fā)性能的影響

• Route 路由結(jié)果緩存，空間換時(shí)間，提升吞吐

• 接近 90% 內(nèi)存復(fù)用，盡量避免字節(jié)拷貝

• Cluster 懶加載，提升 SOFAMosn 啟動(dòng)速度

• 通訊協(xié)議層優(yōu)化，低版本協(xié)議針對性升級，降低解包成本

| 演進(jìn)方向

圖19. 演進(jìn)方向控制面結(jié)合

Service Mesh 的控制面建設(shè)我們也在規(guī)劃中逐步向前推進(jìn)，希望能統(tǒng)一數(shù)據(jù)面和控制面的交互模型，控制面盡量遵循 SMI 標(biāo)準(zhǔn)，增加對 TCP 協(xié)議的描述支持，逐步增強(qiáng) SOFAMosn 作為數(shù)據(jù)面的穩(wěn)定性，減少變更頻率，用更通用的模型來描述服務(wù)發(fā)現(xiàn)、服務(wù)治理等場景，DBMesh 也會(huì)基于 XDS 做配置的下發(fā)，統(tǒng)一又控制面收口數(shù)據(jù)下發(fā)通道。這里控制面直接對接中間件的服務(wù)端是基于性能與容量考慮，螞蟻科技內(nèi)部的服務(wù)發(fā)現(xiàn)數(shù)據(jù)達(dá)單機(jī)房千萬級別，使用 Kubernetes 的 ETCD 無法承載如此巨大的數(shù)據(jù)量，需要又控制面做橋梁并分片服務(wù)于不同的數(shù)據(jù)面。

圖20. 產(chǎn)品化模型

接下來還會(huì)有完整的產(chǎn)品層建設(shè)，借助于 Mesh 化架構(gòu)的思想，更多的能力希望通過下沉至 Sidecar 的方式來拿到架構(gòu)升級帶來的紅利。Mesh 的產(chǎn)品層將會(huì)包括多種 Mesh 數(shù)據(jù)面形態(tài)的 Metrics 采集、監(jiān)控大盤，控制面的統(tǒng)一對外途徑，屏蔽外部系統(tǒng)與 Mesh 的交互復(fù)雜度，統(tǒng)一控制面與數(shù)據(jù)面交互協(xié)議，通過完善的運(yùn)維體系建設(shè)，提升 Mesh 模式下的 Sidecar 灰度升級能力，做到對應(yīng)用無打擾且穩(wěn)定無人值守即可完成版本升級的目的。

| 總結(jié)

總結(jié)一下全文在 Service Mesh 領(lǐng)域的落地實(shí)踐，可以歸納為以下六點(diǎn)：

• 應(yīng)用層與基礎(chǔ)設(shè)施層分離

• 基礎(chǔ)設(shè)置層一次編寫多處復(fù)用

• 數(shù)據(jù)面通過能力平移優(yōu)先落地

• 降低打擾度提升落地效率

• 控制面建設(shè)統(tǒng)一數(shù)據(jù)面配置模型

• 性能、穩(wěn)定性、可觀測性持續(xù)優(yōu)化

本文介紹了螞蟻科技在 Service Mesh 落地的演進(jìn)過程以及相關(guān)痛點(diǎn)的解決方式，希望可以通過我們的實(shí)際經(jīng)歷來為讀者帶來一些不同與社區(qū)主流方案的演進(jìn)思考。

總結(jié)

以上是生活随笔為你收集整理的蚂蚁科技 Service Mesh 落地实践与挑战的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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