文｜林育智（花名：源三?)

螞蟻集團(tuán)高級專家

專注微服務(wù)/服務(wù)發(fā)現(xiàn)相關(guān)領(lǐng)域

校對｜李旭東

本文?8624?字 閱讀?18?分鐘

｜引 言｜

服務(wù)發(fā)現(xiàn)是構(gòu)建分布式系統(tǒng)的最重要的依賴之一， 在螞蟻集團(tuán)承擔(dān)該職責(zé)的是注冊中心和 Antvip，其中注冊中心提供機(jī)房內(nèi)的服務(wù)發(fā)現(xiàn)能力，Antvip 提供跨機(jī)房的服務(wù)發(fā)現(xiàn)能力。

本文討論的重點(diǎn)是注冊中心和多集群部署形態(tài)（IDC 維度），集群和集群之間不涉及到數(shù)據(jù)同步。

PART. 1

背 景

回顧注冊中心在螞蟻集團(tuán)的演進(jìn)，大概起始于 2007/2008 年，至今演進(jìn)超過 13 年。時(shí)至今日，無論是業(yè)務(wù)形態(tài)還是自身的能力都發(fā)生了巨大的變化。

簡單回顧一下注冊中心的歷代發(fā)展：

?V1：引進(jìn)淘寶的 configserver

?V2：橫向擴(kuò)展?

從這個(gè)版本開始，螞蟻和阿里開始獨(dú)立的演進(jìn)，最主要的差異點(diǎn)是在數(shù)據(jù)存儲的方向選擇上。螞蟻選擇了橫向擴(kuò)展，數(shù)據(jù)分片存儲。阿里選擇了縱向擴(kuò)展，加大 data 節(jié)點(diǎn)的內(nèi)存規(guī)格。

這個(gè)選擇影響到若干年后的 SOFARegistry 和 Nacos 的存儲架構(gòu)。

?V3 / V4：LDC 支持和容災(zāi)?

V3 支持 LDC 單元化。

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

?V5：SOFARegistry

前四個(gè)版本是 confreg，17 年啟動 V5 項(xiàng)目 SOFARegistry，目標(biāo)是：

1.代碼可維護(hù)性：confreg 代碼歷史包袱較重

- 少量模塊使用 guice 做依賴管理，但大部分模塊是靜態(tài)類交互，不容易分離核心模塊和擴(kuò)展模塊，不利于產(chǎn)品開源。

- 客戶端與服務(wù)端的交互模型嵌套復(fù)雜，理解成本極高且對多語言不友好。

2.運(yùn)維痛點(diǎn)：引入 Raft 解決 serverlist 的維護(hù)問題，整個(gè)集群的運(yùn)維包括 Raft，通過 operator 來簡化。

3.魯棒性：在一致性 hash 環(huán)增加多節(jié)點(diǎn)備份機(jī)制（默認(rèn) 3 副本），2 副本宕機(jī)業(yè)務(wù)無感。

4.跨集群服務(wù)發(fā)現(xiàn)：站內(nèi)跨集群服務(wù)發(fā)現(xiàn)額外需要 antvip 支撐，希望可以統(tǒng)一 2 套設(shè)施的能力，同時(shí)商業(yè)化場景也有跨機(jī)房數(shù)據(jù)同步的需求。

這些目標(biāo)部分實(shí)現(xiàn)了，部分實(shí)現(xiàn)的還不夠好，例如運(yùn)維痛點(diǎn)還殘留一部分，跨集群服務(wù)發(fā)現(xiàn)在面對主站的大規(guī)模數(shù)據(jù)下穩(wěn)定性挑戰(zhàn)很大。

?V6：SOFARegistry 6.0?

2020 年 11 月，SOFARegistry 總結(jié)和吸收內(nèi)部/商業(yè)化打磨的經(jīng)驗(yàn)，同時(shí)為了應(yīng)對未來的挑戰(zhàn)，啟動了 6.0 版本大規(guī)模重構(gòu)計(jì)劃。

歷時(shí) 10 個(gè)月，完成新版本的開發(fā)和升級工作，同時(shí)鋪開了應(yīng)用級服務(wù)發(fā)現(xiàn)。

PART. 2

挑 戰(zhàn)

?當(dāng)下面臨的問題?

集群規(guī)模的挑戰(zhàn)

- 數(shù)據(jù)增長：隨著業(yè)務(wù)的發(fā)展，業(yè)務(wù)的實(shí)例數(shù)在不斷增長，pub/sub 的數(shù)量也相應(yīng)增長。以其中一個(gè)集群為例，2019 年的數(shù)據(jù)為基準(zhǔn)數(shù)據(jù)，在 2020 年 pub 接近千萬級。

下圖是該集群歷年雙十一時(shí)的數(shù)據(jù)對比和切換應(yīng)用級的優(yōu)化效果。相比 2019 年雙十一，2021 年雙十一接口級的 pub 增長 200%，sub 增長 80%。

- 故障爆炸半徑增長：集群接入的實(shí)例越多，故障影響的業(yè)務(wù)和實(shí)例數(shù)也就越多，保障業(yè)務(wù)的穩(wěn)定是最基礎(chǔ)也是優(yōu)先級最高的要求。

- 考驗(yàn)橫向擴(kuò)展能力：集群達(dá)到一定的規(guī)模后，是否還具備繼續(xù)橫向擴(kuò)展的能力，需要集群具備良好的橫向擴(kuò)展能力，從 10 擴(kuò)到 100 和從 100 擴(kuò)到 500 是不一樣的難度。

- HA 能力：集群實(shí)例數(shù)多了后，面臨的節(jié)點(diǎn)總體的硬件故障率也相應(yīng)增高，各種機(jī)器故障集群是否能快速恢復(fù)？有運(yùn)維經(jīng)驗(yàn)的同學(xué)都知道，運(yùn)維一個(gè)小集群和運(yùn)維一個(gè)大集群面臨的困難簡直是指數(shù)級增長。

- 推送性能：大多數(shù)服務(wù)發(fā)現(xiàn)的產(chǎn)品都選擇了數(shù)據(jù)的最終一致性，但是這個(gè)最終在不同集群的規(guī)模下到底是多久？相關(guān)的產(chǎn)品其實(shí)都沒有給出明確的數(shù)據(jù)。

但是實(shí)際上，我們認(rèn)為這個(gè)指標(biāo)是服務(wù)發(fā)現(xiàn)產(chǎn)品的核心指標(biāo)。這個(gè)時(shí)長對調(diào)用有影響：新加的地址沒有流量；刪除的地址沒有及時(shí)摘除等。螞蟻集團(tuán)的 PaaS 對注冊中心的推送時(shí)延是有 SLO 約束的：如果變更推送列表延時(shí)超過約定值，業(yè)務(wù)端的地址列表就是錯(cuò)誤的。我們歷史上也曾發(fā)生過因推送不及時(shí)導(dǎo)致的故障。

業(yè)務(wù)實(shí)例規(guī)模增加的同時(shí)也帶來推送的性能壓力：發(fā)布端 pub 下面的實(shí)例數(shù)增加；訂閱端業(yè)務(wù)實(shí)例數(shù)增加；一個(gè)簡單的估算，pub/sub 增長 2 倍，推送的數(shù)據(jù)量是 2*2，增長 4 倍，是一個(gè)乘積的關(guān)系。同時(shí)推送的性能也決定了同一時(shí)間可以支持的最大運(yùn)維業(yè)務(wù)實(shí)例數(shù)，例如應(yīng)急場景下，業(yè)務(wù)大規(guī)模重啟。如果這個(gè)是瓶頸，就會影響故障的恢復(fù)時(shí)間。

集群規(guī)模可以認(rèn)為是最有挑戰(zhàn)性的，核心的架構(gòu)決定了它的上限，確定后改造成本非常高。而且往往等到發(fā)現(xiàn)瓶頸的時(shí)候已經(jīng)是兵臨城下了，我們要選擇能拉高產(chǎn)品技術(shù)天花板的架構(gòu)。

運(yùn)維的挑戰(zhàn)

SOFARegistry 立項(xiàng)時(shí)的一個(gè)主要目標(biāo)是具備比 confreg 更好的運(yùn)維能力：引入 meta 角色，通過 Raft 選舉和存儲元信息，提供集群的控制面能力。但是事實(shí)證明，我們還是低估了可運(yùn)維的重要性，正如魯迅先生說：【程序員的工作只有兩件事情，一件是運(yùn)維，另一件還是運(yùn)維】。

三年前的目標(biāo)放到今天已經(jīng)嚴(yán)重滯后了。

- 集群數(shù)增長：螞蟻集團(tuán)內(nèi)部的業(yè)務(wù)是分站點(diǎn)部署的（簡單理解為每個(gè)站點(diǎn)是一塊相對比較獨(dú)立的業(yè)務(wù)，需要不同級別的隔離），同時(shí)一個(gè)站點(diǎn)需要部署多套集群：容災(zāi)需要分機(jī)房部署；開發(fā)需要分多環(huán)境。部署站點(diǎn)的數(shù)目增長超出我們的想像?，F(xiàn)在已經(jīng)達(dá)到數(shù)百個(gè)集群了，還在迅速增長中，增長速度參考最近幾年美聯(lián)儲的貨幣供應(yīng)量增長速度。以前認(rèn)為有些運(yùn)維工作可以茍且，人肉頂一下，集群數(shù)增長后，茍且次數(shù)太多了，擠占了開發(fā)/運(yùn)維同學(xué)的精力，完全沒資源去規(guī)劃詩和遠(yuǎn)方。

-?業(yè)務(wù)打擾：業(yè)務(wù)的運(yùn)維是全天候 7*24 的，容量自適應(yīng)/自愈/MOSN 每月一版本把全站應(yīng)用犁一遍等等。下圖是每分鐘運(yùn)維的機(jī)器批數(shù)，可以看到，就算是周末和深夜，運(yùn)維任務(wù)也是不斷的。

螞蟻集團(tuán)的同學(xué)對注冊中心的運(yùn)維公告應(yīng)該是比較熟悉和痛恨的。因?yàn)闃I(yè)務(wù)的敏感性，注冊中心之前一直是停機(jī)發(fā)布和運(yùn)維，這個(gè)時(shí)候需要鎖定全站的發(fā)布/重啟動作。為了盡量少影響業(yè)務(wù)，注冊中心相關(guān)的同學(xué)只能獻(xiàn)祭一頭黑發(fā)，在深夜低峰期做相關(guān)的操作。即使這樣，仍然沒辦法做到對業(yè)務(wù)零打擾。

?云原生時(shí)代 naming 的挑戰(zhàn)?

云原生的技術(shù)時(shí)代下，可以觀察到一些趨勢：

- 微服務(wù)/FaaS 的推廣導(dǎo)致輕型應(yīng)用增多：實(shí)例數(shù)增多，需要能支撐更大的業(yè)務(wù)規(guī)模

- 應(yīng)用實(shí)例的生命周期更短：FaaS 按需使用，autoscale 容量自適應(yīng)等手段導(dǎo)致實(shí)例的漲潮退潮更頻繁，注冊中心的性能主要體現(xiàn)在實(shí)例變更的響應(yīng)速度上

- 多語言支持：在過去，螞蟻集團(tuán)主要的開發(fā)體系是 Java，非 Java 語言對接基礎(chǔ)設(shè)施都是二等公民，隨著 AI 和創(chuàng)新性業(yè)務(wù)的需求，非 Java 體系的場景越來越多。如果按照每種語言一個(gè) SDK，維護(hù)成本會是個(gè)噩夢，當(dāng)然 sidecar（MOSN）是個(gè)解法，但是自身是否能支持低侵入性的接入方式，甚至 sdk-free 的能力？

- 服務(wù)路由：在過去絕大部分的場景都可以認(rèn)為 endpoint 是平等的，注冊中心只提供通信的地址列表是可以滿足需求的。在 Mesh 的精確路由場景里面，pilot 除了提供 eds（地址列表）也同時(shí)提供 rds（routing），注冊中心需豐富自身的能力。

- K8s：K8s 當(dāng)前已經(jīng)成為事實(shí)上的分布式操作系統(tǒng)，K8s-service 如何和注冊中心打通？更進(jìn)一步，是否能解決 K8s-service 跨 multi-cluster 的問題？

「總結(jié)」

綜上，除了腳踏實(shí)地，解決當(dāng)下的問題，還需要仰望星空。具備解決云原生趨勢下的 naming 挑戰(zhàn)的可能性，也是 V6 重構(gòu)的主要目標(biāo)。

PART. 3

SOFARegistry 6.0：面向效能

SOFARegistry 6.0 不只是一個(gè)注冊中心引擎，需要和周邊的設(shè)施配合，提升開發(fā)、運(yùn)維、應(yīng)急的效能，解決以下的問題。（紅色模塊是比較有挑戰(zhàn)性的領(lǐng)域）

SOFARegistry 6.0 相關(guān)的工作包括：

?架構(gòu)優(yōu)化?

架構(gòu)的改造思路：在保留 V5 的存儲分片架構(gòu)的同時(shí)，重點(diǎn)的目標(biāo)是優(yōu)化元信息 meta 一致性和確保推送正確的數(shù)據(jù)。

元信息 meta 一致性

V5 在 meta 角色中引入 Raft 的強(qiáng)一致性進(jìn)行選舉 leader 和存放元信息，其中元信息包括節(jié)點(diǎn)列表和配置信息。數(shù)據(jù)的分片通過獲取 meta 的節(jié)點(diǎn)列表做一致性 hash，這里面存在兩個(gè)問題：

- Raft/operator 運(yùn)維復(fù)雜

? （1）定制運(yùn)維流程：需要支持 change peer 等編排。在螞蟻集團(tuán)，特化的運(yùn)維流程成本較高，同時(shí)也不利于輸出。

? （2）實(shí)現(xiàn)一個(gè)生產(chǎn)健壯的 operator 成本非常高，包括接入變更管控 operator 自身的變更三板斧等。

? （3）對于網(wǎng)絡(luò)/磁盤的可用性比較敏感。在輸出的場景，會面臨比較惡劣的硬件情況，排查成本較高。

- 脆弱的強(qiáng)一致性

meta 信息的使用建立在滿足強(qiáng)一致性的情況下，如果出現(xiàn)網(wǎng)絡(luò)問題，例如有 session 網(wǎng)絡(luò)分區(qū)連不上 meta，錯(cuò)誤的路由表會導(dǎo)致數(shù)據(jù)分裂。需要機(jī)制確保：即使 meta 信息不一致也能在短時(shí)間內(nèi)維持?jǐn)?shù)據(jù)的正確性，留有應(yīng)急的緩沖時(shí)間。

推送正確的數(shù)據(jù)

當(dāng) data 節(jié)點(diǎn)大規(guī)模運(yùn)維時(shí)，節(jié)點(diǎn)列表劇烈變化導(dǎo)致數(shù)據(jù)不斷遷移，推送出去的數(shù)據(jù)存在完整性/正確性的風(fēng)險(xiǎn)。V5 通過引 3 副本來避免這種情況，只要有一個(gè)副本可用，數(shù)據(jù)就是正確的，但是該限制對運(yùn)維流程負(fù)擔(dān)很大，我們要確保每次操作少于兩個(gè)副本或者挑選出滿足約束的運(yùn)維序列。

對于 V5 及之前的版本，運(yùn)維操作是比較粗糙的，一刀切做停機(jī)發(fā)布，通過鎖 PaaS?禁止業(yè)務(wù)變更，等 data 節(jié)點(diǎn)穩(wěn)定后，再打開推送能力來確保避免推送錯(cuò)誤數(shù)據(jù)的風(fēng)險(xiǎn)。

此外，預(yù)期的運(yùn)維工作可以這樣做，但是對于突發(fā)的多 data 節(jié)點(diǎn)宕機(jī)，這個(gè)風(fēng)險(xiǎn)仍然是存在的。

我們需要有機(jī)制確保：data 節(jié)點(diǎn)列表變化導(dǎo)致數(shù)據(jù)遷移時(shí)，容忍接受額外的輕微推送時(shí)延，確保推送數(shù)據(jù)正確。

「成果」

- meta 存儲/選舉 組件插件化，站內(nèi)去 Raft，使用 db 做 leader 選舉和存儲配置信息，降低運(yùn)維成本。

- 數(shù)據(jù)使用固定 slot 分片，meta 提供調(diào)度能力，slot 的調(diào)度信息通過 slotTable 保存，session/data 節(jié)點(diǎn)可容忍該信息的弱一致性，提升魯棒性。

- 多副本調(diào)度減少 data 節(jié)點(diǎn)變動時(shí)數(shù)據(jù)遷移的開銷，當(dāng)前線上的數(shù)據(jù)量 follower 升級 leader 大概 200ms (follower 持有絕大部分的數(shù)據(jù))，直接分配 leader 數(shù)據(jù)同步耗時(shí) 2s-5s。

- 優(yōu)化數(shù)據(jù)通信/復(fù)制鏈路，提升性能和擴(kuò)展能力。

- 大規(guī)模運(yùn)維不需要深夜鎖 PaaS，減少對業(yè)務(wù)打擾和保住運(yùn)維人員頭發(fā)，提升幸福感。

數(shù)據(jù)鏈路和 slot 調(diào)度：

- slot 分片參考 Redis Cluster 的做法，采用虛擬哈希槽分區(qū)，所有的 dataId 根據(jù)哈希函數(shù)映射到 0 ~ N 整數(shù)槽內(nèi)。

- meta 的 leader 節(jié)點(diǎn)，通過心跳感知存活的 data 節(jié)點(diǎn)列表，盡可能均勻的把 slot 的多副本分配給 data 節(jié)點(diǎn)，相關(guān)的映射關(guān)系保存在 slotTable，有變更后主動通知給 session/data。

- session/data 同時(shí)通過心跳獲取最新的 slotTable，避免 meta 通知失效的風(fēng)險(xiǎn)。

- slot 在 data 節(jié)點(diǎn)上有狀態(tài)機(jī) Migrating -> Accept -> Moved。遷移時(shí)確保 slot 的數(shù)據(jù)是最新的才進(jìn)入 Accept 狀態(tài)，才可以用于推送，確保推送數(shù)據(jù)的完整性。

data 節(jié)點(diǎn)變動的數(shù)據(jù)遷移：

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

同時(shí)我們也在線上驗(yàn)證橫向擴(kuò)展能力，集群嘗試最大擴(kuò)容到 session*370，data*60，meta*3 ；meta 因?yàn)橐幚硭械墓?jié)點(diǎn)心跳，CPU 達(dá)到 50%，需要 8C 垂直擴(kuò)容或者進(jìn)一步優(yōu)化心跳開銷。按照一個(gè) data 節(jié)點(diǎn)的安全水位支撐 200w pub，一個(gè) pub 大概 1.5K 開銷，考慮容忍 data 節(jié)點(diǎn)宕機(jī) 1/3 仍然有服務(wù)能力，需要保留 pub 上漲的 buffer，該集群可支撐 1.2 億的 pub，如果配置雙副本則可支撐 6kw 的 pub。

?應(yīng)用級服務(wù)發(fā)現(xiàn)?

注冊中心對 pub 的格式保留很強(qiáng)的靈活性，部分 RPC 框架實(shí)現(xiàn) RPC 服務(wù)發(fā)現(xiàn)時(shí)，采用一個(gè)接口一個(gè) pub 的映射方式，SOFA/HSF/Dubbo2 都是采用這種模式，這種模型比較自然，但是會導(dǎo)致 pub/sub 和推送量膨脹非常厲害。

Dubbo3 提出了應(yīng)用級服務(wù)發(fā)現(xiàn)和相關(guān)原理^【1】。在實(shí)現(xiàn)上，SOFARegistry 6.0 參考了 Dubbo3，采用在 session 端集成服務(wù)的元數(shù)據(jù)中心模塊的方案，同時(shí)在兼容性上做了一些適配。

「應(yīng)用級服務(wù) pub 數(shù)據(jù)拆分」

「兼容性」

應(yīng)用級服務(wù)發(fā)現(xiàn)的一個(gè)難點(diǎn)是如何低成本的兼容接口級/應(yīng)用級，雖然最后大部分的應(yīng)用都能升級到應(yīng)用級，升級過程中會面臨以下問題：

- 應(yīng)用數(shù)多，同時(shí)各個(gè)應(yīng)用升級到應(yīng)用級的時(shí)間點(diǎn)差距比較大

- 部分應(yīng)用無法升級，例如一些遠(yuǎn)古應(yīng)用

我們采用以應(yīng)用級服務(wù)為主，同時(shí)兼容接口級的解決方案：

在升級時(shí)同時(shí)存在新舊版本的兩個(gè) SOFARegistry，不同版本的 SOFARegistry 對應(yīng)到不同的域名。升級后的應(yīng)用端（圖中的 MOSN）采用雙訂閱雙發(fā)布的方式逐步灰度切換，確保切換過程中，沒有升級接入 MOSN 或者沒有打開開關(guān)的應(yīng)用不受影響。

在完成絕大多數(shù)應(yīng)用的應(yīng)用級遷移后，升級后的應(yīng)用都已經(jīng)到了 SOFARegistry 6.0 版本的注冊中心上，但仍然存在少量應(yīng)用因?yàn)闆]有接入 MOSN，這些余留的 old app 也通過域名切換到 SOFARegistry 6.0，繼續(xù)以接口級訂閱發(fā)布和注冊中心交互。為了確保已升級的和沒升級的應(yīng)用能夠互相訂閱，做了一些支持：

- 提供應(yīng)用級 Publisher 轉(zhuǎn)接到口級 Publisher 的能力：接口級訂閱端是無法直接訂閱應(yīng)用級發(fā)布數(shù)據(jù)的，針對接口級訂閱按需從 AppPublisher 轉(zhuǎn)換出 InterfacePublisher，沒有接入 MOSN 的應(yīng)用可以順利的訂閱到這部分?jǐn)?shù)據(jù)，因?yàn)橹挥猩倭繎?yīng)用沒有接入 MOSN，需要轉(zhuǎn)化的應(yīng)用級 Publisher 很少。

- 應(yīng)用級訂閱端在訂閱的時(shí)候額外發(fā)起一個(gè)接口級的訂閱，用于訂閱沒有接入升級的應(yīng)用發(fā)布數(shù)據(jù)。由于這部分應(yīng)用非常少，實(shí)際絕大多數(shù)的服務(wù)級訂閱都不會有推送任務(wù)，因此對推送不會造成壓力。

「效果」

上圖是一個(gè)集群切換應(yīng)用級后的效果，其中切換后剩余部分接口級 pub 是為了兼容轉(zhuǎn)換出來的數(shù)據(jù)，接口級 sub 沒減少也是為了兼容接口級發(fā)布。如果不考慮兼容性，pub 數(shù)據(jù)減少高達(dá) 97%。極大的減輕了數(shù)據(jù)規(guī)模的對集群的壓力。

?SOFARegistryChaos：自動化測試?

注冊中心的最終一致性的模型一直是個(gè)測試難題：

- 最終是多久？

- 達(dá)到最終前有沒有推送錯(cuò)誤的數(shù)據(jù)

- 達(dá)到最終前有沒有推送少數(shù)據(jù)

- 集群發(fā)生故障/數(shù)據(jù)遷移時(shí)對數(shù)據(jù)的正確性和時(shí)延的影響

- client 端頻繁按照各種順序調(diào)用 API 的影響

- client 端頻繁連接斷連的影響

針對該系列問題，我們開發(fā)了 SOFARegistryChaos，特別針對最終一致性提供完備的測試能力，除此還提供功能/性能/大規(guī)模壓測/混沌測試等能力。同時(shí)，通過插件化的機(jī)制，也支持接入測試其他服務(wù)發(fā)現(xiàn)產(chǎn)品的能力，基于 K8s 的部署能力，能讓我們快速的部署測試組件。

具備以上的能力后，不單可以測試自身的產(chǎn)品能力，例如還可以快速的測試 zookeeper 在服務(wù)發(fā)現(xiàn)方面的相關(guān)性能來做產(chǎn)品比較。

測試觀測性

提供的關(guān)鍵數(shù)據(jù)的觀測能力，通過 metrics 透出，對接 Prometheus 即可提供可視化能力：

- 推送時(shí)延

- 設(shè)定時(shí)間內(nèi)的最終一致性檢測

- 發(fā)生故障注入的時(shí)間點(diǎn)

- 最終一致期間推送數(shù)據(jù)的完整性
該能力的測試是一個(gè)比較有意思的創(chuàng)新點(diǎn)，通過固化一部分的 client 和對應(yīng)的 pub，校驗(yàn)每次其他各種變更導(dǎo)致的推送數(shù)據(jù)，這部分?jǐn)?shù)據(jù)都必須是要完整和正確的。

- 推送次數(shù)

- 推送數(shù)據(jù)體積

失敗 case 的排查

測試場景中，client 操作時(shí)序和故障注入都是隨機(jī)編排的，我們在 SOFARegistryChaos master 端記錄和收集了所有的操作命令時(shí)序。當(dāng) case 失敗時(shí)，可通過失敗的數(shù)據(jù)明細(xì)和各個(gè) client 的 API 調(diào)用情況來快速定位問題。

例如下圖的失敗 case 顯示在某個(gè) Node 上的訂閱者對某個(gè) dataId 的訂閱數(shù)據(jù)沒通過校驗(yàn)，預(yù)期是應(yīng)該要推空， 但是推送了一條數(shù)據(jù)下來。同時(shí)顯示了該 dataId 所有相關(guān)的 publisher 在測試期間的相關(guān)操作軌跡。

黑盒探測

大家是否經(jīng)歷過類似的 case：

- 突然被業(yè)務(wù)告知系統(tǒng)出現(xiàn)問題，一臉懵的我：系統(tǒng)沒異常啊

- 發(fā)現(xiàn)系統(tǒng)出現(xiàn)故障時(shí)，實(shí)際已經(jīng)對業(yè)務(wù)造成了嚴(yán)重影響

注冊中心因?yàn)楸旧淼奶匦?#xff0c;對業(yè)務(wù)的影響往往是滯后的，例如 2K 個(gè) IP 只推送了 1K 個(gè)，這種錯(cuò)誤不會導(dǎo)致業(yè)務(wù)馬上感知到異常。但是實(shí)際本身已經(jīng)出問題了。對于注冊中心，更需要有提前發(fā)現(xiàn)治末病的能力。

這里我們引入黑盒探測的方式：模擬廣義上的用戶行為，探測鏈路是否正常。

SOFARegistryChaos 實(shí)際上就可以作為一個(gè)注冊中心的用戶，并且是加強(qiáng)版的，提供端到端的告警能力。

我們把 SOFARegistryChaos 部署到線上，開啟小流量作為一個(gè)監(jiān)控項(xiàng)。當(dāng)注冊中心異常但還沒對業(yè)務(wù)造成可感知的影響時(shí)，我們有機(jī)會及時(shí)介入，減少風(fēng)險(xiǎn)事件升級成大故障的風(fēng)險(xiǎn)。

磨刀不誤砍柴工

通過 SOFARegistryChaos，核心能力的驗(yàn)證效率極大提升，質(zhì)量得到保障的同時(shí)，開發(fā)同學(xué)寫代碼也輕松了許多。從 7 月份到 10 月中的 3 個(gè)半月時(shí)間里，我們迭代并發(fā)布了 5 個(gè)版本，接近 3 周 1 個(gè)版本。這個(gè)開發(fā)效率在以前是不敢想象的，同時(shí)也獲得完善的端到端告警能力。

?運(yùn)維自動化?

nightly build

雖然我們集群數(shù)目非常多，但是因?yàn)槭菂^(qū)分了多環(huán)境，部分環(huán)境對于穩(wěn)定性的要求相對生產(chǎn)流量要求稍微低一些，例如灰度以下的環(huán)境。這些環(huán)境的集群是否可以在新版本保證質(zhì)量的情況下，快速低成本的 apply 。結(jié)合 SOFARegistryChaos，我們和質(zhì)量/SRE 的同學(xué)正在建設(shè) nightly build 設(shè)施。

SOFARegistryChaos 作為變更門禁，新版本自動化的部署，接受 SOFARegistryChaos 的測試通過后，自動化部署到灰度以下的集群，僅在生產(chǎn)發(fā)布時(shí)候人工介入。

通過 nightly build，極大的減輕非生產(chǎn)環(huán)境的發(fā)布成本，同時(shí)新版本能盡早接受業(yè)務(wù)流量的檢驗(yàn)。

故障演練

雖然我們做了大量的質(zhì)量相關(guān)的工作，但是在線上面對各種故障時(shí)究竟表現(xiàn)如何？是騾子還是馬，還是要拉出來溜一溜。

我們和 SRE 的同學(xué)在線上會定期做故障容災(zāi)演練，包括但不限于網(wǎng)絡(luò)故障；大規(guī)模機(jī)器宕機(jī)等。另外演練不能是一錘子買賣的事情，沒有保鮮的容災(zāi)能力其實(shí)等于 0。在仿真/灰度集群，進(jìn)行容災(zāi)常態(tài)化，演練-迭代循環(huán)。

定位診斷

故障容災(zāi)演練常態(tài)化后，如何快速的定位到故障源成了擺在桌子上的一個(gè)問題，否則每次演練都雞飛狗跳的，效率太低了。

SOFARegistry 各個(gè)節(jié)點(diǎn)做了大量的可觀測性的改進(jìn)，提供豐富的可觀測能力，SRE 的診斷系統(tǒng)通過相關(guān)數(shù)據(jù)做實(shí)時(shí)診斷，例如這個(gè) case 里就是一個(gè) session 節(jié)點(diǎn)故障導(dǎo)致 SLO 破線。有了定位能力后，自愈系統(tǒng)也可以發(fā)揮作用，例如某個(gè) session 節(jié)點(diǎn)被診斷出網(wǎng)絡(luò)故障，自愈系統(tǒng)可以觸發(fā)故障節(jié)點(diǎn)的自動化替換。

目前，我們的容災(zāi)演練應(yīng)急絕大部分 case 已經(jīng)不需要人肉介入，也只有這樣低成本的演練才能常態(tài)化。

「收益」

通過不斷的演練暴露問題和快速迭代修復(fù)，SOFARegistry 的穩(wěn)定性逐步提升。

「總結(jié)」

SOFARegistry 6.0 除了自身的優(yōu)化，在測試/運(yùn)維/應(yīng)急方面做了大量的工作，目標(biāo)是提升研發(fā)/質(zhì)量/運(yùn)維人員的效能，讓相關(guān)同學(xué)擺脫低效的人肉工作，提升幸福感。

PART. 4

開源：一個(gè)人可以走得很快，

但一群人可以走的更遠(yuǎn)

SOFARegistry 是一個(gè)開源項(xiàng)目，也是開源社區(qū) SOFAStack 重要的一環(huán)，我們希望用社區(qū)的力量推動 SOFARegistry 的前進(jìn)，而不是只有螞蟻集團(tuán)的工程師去開發(fā)。

在過去一年，SOFARegistry 因?yàn)橹匦脑?6.0 重構(gòu)上，社區(qū)幾乎處于停滯狀態(tài)，這個(gè)是我們做得不夠好的地方。

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

另外從 6.1 后，我們希望后繼的方案設(shè)計(jì)/討論也是基于社區(qū)來開展，整個(gè)研發(fā)進(jìn)程更透明和開放。

PART. 5

我們?nèi)栽诼飞?/strong>

2021 年是 SOFARegistry 審視過去，全面夯實(shí)基礎(chǔ)，提升效能的一年。

當(dāng)然，我們當(dāng)前還仍然處在初級階段，前面還有很長的路要走。例如今年雙十一的規(guī)模面臨一系列非常棘手的問題：

- 一個(gè)集群內(nèi)單應(yīng)用實(shí)例數(shù)過多（熱點(diǎn)應(yīng)用單集群高達(dá) 7K 個(gè)實(shí)例）導(dǎo)致業(yè)務(wù)端收到地址推送時(shí) CPU/memory 開銷過大。

- 全地址列表推送，導(dǎo)致的連接數(shù)過多等。

還有其他的挑戰(zhàn)：

- 增量推送，減少推送數(shù)據(jù)量和 client 端的資源開銷

- 統(tǒng)一服務(wù)發(fā)現(xiàn)，支持跨集群

- 適應(yīng)云原生下的新趨勢

- 社區(qū)的運(yùn)營

- 產(chǎn)品易用性

「參 考」

【1】Dubbo3 提出了應(yīng)用級服務(wù)發(fā)現(xiàn)和相關(guān)原理：

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/

???本周推薦閱讀??

聊聊技術(shù)人的“績效考核”

敏捷效能提升的五大要素與誤區(qū)

老板要做DDD改造，我現(xiàn)在慌得一比！

Log4j2維護(hù)者吐槽沒工資還要挨罵，GO安全負(fù)責(zé)人建議開源作者向公司收費(fèi)

億級流量架構(gòu)實(shí)戰(zhàn)之秒殺設(shè)計(jì)

精華：軟件架構(gòu)模式的7種武器

聊聊真正的架構(gòu)設(shè)計(jì)

總結(jié)

以上是生活随笔為你收集整理的源三：聊聊注册中心在蚂蚁集团的降本提效之路的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。