簡介
SOFARegistry 是螞蟻集團在生產大規模使用的服務註冊中心，經歷了多年大促的考驗，支撐螞蟻龐大的服務集羣，具有分佈式可水平擴容、容量大、推送延遲低、高可用等特點。
螞蟻生產集羣 — SOFARegistry 支撐 1000 萬服務發佈者、4000 萬服務訂閱者，在業務應用大規模變更觸發千萬級別推送量的場景下，推送延遲的 p99 依然能夠保持在 7s 以下。
《認識 SOFARegistry》 這一系列文章將會基於 SOFARegistry 新版本（V6）的代碼，講解註冊中心在超大規模集羣場景下落地的解析與實踐，同時介紹 SOFARegistry 的各項功能，方便業務落地。
部署架構
SOFARegistry 現有的架構設計：採用雙層存儲架構，外加一個負責內部元數據管理的 Meta 組件。
SOFARegistry 的角色分爲 4 個: client、session、data、meta。
角色分工如下：
Client
提供應用接入服務註冊中心的基本 API 能力，通過編程方式調用服務註冊中心的服務訂閱和服務發佈能力。
SessionServer ｜ 會話服務器
負責接受 Client 的服務發佈和服務訂閱請求，並作爲一箇中間層將寫操作轉發 DataServer 層。SessionServer 這一層可隨業務機器數的規模的增長而擴容。
DataServer ｜ 數據服務器
負責存儲具體的服務數據，數據按 dataInfoId 進行分片存儲，支持多副本備份，保證數據高可用。這一層可隨服務數據量的規模增長而擴容。
MetaServer ｜ 元數據服務器
負責維護集羣 SessionServer 和 DataServer 的一致列表，作爲 SOFARegistry 集羣內部的地址發現服務，在 SessionServer 或 DataServer 節點變更時可以通知到整個集羣。
藉助雙層數據分片的架構，SOFARegistry 具有了支撐海量數據的基石
● 支持海量數據：每臺 DataServer 只存儲一部分的分片數據，隨數據規模的增長，只要擴容 DataServer 服務器即可。
● 支持海量客戶端：連接層的 SessionServer 只負責跟 Client 打交道，SessionServer 之間沒有任何通信或數據複製，所以隨着業務規模的增長，SessionServer 可以較輕量地擴容，不會對集羣造成額外負擔。
數據結構
作爲註冊中心的基礎功能，SOFARegistry 提供發佈訂閱的接口：Subscriber、Publisher。
在服務發現場景下，Subscriber 需要通過服務名稱從註冊中心訂閱到多個服務方的地址，進行負載均衡的訪問。
當存在服務方機器宕機時，註冊中心通知所有的訂閱方從服務列表中摘除這個 IP 地址，這樣就不會再訪問宕機的機器。
下面給出簡化後的發佈者和訂閱者的字段，貼合上述服務發現的需求。
class Subscriber{
String dataId; // 服務名稱
String group; // 業務類型，比如RPC、MSG等等
String instanceId; // 租戶名稱
String zone; // 所在分區，結合scope實現邏輯隔離
ScopeEnum scope; // 訂閱範圍: zone、dataCenter、global
}
class Publisher{
String dataId;
String group;
String instanceId;
String zone;
List<String> dataList; // 發佈的數據, sofarpc 用法中常見url
}
常見用法（JAVA SDK）
發佈者
// 構造發佈者註冊表
PublisherRegistration registration = new PublisherRegistration("com.alipay.test.demo.service:1.0@DEFAULT");
registration.setGroup("TEST_GROUP");
registration.setAppName("TEST_APP");
// 將註冊表註冊進客戶端併發布數據
Publisher publisher = registryClient.register(registration, "10.10.1.1:12200?xx=yy");
// 如需覆蓋上次發佈的數據可以使用發佈者模型重新發布數據
publisher.republish("10.10.1.1:12200?xx=zz");
訂閱者
// 創建 SubscriberDataObserver
SubscriberDataObserver subscriberDataObserver = new SubscriberDataObserver() {
@Override
public void handleData(String dataId, UserData userData) {
System.out.println("receive data success, dataId: " + dataId + ", data: " + userData);
}
};
// 構造訂閱者註冊表，設置訂閱維度，ScopeEnum 共有三種級別 zone, dataCenter, global
String dataId = "com.alipay.test.demo.service:1.0@DEFAULT";
SubscriberRegistration registration = new SubscriberRegistration(dataId, subscriberDataObserver);
registration.setGroup("TEST_GROUP");
registration.setAppName("TEST_APP");
registration.setScopeEnum(ScopeEnum.global);
// 將註冊表註冊進客戶端並訂閱數據，訂閱到的數據會以回調的方式通知 SubscriberDataObserver
Subscriber subscriber = registryClient.register(registration);
更詳細的用法文檔參考官方文檔: https://www.sofastack.tech/projects/sofa-registry/java-sdk/
特點與優勢
這是一張 SOFARegistry 和其他註冊中心產品的特性對比圖，可以看出相比其他產品，SOFARegistry 在功能特性方面還是不足（未來 SOFARegistry 在特性方面會進行完善）。 SOFARegistry 的主要優勢還是在於支撐超大規模集羣，目前比較貼合螞蟻對服務註冊中心容量與性能的要求。
最終一致性
在服務發現場景下，強一致性並不一定是最合適的。服務發現的要求是發佈方的變更能夠在最快速的廣播到整個集羣，收斂時長確定的最終一致性同樣能滿足此要求。基於 CAP 原理，在滿足一致性 C 的場景下，AP 只能選擇一個，但作爲一個分佈式高可用要求的系統，註冊中心是不能捨棄 AP 的。
SOFARegistry 選擇了 AP 模型，採用內存對數據進行存儲，增量搭配全量的數據同步方式，使得能夠滿足超大規模集羣服務發現的需求。
支持海量數據
部分的服務註冊中心繫統，每臺服務器都是存儲着全量的服務註冊數據，服務器之間依靠一致性協議(paxos/raft)實現數據的複製，或者只保證最終一致性的異步數據複製。
“每臺服務器都存儲着全量的服務註冊數據”，在一般規模下是沒問題的。但是在螞蟻集團龐大的業務規模下，服務註冊的數據總量早就超過了單臺服務器的容量瓶頸。
SOFARegistry 對數據進行了分片，每臺 DataServer 只存儲一部分的分片數據。隨數據規模的增長，只要擴容 DataServer 服務器即可應對，這是相對其他服務發現領域的競品來說最大的特點。
我們在線上驗證了橫向擴展能力，集羣嘗試最大擴容到 session370、data60、meta*3。按照一個 data 節點的安全水位支撐 200w pub 一個 pub 大概 1.5K 開銷，考慮容忍 data 節點宕機 1/3 仍然有服務能力（需要保留 pub 上漲的 buffer），該集羣可支撐 1.2 億的 pub，如果配置雙副本則可支撐 6kw 的 pub。
支持海量客戶端
SOFARegistry 集羣內部使用分層的架構，分別爲連接會話層(SessionServer)和數據存儲層(DataServer)。SessionServer 功能很純粹，只負責跟 Client 打交道，SessionServer 之間沒有任何通信或數據複製，所以隨着業務規模(即 Client 數量)的增長，SessionServer 可以很輕量地擴容，不會對集羣造成額外負擔。
高可用
各個角色都有 FailOver 機制：
- MetaServer 集羣部署
內部基於數據庫選舉，只能存在任意運行中機器，就可以對外服務。
- DataServer 集羣部署
基於自研的 slot 分片算法進行數據分片，數據分片擁有多個副本，一個主副本和多個備副本。如果 DataServer 宕機，MetaServer 能感知，並通知所有 DataServer 和 SessionServer，MetaServer 會快速提升備副本的 DataServer 成爲主副本，減少宕機影響時長。
- SessionServer 集羣部署
任何一臺 SessionServer 宕機時，Client 會自動 FailOver 到其他 SessionServer，並且 Client 會拿到最新的 SessionServer 列表，後續不會再連接這臺宕機的 SessionServer。
秒級的服務上下線通知
對於服務的上下線變化，SOFARegistry 使用推送機制，快速地實現端到端的傳達。SOFARegistry 能通過斷鏈事件和心跳快速檢測出來服務宕機的狀況。
無損運維
SOFARegistry 基於內存存儲和分佈式的特點，自身在運維的時候勢必帶來數據遷移。 通過自研的 slot 分片遷移算法和數據回放功能，使得 SOFARegistry 實現了自身運維期間依然能夠對外提供服務，服務零損失。
業務功能
發佈訂閱
發佈訂閱是 SOFARegistry 最基礎的功能。
按 IP 下線
對於沒有服務流量 goaway 和重試功能的場景下，藉助註冊中心實現服務流量的 zero down 運維是一個比較重要的需求。
SOFARegistry 提供 HTTP 接口進行指定 IP 的 Publisher 下線，可以在業務代碼無侵入的場景下實現在一個機器下線下，管控端先從註冊中心下線這個 IP 對應的所有 Publisher。
應用級服務發現
SOFARegistry 內部集成了一個基於數據庫的元數據中心，參考 Dubbo3 的應用級服務發現方案，實現了和 MOSN 配合的應用級服務發現方案，大幅度減少註冊中心的數據量與對客戶端的推送量，該特性已經在螞蟻大規模上線，能夠降低註冊中心數據量一個數量級以上。
數據架構
SOFARegistry 分爲多個角色，多個角色之間進行數據同步實現了高可用。
slot 分片
我們從邏輯上將數據範圍劃分成 N 個大小相等的 Slot，並且 Slot 數量後續不可再修改。然後，還需要引進“路由表”SlotTable 的概念，SlotTable 負責存放這每個節點和 N 個 Slot 的映射關係，並保證儘量把所有 Slot 均勻地分配給每個節點。
Session 在進行路由的時候，根據 DataInfoId 的 Hash 值確定數據所在 Slot，再從路由表中拿到數據對應的 Data 節點進行數據拉取，每個 Slot 都會有一個主節點和多個副本節點，從而實現主節點宕機的時候，副本節點能快速提升爲主節點。
分配算法的主要邏輯是：
- 主節點和副本節點不能分配在同一個 Data 上；
- Slot 對應主節點 Data 宕機時，優先提升副本節點爲主節點，減少不可服務時間；
- 新節點先作爲副本節點進行數據同步；
- 主要目標在於減少節點變更時，儘可能縮短註冊中心數據的不可用時長。
流程
源碼導航
- 接收 Subscriber
- 接收 Publisher
- Data 接收 Session 的數據寫入
- Session 接收 Data 的數據變更通知
- Session 從 Data 拉取數據
- Session 推送給 Client
- 對比 Session 推送版本和 Data 的數據版本，觸發兜底推送
- Data 定時從 Session 批量拉取數據
- Data Follower 定期從 Leader 批量拉取數據
數據一致性
-
client 對於每個 publisher 都會維護一個 version，每次 pub/unpub 都會自增，會帶着 version 一起發送到 session
-
session 通過 version 的判斷來避免併發場景下高低版本的覆蓋問題
-
data 通過 version 的判斷來避免併發場景下高低版本的覆蓋問題
數據推送
-
session 接收到 client 的數據寫入時，會發送到指定的 data 上
-
session 通過斷鏈事件和心跳來檢測 client 的宕機
-
當 data 內發生服務變更（比如接受到了新的 pub），data 會通知所有的 session 觸發對應 dataId 推送
數據同步兜底
-
session 會把 client 註冊的 pub 和 sub 都存儲在內存中，data 會定時和所有的 session 同步對比數據，確保數據能在短時間內達到最終一致。
-
session 定時對比內存中 sub 的推送完成的版本和 data 上數據的最新判斷，判斷是否需要觸發推送。
-
data 包含多個 slot，擁有 follower slot 的 data 會定時和對應的 slot leader 對比同步數據。
本文主要介紹 SOFARegistry 自身的基礎功能與優勢，以及數據架構的大致介紹。
下一篇將會開始介紹如何開發 SOFARegistry 以及各個代碼模塊的介紹，歡迎大家繼續關注 SOFARegistry ～
本週推薦閱讀
穩定性大幅度提升：SOFARegistry v6 新特性介紹
