降本提效!注冊(cè)中心在螞蟻集團(tuán)的蛻變之路
文｜林育智（花名：源三?)
螞蟻集團(tuán)高級(jí)專家專注微服務(wù)/服務(wù)發(fā)現(xiàn)相關(guān)領(lǐng)域校對(duì)｜李旭東
本文?8624?字 閱讀?18?分鐘
｜引 言｜
服務(wù)發(fā)現(xiàn)是構(gòu)建分布式系統(tǒng)的最重要的依賴之一， 在螞蟻集團(tuán)承擔(dān)該職責(zé)的是注冊(cè)中心和 Antvip，其中注冊(cè)中心提供機(jī)房?jī)?nèi)的服務(wù)發(fā)現(xiàn)能力，Antvip 提供跨機(jī)房的服務(wù)發(fā)現(xiàn)能力。
本文討論的重點(diǎn)是注冊(cè)中心和多集群部署形態(tài)（IDC 維度），集群和集群之間不涉及到數(shù)據(jù)同步。
PART. 1
背 景
回顧注冊(cè)中心在螞蟻集團(tuán)的演進(jìn)，大概起始于 2007/2008 年，至今演進(jìn)超過 13 年。時(shí)至今日，無論是業(yè)務(wù)形態(tài)還是自身的能力都發(fā)生了巨大的變化。
簡(jiǎn)單回顧一下注冊(cè)中心的歷代發(fā)展：
?V1：引進(jìn)淘寶的 configserver
?V2：橫向擴(kuò)展?
從這個(gè)版本開始，螞蟻和阿里開始獨(dú)立的演進(jìn)，最主要的差異點(diǎn)是在數(shù)據(jù)存儲(chǔ)的方向選擇上。螞蟻選擇了橫向擴(kuò)展，數(shù)據(jù)分片存儲(chǔ)。阿里選擇了縱向擴(kuò)展，加大 data 節(jié)點(diǎn)的內(nèi)存規(guī)格。
這個(gè)選擇影響到若干年后的 SOFARegistry 和 Nacos 的存儲(chǔ)架構(gòu)。
?V3 / V4：LDC 支持和容災(zāi)?
V3 支持 LDC 單元化。
V4 增加了決策機(jī)制和運(yùn)行時(shí)列表，解決了單機(jī)宕機(jī)時(shí)需要人工介入處理的問題，一定程度上提升高可用和減少運(yùn)維成本。
?V5：SOFARegistry
前四個(gè)版本是 confreg，17 年啟動(dòng) V5 項(xiàng)目 SOFARegistry，目標(biāo)是：
1.代碼可維護(hù)性：confreg 代碼歷史包袱較重
- 少量模塊使用 guice 做依賴管理，但大部分模塊是靜態(tài)類交互，不容易分離核心模塊和擴(kuò)展模塊，不利于產(chǎn)品開源。
- 客戶端與服務(wù)端的交互模型嵌套復(fù)雜，理解成本極高且對(duì)多語(yǔ)言不友好。
2.運(yùn)維痛點(diǎn)：引入 Raft 解決 serverlist 的維護(hù)問題，整個(gè)集群的運(yùn)維包括 Raft，通過 operator 來簡(jiǎn)化。
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è)化場(chǎng)景也有跨機(jī)房數(shù)據(jù)同步的需求。
這些目標(biāo)部分實(shí)現(xiàn)了，部分實(shí)現(xiàn)的還不夠好，例如運(yùn)維痛點(diǎn)還殘留一部分，跨集群服務(wù)發(fā)現(xiàn)在面對(duì)主站的大規(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)對(duì)未來的挑戰(zhàn)，啟動(dòng)了 6.0 版本大規(guī)模重構(gòu)計(jì)劃。
歷時(shí) 10 個(gè)月，完成新版本的開發(fā)和升級(jí)工作，同時(shí)鋪開了應(yīng)用級(jí)服務(wù)發(fā)現(xiàn)。
PART. 2
挑 戰(zhàn)
?當(dāng)下面臨的問題?
集群規(guī)模的挑戰(zhàn)
下圖是該集群歷年雙十一時(shí)的數(shù)據(jù)對(duì)比和切換應(yīng)用級(jí)的優(yōu)化效果。相比 2019 年雙十一，2021 年雙十一接口級(jí)的 pub 增長(zhǎng) 200%，sub 增長(zhǎng) 80%。
- 故障爆炸半徑增長(zhǎng)：集群接入的實(shí)例越多，故障影響的業(yè)務(wù)和實(shí)例數(shù)也就越多，保障業(yè)務(wù)的穩(wěn)定是最基礎(chǔ)也是優(yōu)先級(jí)最高的要求。
- 考驗(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è)大集群面臨的困難簡(jiǎn)直是指數(shù)級(jí)增長(zhǎng)。
- 推送性能：大多數(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í)長(zhǎng)對(duì)調(diào)用有影響：新加的地址沒有流量；刪除的地址沒有及時(shí)摘除等。螞蟻集團(tuán)的 PaaS 對(duì)注冊(cè)中心的推送時(shí)延是有 SLO 約束的：如果變更推送列表延時(shí)超過約定值，業(yè)務(wù)端的地址列表就是錯(cuò)誤的。我們歷史上也曾發(fā)生過因推送不及時(shí)導(dǎo)致的故障。
業(yè)務(wù)實(shí)例規(guī)模增加的同時(shí)也帶來推送的性能壓力：發(fā)布端 pub 下面的實(shí)例數(shù)增加；訂閱端業(yè)務(wù)實(shí)例數(shù)增加；一個(gè)簡(jiǎn)單的估算，pub/sub 增長(zhǎng) 2 倍，推送的數(shù)據(jù)量是 2*2，增長(zhǎng) 4 倍，是一個(gè)乘積的關(guān)系。同時(shí)推送的性能也決定了同一時(shí)間可以支持的最大運(yùn)維業(yè)務(wù)實(shí)例數(shù)，例如應(yīng)急場(chǎng)景下，業(yè)務(wù)大規(guī)模重啟。如果這個(gè)是瓶頸，就會(huì)影響故障的恢復(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 選舉和存儲(chǔ)元信息，提供集群的控制面能力。但是事實(shí)證明，我們還是低估了可運(yùn)維的重要性，正如魯迅先生說：【程序員的工作只有兩件事情，一件是運(yùn)維，另一件還是運(yùn)維】。
三年前的目標(biāo)放到今天已經(jīng)嚴(yán)重滯后了。
-?業(yè)務(wù)打擾：業(yè)務(wù)的運(yùn)維是全天候 7*24 的，容量自適應(yīng)/自愈/MOSN 每月一版本把全站應(yīng)用犁一遍等等。下圖是每分鐘運(yùn)維的機(jī)器批數(shù)，可以看到，就算是周末和深夜，運(yùn)維任務(wù)也是不斷的。
?云原生時(shí)代 naming 的挑戰(zhàn)?
云原生的技術(shù)時(shí)代下，可以觀察到一些趨勢(shì)：
- 應(yīng)用實(shí)例的生命周期更短：FaaS 按需使用，autoscale 容量自適應(yīng)等手段導(dǎo)致實(shí)例的漲潮退潮更頻繁，注冊(cè)中心的性能主要體現(xiàn)在實(shí)例變更的響應(yīng)速度上
- 多語(yǔ)言支持：在過去，螞蟻集團(tuán)主要的開發(fā)體系是 Java，非 Java 語(yǔ)言對(duì)接基礎(chǔ)設(shè)施都是二等公民，隨著 AI 和創(chuàng)新性業(yè)務(wù)的需求，非 Java 體系的場(chǎng)景越來越多。如果按照每種語(yǔ)言一個(gè) SDK，維護(hù)成本會(huì)是個(gè)噩夢(mèng)，當(dāng)然 sidecar（MOSN）是個(gè)解法，但是自身是否能支持低侵入性的接入方式，甚至 sdk-free 的能力？
- 服務(wù)路由：在過去絕大部分的場(chǎng)景都可以認(rèn)為 endpoint 是平等的，注冊(cè)中心只提供通信的地址列表是可以滿足需求的。在 Mesh 的精確路由場(chǎng)景里面，pilot 除了提供 eds（地址列表）也同時(shí)提供 rds（routing），注冊(cè)中心需豐富自身的能力。
- K8s：K8s 當(dāng)前已經(jīng)成為事實(shí)上的分布式操作系統(tǒng)，K8s-service 如何和注冊(cè)中心打通？更進(jìn)一步，是否能解決 K8s-service 跨 multi-cluster 的問題？
「總結(jié)」
綜上，除了腳踏實(shí)地，解決當(dāng)下的問題，還需要仰望星空。具備解決云原生趨勢(shì)下的 naming 挑戰(zhàn)的可能性，也是 V6 重構(gòu)的主要目標(biāo)。
PART. 3
SOFARegistry 6.0：面向效能
SOFARegistry 6.0 不只是一個(gè)注冊(cè)中心引擎，需要和周邊的設(shè)施配合，提升開發(fā)、運(yùn)維、應(yīng)急的效能，解決以下的問題。（紅色模塊是比較有挑戰(zhàn)性的領(lǐng)域）
SOFARegistry 6.0 相關(guān)的工作包括：
?架構(gòu)優(yōu)化?
架構(gòu)的改造思路：在保留 V5 的存儲(chǔ)分片架構(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è)問題：
- 脆弱的強(qiáng)一致性meta 信息的使用建立在滿足強(qiáng)一致性的情況下，如果出現(xiàn)網(wǎng)絡(luò)問題，例如有 session 網(wǎng)絡(luò)分區(qū)連不上 meta，錯(cuò)誤的路由表會(huì)導(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ù)就是正確的，但是該限制對(duì)運(yùn)維流程負(fù)擔(dān)很大，我們要確保每次操作少于兩個(gè)副本或者挑選出滿足約束的運(yùn)維序列。
對(duì)于 V5 及之前的版本，運(yùn)維操作是比較粗糙的，一刀切做停機(jī)發(fā)布，通過鎖 PaaS?禁止業(yè)務(wù)變更，等 data 節(jié)點(diǎn)穩(wěn)定后，再打開推送能力來確保避免推送錯(cuò)誤數(shù)據(jù)的風(fēng)險(xiǎn)。
此外，預(yù)期的運(yùn)維工作可以這樣做，但是對(duì)于突發(fā)的多 data 節(jié)點(diǎn)宕機(jī)，這個(gè)風(fēng)險(xiǎn)仍然是存在的。
我們需要有機(jī)制確保：data 節(jié)點(diǎn)列表變化導(dǎo)致數(shù)據(jù)遷移時(shí)，容忍接受額外的輕微推送時(shí)延，確保推送數(shù)據(jù)正確。
「成果」
- 數(shù)據(jù)使用固定 slot 分片，meta 提供調(diào)度能力，slot 的調(diào)度信息通過 slotTable 保存，session/data 節(jié)點(diǎn)可容忍該信息的弱一致性，提升魯棒性。
- 多副本調(diào)度減少 data 節(jié)點(diǎn)變動(dòng)時(shí)數(shù)據(jù)遷移的開銷，當(dāng)前線上的數(shù)據(jù)量 follower 升級(jí) leader 大概 200ms (follower 持有絕大部分的數(shù)據(jù))，直接分配 leader 數(shù)據(jù)同步耗時(shí) 2s-5s。
- 優(yōu)化數(shù)據(jù)通信/復(fù)制鏈路，提升性能和擴(kuò)展能力。
- 大規(guī)模運(yùn)維不需要深夜鎖 PaaS，減少對(duì)業(yè)務(wù)打擾和保住運(yùn)維人員頭發(fā)，提升幸福感。
數(shù)據(jù)鏈路和 slot 調(diào)度：
- meta 的 leader 節(jié)點(diǎn)，通過心跳感知存活的 data 節(jié)點(diǎn)列表，盡可能均勻的把 slot 的多副本分配給 data 節(jié)點(diǎn)，相關(guān)的映射關(guān)系保存在 slotTable，有變更后主動(dòng)通知給 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)變動(dòng)的數(shù)據(jù)遷移：
對(duì)一個(gè)接入 10w+ client 的集群進(jìn)行推送能力壓測(cè)，分鐘級(jí) 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)用級(jí)服務(wù)發(fā)現(xiàn)?
注冊(cè)中心對(duì) pub 的格式保留很強(qiáng)的靈活性，部分 RPC 框架實(shí)現(xiàn) RPC 服務(wù)發(fā)現(xiàn)時(shí)，采用一個(gè)接口一個(gè) pub 的映射方式，SOFA/HSF/Dubbo2 都是采用這種模式，這種模型比較自然，但是會(huì)導(dǎo)致 pub/sub 和推送量膨脹非常厲害。
Dubbo3 提出了應(yīng)用級(jí)服務(wù)發(fā)現(xiàn)和相關(guān)原理【1】。在實(shí)現(xiàn)上，SOFARegistry 6.0 參考了 Dubbo3，采用在 session 端集成服務(wù)的元數(shù)據(jù)中心模塊的方案，同時(shí)在兼容性上做了一些適配。
「應(yīng)用級(jí)服務(wù) pub 數(shù)據(jù)拆分」
「兼容性」
應(yīng)用級(jí)服務(wù)發(fā)現(xiàn)的一個(gè)難點(diǎn)是如何低成本的兼容接口級(jí)/應(yīng)用級(jí)，雖然最后大部分的應(yīng)用都能升級(jí)到應(yīng)用級(jí)，升級(jí)過程中會(huì)面臨以下問題：
我們采用以應(yīng)用級(jí)服務(wù)為主，同時(shí)兼容接口級(jí)的解決方案：
在升級(jí)時(shí)同時(shí)存在新舊版本的兩個(gè) SOFARegistry，不同版本的 SOFARegistry 對(duì)應(yīng)到不同的域名。升級(jí)后的應(yīng)用端（圖中的 MOSN）采用雙訂閱雙發(fā)布的方式逐步灰度切換，確保切換過程中，沒有升級(jí)接入 MOSN 或者沒有打開開關(guān)的應(yīng)用不受影響。
在完成絕大多數(shù)應(yīng)用的應(yīng)用級(jí)遷移后，升級(jí)后的應(yīng)用都已經(jīng)到了 SOFARegistry 6.0 版本的注冊(cè)中心上，但仍然存在少量應(yīng)用因?yàn)闆]有接入 MOSN，這些余留的 old app 也通過域名切換到 SOFARegistry 6.0，繼續(xù)以接口級(jí)訂閱發(fā)布和注冊(cè)中心交互。為了確保已升級(jí)的和沒升級(jí)的應(yīng)用能夠互相訂閱，做了一些支持：
- 提供應(yīng)用級(jí) Publisher 轉(zhuǎn)接到口級(jí) Publisher 的能力：接口級(jí)訂閱端是無法直接訂閱應(yīng)用級(jí)發(fā)布數(shù)據(jù)的，針對(duì)接口級(jí)訂閱按需從 AppPublisher 轉(zhuǎn)換出 InterfacePublisher，沒有接入 MOSN 的應(yīng)用可以順利的訂閱到這部分?jǐn)?shù)據(jù)，因?yàn)橹挥猩倭繎?yīng)用沒有接入 MOSN，需要轉(zhuǎn)化的應(yīng)用級(jí) Publisher 很少。
- 應(yīng)用級(jí)訂閱端在訂閱的時(shí)候額外發(fā)起一個(gè)接口級(jí)的訂閱，用于訂閱沒有接入升級(jí)的應(yīng)用發(fā)布數(shù)據(jù)。由于這部分應(yīng)用非常少，實(shí)際絕大多數(shù)的服務(wù)級(jí)訂閱都不會(huì)有推送任務(wù)，因此對(duì)推送不會(huì)造成壓力。
「效果」
上圖是一個(gè)集群切換應(yīng)用級(jí)后的效果，其中切換后剩余部分接口級(jí) pub 是為了兼容轉(zhuǎn)換出來的數(shù)據(jù)，接口級(jí) sub 沒減少也是為了兼容接口級(jí)發(fā)布。如果不考慮兼容性，pub 數(shù)據(jù)減少高達(dá) 97%。極大的減輕了數(shù)據(jù)規(guī)模的對(duì)集群的壓力。
?SOFARegistryChaos：自動(dòng)化測(cè)試?
注冊(cè)中心的最終一致性的模型一直是個(gè)測(cè)試難題：
針對(duì)該系列問題，我們開發(fā)了 SOFARegistryChaos，特別針對(duì)最終一致性提供完備的測(cè)試能力，除此還提供功能/性能/大規(guī)模壓測(cè)/混沌測(cè)試等能力。同時(shí)，通過插件化的機(jī)制，也支持接入測(cè)試其他服務(wù)發(fā)現(xiàn)產(chǎn)品的能力，基于 K8s 的部署能力，能讓我們快速的部署測(cè)試組件。
具備以上的能力后，不單可以測(cè)試自身的產(chǎn)品能力，例如還可以快速的測(cè)試 zookeeper 在服務(wù)發(fā)現(xiàn)方面的相關(guān)性能來做產(chǎn)品比較。
測(cè)試觀測(cè)性
提供的關(guān)鍵數(shù)據(jù)的觀測(cè)能力，通過 metrics 透出，對(duì)接 Prometheus 即可提供可視化能力：
該能力的測(cè)試是一個(gè)比較有意思的創(chuàng)新點(diǎn)，通過固化一部分的 client 和對(duì)應(yīng)的 pub，校驗(yàn)每次其他各種變更導(dǎo)致的推送數(shù)據(jù)，這部分?jǐn)?shù)據(jù)都必須是要完整和正確的。- 推送次數(shù)
- 推送數(shù)據(jù)體積
失敗 case 的排查
測(cè)試場(chǎng)景中，client 操作時(shí)序和故障注入都是隨機(jī)編排的，我們?cè)?SOFARegistryChaos master 端記錄和收集了所有的操作命令時(shí)序。當(dāng) case 失敗時(shí)，可通過失敗的數(shù)據(jù)明細(xì)和各個(gè) client 的 API 調(diào)用情況來快速定位問題。
例如下圖的失敗 case 顯示在某個(gè) Node 上的訂閱者對(duì)某個(gè) dataId 的訂閱數(shù)據(jù)沒通過校驗(yàn)，預(yù)期是應(yīng)該要推空， 但是推送了一條數(shù)據(jù)下來。同時(shí)顯示了該 dataId 所有相關(guān)的 publisher 在測(cè)試期間的相關(guān)操作軌跡。
黑盒探測(cè)
大家是否經(jīng)歷過類似的 case：
注冊(cè)中心因?yàn)楸旧淼奶匦裕瑢?duì)業(yè)務(wù)的影響往往是滯后的，例如 2K 個(gè) IP 只推送了 1K 個(gè)，這種錯(cuò)誤不會(huì)導(dǎo)致業(yè)務(wù)馬上感知到異常。但是實(shí)際本身已經(jīng)出問題了。對(duì)于注冊(cè)中心，更需要有提前發(fā)現(xiàn)治末病的能力。
這里我們引入黑盒探測(cè)的方式：模擬廣義上的用戶行為，探測(cè)鏈路是否正常。
SOFARegistryChaos 實(shí)際上就可以作為一個(gè)注冊(cè)中心的用戶，并且是加強(qiáng)版的，提供端到端的告警能力。
我們把 SOFARegistryChaos 部署到線上，開啟小流量作為一個(gè)監(jiān)控項(xiàng)。當(dāng)注冊(cè)中心異常但還沒對(duì)業(yè)務(wù)造成可感知的影響時(shí)，我們有機(jī)會(huì)及時(shí)介入，減少風(fēng)險(xiǎn)事件升級(jí)成大故障的風(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)維自動(dòng)化?
nightly build
雖然我們集群數(shù)目非常多，但是因?yàn)槭菂^(qū)分了多環(huán)境，部分環(huán)境對(duì)于穩(wěn)定性的要求相對(duì)生產(chǎn)流量要求稍微低一些，例如灰度以下的環(huán)境。這些環(huán)境的集群是否可以在新版本保證質(zhì)量的情況下，快速低成本的 apply 。結(jié)合 SOFARegistryChaos，我們和質(zhì)量/SRE 的同學(xué)正在建設(shè) nightly build 設(shè)施。
SOFARegistryChaos 作為變更門禁，新版本自動(dòng)化的部署，接受 SOFARegistryChaos 的測(cè)試通過后，自動(dòng)化部署到灰度以下的集群，僅在生產(chǎn)發(fā)布時(shí)候人工介入。
通過 nightly build，極大的減輕非生產(chǎn)環(huán)境的發(fā)布成本，同時(shí)新版本能盡早接受業(yè)務(wù)流量的檢驗(yàn)。
故障演練
雖然我們做了大量的質(zhì)量相關(guān)的工作，但是在線上面對(duì)各種故障時(shí)究竟表現(xiàn)如何？是騾子還是馬，還是要拉出來溜一溜。
我們和 SRE 的同學(xué)在線上會(huì)定期做故障容災(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)做了大量的可觀測(cè)性的改進(jìn)，提供豐富的可觀測(cè)能力，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)的自動(dòng)化替換。
目前，我們的容災(zāi)演練應(yīng)急絕大部分 case 已經(jīng)不需要人肉介入，也只有這樣低成本的演練才能常態(tài)化。
「收益」
通過不斷的演練暴露問題和快速迭代修復(fù)，SOFARegistry 的穩(wěn)定性逐步提升。
「總結(jié)」
SOFARegistry 6.0 除了自身的優(yōu)化，在測(cè)試/運(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ū)的力量推動(dòng) SOFARegistry 的前進(jìn)，而不是只有螞蟻集團(tuán)的工程師去開發(fā)。
在過去一年，SOFARegistry 因?yàn)橹匦脑?6.0 重構(gòu)上，社區(qū)幾乎處于停滯狀態(tài)，這個(gè)是我們做得不夠好的地方。
我們制定了未來半年的社區(qū)計(jì)劃，在 12 月份會(huì)基于內(nèi)部版本開源 6.0，開源的代碼包含內(nèi)部版本的所有核心能力，唯一區(qū)別是內(nèi)部版本多了對(duì) confreg-client 的兼容性支持。
另外從 6.1 后，我們希望后繼的方案設(shè)計(jì)/討論也是基于社區(qū)來開展，整個(gè)研發(fā)進(jìn)程更透明和開放。
PART. 5
我們?nèi)栽诼飞?/strong>
2021 年是 SOFARegistry 審視過去，全面夯實(shí)基礎(chǔ)，提升效能的一年。
當(dāng)然，我們當(dāng)前還仍然處在初級(jí)階段，前面還有很長(zhǎng)的路要走。例如今年雙十一的規(guī)模面臨一系列非常棘手的問題：
還有其他的挑戰(zhàn)：
「參 考」
【1】Dubbo3 提出了應(yīng)用級(jí)服務(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/
關(guān)于我們：
螞蟻應(yīng)用服務(wù)團(tuán)隊(duì)是服務(wù)于整個(gè)螞蟻集團(tuán)的核心技術(shù)團(tuán)隊(duì)，打造了世界領(lǐng)先的金融級(jí)分布式架構(gòu)的基礎(chǔ)設(shè)施平臺(tái)，是 Service Mesh 等云原生領(lǐng)域的領(lǐng)先者，開發(fā)運(yùn)維著全球最大的 Service Mesh 集群，螞蟻集團(tuán)的消息中間件每天支撐上萬(wàn)億的消息流轉(zhuǎn)。
歡迎對(duì) Service Mesh/微服務(wù)/服務(wù)發(fā)現(xiàn) 等領(lǐng)域感興趣的同學(xué)加入我們。
聯(lián)系郵箱：?[email protected]
???本周推薦閱讀??
穩(wěn)定性大幅度提升：SOFARegistry v6 新特性介紹
Prometheus on CeresDB 演進(jìn)之路
如何在生產(chǎn)環(huán)境排查 Rust 內(nèi)存占用過高問題