導(dǎo)語:上次跟大家分享了 螞蟻Service Mesh探索與思考(上):打造不一樣的基礎(chǔ)能力。在過去的一年多時(shí)間里,螞蟻在 Service Mesh 上建設(shè)了大量能力,而這些基礎(chǔ)設(shè)施能力的快速演進(jìn)正是得益于 Service Mesh 將業(yè)務(wù)和基礎(chǔ)設(shè)施的解耦。
在 Service Mesh 落地之后,我們曾設(shè)想過 Service Mesh 再向前探索可能會遇到的種種困難,包括資源利用率、性能損耗等等,但是未曾想到過去一年中最大的挑戰(zhàn)是研發(fā)效能。
研發(fā)能效的挑戰(zhàn)
當(dāng) Service Mesh 的優(yōu)勢逐漸顯現(xiàn),越來越多的能力希望下沉到 MOSN 中。而我們也逐漸發(fā)現(xiàn) MOSN 在實(shí)際迭代過程中遇到的一些困難,其中比較突出的兩個(gè)難題:
1. 變更量大:大量的功能希望進(jìn)入 MOSN,因此每一個(gè) MOSN 的版本發(fā)布都是一次代碼量巨大的變更。這對質(zhì)量保障和技術(shù)風(fēng)險(xiǎn)的挑戰(zhàn)都是很大的。
2. 集中式發(fā)布:以前由業(yè)務(wù)應(yīng)用升級基礎(chǔ)組件 SDK 的方式,由各個(gè)業(yè)務(wù)應(yīng)用主動發(fā)起升級的發(fā)布,發(fā)布時(shí)主要由該業(yè)務(wù)應(yīng)用自己監(jiān)控其系統(tǒng)穩(wěn)定性。這種升級方式從覆蓋的空間和時(shí)間上來說都是分散的,便于灰度和發(fā)現(xiàn)問題。而 MOSN 的升級方式則是集中式的。即使按照萬分之一容器數(shù)量進(jìn)行灰度,這個(gè)數(shù)字都是巨大的。這對質(zhì)量保障和技術(shù)風(fēng)險(xiǎn)的挑戰(zhàn)也是很大的。
面對這些難題,每一個(gè) MOSN 的版本在上線之前需要很長時(shí)間的測試,上線過程中需要很長時(shí)間的灰度。但是當(dāng)最終發(fā)布上線后,如果出現(xiàn)一個(gè)問題,則又會導(dǎo)致整個(gè)版本的回滾,長時(shí)間的測試和灰度付之一炬,又需從頭再來。在面對穩(wěn)定性這個(gè)壓倒一切的要求時(shí),退讓的就是 MOSN 的研發(fā)效能。即各個(gè)功能從開始開發(fā)到最終全集群覆蓋的速度。這是在犧牲 Service Mesh 的核心價(jià)值啊!這是我們所不能接受的。因此只有在質(zhì)量保障和技術(shù)風(fēng)險(xiǎn)上突破掉這些挑戰(zhàn),才能讓 Service Mesh 發(fā)揮出它真正的價(jià)值。
● 質(zhì)量保證
在 MOSN 研發(fā)流程中,質(zhì)量保障作為研發(fā)效能中的關(guān)鍵一環(huán),重點(diǎn)需要解決的難題:
多模塊共建質(zhì)量:云原生背景下,除去 Service Mesh 自身外,很多業(yè)務(wù)方的訴求也一并下沉至 MOSN,多個(gè)業(yè)務(wù)方的共建質(zhì)量復(fù)雜度幾何倍的提升,如何保障共建方也持續(xù)高質(zhì)量的輸出。
版本穩(wěn)定性:MOSN 的每一次發(fā)布,變更內(nèi)容多、變更范圍廣,如何確保每個(gè)版本的穩(wěn)定性,以及線上多個(gè)版本共存情況下,版本之間的兼容性。
效能提升:在保障質(zhì)量穩(wěn)定性的前提下,如何提升版本測試的效能。
測試策略上,我們主要通過云原生多模塊質(zhì)量數(shù)據(jù)建模和版本穩(wěn)定性兩個(gè)維度解決上述問題。
? 云原生多模塊質(zhì)量數(shù)據(jù)建模
對于 MOSN 里的每個(gè)模塊的功能,除了基礎(chǔ)的單元測試和集成測試保障手段外,我們期望通過錄制線上的真實(shí)流量,經(jīng)過數(shù)據(jù)清洗和建模后,獲取 MOSN 中不同模塊的真實(shí)業(yè)務(wù)場景,作為 MOSN 中多模塊測試場景的輸入;另外,MOSN 支持 MOCK 模式,對這些線上錄制的業(yè)務(wù)場景,在線下做自動化的回放驗(yàn)證。
多模塊數(shù)據(jù)采樣
這里采集的數(shù)據(jù)共包含:流量數(shù)據(jù)、業(yè)務(wù)特征數(shù)據(jù)和內(nèi)存配置數(shù)據(jù)。
MOSN 使用 Golang 語言編寫,無法像 JAVA 一樣,通過 JVM 插樁的方式實(shí)現(xiàn)流量的錄制和回放。
對于 Golang 語言的錄制回放工具,開源也有優(yōu)秀的工具,如 tcpcopy 和 goreplay 等,這些工具主要是從程序外部,對生產(chǎn)的正式流量進(jìn)行錄制,而這對于 MOSN 并不適用。
如能力建設(shè)部分所述,螞蟻內(nèi)部通信目標(biāo) 100% 覆蓋鏈路加密,使用上述工具錄制的流量為加密后的流量數(shù)據(jù),線下回放時(shí),會因?yàn)樽C書問題導(dǎo)致回放失敗。因此,我們需要在 MOSN 內(nèi),建立一套流量錄制、業(yè)務(wù)特征數(shù)據(jù)上報(bào)、內(nèi)存配置數(shù)據(jù)上報(bào)的能力,我們稱之為 Test Mesh 的能力。
流量錄制:錄制的是 TLS 解密后的二進(jìn)制數(shù)據(jù)。
數(shù)據(jù)上報(bào):提供統(tǒng)一的數(shù)據(jù)上報(bào)接口,供 MOSN 中不同的業(yè)務(wù)模塊上報(bào)各自的流量特征數(shù)據(jù),通過和錄制的流量做關(guān)聯(lián),達(dá)到流量清洗和線上流量建模的目的。
數(shù)據(jù)采樣:對于持久化的數(shù)據(jù)(包括二進(jìn)制數(shù)據(jù)、流量特征數(shù)據(jù)、內(nèi)存鏡像和靜態(tài)配置),通過配置中心控制采樣開關(guān)和采樣頻率,在開關(guān)開啟的情況下,根據(jù)采樣頻率開啟采樣窗口,每個(gè)采樣窗口內(nèi)同一個(gè)業(yè)務(wù)類型采集一筆流量。
熔斷保護(hù):為了不影響主流程,流量錄制和數(shù)據(jù)上報(bào)均設(shè)計(jì)為同步受理異步處理的模式,且支持根據(jù) CPU, MEM 的水位自動熔斷的能力,水位的閾值支持動態(tài)調(diào)整。
建模清洗
數(shù)據(jù)同步:線上錄制的數(shù)據(jù)持久化到磁盤文件中,通過數(shù)據(jù)服務(wù)平臺將數(shù)據(jù)同步至離線 ODPS 表中。
數(shù)據(jù)清洗:算法模塊包裝了數(shù)據(jù)清洗的原子能力(如:正則匹配、去重等),用戶通過不同模塊上報(bào)的流量特征數(shù)據(jù),指定清洗規(guī)則,由算法平臺定時(shí)做數(shù)據(jù)清洗,并將清洗后的數(shù)據(jù)同步至存儲平臺,構(gòu)成不同業(yè)務(wù)模塊的業(yè)務(wù)場景基線。
模型場景回放
有了業(yè)務(wù)場景和二進(jìn)制流量,我們構(gòu)建了回放系統(tǒng),并在 MOSN 內(nèi)部支持了 MOCK 模式,支持線下回放驗(yàn)證。
MOCK 模式:線下回放時(shí),MOSN 基于線上采樣的內(nèi)存配置加載起來后,其與外圍的配置需要全部 MOCK 掉,確保內(nèi)存不會被線下的 Registry、動態(tài)配置中心 等更新掉,保障回放結(jié)果的正確性。
流量回放:回放系統(tǒng)提供回放任務(wù)觸發(fā)、任務(wù)編排、MOSN 以 MOCK 模式拉起、回放執(zhí)行、結(jié)果展示等功能。
? 版本穩(wěn)定性
持續(xù)集成
我們在原有持續(xù)集成 pipeline 流水線的基礎(chǔ)上,提出了更高的要求:每個(gè)代碼 PR 合并后即達(dá)到可發(fā)布的狀態(tài)。
提交的每個(gè) PR 均會觸發(fā)這樣一條流水線的運(yùn)行,每個(gè) PR 獨(dú)立構(gòu)建測試環(huán)境,并在整個(gè) pipeline 流程中集成了研發(fā)、測試活動,從而確保 PR 合并后即可達(dá)到發(fā)布狀態(tài)。這里僅簡單介紹了 pipeline 的流程,pipeline 中的每個(gè) job 還在持續(xù)建設(shè)中。
功能預(yù)演
原先在 MOSN 的研發(fā)流程中,MOSN 版本交付后,逐步灰度升級生產(chǎn)的業(yè)務(wù)應(yīng)用,這中間缺失了一環(huán) MOSN 自身生產(chǎn)升級的灰度驗(yàn)證能力。
為此,我們搭建了 MOSN 自身的預(yù)演應(yīng)用,這些應(yīng)用模擬線上業(yè)務(wù)應(yīng)用的真實(shí)使用場景,且按照線上真實(shí)業(yè)務(wù)應(yīng)用部署。MOSN 每個(gè)版本交付后,先對這些應(yīng)用做升級驗(yàn)證,確認(rèn)無問題后再做業(yè)務(wù)應(yīng)用的升級,從而實(shí)現(xiàn) MOSN 自身的灰度發(fā)布和版本升級的質(zhì)量保障。
對于這里說的“真實(shí)使用場景”,其數(shù)據(jù)也是來源于 Test Mesh 錄制到的流量特征數(shù)據(jù),這些流量特征數(shù)據(jù)經(jīng)過清洗建模后,構(gòu)建了業(yè)務(wù)場景基線,預(yù)演應(yīng)用參照業(yè)務(wù)場景基線達(dá)到對線上“真實(shí)使用場景”的全面覆蓋。
● 技術(shù)風(fēng)險(xiǎn)
通常來說,減小升級頻率就會將穩(wěn)定性的風(fēng)險(xiǎn)減小。畢竟代碼變更是導(dǎo)致故障的一大來源。但是這對 MOSN 來說是不可接受的,例如一年我們只做一次發(fā)布升級,前面提到了 MOSN 的代碼變更量是較大的,可想而知一年堆積下來的代碼變更量是多么巨大。加上集中式的發(fā)布方式,這就好像是把一顆“代碼變更炸彈”在短時(shí)間內(nèi)扔在了不小數(shù)量的容器上。對 MOSN 自身的這一大量代碼變更來說,要保證完全沒有問題有不小挑戰(zhàn),容易導(dǎo)致我們無法成功完成這次全集群升級。所以這不僅對穩(wěn)定性是挑戰(zhàn),對 MOSN 的研發(fā)效能也是挑戰(zhàn)。如何去解決這個(gè)問題呢,這里我們解讀兩個(gè)對這方面的探索。一個(gè)是采取更低侵入高頻的發(fā)布方式,我們反而利用更加高頻的發(fā)布模式來將較大量的變更風(fēng)險(xiǎn)分散開來;另一個(gè)是對健康度的度量,這能讓我們對每個(gè) MOSN 節(jié)點(diǎn)的健康情況都準(zhǔn)確掌握,做到更加自動化的發(fā)布和相應(yīng)的技術(shù)風(fēng)險(xiǎn)決策。
? 低侵入高頻發(fā)布
MOSN 是以 sidecar 形態(tài)與業(yè)務(wù)容器共同部署在 Pod 內(nèi)。由于 MOSN 依賴與應(yīng)用的業(yè)務(wù)進(jìn)程交互獲取應(yīng)用的服務(wù)信息,與服務(wù)配置中心交互并建立連接。這些信息在 MOSN 的發(fā)布過程中都需要重建。因此 MOSN 的發(fā)布過程也要求應(yīng)用容器同時(shí)做重啟,以保證應(yīng)用的服務(wù)信息能完整的在 MOSN 重新被初始化。但由于應(yīng)用的啟動速度通常較慢,這個(gè)方式也嚴(yán)重的降低了 MOSN 的發(fā)布效率。
在最初考慮這個(gè)問題時(shí),我們做了一些熱升級的嘗試,但熱升級引入了多個(gè) MOSN 容器的交互,大幅增加了運(yùn)維復(fù)雜性,因此我們又探索了新的低侵入發(fā)布模式,我們稱之為溫升級——僅關(guān)閉一切流量,不通知應(yīng)用業(yè)務(wù)進(jìn)程,接近業(yè)務(wù)無感方式的發(fā)布。
溫升級整體的流程如下。
流量管理與服務(wù)元數(shù)據(jù)的繼承
我們在原有持續(xù)集成 pipeline 流水線的基礎(chǔ)上,提出了更高的要求:每個(gè)代碼 PR 合并后即達(dá)到可發(fā)布的狀態(tài)。
MOSN 接管了業(yè)務(wù)的所有進(jìn)出流量,并直接與流量相關(guān)的中間件交互,因此 MOSN 具備從源頭關(guān)停流量的能力。當(dāng)發(fā)布開始后,MOSN 先從各中間件注銷自身,確保不再承接流量,之后 MOSN 容器退出銷毀,kubelet 使用新的 image 重建新的 MOSN 容器并啟動 MOSN。
由于此時(shí)無法從應(yīng)用業(yè)務(wù)進(jìn)程獲取服務(wù)的元數(shù)據(jù)信息(業(yè)務(wù)進(jìn)程不知道 MOSN 進(jìn)行了更新),新啟動的 MOSN 只能從之前的 MOSN 繼承這部分信息:MOSN 會準(zhǔn)實(shí)時(shí)的將所有的動態(tài)配置信息(含服務(wù)元數(shù)據(jù))dump 到一個(gè)共享的掛載卷,當(dāng)新的 MOSN 容器啟動時(shí),也會掛載同一個(gè)卷,并在 MOSN 進(jìn)程啟動時(shí)加載這些配置,從而最大程度繼承原來 MOSN 的狀態(tài)。
由于依賴于舊版本動態(tài)配置信息的加載,MOSN 也做了相應(yīng)的向下兼容,確保升級過程中的元數(shù)據(jù)都能正確加載。
連接重建
完成狀態(tài)繼承后,MOSN 將自身所在 Pod 重新發(fā)布到服務(wù)配置中心等中間件,并開啟與遠(yuǎn)程建立多個(gè)主動或被動的連接。對于后端的服務(wù)連接來說,MOSN 的升級過程就是一次普通的連接中斷,通常的服務(wù)框架都能自動處理連接中斷并重試建立新的連接。高頻發(fā)布當(dāng)?shù)颓秩氲陌l(fā)布實(shí)現(xiàn)之后,更高頻的發(fā)布也變得可能。我們基于溫升級的能力,建設(shè)了從研發(fā)迭代直通到生產(chǎn)的 nighly build 交付的 CI/CD 流程,讓新研發(fā)的功能代碼在風(fēng)險(xiǎn)可控的前提下能夠以最快的速度接觸到生產(chǎn)流量,縮短了反饋回環(huán),極大加快了新能力的落地。
? 健康度度量
當(dāng)新版本的 MOSN 發(fā)布后,如何快速知道 MOSN 運(yùn)行得是否健康。除了傳統(tǒng)的監(jiān)控方式外,我們讓 MOSN 將自己的健康度主動透出,并配套監(jiān)控平臺,發(fā)布平臺和巡檢系統(tǒng)做到第一時(shí)間發(fā)現(xiàn)問題,自動暫停發(fā)布和回滾。
靜態(tài)健康度
MOSN 定義了標(biāo)準(zhǔn)的組件框架,MOSN 中的每個(gè)組件都需要實(shí)現(xiàn)健康狀態(tài)的相關(guān)接口將自己的健康狀態(tài)細(xì)致地透出。例如:注冊中心客戶端會透出自己和服務(wù)端的連接狀態(tài)、心跳狀態(tài),透出自己每一個(gè)訂閱和發(fā)布結(jié)果等;配置中心客戶端會透出自己和服務(wù)端的連接狀態(tài),透出自己對每一個(gè)配置的拉取結(jié)果等。這些組件的狀態(tài)和結(jié)果會作為發(fā)布后流量是否開啟的前置檢查項(xiàng),如果有組件不健康則不會開啟流量。巡檢平臺也會在查看 MOSN 運(yùn)行時(shí)的健康狀態(tài),如果是不健康的狀態(tài)則會阻斷繼續(xù)發(fā)布。
動態(tài)健康度
靜態(tài)健康度側(cè)重在以組件的視角去觀察各個(gè)組件自身運(yùn)行情況的健康情況,動態(tài)健康度則是側(cè)重在以全站流量的視角去觀察各個(gè) MOSN 節(jié)點(diǎn)的健康情況。以 RPC 為例,每一筆調(diào)用其實(shí)都是 應(yīng)用_A -> MOSN_A -> MOSN_B -> 應(yīng)用_B 的模型,這個(gè)模型中可以從 6 個(gè)地方觀察到這筆調(diào)用的健康狀態(tài):應(yīng)用_A 的 Egress 視角,MOSN_A 的 Ingress 和 Egress 視角,MOSN_B 的 Ingress 和 Egress 視角,應(yīng)用_B 的 Ingress 視角。每一個(gè)視角都可以做調(diào)用情況的統(tǒng)計(jì),基于這些調(diào)用統(tǒng)計(jì),最終可以聚合計(jì)算出每個(gè) MOSN 節(jié)點(diǎn)的健康情況。
如圖 應(yīng)用_B 的 Egress 成功率和 MOSN_B 的 Ingress 成功率下跌,由此可判斷 MOSN_B 節(jié)點(diǎn)為不健康狀態(tài),而 MOSN_B 的 Egress 成功率未變,所以還能進(jìn)一步判斷是 MOSN_B 的 Ingress 模塊可能出現(xiàn)了問題。如果此時(shí) 成功率_7 也出現(xiàn)下跌,而 成功率_8 和 應(yīng)用_A -> MOSN_A -> MOSN_C 鏈路上的成功率都未發(fā)生改變,則可判斷是 MOSN_B 的 Egress 模塊出現(xiàn)了問題。
實(shí)際上,我們的動態(tài)健康度的度量維度會更復(fù)雜一些,例如還會區(qū)分出該筆流量是在 MOSN 節(jié)點(diǎn)內(nèi)部發(fā)生異常還是在發(fā)起調(diào)用之后發(fā)生異常,還會有 MOSN 的版本等信息,由此可以更加精確的定位到出現(xiàn)異常的 MOSN 節(jié)點(diǎn),并追溯到它的發(fā)布單及迭代等信息,幫助最終的自動化決策。
● 問題診斷
在質(zhì)量保障和技術(shù)風(fēng)險(xiǎn)的強(qiáng)大保障下,每一次 MOSN 的升級已經(jīng)達(dá)到了一個(gè)高水準(zhǔn)的穩(wěn)定性。但是 MOSN 升級的覆蓋范圍之大,場景之復(fù)雜,有的問題甚至可能在幾個(gè)月之后才會暴露出來,如何再去發(fā)現(xiàn)這些漏網(wǎng)之魚的 corner case 呢。其中有一些問題較難定位,這些問題的特點(diǎn)是:發(fā)生隨機(jī),過程時(shí)間短,難以抓到現(xiàn)場。一些偶發(fā)的 CPU 使用飚升、OOM 的問題對穩(wěn)定性是大風(fēng)險(xiǎn),我們需要有辦法把這些問題盡快定位出來,不能讓其一直潛伏到業(yè)務(wù)的關(guān)鍵時(shí)間點(diǎn)再爆發(fā)。
我們選取程序所占用的 CPU、RSS 和 goroutine 數(shù)來作為進(jìn)程的運(yùn)行時(shí)指標(biāo)。分為兩種情況:
i. 如果這些指標(biāo)在較短時(shí)間內(nèi)發(fā)生較大波動,那么認(rèn)為可能發(fā)生了瞬時(shí)抖動
ii. 如果這些指標(biāo)到達(dá)非預(yù)期的閾值,那么認(rèn)為可能發(fā)生了資源泄露或瞬時(shí)抖動
對上述三個(gè)指標(biāo),每經(jīng)過 5s 采集一次,保存在相應(yīng)的環(huán)形數(shù)組中。每次采集新一輪指標(biāo)時(shí),均與之前十個(gè)周期的數(shù)值平均(可以認(rèn)為是一種形式的 moving average)進(jìn)行 diff,并判斷當(dāng)前的值是否已到達(dá)預(yù)期外的閾值。
i. 若 CPU 規(guī)則被觸發(fā),自動啟動 Go 的 CPU Profile,并將文件保存在日志目錄中。
ii. 若 RSS 規(guī)則被觸發(fā),自動將 Go 的 heap Profile 保存在日志目錄中。
iii. 若 Goroutine 規(guī)則被觸發(fā),自動將 Go 的 goroutine Profile 保存左日志目錄中。
這些功能上線之后,我們只要根據(jù)監(jiān)控系統(tǒng)推下來的報(bào)警 host 找到相應(yīng)的目錄位置,并把 profile 下載到本地慢慢分析就可以了。
診斷功能上線之后幫我們定位出了多個(gè)之前難以發(fā)現(xiàn)的漏洞/代碼問題,我們將該功能沉淀為一個(gè)開源 lib:holmes,目前已開源在 MOSN 組織下。
總結(jié)及未來
在過去一年中,得益于 Service Mesh 的落地,我們的基礎(chǔ)設(shè)施得到前所未有的演進(jìn)速度,并在性能,效能,穩(wěn)定性和可用率等各方面幫助業(yè)務(wù)得到提升。
在向前探索的過程中,我們越發(fā)看清 Service Mesh 真正價(jià)值的體現(xiàn)不在于它建設(shè)了多少能力,而是體現(xiàn)在它自身將這些基礎(chǔ)設(shè)施能力大規(guī)模應(yīng)用于業(yè)務(wù)的周期和穩(wěn)定性。
由此我們發(fā)現(xiàn) Service Mesh 目前最大的挑戰(zhàn)其實(shí)是它自身的研發(fā)效能,只有一個(gè)高效和穩(wěn)定的 Service Mesh 才能持續(xù)不斷地將基礎(chǔ)設(shè)施能力賦予業(yè)務(wù)并得以演進(jìn)。因此我們在質(zhì)量保障,技術(shù)風(fēng)險(xiǎn)和問題診斷上也在不斷突破創(chuàng)新,最終使得 Service Mesh 的核心價(jià)值真正發(fā)揮了出來。
螞蟻的 Service Mesh 一直走在這個(gè)領(lǐng)域的最前沿,接下來我們又會向什么方向探索呢。我們會持續(xù)將更多的能力下沉至 MOSN ,接管所有的進(jìn)出流量,讓任意技術(shù)棧的應(yīng)用只需要接入 MOSN 就能擁有完整的基礎(chǔ)設(shè)施能力;結(jié)合螞蟻豐富的實(shí)踐經(jīng)驗(yàn)與社區(qū)的力量制定出一套 API 作為應(yīng)用和控制面等同 Service Mesh 交互的標(biāo)準(zhǔn),一起推進(jìn) Service Mesh 的發(fā)展;不斷結(jié)合業(yè)務(wù)挖掘出有價(jià)值的場景,通過 Service Mesh 的優(yōu)勢為業(yè)務(wù)帶來幫助;我們也會通過技術(shù)創(chuàng)新讓 MOSN 具備被集成的能力,使得 MOSN 和更多優(yōu)秀高性能網(wǎng)關(guān)生態(tài)打通,進(jìn)一步發(fā)揮 MOSN 沉淀的能力, 從而釋放 1 + 1 > 2 的技術(shù)紅利;另外會持續(xù)投入開源,MOSN 的核心能力一直是開源共建的方式,不斷吸取社區(qū)良好的輸入,并與螞蟻內(nèi)部大規(guī)模場景下的實(shí)踐相碰撞,最終又將這些優(yōu)秀的能力貢獻(xiàn)于社區(qū)。
最后,歡迎有興趣的小伙伴加入我們共同建設(shè) Service Mesh !前方已是無人區(qū)!
