[原始碼閱讀] 阿里SOFA服務註冊中心MetaServer(1)
阿新 • • 發佈：2020-10-09
# [原始碼閱讀] 阿里SOFA服務註冊中心MetaServer(1)
[toc]
## 0x00 摘要
SOFARegistry 是螞蟻金服開源的一個生產級、高時效、高可用的服務註冊中心。本系列將帶領大家一起分析其MetaServer的實現機制，本文為第一篇，介紹MetaServer總體架構。
本系列總體參考了官方的部落格，具體請參見"0xFF 參考"。大家可以把參考作為總綱，我這系列文章作為註釋補遺翻閱。
## 0x01 服務註冊中心
### 1.1 服務註冊中心簡介
在微服務架構下，一個網際網路應用的服務端背後往往存在大量服務間的相互呼叫。例如服務 A 在鏈路上依賴於服務 B，那麼在業務發生時，服務 A 需要知道服務 B 的地址，才能完成服務呼叫。而分散式架構下，每個服務往往都是叢集部署的，叢集中的機器也是經常變化的，所以服務 B 的地址不是固定不變的。如果要保證業務的可靠性，服務呼叫者則需要感知被呼叫服務的地址變化。
既然成千上萬的服務呼叫者都要感知這樣的變化，**那這種感知能力便下沉成為微服務中一種固定的架構模式：服務註冊中心**。
服務註冊中心裡，有服務提供者和服務消費者兩種重要的角色，服務呼叫方是消費者，服務被調方是提供者。對於同一臺機器，往往兼具兩者角色，既被其它服務呼叫，也呼叫其它服務。服務提供者將自身提供的服務資訊釋出到服務註冊中心，服務消費者通過訂閱的方式感知所依賴服務的資訊是否發生變化。
服務註冊中心在服務呼叫的場景中，扮演一個“中介”的角色，服務釋出者 (Publisher) 將服務釋出到服務註冊中心，服務呼叫方 (Subscriber) 通過訪問服務註冊中心就能夠獲取到服務資訊，進而實現呼叫。
Subscriber 在第一次呼叫服務時，會通過 Registry 找到相應的服務的 IP 地址列表，通過負載均衡演算法從 IP 列表中取一個服務提供者的伺服器呼叫服務。同時 Subscriber 會將 Publisher 的服務列表資料快取到本地，供後續使用。當 Subscriber 後續再呼叫 Publisher 時，優先使用快取的地址列表，不需要再去請求Registry。
```java
+----------+ +---------+
|Subscriber| <--------+ +--------+ |Publisher|
+----------+ | | +---------+
| |
+----------+ | v
|Subscriber| <--------+ +----------++ +---------+
+----------+ <---+ Registry | <-------+Publisher|
| +----------++ +---------+
+----------+ | ^
|Subscriber| <--------+ |
+----------+ |
| +---------+
+----------+Publisher|
+---------+
```
服務註冊中心Registry的最主要能力是服務註冊和服務發現兩個過程。
- 服務註冊的過程最重要是對服務釋出的資訊進行儲存。
- 服務發現的過程是把服務釋出端的所有變化（包括節點變化和服務資訊變化）及時準確的通知到訂閱方的過程。
### 1.2 SOFARegistry 總體架構
#### 1.2.1 分層
SOFARegistry 作為服務註冊中心，分為4個層，分別為：
- **Client 層**
Client 層是應用伺服器叢集。Client 層是應用層，每個應用系統通過依賴註冊中心相關的客戶端 jar 包，通過程式設計方式來使用服務註冊中心的服務釋出和服務訂閱能力。
- **Session 層**
Session層是伺服器叢集。顧名思義，Session 層是會話層，通過長連線和 Client 層的應用伺服器保持通訊，負責接收 Client 的服務釋出和服務訂閱請求。
在服務註冊中心的服務端因為每個儲存節點對應的客戶端的連結資料量有限，必須進行特殊的一層劃分用於專門收斂無限擴充的客戶端連線，然後在透傳相應的請求到儲存層。
該層只在記憶體中儲存各個服務的釋出訂閱關係，對於具體的服務資訊，只在 Client 層和 Data 層之間透傳轉發。Session 層是一個無資料狀態的代理層，可以隨著 Client 層應用規模的增長而擴容