在微服務架構下，主要有三種角色：

• 服務提供者(RPC Server)
• 服務消費者(RPC Client)
• 服務注冊中心(Registry)

RPC Server：服務提供者，啟動時根據服務發布文件server.xml中的配置信息向Registry注冊自身服務，并定期向Registry發送心跳匯報存活狀態。

RPC Client：服務消費者，啟動時根據服務引用文件client.xml中的配置信息向Registry訂閱服務，并緩存Registry返回的服務節點列表到本地內存中。

RPC Server節點變更：Registry會同步變更，RPC Client感知到服務節點變更后會更新本地內存中緩存的服務節點列表。

RPC Client調用：RPC Client根據本地緩存的服務節點列表，基于負載均衡算法選擇一臺RPC Server發起調用。

注冊中心實現思路：

• 注冊中心需要提供哪些接口？
• 注冊中心如何部署？
• 如何存儲服務信息
• 如何監控服務節點的存活狀態？
• 服務節點變更如何通知到消費者？
• 注冊中心的訪問權限控制？

1.注冊中心API

基本API:

• 服務注冊接口：服務提供者通過調用服務注冊接口完成服務注冊
• 服務反注冊接口：服務提供者通過調用服務反注冊接口完成服務注銷
• 心跳匯報接口：服務提供者通過心跳匯報接口上報節點存活狀態
• 服務訂閱接口：服務消費者通過調用服務訂閱接口完成服務訂閱，獲取到可用的服務提供者節點列表
• 服務變更查詢接口：服務消費者通過調用服務變更查詢接口，獲取最新的服務節點列表

后臺管理API:

• 服務查詢接口：查詢注冊中心當前注冊了哪些接口
• 服務修改接口：修改注冊中心的某一服務的信息

2.集群部署

注冊中心都是需要采用集群部署來保證注冊中心的高可用性，并通過分布式一致性協議確保集群中節點之前的數據一致性。

以開源注冊中心Zookeeper工作原理解釋：

• 每個server內存中存儲了一份數據，client可以請求任意server
• Zookeeper啟動時將從實例中選取一個leader(Paxos協議)
• leader負責處理數據更新等操作(ZAB協議)
• 一個更新操作成功，當且僅當大多數server在內存中更新成功

3.目錄存儲

開源注冊中心Zookeeper存儲服務信息采用的是層次化的目錄結構：

• 每個目錄在Zookeeper中叫作znode，并且具有一個唯一的路徑標識
• znode可以包含數據和子znode
• znode中的數據可以有多個版本，那么查詢這個路徑下的數據就需要帶入版本信息

4.服務健康狀態檢測

開源注冊中心Zookeeper的服務健康狀態檢測機制實現原理：通過客戶端和服務端建立長鏈接以及會話的超時機制來實現服務健康狀態檢測。

主要步驟如下：

• 客戶端與服務端建立長鏈接后，同時生成會話，并生成一個全局的唯一Session ID。
• 在客戶端和服務端的長鏈接的SESSION_TIMEOUT周期內，客戶端會定時向服務端發送心跳消息(ping消息)。
• 如果服務器接收到客戶端心跳消息，會后重置下次SESSION_TIMEOUT時間。
• 如果服務器在這個SESSION_TIMEOUT時間內沒有接收到客戶端心跳消息，則服務端會認為這個session就已經結束，zookeeper就會認為這個服務節點不可用，將會從注冊中心中刪除該節點信息。

5.服務狀態變更通知

一旦注冊中心檢測到有服務提供者節點新加入或者被剔除，就必須立刻通知所有訂閱該服務的消費者，刷新本地緩存的服務節點信息，確保服務調用不會請求到不可用的節點。

開源注冊中心Zookeeper的服務變更通知實現原理：是基于監聽器Watcher機制，來實現服務狀態變更通知給服務消費者。

主要步驟如下：

服務消費者在調用Zookeeper的getData方法訂閱服務時，還可以通過監聽器Watcher的process方法感知到服務的變更，再通過調用getData方法獲取變更后的數據，重新刷新本地緩存的節點信息。

6.白名單機制

注冊中心可以提供一個白名單機制，只有添加到注冊中心白名單內的RPC Server，才能調用注冊中心的注冊接口，避免測試環境的節點注冊到線上引起服務不可用。

這篇就總結到這里，如果喜歡我的文章，歡迎關注我的頭條號，后續會有新的文章更新。

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的微服务 注册中心_4.微服务架构的第二个组件：注册中心的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。