降本提效!註冊中心在螞蟻集團的蛻變之路

文|林育智(花名:源三 )

螞蟻集團高級專家

專注微服務 / 服務發現相關領域

校對|李旭東

|引 言|

服務發現是構建分佈式系統的最重要的依賴之一, 在螞蟻集團承擔該職責的是註冊中心和 Antvip,其中註冊中心提供機房內的服務發現能力,Antvip 提供跨機房的服務發現能力。

本文討論的重點是註冊中心和多集羣部署形態(IDC 維度)集羣和集羣之間不涉及到數據同步

PART. 1

背 景

回顧註冊中心在螞蟻集團的演進,大概起始於 2007/2008 年,至今演進超過 13 年。時至今日,無論是業務形態還是自身的能力都發生了巨大的變化。

簡單回顧一下注冊中心的歷代發展:

** V1:引進淘寶的 configserver**

** V2:橫向擴展 **

從這個版本開始,螞蟻和阿里開始獨立的演進,最主要的差異點是在數據存儲的方向選擇上。螞蟻選擇了橫向擴展,數據分片存儲。阿里選擇了縱向擴展,加大 data 節點的內存規格。

這個選擇影響到若干年後的 SOFARegistry 和 Nacos 的存儲架構。

** V3 / V4:LDC 支持和容災 **

V3 支持 LDC 單元化。

V4 增加了決策機制和運行時列表,解決了單機宕機時需要人工介入處理的問題,一定程度上提升高可用和減少運維成本。

** V5:SOFARegistry**

前四個版本是 confreg,17 年啓動 V5 項目 SOFARegistry,目標是:

  1. 代碼可維護性:confreg 代碼歷史包袱較重
  1. 運維痛點:引入 Raft 解決 serverlist 的維護問題,整個集羣的運維包括 Raft,通過 operator 來簡化。

  2. 魯棒性:在一致性 hash 環增加多節點備份機制_(默認 3 副本)_,2 副本宕機業務無感。

  3. 跨集羣服務發現:站內跨集羣服務發現額外需要 antvip 支撐,希望可以統一 2 套設施的能力,同時商業化場景也有跨機房數據同步的需求。

這些目標部分實現了,部分實現的還不夠好,例如運維痛點還殘留一部分,跨集羣服務發現在面對主站的大規模數據下穩定性挑戰很大。

** V6:SOFARegistry 6.0 **

2020 年 11 月,SOFARegistry 總結和吸收內部 / 商業化打磨的經驗,同時爲了應對未來的挑戰,啓動了 6.0 版本大規模重構計劃。

歷時 10 個月,完成新版本的開發和升級工作,同時鋪開了應用級服務發現。

PART. 2

挑 戰

** 當下面臨的問題 **

集羣規模的挑戰

下圖是該集羣歷年雙十一時的數據對比和切換應用級的優化效果。相比 2019 年雙十一,2021 年雙十一接口級的 pub 增長 200%,sub 增長 80%。

但是實際上,我們認爲這個指標是服務發現產品的核心指標。這個時長對調用有影響:新加的地址沒有流量;刪除的地址沒有及時摘除等。螞蟻集團的 PaaS 對註冊中心的推送時延是有 SLO 約束的:如果變更推送列表延時超過約定值,業務端的地址列表就是錯誤的。我們歷史上也曾發生過因推送不及時導致的故障。

業務實例規模增加的同時也帶來推送的性能壓力:發佈端 pub 下面的實例數增加;訂閱端業務實例數增加;一個簡單的估算,pub/sub 增長 2 倍,推送的數據量是 2*2,增長 4 倍,是一個乘積的關係。同時推送的性能也決定了同一時間可以支持的最大運維業務實例數,例如應急場景下,業務大規模重啓。如果這個是瓶頸,就會影響故障的恢復時間。

集羣規模可以認爲是最有挑戰性的,核心的架構決定了它的上限,確定後改造成本非常高。而且往往等到發現瓶頸的時候已經是兵臨城下了,我們要選擇能拉高產品技術天花板的架構。

運維的挑戰

SOFARegistry 立項時的一個主要目標是具備比 confreg 更好的運維能力:引入 meta 角色,通過 Raft 選舉和存儲元信息,提供集羣的控制面能力。但是事實證明,我們還是低估了可運維的重要性,正如魯迅先生說:【程序員的工作只有兩件事情,一件是運維,另一件還是運維】

三年前的目標放到今天已經嚴重滯後了。

- 業務打擾:業務的運維是全天候 7*24 的,容量自適應 / 自愈 / MOSN 每月一版本把全站應用犁一遍等等。下圖是每分鐘運維的機器批數,可以看到,就算是週末和深夜,運維任務也是不斷的。

螞蟻集團的同學對註冊中心的運維公告應該是比較熟悉和痛恨的。因爲業務的敏感性,註冊中心之前一直是停機發布和運維,這個時候需要鎖定全站的發佈 / 重啓動作。爲了儘量少影響業務,註冊中心相關的同學只能獻祭一頭黑髮,在深夜低峯期做相關的操作。即使這樣,仍然沒辦法做到對業務零打擾。

** 雲原生時代 naming 的挑戰 **

雲原生的技術時代下,可以觀察到一些趨勢:

「總結」

綜上,除了腳踏實地,解決當下的問題,還需要仰望星空。具備解決雲原生趨勢下的 naming 挑戰的可能性,也是 V6 重構的主要目標。

PART. 3

SOFARegistry 6.0:面向效能

SOFARegistry 6.0 不只是一個註冊中心引擎,需要和周邊的設施配合,提升開發、運維、應急的效能,解決以下的問題。(紅色模塊是比較有挑戰性的領域)

SOFARegistry 6.0 相關的工作包括:

** 架構優化 **

架構的改造思路:在保留 V5 的存儲分片架構的同時,重點的目標是優化元信息 meta 一致性和確保推送正確的數據。

元信息 meta 一致性

V5 在 meta 角色中引入 Raft 的強一致性進行選舉 leader 和存放元信息,其中元信息包括節點列表和配置信息。數據的分片通過獲取 meta 的節點列表做一致性 hash,這裏面存在兩個問題:

  (1)定製運維流程:需要支持 change peer 等編排。在螞蟻集團,特化的運維流程成本較高,同時也不利於輸出。

  (2)實現一個生產健壯的 operator 成本非常高,包括接入變更管控 operator 自身的變更三板斧等。

  (3)對於網絡 / 磁盤的可用性比較敏感。在輸出的場景,會面臨比較惡劣的硬件情況,排查成本較高。

meta 信息的使用建立在滿足強一致性的情況下,如果出現網絡問題,例如有 session 網絡分區連不上 meta,錯誤的路由表會導致數據分裂。需要機制確保:即使 meta 信息不一致也能在短時間內維持數據的正確性,留有應急的緩衝時間。

推送正確的數據

當 data 節點大規模運維時,節點列表劇烈變化導致數據不斷遷移,推送出去的數據存在完整性 / 正確性的風險。V5 通過引 3 副本來避免這種情況,只要有一個副本可用,數據就是正確的,但是該限制對運維流程負擔很大,我們要確保每次操作少於兩個副本或者挑選出滿足約束的運維序列。
對於 V5 及之前的版本,運維操作是比較粗糙的,一刀切做停機發布,通過鎖 PaaS 禁止業務變更,等 data 節點穩定後,再打開推送能力來確保避免推送錯誤數據的風險。
此外,預期的運維工作可以這樣做,但是對於突發的多 data 節點宕機,這個風險仍然是存在的。
我們需要有機制確保:data 節點列表變化導致數據遷移時,容忍接受額外的輕微推送時延,確保推送數據正確。

「成果」

數據鏈路和 slot 調度:

data 節點變動的數據遷移:

對一個接入 10w+ client 的集羣進行推送能力壓測,分鐘級 12M 的推送量,推送延遲 p999 可以保持在 8s 以下。session cpu20%,data cpu10%,物理資源水位較低,還有較大的推送 buffer。

同時我們也在線上驗證橫向擴展能力,集羣嘗試最大擴容到 session370,data60,meta*3 ;meta 因爲要處理所有的節點心跳,CPU 達到 50%,需要 8C 垂直擴容或者進一步優化心跳開銷。按照一個 data 節點的安全水位支撐 200w pub,一個 pub 大概 1.5K 開銷,考慮容忍 data 節點宕機 1/3 仍然有服務能力,需要保留 pub 上漲的 buffer,該集羣可支撐 1.2 億的 pub,如果配置雙副本則可支撐 6kw 的 pub。

** 應用級服務發現 **

註冊中心對 pub 的格式保留很強的靈活性,部分 RPC 框架實現 RPC 服務發現時,採用一個接口一個 pub 的映射方式,SOFA/HSF/Dubbo2 都是採用這種模式,這種模型比較自然,但是會導致 pub/sub 和推送量膨脹非常厲害。

Dubbo3 提出了應用級服務發現和相關原理【1】。在實現上,SOFARegistry 6.0 參考了 Dubbo3,採用在 session 端集成服務的元數據中心模塊的方案,同時在兼容性上做了一些適配。

「應用級服務 pub 數據拆分」

「兼容性」

應用級服務發現的一個難點是如何低成本的兼容接口級 / 應用級,雖然最後大部分的應用都能升級到應用級,升級過程中會面臨以下問題:

我們採用以應用級服務爲主,同時兼容接口級的解決方案:

在升級時同時存在新舊版本的兩個 SOFARegistry,不同版本的 SOFARegistry 對應到不同的域名。升級後的應用端_(圖中的 MOSN)_採用雙訂閱雙發佈的方式逐步灰度切換,確保切換過程中,沒有升級接入 MOSN 或者沒有打開開關的應用不受影響。

在完成絕大多數應用的應用級遷移後,升級後的應用都已經到了 SOFARegistry 6.0 版本的註冊中心上,但仍然存在少量應用因爲沒有接入 MOSN,這些餘留的 old app 也通過域名切換到 SOFARegistry 6.0,繼續以接口級訂閱發佈和註冊中心交互。爲了確保已升級的和沒升級的應用能夠互相訂閱,做了一些支持:

「效果」

上圖是一個集羣切換應用級後的效果,其中切換後剩餘部分接口級 pub 是爲了兼容轉換出來的數據,接口級 sub 沒減少也是爲了兼容接口級發佈。如果不考慮兼容性,pub 數據減少高達 97%。極大的減輕了數據規模的對集羣的壓力。

** SOFARegistryChaos:自動化測試 **

註冊中心的最終一致性的模型一直是個測試難題:

針對該系列問題,我們開發了 SOFARegistryChaos,特別針對最終一致性提供完備的測試能力,除此還提供功能 / 性能 / 大規模壓測 / 混沌測試等能力。同時,通過插件化的機制,也支持接入測試其他服務發現產品的能力,基於 K8s 的部署能力,能讓我們快速的部署測試組件。

具備以上的能力後,不單可以測試自身的產品能力,例如還可以快速的測試 zookeeper 在服務發現方面的相關性能來做產品比較。

測試觀測性

提供的關鍵數據的觀測能力,通過 metrics 透出,對接 Prometheus 即可提供可視化能力:

失敗 case 的排查

測試場景中,client 操作時序和故障注入都是隨機編排的,我們在 SOFARegistryChaos master 端記錄和收集了所有的操作命令時序。當 case 失敗時,可通過失敗的數據明細和各個 client 的 API 調用情況來快速定位問題。

例如下圖的失敗 case 顯示在某個 Node 上的訂閱者對某個 dataId 的訂閱數據沒通過校驗,預期是應該要推空, 但是推送了一條數據下來。同時顯示了該 dataId 所有相關的 publisher 在測試期間的相關操作軌跡。

黑盒探測

大家是否經歷過類似的 case:

註冊中心因爲本身的特性,對業務的影響往往是滯後的,例如 2K 個 IP 只推送了 1K 個,這種錯誤不會導致業務馬上感知到異常。但是實際本身已經出問題了。對於註冊中心,更需要有提前發現治末病的能力。

這裏我們引入黑盒探測的方式:模擬廣義上的用戶行爲,探測鏈路是否正常。
SOFARegistryChaos 實際上就可以作爲一個註冊中心的用戶,並且是加強版的,提供端到端的告警能力。

我們把 SOFARegistryChaos 部署到線上,開啓小流量作爲一個監控項。當註冊中心異常但還沒對業務造成可感知的影響時,我們有機會及時介入,減少風險事件升級成大故障的風險。

磨刀不誤砍柴工

通過 SOFARegistryChaos,核心能力的驗證效率極大提升,質量得到保障的同時,開發同學寫代碼也輕鬆了許多。從 7 月份到 10 月中的 3 個半月時間裏,我們迭代併發布了 5 個版本,接近 3 周 1 個版本。這個開發效率在以前是不敢想象的,同時也獲得完善的端到端告警能力。

** 運維自動化 **

nightly build

雖然我們集羣數目非常多,但是因爲是區分了多環境,部分環境對於穩定性的要求相對生產流量要求稍微低一些,例如灰度以下的環境。這些環境的集羣是否可以在新版本保證質量的情況下,快速低成本的 apply 。結合 SOFARegistryChaos,我們和質量 / SRE 的同學正在建設 nightly build 設施。

SOFARegistryChaos 作爲變更門禁,新版本自動化的部署,接受 SOFARegistryChaos 的測試通過後,自動化部署到灰度以下的集羣,僅在生產發佈時候人工介入。

通過 nightly build,極大的減輕非生產環境的發佈成本,同時新版本能儘早接受業務流量的檢驗。

故障演練

雖然我們做了大量的質量相關的工作,但是在線上面對各種故障時究竟表現如何?是騾子還是馬,還是要拉出來溜一溜。

我們和 SRE 的同學在線上會定期做故障容災演練,包括但不限於網絡故障;大規模機器宕機等。另外演練不能是一錘子買賣的事情,沒有保鮮的容災能力其實等於 0。在仿真 / 灰度集羣,進行容災常態化,演練 - 迭代循環。

定位診斷

故障容災演練常態化後,如何快速的定位到故障源成了擺在桌子上的一個問題,否則每次演練都雞飛狗跳的,效率太低了。
SOFARegistry 各個節點做了大量的可觀測性的改進,提供豐富的可觀測能力,SRE 的診斷系統通過相關數據做實時診斷,例如這個 case 裏就是一個 session 節點故障導致 SLO 破線。有了定位能力後,自愈系統也可以發揮作用,例如某個 session 節點被診斷出網絡故障,自愈系統可以觸發故障節點的自動化替換。

目前,我們的容災演練應急絕大部分 case 已經不需要人肉介入,也只有這樣低成本的演練才能常態化。

「收益」

通過不斷的演練暴露問題和快速迭代修復,SOFARegistry 的穩定性逐步提升。

「總結」

SOFARegistry 6.0 除了自身的優化,在測試 / 運維 / 應急方面做了大量的工作,目標是提升研發 / 質量 / 運維人員的效能,讓相關同學擺脫低效的人肉工作,提升幸福感。

PART. 4

**開源:**一個人可以走得很快,

但一羣人可以走的更遠

SOFARegistry 是一個開源項目,也是開源社區 SOFAStack 重要的一環,我們希望用社區的力量推動 SOFARegistry 的前進,而不是隻有螞蟻集團的工程師去開發。

在過去一年,SOFARegistry 因爲重心在 6.0 重構上,社區幾乎處於停滯狀態,這個是我們做得不夠好的地方。

我們制定了未來半年的社區計劃,在 12 月份會基於內部版本開源 6.0,開源的代碼包含內部版本的所有核心能力,唯一區別是內部版本多了對 confreg-client 的兼容性支持。

另外從 6.1 後,我們希望後繼的方案設計 / 討論也是基於社區來開展,整個研發進程更透明和開放。

PART. 5

我們仍在路上

2021 年是 SOFARegistry 審視過去,全面夯實基礎,提升效能的一年。

當然,我們當前還仍然處在初級階段,前面還有很長的路要走。例如今年雙十一的規模面臨一系列非常棘手的問題:

還有其他的挑戰:

「參 考」

【1】Dubbo3 提出了應用級服務發現和相關原理:

https://dubbo.apache.org/zh/blog/2021/06/02/dubbo3-%E5%BA%94%E7%94%A8%E7%BA%A7%E6%9C%8D%E5%8A%A1%E5%8F%91%E7%8E%B0/

關於我們:

螞蟻應用服務團隊是服務於整個螞蟻集團的核心技術團隊,打造了世界領先的金融級分佈式架構的基礎設施平臺,是 Service Mesh 等雲原生領域的領先者,開發運維着全球最大的 Service Mesh 集羣之一,螞蟻集團的消息中間件每天支撐上萬億的消息流轉。

歡迎對 Service Mesh / 微服務 / 服務發現 等領域感興趣的同學加入我們。

聯繫郵箱: yuzhi.lyz@antgroup.com

本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源https://mp.weixin.qq.com/s/NxTq9dMCY8gow-P_Q4rU9Q