開源註冊中心架構
- 客戶端 註冊中心
- 服務端 註冊中心
一般分爲應用內註冊和應用外註冊
- 應用內註冊與發現：註冊中心提供服務端和客戶端的 SDK，業務應用通過引入註冊中心提供的 SDK，通過 SDK 與註冊中心交互，來實現服務的註冊和發現。
- 應用外註冊與發現：業務應用本身不需要通過 SDK 與註冊中心打交道，而是通過其他方式與註冊中心交互，間接完成服務註冊與發現。
![在這裏插入圖片描述]()
- Eureka Server：註冊中心的服務端，實現了服務信息註冊、存儲以及查詢等功能。
- 服務端的 Eureka Client：集成在服務端的註冊中心 SDK，服務提供者通過調用 SDK，實現服務註冊、反註冊等功能。客戶端的
- Eureka Client：集成在客戶端的註冊中心 SDK，服務消費者通過調用 SDK，實現服務訂閱、服務更新等功能。
![在這裏插入圖片描述]()
- Consul：註冊中心的服務端，實現服務註冊信息的存儲，並提供註冊和發現服務。
- Registrator：一個開源的第三方服務管理器項目，它通過監聽服務部署的 Docker 實例是否存活，來負責服務提供者的註冊和銷燬。
- Consul Template：定時從註冊中心服務端獲取最新的服務提供者節點列表並刷新 LB 配置（比如 Nginx 的 upstream），這樣服務消費者就通過訪問 Nginx 就可以獲取最新的服務提供者信息。
註冊中心選型
主要看應用場景
高可用性
- 集羣部署
- 多IDC部署
從下面的官方架構圖中你可以看到，一方面，在每個數據中心（DATACENTER）內都有多個註冊中心 Server 節點可供訪問；另一方面還可以部署在多個數據中心來保證多機房高可用性。
![在這裏插入圖片描述]()
數據一致性
數據一致性問題一般是 採用cap原理 C（Consistency）代表一致性，A（Avalibabilty)可用性 ，P（Partition Tolerance)代表分區容錯性
分佈式集羣如何保證數據一致性
問題描述：
- 分區有可能網絡問題導出整個網絡被切割成互不連通的區域，出現分區一個區域的節點就沒有辦法相互訪問，最好的辦法就是把數據複製到其他區域內的節點，這就是數據的容錯性。
- 但是把數據複製到多個節點上有可能出現數據不一致的問題，這就是一致性。要保證一致性，就要等所有節點上的數據都更新成功纔可以，這就是可用性。
- 總的來說數據節點越多，分區容錯性越高，但是數據一致性就越難保證。爲了保證數據一致性，會帶來可用性問題。
cp型註冊中
犧牲可用性來保證數據的一致性，最典型的就是zookeeper，etcd,Consul.Zookeeper集羣內部只有一個Leader，而且在leader無法使用是會通過Paxos算法選舉出一個Leader.這個leader就是爲了保證寫信息的時候只向這個Leader寫入，Leader會同步信息到Followers，這個過程就可以保證數據強一致性。但如果多個Zookerper之間出現網絡問題，造成多個Leader，發生腦裂的話註冊中心就不可用
Ap型註冊中心
犧牲數據一致性，保證服務的可用性，最典型的急速Eureka