springcloud四個註冊中心的比較

一、概述

springcloud是一個非常優秀的微服務框架，要管理眾多的服務，就需要對這些服務進行治理，也就是我們說的服務治理,服務治理的作用就是在傳統的rpc遠端呼叫框架中，管理每個服務與每個服務之間的依賴關係，可以實現服務呼叫、負載均衡、服務容錯、以及服務的註冊與發現。
​ 如果微服務之間存在呼叫依賴，就需要得到目標服務的服務地址，也就是微服務治理的服務發現。要完成服務發現，就需要將服務資訊儲存到某個載體，載體本身即是微服務治理的服務註冊中心，而儲存到載體的動作即是服務註冊。
​ springcloud支援的註冊中心有Eureka、Zookeeper

二、功能異同

這四個元件雖然都實現了註冊中心的功能，但是他們的功能和實現方式都有不同的地方，也各有各的優點,單從註冊中心方面來比價四個註冊中心(如果不瞭解CAP定理可先閱讀下一章節):

2.1 基本實現不同

eureka就是個servlet程式，跑在servlet容器中; Consul則是go編寫而成。

2.2 功能支援度不同

三、CAP定理

CAP原則又稱CAP定理，指的是在一個分散式系統中，一致性（Consistency）、可用性（Availability）、分割槽容錯性（Partition tolerance）。CAP 原則指的是，這三個要素最多隻能同時實現兩點，不可能三者兼顧。參考 阮一峰部落格。

• Consistency 一致性:所有資料備份，在同一時刻是否同樣的值。（等同於所有節點訪問同一份最新的資料副本）
• Availability 可用性:在叢集中一部分節點故障後，叢集整體是否還能響應客戶端的讀寫請求。（對資料更新具備高可用性）
• Partition Tolerance 容錯性:以實際效果而言，分割槽相當於對通訊的時限要求。系統如果不能在時限內達成資料一致性，就意味著發生了分割槽的情況，必須就當前操作在C和A之間做出選擇。

CAP原則的精髓就是要麼AP，要麼CP，要麼AC，但是不存在CAP。如果在某個分散式系統中資料無副本， 那麼系統必然滿足強一致性條件， 因為只有獨一資料，不會出現資料不一致的情況，此時C和P兩要素具備，但是如果系統發生了網路分割槽狀況或者宕機，必然導致某些資料不可以訪問，此時可用性條件就不能被滿足，即在此情況下獲得了CP系統，但是CAP不可同時滿足。

因此在進行分散式架構設計時，必須做出取捨。當前一般是通過分散式快取中各節點的最終一致性來提高系統的效能，通過使用多節點之間的資料非同步複製技術來實現叢集化的資料一致性。通常使用類似 memcached 之類的 NOSQL 作為實現手段。雖然 memcached 也可以是分散式叢集環境的，但是對於一份資料來說，它總是儲存在某一臺 memcached 伺服器上。如果發生網路故障或是伺服器宕機，則儲存在這臺伺服器上的所有資料都將不可訪問。由於資料是儲存在記憶體中的，重啟伺服器，將導致資料全部丟失。當然也可以自己實現一套機制，用來在分散式 memcached 之間進行資料的同步和持久化，但是實現難度是非常大的

CAP定理關注的粒度是資料，而不是整體的架構。

例如，根據CAP定理將NoSql資料分成了滿足CA原則、滿足CP原則和滿足AP原則的三大類:

• CA-單點叢集，滿足一致性可用性的系統，擴充套件能力不強
• CP-滿足一致性和容錯性系統，效能不高
• AP-滿足可用性、容錯性的系統，對一致性要求低一些。

四、參考文件

• 註冊中心ZooKeeper、Eureka、Consul 、Nacos對比 https://blog.csdn.net/fly910905/article/details/100023415

• 阮一峰 cap定理 http://www.ruanyifeng.com/blog/2018/07/cap.html

一、概述

springcloud是一個非常優秀的微服務框架，要管理眾多的服務，就需要對這些服務進行治理，也就是我們說的服務治理,服務治理的作用就是在傳統的rpc遠端呼叫框架中，管理每個服務與每個服務之間的依賴關係，可以實現服務呼叫、負載均衡、服務容錯、以及服務的註冊與發現。
​ 如果微服務之間存在呼叫依賴，就需要得到目標服務的服務地址，也就是微服務治理的服務發現。要完成服務發現，就需要將服務資訊儲存到某個載體，載體本身即是微服務治理的服務註冊中心，而儲存到載體的動作即是服務註冊。
​ springcloud支援的註冊中心有Eureka、Zookeeper、Consul、Nacos

二、功能異同

這四個元件雖然都實現了註冊中心的功能，但是他們的功能和實現方式都有不同的地方，也各有各的優點,單從註冊中心方面來比價四個註冊中心(如果不瞭解CAP定理可先閱讀下一章節):

2.1 基本實現不同

eureka就是個servlet程式，跑在servlet容器中; Consul則是go編寫而成。

2.2 功能支援度不同

三、CAP定理

CAP原則又稱CAP定理，指的是在一個分散式系統中，一致性（Consistency）、可用性（Availability）、分割槽容錯性（Partition tolerance）。CAP 原則指的是，這三個要素最多隻能同時實現兩點，不可能三者兼顧。參考 阮一峰部落格。

• Consistency 一致性:所有資料備份，在同一時刻是否同樣的值。（等同於所有節點訪問同一份最新的資料副本）
• Availability 可用性:在叢集中一部分節點故障後，叢集整體是否還能響應客戶端的讀寫請求。（對資料更新具備高可用性）
• Partition Tolerance 容錯性:以實際效果而言，分割槽相當於對通訊的時限要求。系統如果不能在時限內達成資料一致性，就意味著發生了分割槽的情況，必須就當前操作在C和A之間做出選擇。

CAP原則的精髓就是要麼AP，要麼CP，要麼AC，但是不存在CAP。如果在某個分散式系統中資料無副本， 那麼系統必然滿足強一致性條件， 因為只有獨一資料，不會出現資料不一致的情況，此時C和P兩要素具備，但是如果系統發生了網路分割槽狀況或者宕機，必然導致某些資料不可以訪問，此時可用性條件就不能被滿足，即在此情況下獲得了CP系統，但是CAP不可同時滿足。

因此在進行分散式架構設計時，必須做出取捨。當前一般是通過分散式快取中各節點的最終一致性來提高系統的效能，通過使用多節點之間的資料非同步複製技術來實現叢集化的資料一致性。通常使用類似 memcached 之類的 NOSQL 作為實現手段。雖然 memcached 也可以是分散式叢集環境的，但是對於一份資料來說，它總是儲存在某一臺 memcached 伺服器上。如果發生網路故障或是伺服器宕機，則儲存在這臺伺服器上的所有資料都將不可訪問。由於資料是儲存在記憶體中的，重啟伺服器，將導致資料全部丟失。當然也可以自己實現一套機制，用來在分散式 memcached 之間進行資料的同步和持久化，但是實現難度是非常大的

CAP定理關注的粒度是資料，而不是整體的架構。

例如，根據CAP定理將NoSql資料分成了滿足CA原則、滿足CP原則和滿足AP原則的三大類:

• CA-單點叢集，滿足一致性可用性的系統，擴充套件能力不強
• CP-滿足一致性和容錯性系統，效能不高
• AP-滿足可用性、容錯性的系統，對一致性要求低一些。

四、參考文件

• 註冊中心ZooKeeper、Eureka、Consul 、Nacos對比 https://blog.csdn.net/fly910905/article/details/100023415

• 阮一峰 cap定理 http://www.ruanyifeng.com/blog/2018/07/cap.html