蚂蚁金服 Service Mesh 落地实践与挑战|成都Service Mesh沙龙预告
本文整理自 GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）全球互聯(lián)網(wǎng)架構(gòu)大會，螞蟻金服平臺數(shù)據(jù)技術(shù)事業(yè)群技術(shù)專家石建偉（花名：卓與）的分享。分享基于 Service Mesh 的理念，結(jié)合螞蟻金服內(nèi)部實際場景，將中間件、數(shù)據(jù)層、安全層等能力從應(yīng)用中剝離出來后下沉至獨立的 Sidecar SOFAMosn 中，結(jié)合 Kubernetes 運維體系，提供應(yīng)用無感知的情況下升級基礎(chǔ)設(shè)施層能力的案例。
本次分享將從以如下次序展開進行：
| 螞蟻金服當(dāng)前的服務(wù)化現(xiàn)狀
在看螞蟻金服的服務(wù)化架構(gòu)之前我們先從一個簡單的服務(wù)化調(diào)用示例說起，下圖是 SOFARPC 基本原理：
圖1. SOFARPC 基本原理
我們從上圖可以看出，構(gòu)建一個服務(wù)化框架需要有服務(wù)注冊中心，有服務(wù)定義，調(diào)用方和服務(wù)提供方使用相同的服務(wù)定義來互相通訊。通過服務(wù)注冊中心，調(diào)用方可以直接訂閱到服務(wù)提供方的地址，采用點對點的方式直接發(fā)起請求。客戶端內(nèi)可實現(xiàn)服務(wù)發(fā)現(xiàn)、路由尋址、負載均衡、限流熔斷等能力來增強服務(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ù)，這個數(shù)據(jù)背后有非常復(fù)雜的架構(gòu)支持，LDC 單元化架構(gòu)是螞蟻金服沉淀多年的核心架構(gòu)，依靠這個架構(gòu)實現(xiàn)每年峰值交易量飛速增長下系統(tǒng)依然能平滑渡過。我們來簡要看下 LDC 架構(gòu)：
圖3. LDC 架構(gòu)示例
上圖摘自 金融級分布式架構(gòu) 中的?素描單元化?一文，這里不詳細展開。LDC 的單元化架構(gòu)給應(yīng)用的服務(wù)化帶來更多的規(guī)范與抽象，服務(wù)路由中需要考慮單元間的調(diào)用，跨機房調(diào)用等更多場景。這里主要希望表達的是 LDC 架構(gòu)給 RPC 調(diào)用帶來更高的復(fù)雜度。
| 服務(wù)化痛點
中間件版本升級
在上面介紹背景時，有介紹到目前 LDC 架構(gòu)下服務(wù)調(diào)用的復(fù)雜度，這些復(fù)雜度目前是直接體現(xiàn)在應(yīng)用的代碼中。對于業(yè)務(wù)同學(xué)來講，一個應(yīng)用的關(guān)注重點是如何實現(xiàn)業(yè)務(wù)邏輯，至于高可用、容災(zāi)等能力更多是整體架構(gòu)層面會考慮的點。應(yīng)用內(nèi)通過引入 RPC 的 jar 包即可獲得 LDC 架構(gòu)下服務(wù)調(diào)用各種能力的支撐，帶來便利的同時也可以看到這種模式的缺點：
圖4. APP 業(yè)務(wù)與 SDK 組成部分
應(yīng)用內(nèi)除業(yè)務(wù)邏輯之外，由中間件的 SDK 引入大量外部依賴，來完成服務(wù)發(fā)現(xiàn)、路由尋址、負載均衡、限流熔斷、序列化、通訊等能力，每個組件的引入都可能帶來穩(wěn)定性風(fēng)險，以及更高的升級成本。
圖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)⒂嬎隳壳?Zone 然后確定調(diào)用目標，限流熔斷依賴 Guardian 組件，通訊協(xié)議與序列化協(xié)議相對穩(wěn)定，變更較少。僅為了完成服務(wù)調(diào)用，應(yīng)用需要額外引入 7+ 客戶端包。
每年雙 11 需要涉及到架構(gòu)調(diào)整時：比如支持彈性架構(gòu)，需要做很多中間件客戶端的版本升級來支撐更優(yōu)的架構(gòu)，對于業(yè)務(wù)同學(xué)來講，這些升級是很耗費精力的，拿 200 個核心應(yīng)用舉例，每個應(yīng)用升級中間件版本經(jīng)過研發(fā)、測試、再到部署預(yù)發(fā)、灰度、生產(chǎn)等環(huán)境需要 5個人日的話，200 個核心應(yīng)用中間件升級需要耗費 1000 人日，如果這部分時間可以節(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è)施，前端團隊使用 NodeJS 逐步重寫了各種中間件客戶端，讓整個 NodeJS 和 Java 體系可以完美互通。
圖6. Java 與 NodeJS 互調(diào)
中間件 SDK 跨語言重寫與維護成本極高，隨著語言種類的增多，跨語言通訊的訴求也越來越多。
圖7. 多語言場景
Java, NodeJS, Go, Python, C++ 等，5+ 語言，中間件 SDK 全部重寫成本極高。這些問題不得不激勵我們尋找更優(yōu)的解法。
| 解決痛點
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)、路由尋址、限流熔斷等特性，是更易于變更的，我們將這部分能力下沉至獨立的 Sidecar 中，可以復(fù)用這部分能力，讓多語言的 SDK 只實現(xiàn)最基本的序列化與通訊協(xié)議，而這些能力是很輕量且易于實現(xiàn)的。這里的 Sidecar 我們是希望它作為獨立進程存在，和業(yè)務(wù)應(yīng)用的進程剝離，并和業(yè)務(wù)應(yīng)用的升級解耦開來，實現(xiàn)業(yè)務(wù)和基礎(chǔ)設(shè)施并行發(fā)展，互不干擾的愿景。
圖10. RPC 消息與數(shù)據(jù)源能力下沉
除了 RPC 通訊，我們還可以下沉消息、數(shù)據(jù)源等能力至 Sidecar 中，業(yè)務(wù)應(yīng)用可以越來越薄，SDK 實現(xiàn)成本也降低到可接受的程度，基礎(chǔ)設(shè)施層與業(yè)務(wù)剝離，雙方均可獨立演進。
| 落地架構(gòu)
整體架構(gòu)
圖11. Mesh 落地架構(gòu)
不同于開源的 Istio 體系，螞蟻金服內(nèi)部版 Service Mesh 落地優(yōu)先考慮數(shù)據(jù)面的實現(xiàn)與落地，控制面在逐步建設(shè)中，整體的架構(gòu)上看，我們使用數(shù)據(jù)面直接和內(nèi)部的各種中間件服務(wù)端對接，來完成 RPC、消息等能力的下沉，給業(yè)務(wù)應(yīng)用減負。由上圖可以看出，我們將不同的 Sidecar 與業(yè)務(wù)應(yīng)用編排在同一個 Pod 中，App 與 SOFAMosn 直接通訊，SOFAMosn 來負責(zé)目標接口的服務(wù)發(fā)現(xiàn)、路由尋址，并且由 SOFAMosn 內(nèi)置的安全模塊來做應(yīng)用間調(diào)用的加密鑒權(quán)。通過 DBMesh 的 Sidecar 來實現(xiàn)數(shù)據(jù)層的下沉，App 不在需要與多個數(shù)據(jù)源建立連接，只需要連接本 Pod 內(nèi)的 DBMesh 即可完成數(shù)據(jù)層調(diào)用，數(shù)據(jù)庫的用戶名、密碼、分庫分表規(guī)則等均不再需要關(guān)心。
圖中名詞解析：
ConfigServer：配置中心，負責(zé)各種元數(shù)據(jù)配置、動態(tài)開關(guān)等
Registry：服務(wù)注冊中心，負責(zé) IDC 內(nèi)服務(wù)發(fā)現(xiàn)
AntVip：類 DNS 解析的產(chǎn)品，可通過域名解析一組目標地址，用于跨 IDC 服務(wù)發(fā)現(xiàn)
MQ：消息中心服務(wù)端，用于收發(fā)消息
落地數(shù)據(jù)
圖12. 落地 CPU 數(shù)據(jù)
目前這套架構(gòu)已經(jīng)在支付核心鏈路中做試點，618 大促 Mesh 化應(yīng)用對比無 Mesh 化應(yīng)用 CPU 損耗增長 1.7%，單筆交易整體耗時增長 5ms。CPU 增長是由于多出一個進程，請求增加一條之后，RT 會有穩(wěn)定的小幅增長，但這些成本相比于整體架構(gòu)帶來的紅利，微乎其微，并且針對整個數(shù)據(jù)面的持續(xù)優(yōu)化是有望逐步減少資源占用，提升資源利用率。
降低打擾度
中間件能力下沉在架構(gòu)上看是可行的，實際落地如何做到無打擾的在奔跑的火車上換輪子，低打擾是一個非常重要的考量點。借助于 Kubernetes 的優(yōu)秀實踐，將業(yè)務(wù)容器與 Sidecar 容器編排在同一個 Pod 中是比較合理的架構(gòu)，Sidecar 與業(yè)務(wù)容器互不干擾，互相升級均可做到雙方無感。
圖13. 落地方式
我們?yōu)榱俗寴I(yè)務(wù)應(yīng)用升級盡可能如絲般順滑，主要做了如下優(yōu)化方案：
1. 無感鏡像化
螞蟻金服內(nèi)部還有部分應(yīng)用未完成鏡像化，或者說以富容器的方式來使用鏡像化，這種方式也是在逐步淘汰的過程中，為了讓業(yè)務(wù)更順滑的鏡像化，PAAS 平臺聯(lián)動整個研發(fā)體系，將應(yīng)用的打包過程通過自動生成 Dockerfile 的方式主動幫用戶完成鏡像化。做到用戶無感知鏡像化改造。
2. 低感 Mesh 化
鏡像化完成之后，想要借助 Pod 模型將應(yīng)用的容器和 SOFAMosn 的容器部署在一起，我們需要將底層資源管理與調(diào)度全部替換到 Kubernetes 體系。然后在 PAAS 上給 Mesh 化的應(yīng)用增加標識，通過 Kubernetes 識別這些標識并主動注入 SOFAMosn sidecar 來完成應(yīng)用的 Mesh 化接入。
3. 無感 Sidecar 升級
Sidecar 與業(yè)務(wù)進程獨立后，還有一個核心的訴求就是希望 Sidecar 可以獨立升級，為了讓 Sidecar 的升級盡量對生產(chǎn)做到無打擾，我們實現(xiàn)了 SOFAMosn 平滑升級的 Operator，通過對運行中 SOFAMosn 的連接遷移，實現(xiàn)整個升級過程應(yīng)用完全無感知。當(dāng)然這里面包含著很多挑戰(zhàn)，后面我們會詳細介紹。
| 落地挑戰(zhàn)
Sidecar 平滑升級
目前我們已經(jīng)實現(xiàn) SOFAMosn 的平滑升級能力，SOFAMosn 的主要能力是 RPC 和 消息的通訊代理，平滑升級的目的是業(yè)務(wù) App 進程不重啟，業(yè)務(wù)請求不中斷，完成 SOFAMosn 的版本升級。
圖14. SOFAMosn 平滑升級
由于 SOFAMosn 與應(yīng)用是獨立的 container，如上圖描述，SOFAMosn 的升級是需要做到 Pod 內(nèi)鏡像的熱替換，這種熱替換能力必須要保障幾點：
Pod 不會被重建，應(yīng)用進程始終正常運行
鏡像的替換不會影響運行中的流量
鏡像替換后整個 Pod 描述需要進行更新
為了達成以上目標，我們通過對 Kubernetes 的改造以及自定義 Operator 來完成以上升級的處理。處理流程如下：
圖15. SOFAMosn 平滑升級流程
在不考慮多鏡像間做平滑升級的場景下，通過 Fork 進程，可以繼承父進程的 FD 來完成長連接的遷移，實現(xiàn)無損熱升級。SOFAMosn 以鏡像化的方式運行后，平滑升級的難度極大增加。整個平滑升級的難點在于如何讓不同容器內(nèi)的 SOFAMosn 進程可互相感知并可完成連接遷移。
下面我們來看下 SOFAMosn 升級過程中，如何保障流量無損：
圖16. 正常流量走向
SOFAMosn 處理的正常流量分為入口流量和出口流量，Client 可以看成和 SOFAMosn 部署在同 Pod 內(nèi)的 App，Server 可以是請求調(diào)用的目標服務(wù)提供方，可以是一個 App 也可以是被調(diào)用 App 側(cè)的 SOFAMosn。當(dāng)一筆請求從 Client 發(fā)至 Server 時，中間會經(jīng)過兩條長連接：TCP1 和 TCP2，SOFAMosn 會記錄這筆請求對應(yīng)的 ConnectionID，來完成請求的發(fā)起與響應(yīng)。
圖16. 正向流量遷移
當(dāng)新的 Mosn 容器被啟動時，Mosn 會根據(jù)本地的 Domain Socket 來嘗試發(fā)送請求，當(dāng)另一個 Mosn 進程存在時，Mosn V1 和 Mosn V2 進入熱升級模式，Mosn V1 會將已存在連接的 FD 和已讀出的數(shù)據(jù)包 通過 Domain Socket 發(fā)送至 Mosn V2 同時 V1 將不會再從已遷移的 FD 中讀取數(shù)據(jù)，FD 遷移完成所有流量將會直接由 Mosn V2 來處理。
圖17. 逆向流量遷移
Mosn V1 和 Mosn V2 進入熱升級模式之后，可能會存在 Mosn V1 已經(jīng)將請求發(fā)給 Server 后 Server 還沒有來得及響應(yīng)的情況，這種場景 Mosn V1 在遷移 FD 給 Mosn V2 時，Mosn V2 會在 FD 接管到之后的 ConnectionID 返回給 Mosn V1，當(dāng) Mosn V1 收到 Server 返回的 Response 之后，會將這筆請求通過 Domain Socket 發(fā)送給 Mosn V2，然后 Mosn V2 根據(jù) ConnectionId 即可找到 TCP1 的連接，然后響應(yīng)給 Client。
極致性能優(yōu)化
圖18. 請求合并寫
SOFAMosn 的核心網(wǎng)絡(luò)模型是完全自實現(xiàn)的，我們在整個網(wǎng)絡(luò)層做了非常多的優(yōu)化，通過 golang 的 writev 我們把多筆請求合并成一次寫，降低 sys.call 的調(diào)用，提升整體的性能與吞吐。同時在使用 writev 的過程中，有發(fā)現(xiàn) golang 對 writev 的實現(xiàn)有 bug，會導(dǎo)致部分內(nèi)存無法回收，我們給 golang 提交 PR 修復(fù)此問題，已被接受：https://github.com/golang/go/pull/32138?
SOFAMosn 日志異步化，避免磁盤問題對 SOFAMosn 轉(zhuǎn)發(fā)性能的影響
Route 路由結(jié)果緩存，空間換時間，提升吞吐
接近 90% 內(nèi)存復(fù)用，盡量避免字節(jié)拷貝
Cluster 懶加載，提升 SOFAMosn 啟動速度
通訊協(xié)議層優(yōu)化，低版本協(xié)議針對性升級，降低解包成本
| 演進方向
圖19. 演進方向控制面結(jié)合
Service Mesh 的控制面建設(shè)我們也在規(guī)劃中逐步向前推進，希望能統(tǒng)一數(shù)據(jù)面和控制面的交互模型，控制面盡量遵循 SMI 標準，增加對 TCP 協(xié)議的描述支持，逐步增強 SOFAMosn 作為數(shù)據(jù)面的穩(wěn)定性，減少變更頻率，用更通用的模型來描述服務(wù)發(fā)現(xiàn)、服務(wù)治理等場景，DBMesh 也會基于 XDS 做配置的下發(fā)，統(tǒng)一又控制面收口數(shù)據(jù)下發(fā)通道。這里控制面直接對接中間件的服務(wù)端是基于性能與容量考慮，螞蟻金服內(nèi)部的服務(wù)發(fā)現(xiàn)數(shù)據(jù)達單機房千萬級別，使用 Kubernetes 的 ETCD 無法承載如此巨大的數(shù)據(jù)量，需要又控制面做橋梁并分片服務(wù)于不同的數(shù)據(jù)面。
圖20. 產(chǎn)品化模型
接下來還會有完整的產(chǎn)品層建設(shè)，借助于 Mesh 化架構(gòu)的思想，更多的能力希望通過下沉至 Sidecar 的方式來拿到架構(gòu)升級帶來的紅利。Mesh 的產(chǎn)品層將會包括多種 Mesh 數(shù)據(jù)面形態(tài)的 Metrics 采集、監(jiān)控大盤，控制面的統(tǒng)一對外途徑，屏蔽外部系統(tǒng)與 Mesh 的交互復(fù)雜度，統(tǒng)一控制面與數(shù)據(jù)面交互協(xié)議，通過完善的運維體系建設(shè)，提升 Mesh 模式下的 Sidecar 灰度升級能力，做到對應(yīng)用無打擾且穩(wěn)定無人值守即可完成版本升級的目的。
| 總結(jié)
總結(jié)一下全文在 Service Mesh 領(lǐng)域的落地實踐，可以歸納為以下六點：
應(yīng)用層與基礎(chǔ)設(shè)施層分離
基礎(chǔ)設(shè)置層一次編寫多處復(fù)用
數(shù)據(jù)面通過能力平移優(yōu)先落地
降低打擾度提升落地效率
控制面建設(shè)統(tǒng)一數(shù)據(jù)面配置模型
性能、穩(wěn)定性、可觀測性持續(xù)優(yōu)化
本文介紹了螞蟻金服在 Service Mesh 落地的演進過程以及相關(guān)痛點的解決方式，希望可以通過我們的實際經(jīng)歷來為讀者帶來一些不同與社區(qū)主流方案的演進思考。
提到的相關(guān)開源組件地址：
SOFAMosn：
https://github.com/sofastack/sofa-mosn
SOFARPC：
https://github.com/sofastack/sofa-rpc
SOFARegistry：
https://github.com/sofastack/sofa-registry
SOFABoot：
https://github.com/sofastack/sofa-boot
在 KubeCon&CloudNativeCon&Open Source Summit 上，SOFAStack 進行了全天的 Workshop，其中提供了 Service Mesh 實踐 Demo，我們將在近期同步，請關(guān)注下圖二維碼噢
華麗的分割線
成都沙龍預(yù)告
活動詳情
孟秋廿二，風(fēng)云際會。
數(shù)字變局，誰主沉浮？
今道客落地錦城，扎根生長，服務(wù)西部數(shù)據(jù)中心，
誠邀各路英豪，論道云原生，共商數(shù)字未來！
最開始 Service Mesh 的概念是由 Buoyant 公司在 2016 年提出。隨后幾年業(yè)內(nèi)就圍繞著 Service Mesh 思想探索出了各種實現(xiàn)。Service Mesh 被大家稱為下一代的微服務(wù)，是微服務(wù)領(lǐng)域的一顆新星。DaoCloud 和?中生代技術(shù)?誠邀您參加論道云原生系列沙龍「論道云原生 | Service Mesh 成都專場?」。
識別上圖二維碼或者點擊閱讀原文可以報名
總結(jié)
以上是生活随笔為你收集整理的蚂蚁金服 Service Mesh 落地实践与挑战|成都Service Mesh沙龙预告的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： QGLViewer编译过程
- 下一篇： 漫画: 可以给女朋友讲解 Linux 内