蚂蚁金服 Service Mesh 大规模落地系列 - 运维篇
《螞蟻金服 Service Mesh 大規(guī)模落地系列》將會(huì)從核心、RPC、消息、無線網(wǎng)關(guān)、控制面、安全、運(yùn)維、測(cè)試等模塊對(duì) Service Mesh 雙十一大規(guī)模落地實(shí)踐進(jìn)行詳細(xì)解析，文末包含往期系列文章。本文為該系列文章的第三篇 - 運(yùn)維篇。
引言
Service Mesh 是螞蟻金服下一代架構(gòu)的核心，也是螞蟻金服內(nèi)部向云原生演進(jìn)的重要一環(huán)。本文為 Service Mesh 系列文章的運(yùn)維篇，作者：黃家琦 （花名：嘉祁），螞蟻金服運(yùn)維專家，Service Mesh SRE，主要關(guān)注云原生基礎(chǔ)設(shè)施、中間件及 Service Mesh 的穩(wěn)定性，同時(shí)也是 Pythoner，sofa-bolt-python 作者。
本文將主要分享大規(guī)模服務(wù)網(wǎng)格在螞蟻金服當(dāng)前體量下落地到支撐螞蟻金服雙十一大促過程中，運(yùn)維角度所面臨的挑戰(zhàn)與演進(jìn)，包括云原生化的選擇與問題，對(duì)資源模型的挑戰(zhàn)，大規(guī)模下運(yùn)維設(shè)施的演進(jìn)，以及周邊技術(shù)風(fēng)險(xiǎn)能力的建設(shè)。
Service Mesh 在2019年得到了大規(guī)模的應(yīng)用與落地，截止目前，螞蟻金服的 Service Mesh 數(shù)據(jù)平面 MOSN 已接入應(yīng)用數(shù)百個(gè)，接入容器數(shù)量達(dá)數(shù)十萬，是目前已知的全世界最大的 Service Mesh 集群。同時(shí)，在剛剛結(jié)束的雙十一大促中，Service Mesh 的表現(xiàn)也十分亮眼，RPC 峰值 QPS 達(dá)到了幾千萬，消息峰值 TPS 達(dá)到了幾百萬，且引入 Service Mesh 后的平均 RT 增長(zhǎng)幅度控制在 0.2 ms 以內(nèi)。
擁抱云原生
Service Mesh 在軟件形態(tài)上，是將中間件的能力從框架中剝離成獨(dú)立軟件。而在具體部署上，保守的做法是以獨(dú)立進(jìn)程的方式與業(yè)務(wù)進(jìn)程共同存在于業(yè)務(wù)容器內(nèi)。我們?cè)谖浵伣鸱?nèi)部的做法，則從開始，就選擇了擁抱云原生。
Sidecar 模式
業(yè)務(wù)容器內(nèi)獨(dú)立進(jìn)程的好處在于與傳統(tǒng)的部署模式兼容，易于快速上線；但獨(dú)立進(jìn)程強(qiáng)侵入業(yè)務(wù)容器，對(duì)于鏡像化的容器更難于管理。而云原生化，則可以將 Service Mesh 本身的運(yùn)維與業(yè)務(wù)容器解耦開來，實(shí)現(xiàn)中間件運(yùn)維能力的下沉。在業(yè)務(wù)鏡像內(nèi)，僅僅保留長(zhǎng)期穩(wěn)定的 Service Mesh 相關(guān) JVM 參數(shù)，從而僅通過少量環(huán)境變量完成與 Service Mesh 的聯(lián)結(jié)。同時(shí)考慮到面向容器的運(yùn)維模式的演進(jìn)，接入 Service Mesh 還同時(shí)要求業(yè)務(wù)完成鏡像化，為進(jìn)一步的云原生演進(jìn)打下基礎(chǔ)。
優(yōu) | 劣 | |
獨(dú)立進(jìn)程 |
|
|
Sidecar |
|
|
在接入 Service Mesh 之后，一個(gè)典型的 POD 結(jié)構(gòu)可能包含多個(gè) Sidecar：
MOSN：RPC Mesh, MSG Mesh, ...（擴(kuò)展中）；
其它 Sidecar；
MOSN：https://github.com/sofastack/sofa-mosn
這些 Sidecar 容器，與業(yè)務(wù)容器共享相同的網(wǎng)絡(luò) Namespace，使得業(yè)務(wù)進(jìn)程可以以本地端口訪問 Service Mesh 提供的服務(wù)，保證了與保守做法一致的體驗(yàn)。
基礎(chǔ)設(shè)施云原生支撐
我們也在基礎(chǔ)設(shè)施層面同步推進(jìn)了面向云原生的改造，以支撐 Service Mesh 的落地。
業(yè)務(wù)全面鏡像化
首先是在螞蟻金服內(nèi)部推進(jìn)了全面的鏡像化，我們完成了內(nèi)部核心應(yīng)用的全量容器的鏡像化改造。改造點(diǎn)包括：
基礎(chǔ)鏡像層面增加對(duì)于 Service Mesh 的環(huán)境變量支撐；
應(yīng)用 Dockerfile 對(duì)于 Service Mesh 的適配；
推進(jìn)解決了存量前后端分離管理的靜態(tài)文件的鏡像化改造；
推進(jìn)了大量使用前端區(qū)塊分發(fā)的應(yīng)用進(jìn)行了推改拉的改造；
大批量的 VM 模式的容器升級(jí)與替換；
容器 POD 化
除了業(yè)務(wù)鏡像層面的改造，Sidecar 模式還需要業(yè)務(wù)容器全部跑在 POD 上，來適應(yīng)多容器共享網(wǎng)絡(luò)。由于直接升級(jí)的開發(fā)和試錯(cuò)成本很高，我們最終選擇將接入 Service Mesh 的 數(shù)百個(gè)應(yīng)用的數(shù)萬個(gè)非 K8s 容器，通過大規(guī)模擴(kuò)縮容的方式，全部更換成了 K8s PODs。
經(jīng)過這兩輪改造，我們?cè)诨A(chǔ)設(shè)施層面同步完成了面向云原生的改造。
資源的演進(jìn)
Sidecar 模式的帶來一個(gè)重要的問題，如何分配資源。
理想比例的假設(shè)
最初的資源設(shè)計(jì)基于內(nèi)存無法超賣的現(xiàn)實(shí)。我們做了一個(gè)假設(shè)：
MOSN 的基本資源占用與業(yè)務(wù)選擇的規(guī)格同比例這一假設(shè)。
CPU 和 Memory 申請(qǐng)與業(yè)務(wù)容器相應(yīng)比例的額外資源。這一比例最后設(shè)定在了 CPU 1/4，Memory 1/16。
此時(shí)一個(gè)典型 Pod 的資源分配如下圖示：
這一方式帶來了兩個(gè)問題：
螞蟻金服已經(jīng)實(shí)現(xiàn)了業(yè)務(wù)資源的 Quota 管控，但 Sidecar 并不在業(yè)務(wù)容器內(nèi)，Service Mesh 容器成為了一個(gè)資源泄漏點(diǎn)；
業(yè)務(wù)很多樣，部分高流量應(yīng)用的 Service Mesh 容器出現(xiàn)了嚴(yán)重的內(nèi)存不足和 OOM 情況；
完美分割的不完美
不止于此，為了快速支撐 Service Mesh 在非云環(huán)境的鋪開，上線了原地接入 Service Mesh。而原地接入 Service Mesh 的資源無法額外分配，在內(nèi)存不能超賣的情況下，采取了二次分割的分配方式。此時(shí)的 POD 內(nèi)存資源被切分為1/16內(nèi)存給 Sidecar，與15/16給業(yè)務(wù)容器。除了以上兩個(gè)問題，還帶來一些新的問題：
業(yè)務(wù)可見內(nèi)存不一致，業(yè)務(wù)監(jiān)控偏差，業(yè)務(wù)進(jìn)程 OOM 風(fēng)險(xiǎn)。
討論之后，我們追加了一個(gè)假設(shè)：
Service Mesh 容器占用的資源實(shí)質(zhì)是在接入 Service Mesh 之前業(yè)務(wù)已使用的資源。接入 Service Mesh 的過程，同時(shí)也是一次資源置換。
共享
基于這個(gè)假設(shè)，推進(jìn)了調(diào)度層面支持 POD 內(nèi)的資源超賣，新的資源分配方案如下圖，Service Mesh 容器的 CPU、MEM 都從 POD 中超賣出來，業(yè)務(wù)容器內(nèi)仍然可以看到全部的資源。
考慮到內(nèi)存超賣也引入了 POD OOM 的風(fēng)險(xiǎn)，因此對(duì)于 Sidecar 容器還調(diào)整了 OOM Score，保證在內(nèi)存不足時(shí)，Service Mesh 進(jìn)程能夠發(fā)揮啟動(dòng)比 Java 業(yè)務(wù)進(jìn)程更快的優(yōu)勢(shì)，降低影響。
新的分配方案解決了同時(shí)解決了以上兩個(gè)問題，并且平穩(wěn)支持了大促前的多輪壓測(cè)。
重建
但新的分配方案上線時(shí)，Service Mesh 已經(jīng)在彈性建站時(shí)同步上線。同時(shí)我們還發(fā)現(xiàn)在一些場(chǎng)景下，Service Mesh 容器無法搶占到 CPU 資源，導(dǎo)致業(yè)務(wù) RT 出現(xiàn)了大幅抖動(dòng)，原因是在 CPU Share 模式下，POD 內(nèi)默認(rèn)并沒有等額的分配 CPU Quota 給 Sidecar。
于是還有兩個(gè)問題待解決：
存量的已分配 Sidecar 仍有 OOM 風(fēng)險(xiǎn)；
Sidecar 無法搶占到 CPU；
我們已經(jīng)無法承受更換全部 POD 的代價(jià)。最終在調(diào)度的支持下，通過對(duì) Pod Annotation 的手動(dòng)重新計(jì)算+修改，在 POD 內(nèi)進(jìn)行了全部資源的重分配，來修復(fù)這兩個(gè)風(fēng)險(xiǎn)。最終的修復(fù)容器總數(shù)約 25w 個(gè)。
變更與規(guī)模化下的運(yùn)維挑戰(zhàn)
Service Mesh 的變更包括了接入與升級(jí)，所有變更底層都是由 Operator 組件來接受上層寫入到 POD annotation 上的標(biāo)識(shí)，對(duì)相應(yīng) POD Spec 進(jìn)行修改來完成，這是典型的云原生的方式。由于螞蟻金服的資源現(xiàn)狀與運(yùn)維需要，又發(fā)展出了原地接入與平滑升級(jí)。與 Operator 有關(guān)的具體細(xì)節(jié)在 Operator 篇中會(huì)詳細(xì)介紹，請(qǐng)持續(xù)關(guān)注本公眾號(hào)。
接入
最初的 Service Mesh 接入只提供了創(chuàng)建時(shí)注入 Sidecar。之后引入原地接入的原因，是為了支撐大規(guī)模的快速接入與回滾。
創(chuàng)建接入：
資源替換過程需要大量 Buffer；
回滾困難；
原地接入：
不需要重新分配資源；
可原地回滾；
原地接入/回滾需要對(duì) POD Spec 進(jìn)行精細(xì)化的修改，實(shí)踐中發(fā)現(xiàn)了很多問題，當(dāng)前能力只做了小范圍的測(cè)試。
升級(jí)
Service Mesh 是深度參與業(yè)務(wù)流量的，因此最初的 Sidecar 的升級(jí)方式也需要業(yè)務(wù)伴隨重啟。看似簡(jiǎn)單的這個(gè)過程中，我們也遇到了一個(gè)嚴(yán)重問題：
Pod 內(nèi)的容器啟動(dòng)順序隨機(jī)導(dǎo)致業(yè)務(wù)無法啟動(dòng)。
這個(gè)問題最終依賴于調(diào)度層修改了啟動(dòng)邏輯，POD 內(nèi)需要優(yōu)先等待所有 Sidecar 啟動(dòng)完成，于是帶來第二個(gè)問題：
Sidecar 啟動(dòng)慢了，上層超時(shí)。
此問題仍在解決中。
Sidecar 中，MOSN 提供了更為靈活的平滑升級(jí)機(jī)制：由 Operator 控制啟動(dòng)第二個(gè) MOSN Sidecar，完成連接遷移，再退出舊的 Sidecar。小規(guī)模測(cè)試顯示，整個(gè)過程業(yè)務(wù)可以做到流量不中斷，幾近無感。目前平滑升級(jí)同樣涉及到 POD Spec 的大量操作，考慮到大促前的穩(wěn)定性，目前此方式未做大規(guī)模使用。
規(guī)模化的問題
在逐漸達(dá)到大促狀態(tài)的過程中，接入 Service Mesh 的容器數(shù)量開始大爆炸式增加。容器數(shù)量從千級(jí)別迅速膨脹到10w+，最終達(dá)到全站數(shù)十萬容器規(guī)模，并在膨脹后還經(jīng)歷了數(shù)次版本變更。
快速奔跑的同時(shí)，缺少相應(yīng)的平臺(tái)能力也給大規(guī)模的 Sidecar 運(yùn)維帶來了極大挑戰(zhàn)：
版本管理混亂：
Sidecar 的版本與應(yīng)用/ Zone 的映射關(guān)系維護(hù)在內(nèi)部元數(shù)據(jù)平臺(tái)的配置中。大量應(yīng)用接入后，全局版本，實(shí)驗(yàn)版本，特殊 Bugfix 版本等混雜在多個(gè)配置項(xiàng)中，統(tǒng)一基線被打破，難于維護(hù)。
元數(shù)據(jù)不一致：
元數(shù)據(jù)平臺(tái)維護(hù)了 POD 粒度的 Sidecar 版本信息，但是由于 Operator 是面向終態(tài)的，會(huì)出現(xiàn)元數(shù)據(jù)與底層實(shí)際不一致的情況，當(dāng)前仍依賴巡檢發(fā)現(xiàn)。
缺少完善的 Sidecar ops 支撐平臺(tái)：
缺少多維度的全局視圖；
缺少固化的灰度發(fā)布流程；
依賴于人工經(jīng)驗(yàn)配置管理變更；
監(jiān)控噪聲巨大；
當(dāng)然，Service Mesh 與 PaaS 的開發(fā)團(tuán)隊(duì)都已經(jīng)在建設(shè)相應(yīng)的一些能力，這些問題正得到逐步的緩解。
技術(shù)風(fēng)險(xiǎn)建設(shè)
監(jiān)控能力
我們的監(jiān)控平臺(tái)為 Service Mesh 提供了基礎(chǔ)的監(jiān)控能力和大盤，以及應(yīng)用維度的 Sidecar 的監(jiān)控情況。包括：
系統(tǒng)監(jiān)控：
CPU；
MEM；
LOAD；
業(yè)務(wù)監(jiān)控：
RT；
RPC 流量；
MSG 流量；
Error 日志監(jiān)控；
Service Mesh 進(jìn)程還提供了相應(yīng)的 Metrics 接口，提供服務(wù)粒度的數(shù)據(jù)采集與計(jì)算。
巡檢
在 Service Mesh 上線后，巡檢也陸續(xù)被加入：
日志 Volume 檢查；
版本一致性；
分時(shí)調(diào)度狀態(tài)一致；
預(yù)案與應(yīng)急
Service Mesh 自身具備按需關(guān)閉部分功能的能力，當(dāng)前通過配置中心實(shí)現(xiàn)：
日志分級(jí)降級(jí)；
Tracelog 日志分級(jí)降級(jí)；
控制面(Pilot)依賴降級(jí)；
軟負(fù)載均衡長(zhǎng)輪詢降級(jí)；
對(duì)于 Service Mesh 依賴的服務(wù)，為了防止?jié)撛诘亩秳?dòng)風(fēng)險(xiǎn)，也增加了相應(yīng)的預(yù)案：
軟負(fù)載均衡列表停止變更；
服務(wù)注冊(cè)中心高峰期關(guān)閉推送；
Service Mesh 是非常基礎(chǔ)的組件，目前的應(yīng)急手段主要是重啟：
Sidecar 單獨(dú)重啟；
POD 重啟；
變更風(fēng)險(xiǎn)防控
除了傳統(tǒng)的變更三板斧之外，我們還引入了無人值守變更，對(duì) Service Mesh 變更做了自動(dòng)檢測(cè)，自動(dòng)分析與變更熔斷。
無人值守變更防控主要關(guān)注變更后對(duì)系統(tǒng)和業(yè)務(wù)和影響，串聯(lián)了多層檢測(cè)，主要包括：
系統(tǒng)指標(biāo)：包括機(jī)器內(nèi)存、磁盤、CPU；
業(yè)務(wù)指標(biāo)：業(yè)務(wù)和 Service Mesh 的 RT、QPS 等；
業(yè)務(wù)關(guān)聯(lián)鏈路：業(yè)務(wù)上下游的的異常情況；
全局的業(yè)務(wù)指標(biāo)；
經(jīng)過這一系列防控設(shè)施，可以將全站性的 Service Mesh 變更風(fēng)險(xiǎn)在單一批次變更內(nèi)發(fā)現(xiàn)和阻斷，避免了風(fēng)險(xiǎn)放大。
未來
Service Mesh 在快速落地的過程中，遇到并解決了一系列的問題，但同時(shí)也要看到還有更多的問題還亟待解決。做為下一代云原生化中間件的核心組件之一，Service Mesh 的技術(shù)風(fēng)險(xiǎn)能力還需要持續(xù)的建議與完善。未來需要在下面這些方面持續(xù)建設(shè)：
大規(guī)模高效接入與回滾能力支撐；
更靈活的變更能力，包括業(yè)務(wù)無感的平滑/非平滑變更能力；
更精準(zhǔn)的變更防控能力；
更高效，低噪聲的監(jiān)控；
更完善的控制面支持；
應(yīng)用維度的參數(shù)定制能力；
歡迎有志于中間件 Service Mesh 化與云原生穩(wěn)定性的同學(xué)加入我們，共同建設(shè) Service Mesh 的未來。
往期系列閱讀
螞蟻金服 Service Mesh 大規(guī)模落地系列 - 消息篇
螞蟻金服 Service Mesh 大規(guī)模落地系列 - 核心篇
Service Mesh 落地負(fù)責(zé)人親述：螞蟻金服雙十一四大考題
?????獎(jiǎng)勵(lì)支持 SOFAStack 的你~
* 點(diǎn)下右下角“在看”
總結(jié)
以上是生活随笔為你收集整理的蚂蚁金服 Service Mesh 大规模落地系列 - 运维篇的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 动态规划之——又见拦截导弹（nyoj81
- 下一篇： JeecgBoot 常见问题QA