一、概述
springcloud是一個非常優秀的微服務框架，要管理眾多的服務，就需要對這些服務進行治理，也就是我們說的服務治理,服務治理的作用就是在傳統的rpc遠程調用框架中，管理每個服務與每個服務之間的依賴關系，可以實現服務調用、負載均衡、服務容錯、以及服務的注冊與發現。
如果微服務之間存在調用依賴，就需要得到目標服務的服務地址，也就是微服務治理的服務發現。要完成服務發現，就需要將服務信息存儲到某個載體，載體本身即是微服務治理的服務注冊中心，而存儲到載體的動作即是服務注冊。
springcloud支持的注冊中心有Eureka、Zookeeper、Consul、Nacos
| 組件名稱 | 所屬公司 | 組件簡介 |
|---|---|---|
| Eureka | Netflix | springcloud最早的注冊中心，目前已經進入停更進維了 |
| Zookeeper | Apache | zookeeper是一個分布式協調工具，可以實現注冊中心功能 |
| Consul | Hashicorp | Consul 簡化了分布式環境中的服務的注冊和發現流程，通過 HTTP 或者 DNS 接口發現。支持外部 SaaS 提供者等。 |
| Nacos | Alibaba | Nacos 致力於幫助您發現、配置和管理微服務。Nacos 提供了一組簡單易用的特性集，幫助您快速實現動態服務發現、服務配置、服務元數據及流量管理。 |
二、功能異同
這四個組件雖然都實現了注冊中心的功能，但是他們的功能和實現方式都有不同的地方，也各有各的優點,單從注冊中心方面來比價四個注冊中心(如果不了解CAP定理可先閱讀下一章節):
2.1 基本實現不同
| 組件名稱 | 實現語言 | CAP | 健康檢查 |
|---|---|---|---|
| Eureka | Java |
AP | 可配 |
| Zookeeper | Java |
CP | 支持 |
| Consul | Golang |
CP | 支持 |
| Nacos | Java |
AP | 支持 |
eureka就是個servlet程序，跑在servlet容器中; Consul則是go編寫而成。
2.2 功能支持度不同
| Nacos | Eureka | Consul | CoreDNS | Zookeeper | |
|---|---|---|---|---|---|
| 一致性協議 | CP+AP | AP | CP | — | CP |
| 健康檢查 | TCP/HTTP/MYSQL/Client Beat | Client Beat | TCP/HTTP/gRPC/Cmd | — | Keep Alive |
| 負載均衡策略 | 權重/metadata/Selector | Ribbon | Fabio | RoundRobin | — |
| 雪崩保護 | 有 | 有 | 無 | 無 | 無 |
| 自動注銷實例 | 支持 | 支持 | 不支持 | 不支持 | 支持 |
| 訪問協議 | HTTP/DNS | HTTP | HTTP/DNS | DNS | TCP |
| 監聽支持 | 支持 | 支持 | 支持 | 不支持 | 支持 |
| 多數據中心 | 支持 | 支持 | 支持 | 不支持 | 不支持 |
| 跨注冊中心同步 | 支持 | 不支持 | 支持 | 不支持 | 不支持 |
| SpringCloud集成 | 支持 | 支持 | 支持 | 不支持 | 不支持 |
| Dubbo集成 | 支持 | 不支持 | 不支持 | 不支持 | 支持 |
| K8S集成 | 支持 | 不支持 | 支持 | 支持 | 不支持 |
三、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
作者：Martain
鏈接：https://www.jianshu.com/p/9b8a746e0d90
來源：簡書