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