服務註冊中心和配置中心的選擇

註冊中心的本質和選擇

註冊中心本質就是一個 Query 函數：Si=F(ServiceName)

其中 ServiceName 爲查詢服務參數，Si 爲服務可用的列表（IP:Port）

如下圖所示：

1. ServiceA 的三個實例實測註冊到註冊中心；

2. 服務調用方想要調用 ServiceA，通過 ServiceName 去註冊中心查詢。然後註冊中心通過 Si=F(ServiceName) 查詢出 Service 的 IP:Port 列表。

3. 服務調用方通過 IP:Port 列表去調用服務。

上面的圖畫的很清楚，解釋的也挺完美。但我們想一個問題：對於 ServiceA 來說，如果它在註冊中心註冊的時候，只成功了兩個實例，那麼是否應該允許服務調用方訪問 Service 的兩個實例？

在真實的微服務中，我們一定是希望服務調用方能訪問 ServiceA 註冊成功的兩個實例的。而不是必須三個實例都註冊成功才能被訪問。最多是實例流量不均衡。

因此，註冊中心強調的是 CP 模型，而不是 AP 模型。它應該追求最終一致性就可以。註冊中心本質應該是一個 AP 模型。

此外，註冊中心不能因爲自身的任何原因破壞服務之間本身的可連通性。

如下圖所示，我們將服務註冊中心集羣三個實例分別部署到三個機房。每個機房各有兩個微服務。如果機房 3 的網絡出現問題，不能與機房 1 和機房 2 進行通訊，結果是什麼呢？

如果是強一致性的註冊中心（CP 模型），那麼機房 C 實例 3 由於是少數節點，將會出現問題，down 掉。這樣，不僅 ServerE 和 ServiceF 不能訪問機房 1 和機房 2 的服務，這兩個服務之間的訪問也會出問題。

接下來，我們看一下幾種註冊中心的對比。

我們看到 ZooKeeper（下面簡稱 ZK）、etcd、Consul 都是 CP 模型。而 ectd 和 ZK 都不支持跨數據中心部署，因此就沒有討論類似 K8S 和 OpenShift 三個 Master 跨數據中心部署的必要性了。

ZK 是 google chubby（paxos 分佈式協調算法）的開源實現，內部用的 zab。

ZK 可以起到分佈式程序協調服務的作用，其中包括：

• 節點選主

• 配置管理

• 粗粒度分佈式鎖（併發不是很高）

• 服務註冊

• 服務發現

當分佈式集羣節點大於 1000 時，或者大規模交易，大規模服務發現時，使用 ZK 做註冊中心不合適。ZK 適合：大數據、分佈式協調。例如：kafka、flink、spark、hadoop、storm。

不適合：

目前在業務側，服務註冊中心比較好的是 Nacos。我們使用 Nacos 的 AP 模式做註冊中心。

但 Gossip 協議也有缺點：消息延遲、消息冗餘。

如果我們要自行設計一個功能完善的服務註冊中心，應該能到達如下的效果：

• 提供可跨語言的服務註冊和服務發現功能

• 提供指令下發功能（註冊中心和業務之間是 TCP 長連接）能對集羣服務進行管理。管理指令（熔斷、熔斷恢復、限流）存在時效性，指令是可損的。

• 提供節點信息存儲與擴展。服務器類型（物理機、VM、容器雲）節點權重、服務分組等。

服務註冊發現：

配置策略下發:

配置中心的本質和選擇

配置中心存儲的是獨立於應用的只讀變量。配置中心需要有權限控制，可以進行多個不同集羣的配置管理。

在配置中心方面，由於 ZK 和 etcd 沒有邊界的 UI 管理工具，並且沒有權限管理和審覈機制，我們不選擇它們作爲業務配置中心。需要指出的是，OpenShift 的默認的配置管理是 ConfigMap。通過這種方式給應用註冊配置。ConfigMap 訪問權限控是由 OpenShift 自身的 RBAC 提供。目前我看到的客戶微服務的配置，大多是使用外置的配置中心。

幾種開源的配置中心對比如下：

我們知道，Nacos 也有配置中心的功能，但 Apollo 的穩定性更很高。因此配置中心我們選擇 Apollo。

Apollo 支持 java、.net 應用。針對這兩種語言有客戶端。如果不是這兩種應用，使用 http 協議。

Apollo Server 端的內部架構如下：    

Apollo 由於較好的冗餘性設計，其高可用很強：

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/4gOoYI9GsfauCcDoq_6Wxw