ZooKeeper怎么實(shí)現(xiàn)注冊中心

本篇內(nèi)容介紹了“ZooKeeper怎么實(shí)現(xiàn)注冊中心”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

實(shí)現(xiàn)方式

注冊中心API

根據(jù)注冊中心原理的描述，注冊中心必須提供以下最基本的API，例如：

• 服務(wù)注冊接口：服務(wù)提供者通過調(diào)用服務(wù)注冊接口來完成服務(wù)注冊。
  

• 服務(wù)反注冊接口：服務(wù)提供者通過調(diào)用服務(wù)反注冊接口來完成服務(wù)注銷。
  

• 心跳匯報(bào)接口：服務(wù)提供者通過調(diào)用心跳匯報(bào)接口完成節(jié)點(diǎn)存活狀態(tài)上報(bào)。
  

• 服務(wù)訂閱接口：服務(wù)消費(fèi)者通過調(diào)用服務(wù)訂閱接口完成服務(wù)訂閱，獲取可用的服務(wù)提供者節(jié)點(diǎn)列表。
  

• 服務(wù)變更查詢接口：服務(wù)消費(fèi)者通過調(diào)用服務(wù)變更查詢接口，獲取最新的可用服務(wù)節(jié)點(diǎn)列表。
  

除此之外，為了便于管理，注冊中心還必須提供一些后臺(tái)管理的API，例如：

• 服務(wù)查詢接口：查詢注冊中心當(dāng)前注冊了哪些服務(wù)信息。
  

• 服務(wù)修改接口：修改注冊中心中某一服務(wù)的信息。
  

集群部署

注冊中心作為服務(wù)提供者和服務(wù)消費(fèi)者之間溝通的橋梁，它的重要性不言而喻。所以注冊中心一般都是采用集群部署來保證高可用性，并通過分布式一致性協(xié)議來確保集群中不同節(jié)點(diǎn)之間的數(shù)據(jù)保持一致。

以開源注冊中心ZooKeeper為例，ZooKeeper集群中包含多個(gè)節(jié)點(diǎn)，服務(wù)提供者和服務(wù)消費(fèi)者可以同任意一個(gè)節(jié)點(diǎn)通信，因?yàn)樗鼈兊臄?shù)據(jù)一定是相同的，這是為什么呢？這就要從ZooKeeper的工作原理說起：

• 每個(gè)Server在內(nèi)存中存儲(chǔ)了一份數(shù)據(jù)，Client的讀請(qǐng)求可以請(qǐng)求任意一個(gè)Server。
  

• ZooKeeper啟動(dòng)時(shí)，將從實(shí)例中選舉一個(gè)leader（Paxos協(xié)議）。
  

• Leader負(fù)責(zé)處理數(shù)據(jù)更新等操作（ZAB協(xié)議）。
  

• 一個(gè)更新操作成功，當(dāng)且僅當(dāng)大多數(shù)Server在內(nèi)存中成功修改 。
  

通過上面這種方式，ZooKeeper保證了高可用性以及數(shù)據(jù)一致性。

目錄存儲(chǔ)

還是以ZooKeeper為例，注冊中心存儲(chǔ)服務(wù)信息一般采用層次化的目錄結(jié)構(gòu)：

• 每個(gè)目錄在ZooKeeper中叫作znode，并且其有一個(gè)唯一的路徑標(biāo)識(shí)。
  

• znode可以包含數(shù)據(jù)和子znode。
  

• znode中的數(shù)據(jù)可以有多個(gè)版本，比如某一個(gè)znode下存有多個(gè)數(shù)據(jù)版本，那么查詢這個(gè)路徑下的數(shù)據(jù)需帶上版本信息。
  

服務(wù)健康狀態(tài)檢測

注冊中心除了要支持最基本的服務(wù)注冊和服務(wù)訂閱功能以外，還必須具備對(duì)服務(wù)提供者節(jié)點(diǎn)的健康狀態(tài)檢測功能，這樣才能保證注冊中心里保存的服務(wù)節(jié)點(diǎn)都是可用的。

還是以ZooKeeper為例，它是基于ZooKeeper客戶端和服務(wù)端的長連接和會(huì)話超時(shí)控制機(jī)制，來實(shí)現(xiàn)服務(wù)健康狀態(tài)檢測的。

在ZooKeeper中，客戶端和服務(wù)端建立連接后，會(huì)話也隨之建立，并生成一個(gè)全局唯一的Session ID。服務(wù)端和客戶端維持的是一個(gè)長連接，在SESSION_TIMEOUT周期內(nèi)，服務(wù)端會(huì)檢測與客戶端的鏈路是否正常，具體方式是通過客戶端定時(shí)向服務(wù)端發(fā)送心跳消息（ping消息），服務(wù)器重置下次SESSION_TIMEOUT時(shí)間。如果超過SESSION_TIMEOUT后服務(wù)端都沒有收到客戶端的心跳消息，則服務(wù)端認(rèn)為這個(gè)Session就已經(jīng)結(jié)束了，ZooKeeper就會(huì)認(rèn)為這個(gè)服務(wù)節(jié)點(diǎn)已經(jīng)不可用，將會(huì)從注冊中心中刪除其信息。

服務(wù)狀態(tài)變更通知

一旦注冊中心探測到有服務(wù)提供者節(jié)點(diǎn)新加入或者被剔除，就必須立刻通知所有訂閱該服務(wù)的服務(wù)消費(fèi)者，刷新本地緩存的服務(wù)節(jié)點(diǎn)信息，確保服務(wù)調(diào)用不會(huì)請(qǐng)求不可用的服務(wù)提供者節(jié)點(diǎn)。

繼續(xù)以ZooKeeper為例，基于ZooKeeper的Watcher機(jī)制，來實(shí)現(xiàn)服務(wù)狀態(tài)變更通知給服務(wù)消費(fèi)者的。服務(wù)消費(fèi)者在調(diào)用ZooKeeper的getData方法訂閱服務(wù)時(shí)，還可以通過監(jiān)聽器Watcher的process方法獲取服務(wù)的變更，然后調(diào)用getData方法來獲取變更后的數(shù)據(jù)，刷新本地緩存的服務(wù)節(jié)點(diǎn)信息。

白名單機(jī)制

在實(shí)際的微服務(wù)測試和部署時(shí)，通常包含多套環(huán)境，比如生產(chǎn)環(huán)境一套、測試環(huán)境一套。開發(fā)在進(jìn)行業(yè)務(wù)自測、測試在進(jìn)行回歸測試時(shí)，一般都是用測試環(huán)境，部署的RPC Server節(jié)點(diǎn)注冊到測試的注冊中心集群。但經(jīng)常會(huì)出現(xiàn)開發(fā)或者測試在部署時(shí)，錯(cuò)誤的把測試環(huán)境下的服務(wù)節(jié)點(diǎn)注冊到了線上注冊中心集群，這樣的話線上流量就會(huì)調(diào)用到測試環(huán)境下的RPC Server節(jié)點(diǎn)，可能會(huì)造成意想不到的后果。

為了防止這種情況發(fā)生，注冊中心需要提供一個(gè)保護(hù)機(jī)制，你可以把注冊中心想象成一個(gè)帶有門禁的房間，只有擁有門禁卡的RPC Server才能進(jìn)入。在實(shí)際應(yīng)用中，注冊中心可以提供一個(gè)白名單機(jī)制，只有添加到注冊中心白名單內(nèi)的RPC Server，才能夠調(diào)用注冊中心的注冊接口，這樣的話可以避免測試環(huán)境中的節(jié)點(diǎn)意外跑到線上環(huán)境中去。

解決方案

當(dāng)下主流的服務(wù)注冊與發(fā)現(xiàn)的解決方案，主要有兩種：

1. 應(yīng)用內(nèi)注冊與發(fā)現(xiàn)：注冊中心提供服務(wù)端和客戶端的SDK，業(yè)務(wù)應(yīng)用通過引入注冊中心提供的SDK，通過SDK與注冊中心交互，來實(shí)現(xiàn)服務(wù)的注冊和發(fā)現(xiàn)。
   

2. 應(yīng)用外注冊與發(fā)現(xiàn)：業(yè)務(wù)應(yīng)用本身不需要通過SDK與注冊中心打交道，而是通過其他方式與注冊中心交互，間接完成服務(wù)注冊與發(fā)現(xiàn)。
   

這兩種解決方案的不同之處在于應(yīng)用場景，應(yīng)用內(nèi)的解決方案一般適用于服務(wù)提供者和服務(wù)消費(fèi)者同屬于一個(gè)技術(shù)體系；應(yīng)用外的解決方案一般適合服務(wù)提供者和服務(wù)消費(fèi)者采用了不同技術(shù)體系的業(yè)務(wù)場景，比如服務(wù)提供者提供的是C++服務(wù)，而服務(wù)消費(fèi)者是一個(gè)Java應(yīng)用，這時(shí)候采用應(yīng)用外的解決方案就不依賴于具體一個(gè)技術(shù)體系。同時(shí)，對(duì)于容器化后的云應(yīng)用來說，一般不適合采用應(yīng)用內(nèi)SDK的解決方案，因?yàn)檫@樣會(huì)侵入業(yè)務(wù)，而應(yīng)用外的解決方案正好能夠解決這個(gè)問題。

注冊中心選型

高可用性

注冊中心作為服務(wù)提供者和服務(wù)消費(fèi)者之間溝通的紐帶，它的高可用性十分重要。試想，如果注冊中心不可用了，那么服務(wù)提供者就無法對(duì)外暴露自己的服務(wù)，而服務(wù)消費(fèi)者也無法知道自己想要調(diào)用的服務(wù)的具體地址，后果將不堪設(shè)想。實(shí)現(xiàn)高可用性的方法主要有兩種：

• 集群部署，顧名思義就是通過部署多個(gè)實(shí)例組成集群來保證高可用性，這樣的話即使有部分機(jī)器宕機(jī)，將訪問遷移到正常的機(jī)器上就可以保證服務(wù)的正常訪問。
  

• 多IDC部署，就是部署在不止一個(gè)機(jī)房，這樣能保證即使一個(gè)機(jī)房因?yàn)閿嚯娀蛘吖饫|被挖斷等不可抗力因素不可用時(shí)，仍然可以通過把請(qǐng)求遷移到其他機(jī)房來保證服務(wù)的正常訪問。

數(shù)據(jù)一致性

為了保證注冊中心的高可用性，注冊中心的部署往往都采用集群部署，并且還通常部署在不止一個(gè)數(shù)據(jù)中心，這樣的話就會(huì)引出另一個(gè)問題，多個(gè)數(shù)據(jù)中心之間如何保證數(shù)據(jù)一致？如何確保訪問數(shù)據(jù)中心中任何一臺(tái)機(jī)器都能得到正確的數(shù)據(jù)？

這里就涉及分布式系統(tǒng)中著名的CAP理論，即同時(shí)滿足一致性、可用性、分區(qū)容錯(cuò)性這三者是不可能的，其中C（Consistency）代表一致性，A（Availability）代表可用性，P（Partition Tolerance）代表分區(qū)容錯(cuò)性。

為什么說CAP三者不能被同時(shí)滿足的呢？

你可以想象在一個(gè)分布式系統(tǒng)里面，包含了多個(gè)節(jié)點(diǎn)，節(jié)點(diǎn)之間通過網(wǎng)絡(luò)連通在一起。正常情況下，通過網(wǎng)絡(luò)，從一個(gè)節(jié)點(diǎn)可以訪問任何別的節(jié)點(diǎn)上的數(shù)據(jù)。

但是有可能出現(xiàn)網(wǎng)絡(luò)故障，導(dǎo)致整個(gè)網(wǎng)絡(luò)被分成了互不連通的區(qū)域，這就叫作分區(qū)。一旦出現(xiàn)分區(qū)，那么一個(gè)區(qū)域內(nèi)的節(jié)點(diǎn)就沒法訪問其他節(jié)點(diǎn)上的數(shù)據(jù)了，最好的辦法是把數(shù)據(jù)復(fù)制到其他區(qū)域內(nèi)的節(jié)點(diǎn)，這樣即使出現(xiàn)分區(qū)，也能訪問任意區(qū)域內(nèi)節(jié)點(diǎn)上的數(shù)據(jù)，這就是分區(qū)容錯(cuò)性。

但是把數(shù)據(jù)復(fù)制到多個(gè)節(jié)點(diǎn)就可能出現(xiàn)數(shù)據(jù)不一致的情況，這就是一致性。要保證一致，就必須等待所有節(jié)點(diǎn)上的數(shù)據(jù)都更新成功才可用，這就是可用性。

總的來說，就是數(shù)據(jù)節(jié)點(diǎn)越多，分區(qū)容錯(cuò)性越高，但數(shù)據(jù)一致性越難保證。為了保證數(shù)據(jù)一致性，又會(huì)帶來可用性的問題。

而注冊中心一般采用分布式集群部署，也面臨著CAP的問題，根據(jù)CAP不能同時(shí)滿足，所以不同的注冊中心解決方案選擇的方向也就不同，大致可分為兩種。

• CP型注冊中心，犧牲可用性來保證數(shù)據(jù)強(qiáng)一致性，最典型的例子就是ZooKeeper，etcd，Consul了。ZooKeeper集群內(nèi)只有一個(gè)Leader，而且在Leader無法使用的時(shí)候通過Paxos算法選舉出一個(gè)新的Leader。這個(gè)Leader的目的就是保證寫信息的時(shí)候只向這個(gè)Leader寫入，Leader會(huì)同步信息到Followers，這個(gè)過程就可以保證數(shù)據(jù)的強(qiáng)一致性。但如果多個(gè)ZooKeeper之間網(wǎng)絡(luò)出現(xiàn)問題，造成出現(xiàn)多個(gè)Leader，發(fā)生腦裂的話，注冊中心就不可用了。而etcd和Consul集群內(nèi)都是通過raft協(xié)議來保證強(qiáng)一致性，如果出現(xiàn)腦裂的話， 注冊中心也不可用。
  

• AP型注冊中心，犧牲一致性來保證可用性，最典型的例子就是Eureka了。對(duì)比下Zookeeper，Eureka不用選舉一個(gè)Leader，每個(gè)Eureka服務(wù)器單獨(dú)保存服務(wù)注冊地址，因此有可能出現(xiàn)數(shù)據(jù)信息不一致的情況。但是當(dāng)網(wǎng)絡(luò)出現(xiàn)問題的時(shí)候，每臺(tái)服務(wù)器都可以完成獨(dú)立的服務(wù)。
  

而對(duì)于注冊中心來說，最主要的功能是服務(wù)的注冊和發(fā)現(xiàn)，在網(wǎng)絡(luò)出現(xiàn)問題的時(shí)候，可用性的需求要遠(yuǎn)遠(yuǎn)高于數(shù)據(jù)一致性。即使因?yàn)閿?shù)據(jù)不一致，注冊中心內(nèi)引入了不可用的服務(wù)節(jié)點(diǎn)，也可以通過其他措施來避免，比如客戶端的快速失敗機(jī)制等，只要實(shí)現(xiàn)最終一致性，對(duì)于注冊中心來說就足夠了。因此，選擇AP型注冊中心，一般更加合適。

“ZooKeeper怎么實(shí)現(xiàn)注冊中心”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！