服務註冊發現與註冊中心對比-Eureka,Consul,Zookeeper,Nacos對比

註冊中心簡介

微服務架構中，註冊中心是最核心的基礎服務之一，註冊中心可以看做是微服務架構中的通信中心，當一個服務去請求另一個服務時，通過註冊中心可以獲取該服務的狀態，地址等核心信息。

服務註冊主要關係到三大角色：服務提供者、服務消費者、註冊中心。

流程和原理

基礎流程

服務啓動時，將自身的網絡地址等信息註冊到註冊中心，註冊中心記錄服務註冊數據。
服務消費者從註冊中心獲取服務提供者的地址，並通過地址和基於特定的方式調用服務提供者的接口。
各個服務與註冊中心使用一定機制通信。如果註冊中心與服務長時間無法通信，就會註銷該實例，這也稱爲服務下線，當服務重新連接之後，會基於一定的策略在線上線。
服務地址相關信息發生變化時，會重新註冊到註冊中心。這樣，服務消費者就無需手工維護提供者的相關配置。

核心功能

通過上面的基本流程，不難發現一個註冊中心需要具備哪些核心功能：

• 服務發現
  服務發現是指服務在啓動後，註冊到註冊中心，服務方提供自身的元數據，比如IP地址、端口、運行狀況指標的Uri 、主頁地址等信息。

• 服務記錄
  記錄註冊中心的服務的信息，例如服務名稱、IP地址、端口等。服務消費方基於查詢獲取可用的服務實例列表。

• 動態管理服務
  註冊中心基於特定的機制定時測試已註冊的服務，例如：默認的情況下會每隔30秒發送一次心跳來進行服務續約。通過服務續約來告知Server該Client仍然可用。正常情況下，如果Server在90 秒內沒有收到Client 的心跳，Server會將Client 實例從註冊列表中刪除。

1、Eureka、Consul、Zookeeper三者異同點

它們的使用方式基本一致，只是導入依賴不同。

1.1 Nacos 與其它註冊中心特性對比

Nacos 支持 AP（高可用） 和 CP（強一致性） 模式的切換
使用命令 curl -X PUT ‘$NACOS_SERVER:8848/nacos/v1/ns/operator/switches?entry=serverMode&value=CP’ 進行切換

2、CAP理論

• C：Consistency（強一致性）
  一致性就是說，我們讀寫數據必須是一摸一樣的。
  比如一條數據，分別存在兩個服務器中，server1和server2。
  我們此時將數據a通過server1修改爲數據b。此時如果我們訪問server1訪問的應該是b。
  當我們訪問server2的時候，如果返回的還是未修改的a，那麼則不符合一致性，如果返回的是b，則符合數據的一致性。

• A：Availability（可用性）
  只要我對服務器，發送請求，服務器必須對我進行相應，保證服務器一直是可用的。

• P：Partition tolerance（分區容錯性）
  一般來說，分佈式系統是分佈在多個位置的。比如我們的一臺服務器在北京，一臺在上海。可能由於天氣等原因的影響。造成了兩條服務器直接不能互相通信，數據不能進行同步。這就是分區容錯。我們認爲，分區容錯是不可避免的。也就是說 P 是必然存在的。

CAP 理論關注粒度是數據，而不是整體系統設計的策略
CAP 理論的核心是：一個分佈式系統不可能同時很好的滿足一致性, 可用性和分區容錯性這三個需求。

因此，根據CAP原理將NoSQL數據庫分成了滿足CA原則、滿足CP原則和滿足AP原則三大類:

• CA - 單點集羣，滿足一致性，可用性的系統，通常在可擴展性上不太強大。
• CP - 滿足一致性，分區容忍必的系統，通常性能不是特別高。
• AP - 滿足可用性，分區容忍性的系統，通常可能對一致性要求低一些。
  

3、eureka和zookeeper的cap理論

eureka是基於ap的。zookeeper是基於cp的。

3.1 Eureka

eureka的架構實現圖如下：

3.1.1 eureka的基本原理

上圖是來自eureka的官方架構圖，這是基於集羣配置的eureka；

• 處於不同節點的eureka通過Replicate進行數據同步
• Application Service爲服務提供者
• Application Client爲服務消費者
• Make Remote Call完成一次服務調用
  服務啓動後向Eureka註冊，Eureka Server會將註冊信息向其他Eureka Server進行同步，當服務消費者要調用服務提供者，則向服務註冊中心獲取服務提供者地址，然後會將服務提供者地址緩存在本地，下次再調用時，則直接從本地緩存中取，完成一次調用。

當服務註冊中心Eureka Server檢測到服務提供者因爲宕機、網絡原因不可用時，則在服務註冊中心將服務置爲DOWN狀態，並把當前服務提供者狀態向訂閱者發佈，訂閱過的服務消費者更新本地緩存。

服務提供者在啓動後，週期性（默認30秒）向Eureka Server發送心跳，以證明當前服務是可用狀態。Eureka Server在一定的時間（默認90秒）未收到客戶端的心跳，則認爲服務宕機，註銷該實例。

3.1.2 eureka的自我保護機制

在默認配置中，Eureka Server在默認90s沒有得到客戶端的心跳，則註銷該實例，但是往往因爲微服務跨進程調用，網絡通信往往會面臨着各種問題，比如微服務狀態正常，但是因爲網絡分區故障時，Eureka Server註銷服務實例則會讓大部分微服務不可用，這很危險，因爲服務明明沒有問題。

爲了解決這個問題，Eureka 有自我保護機制，通過在Eureka Server配置如下參數，可啓動保護機制。
eureka.server.enable-self-preservation=true
它的原理是，當Eureka Server節點在短時間內丟失過多的客戶端時（可能發送了網絡故障），那麼這個節點將進入自我保護模式，不再註銷任何微服務，當網絡故障回覆後，該節點會自動退出自我保護模式。

3.1.3 eureka保證ap

eureka優先保證可用性。在Eureka平臺中，如果某臺服務器宕機，Eureka不會有類似於ZooKeeper的選舉leader的過程；客戶端請求會自動切換 到新的Eureka節點；當宕機的服務器重新恢復後，Eureka會再次將其納入到服務器集羣管理之中；而對於它來說，所有要做的無非是同步一些新的服務 註冊信息而已。所以，再也不用擔心有“掉隊”的服務器恢復以後，會從Eureka服務器集羣中剔除出去的風險了。Eureka甚至被設計用來應付範圍更廣 的網絡分割故障，並實現“0”宕機維護需求。當網絡分割故障發生時，每個Eureka節點，會持續的對外提供服務（注：ZooKeeper不會）：接收新 的服務註冊同時將它們提供給下游的服務發現請求。這樣一來，就可以實現在同一個子網中（same side of partition），新發布的服務仍然可以被發現與訪問。Eureka各個節點都是平等的，幾個節點掛掉不會影響正常節點的工作，剩餘的節點依然可以提供註冊和查詢服務。而Eureka的客戶端在向某個Eureka註冊或時如果發現連接失敗，則會自動切換至其它節點，只要有一臺Eureka還在，就能保證註冊服務可用(保證可用性)，只不過查到的信息可能不是最新的(不保證強一致性)。除此之外，Eureka還有一種自我保護機制，如果在15分鐘內超過85%的節點都沒有正常的心跳，那麼Eureka就認爲客戶端與註冊中心出現了網絡故障，此時會出現以下幾種情況：

1. Eureka不再從註冊列表中移除因爲長時間沒收到心跳而應該過期的服務
2. Eureka仍然能夠接受新服務的註冊和查詢請求，但是不會被同步到其它節點上(即保證當前節點依然可用)
3. 當網絡穩定時，當前實例新的註冊信息會被同步到其它節點中
   Eureka還有客戶端緩存功能（注：Eureka分爲客戶端程序與服務器端程序兩個部分，客戶端程序負責向外提供註冊與發現服務接口）。 所以即便Eureka集羣中所有節點都失效，或者發生網絡分割故障導致客戶端不能訪問任何一臺Eureka服務器；Eureka服務的消費者仍然可以通過 Eureka客戶端緩存來獲取現有的服務註冊信息。甚至最極端的環境下，所有正常的Eureka節點都不對請求產生相應，也沒有更好的服務器解決方案來解 決這種問題時；得益於Eureka的客戶端緩存技術，消費者服務仍然可以通過Eureka客戶端查詢與獲取註冊服務信息。

4、zookeeper

zookeeper保證cp。
作爲一個分佈式協同服務，ZooKeeper非常好，但是對於Service發現服務來說就不合適了；因爲對於Service發現服務來說就算是 返回了包含不實的信息的結果也比什麼都不返回要好；再者，對於Service發現服務而言，寧可返回某服務5分鐘之前在哪幾個服務器上可用的信息，也不能 因爲暫時的網絡故障而找不到可用的服務器，而不返回任何結果。所以說，用ZooKeeper來做Service發現服務是肯定錯誤的。

當向註冊中心查詢服務列表時，我們可以容忍註冊中心返回的是幾分鐘以前的註冊信息，但不能接受服務直接down掉不可用。也就是說，服務註冊功能對可用性的要求要高於一致性。但是zk會出現這樣一種情況，當master節點因爲網絡故障與其他節點失去聯繫時，剩餘節點會重新進行leader選舉。問題在於，選舉leader的時間太長，30 ~ 120s, 且選舉期間整個zk集羣都是不可用的，這就導致在選舉期間註冊服務癱瘓。在雲部署的環境下，因網絡問題使得zk集羣失去master節點是較大概率會發生的事，雖然服務能夠最終恢復，但是漫長的選舉時間導致的註冊長期不可用是不能容忍的。

4.1 基礎描述

ZooKeeper是非常經典的服務註冊中心中間件，在國內環境下，由於受到Dubbo框架的影響，大部分情況下認爲Zookeeper是RPC服務框架下注冊中心最好選擇，隨着Dubbo框架的不斷開發優化，和各種註冊中心組件的誕生，即使是RPC框架，現在的註冊中心也逐步放棄了ZooKeeper。在常用的開發集羣環境中，ZooKeeper依然起到十分重要的作用，Java體系中，大部分的集羣環境都是依賴ZooKeeper管理服務的各個節點。

4.2 組件特點

從Zookeeper的數據結構特點看，並不是基於服務註冊而設計的，ZooKeeper提供的命名空間與文件系統的名稱空間非常相似，在數據結構上高度抽象爲K-V格式，十分通用，說到這裏不得不提一下Redis，也可以作爲註冊中心使用，只是用的不多。

ZooKeeper組件支持節點短暫存在，只要創建znode的會話處於活動狀態，這些znode就會存在，會話結束時，將刪除znode。Dubbo框架正是基於這個特點，服務啓動往Zookeeper註冊的就是臨時節點，需要定時發心跳到Zookeeper來續約節點，並允許服務下線時，將Zookeeper上相應的節點刪除，同時Zookeeper使用ZAB協議雖然保證了數據的強一致性。

5、eureka和zookeeper的區別總結

Eureka可以很好的應對因網絡故障導致部分節點失去聯繫的情況，而不會像zookeeper那樣使整個註冊服務癱瘓。Eureka作爲單純的服務註冊中心來說要比zookeeper更加“專業”，因爲註冊服務更重要的是可用性，我們可以接受短期內達不到一致性的狀況。

6、Consul組件

6.1 基礎描述

Consul是用於服務發現和配置的工具。Consul是分佈式的，高度可用的，並且具有極高的可伸縮性，而且開發使用都很簡便。它提供了一個功能齊全的控制面板，主要特點是：服務發現、健康檢查、鍵值存儲、安全服務通信、多數據中心、ServiceMesh。Consul在設計上把很多分佈式服務治理上要用到的功能都包含在內了。

6.2 組件特點

Consul提供多個數據中心的支持，基於Fabio做負載均衡，每個數據中心內，都有客戶端和服務端的混合構成。預計有三到五臺服務端。可以在失敗和性能的可用性之間取得良好的平衡。數據中心中的所有節點都參與八卦協議。這意味着有一個八卦池，其中包含給定數據中心的所有節點。這有幾個目的：首先，不需要爲客戶端配置服務器的地址;發現是自動完成的。其次，檢測節點故障的工作不是放在服務器上，而是分佈式的。這使得故障檢測比天真的心跳方案更具可擴展性。第三，它被用作消息傳遞層，用於在諸如領導者選舉等重要事件發生時進行通知。

7、Nacos組件

7.1 基礎描述

Nacos致力於發現、配置和管理微服務。Nacos提供了一組簡單易用的特性集，幫助您實現動態服務發現、服務配置管理、服務及流量管理。Nacos更敏捷和容易地構建、交付和管理微服務平臺。 Nacos 是構建以“服務”爲中心的現代應用架構(例如微服務範式、雲原生範式)的服務基礎設施。Nacos支持作爲RPC註冊中心，例如：支持Dubbo框架；也具備微服務註冊中心的能力，例如：SpringCloud框架。

7.2 組件特點

Nacos在經過多年生產經驗後提煉出的數據模型，則是一種服務-集羣-實例的三層模型。如上文所說，這樣基本可以滿足服務在所有場景下的數據存儲和管理,數據模型雖然相對複雜，但是並不強制使用數據結構的風格，大多數應用場景下，和Eureka數據模型是類似的。

Nacos提供數據邏輯隔離模型，用戶賬號可以新建多個命名空間，每個命名空間對應一個客戶端實例，這個命名空間對應的註冊中心物理集羣是可以根據規則進行路由的，這樣可以讓註冊中心內部的升級和遷移對用戶是無感知的。

8、組件選擇