SpringCloud 常見注冊中心的比較
一、概述
springcloud是一個非常優(yōu)秀的微服務框架，要管理眾多的服務，就需要對這些服務進行治理，也就是我們說的服務治理,服務治理的作用就是在傳統(tǒng)的rpc遠程調(diào)用框架中，管理每個服務與每個服務之間的依賴關(guān)系，可以實現(xiàn)服務調(diào)用、負載均衡、服務容錯、以及服務的注冊與發(fā)現(xiàn)。
如果微服務之間存在調(diào)用依賴，就需要得到目標服務的服務地址，也就是微服務治理的服務發(fā)現(xiàn)。要完成服務發(fā)現(xiàn)，就需要將服務信息存儲到某個載體，載體本身即是微服務治理的服務注冊中心，而存儲到載體的動作即是服務注冊。
springcloud支持的注冊中心有Eureka、Zookeeper、Consul、Nacos
| 組件名稱 | 所屬公司 | 組件簡介 |
|---|---|---|
| Eureka | Netflix | springcloud最早的注冊中心，目前已經(jīng)進入停更進維了 |
| Zookeeper | Apache | zookeeper是一個分布式協(xié)調(diào)工具，可以實現(xiàn)注冊中心功能 |
| Consul | Hashicorp | Consul 簡化了分布式環(huán)境中的服務的注冊和發(fā)現(xiàn)流程，通過 HTTP 或者 DNS 接口發(fā)現(xiàn)。支持外部 SaaS 提供者等。 |
| Nacos | Alibaba | Nacos 致力于幫助您發(fā)現(xiàn)、配置和管理微服務。Nacos 提供了一組簡單易用的特性集，幫助您快速實現(xiàn)動態(tài)服務發(fā)現(xiàn)、服務配置、服務元數(shù)據(jù)及流量管理。 |
1.1 eureka
Spring Cloud Netflix 在設(shè)計 Eureka 時就緊遵AP原則,Eureka Server 也可以運行多個實例來構(gòu)建集群，解決單點問題，但不同于 ZooKeeper 的選舉 leader 的過程，Eureka Server 采用的是Peer to Peer 對等通信。這是一種去中心化的架構(gòu)，無 master/slave 之分，每一個 Peer 都是對等的。在這種架構(gòu)風格中，節(jié)點通過彼此互相注冊來提高可用性，每個節(jié)點需要添加一個或多個有效的 serviceUrl 指向其他節(jié)點。每個節(jié)點都可被視為其他節(jié)點的副本。
在集群環(huán)境中如果某臺 Eureka Server 宕機，Eureka Client 的請求會自動切換到新的 Eureka Server 節(jié)點上，當宕機的服務器重新恢復后，Eureka 會再次將其納入到服務器集群管理之中。當節(jié)點開始接受客戶端請求時，所有的操作都會在節(jié)點間進行復制（replicate To Peer）操作，將請求復制到該 Eureka Server 當前所知的其它所有節(jié)點中。
Eureka的集群中，只要有一臺Eureka還在，就能保證注冊服務可用（保證可用性），只不過查到的信息可能不是最新的（不保證強一致性）。除此之外，Eureka還有一種自我保護機制，如果在15分鐘內(nèi)超過85%的節(jié)點都沒有正常的心跳，那么Eureka就認為客戶端與注冊中心出現(xiàn)了網(wǎng)絡(luò)故障，此時會出現(xiàn)以下幾種情況:
Eureka不再從注冊表中移除因為長時間沒有收到心跳而過期的服務；
Eureka仍然能夠接受新服務注冊和查詢請求，但是不會被同步到其它節(jié)點上（即保證當前節(jié)點依然可用）；
當網(wǎng)絡(luò)穩(wěn)定時，當前實例新注冊的信息會被同步到其它節(jié)點中；
因此，Eureka可以很好的應對因網(wǎng)絡(luò)故障導致部分節(jié)點失去聯(lián)系的情況，而不會像zookeeper那樣使得整個注冊服務癱瘓
Eureka保證高可用(A)和最終一致性：
服務注冊相對要快，因為不需要等注冊信息replicate到其他節(jié)點，也不保證注冊信息是否replicate成功
當數(shù)據(jù)出現(xiàn)不一致時，雖然A, B上的注冊信息不完全相同，但每個Eureka節(jié)點依然能夠正常對外提供服務，這會出現(xiàn)查詢服務信息時如果請求A查不到，但請求B就能查到。如此保證了可用性但犧牲了一致性。
1.2 zookeeper
與 Eureka 有所不同，Apache Zookeeper 在設(shè)計時就緊遵CP原則，即任何時候?qū)?Zookeeper 的訪問請求能得到一致的數(shù)據(jù)結(jié)果，同時系統(tǒng)對網(wǎng)絡(luò)分割具備容錯性，但是 Zookeeper 不能保證每次服務請求都是可達的。從 Zookeeper 的實際應用情況來看，在使用 Zookeeper 獲取服務列表時，如果此時的 Zookeeper 集群中的 Leader 宕機了，該集群就要進行 Leader 的選舉，又或者 Zookeeper 集群中半數(shù)以上服務器節(jié)點不可用（例如有三個節(jié)點，如果節(jié)點一檢測到節(jié)點三掛了 ，節(jié)點二也檢測到節(jié)點三掛了，那這個節(jié)點才算是真的掛了），那么將無法處理該請求。所以說，Zookeeper 不能保證服務可用性。
1.3 consul
Consul 是 HashiCorp 公司推出的開源工具，用于實現(xiàn)分布式系統(tǒng)的服務發(fā)現(xiàn)與配置。Consul 使用 Go 語言編寫，因此具有天然可移植性（支持Linux、windows和Mac OS X）。Consul 內(nèi)置了服務注冊與發(fā)現(xiàn)框架、分布一致性協(xié)議實現(xiàn)、健康檢查、Key/Value 存儲、多數(shù)據(jù)中心方案，不再需要依賴其他工具（比如 ZooKeeper 等），使用起來也較為簡單。
Consul 遵循CAP原理中的CP原則，保證了強一致性和分區(qū)容錯性，且使用的是Raft算法，比zookeeper使用的Paxos算法更加簡單。雖然保證了強一致性，但是可用性就相應下降了，例如服務注冊的時間會稍長一些，因為 Consul 的 raft 協(xié)議要求必須過半數(shù)的節(jié)點都寫入成功才認為注冊成功 ；在leader掛掉了之后，重新選舉出leader之前會導致Consul 服務不可用。
Consul強一致性(C)帶來的是：
服務注冊相比Eureka會稍慢一些。因為Consul的raft協(xié)議要求必須過半數(shù)的節(jié)點都寫入成功才認為注冊成功
Leader掛掉時，重新選舉期間整個consul不可用。保證了強一致性但犧牲了可用性。
1.4 Nacos
Nacos是阿里開源的，Nacos 支持基于 DNS 和基于 RPC 的服務發(fā)現(xiàn)。Nacos除了服務的注冊發(fā)現(xiàn)之外，還支持動態(tài)配置服務。動態(tài)配置服務可以讓您以中心化、外部化和動態(tài)化的方式管理所有環(huán)境的應用配置和服務配置。動態(tài)配置消除了配置變更時重新部署應用和服務的需要，讓配置管理變得更加高效和敏捷。配置中心化管理讓實現(xiàn)無狀態(tài)服務變得更簡單，讓服務按需彈性擴展變得更容易。一句話概括就是Nacos = 注冊中心 + 配置中心。
二、功能異同
這四個組件雖然都實現(xiàn)了注冊中心的功能，但是他們的功能和實現(xiàn)方式都有不同的地方，也各有各的優(yōu)點,單從注冊中心方面來比價四個注冊中心(如果不了解CAP定理可先閱讀下一章節(jié)):
2.1 基本實現(xiàn)不同
官網(wǎng)地址
eureka: https://github.com/Netflix/eureka
zookeeper: https://zookeeper.apache.org/
consul: https://www.consul.io/
nacos: https://nacos.io/zh-cn/| 組件名稱 | 實現(xiàn)語言 | 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 | |
|---|---|---|---|---|---|
| 一致性協(xié)議 | CP+AP | AP | CP | — | CP |
| 健康檢查 | TCP/HTTP/MYSQL/Client Beat | Client Beat | TCP/HTTP/gRPC/Cmd | — | Keep Alive |
| 負載均衡策略 | 權(quán)重/metadata/Selector | Ribbon | Fabio | RoundRobin | — |
| 雪崩保護 | 有 | 有 | 無 | 無 | 無 |
| 自動注銷實例 | 支持 | 支持 | 不支持 | 不支持 | 支持 |
| 訪問協(xié)議 | HTTP/DNS | HTTP | HTTP/DNS | DNS | TCP |
| 監(jiān)聽支持 | 支持 | 支持 | 支持 | 不支持 | 支持 |
| 多數(shù)據(jù)中心 | 支持 | 支持 | 支持 | 不支持 | 不支持 |
| 跨注冊中心同步 | 支持 | 不支持 | 支持 | 不支持 | 不支持 |
| SpringCloud集成 | 支持 | 支持 | 支持 | 不支持 | 不支持 |
| Dubbo集成 | 支持 | 不支持 | 不支持 | 不支持 | 支持 |
| K8S集成 | 支持 | 不支持 | 支持 | 支持 | 不支持 |
三、CAP定理
cap定理
CAP原則又稱CAP定理，指的是在一個分布式系統(tǒng)中，一致性（Consistency）、可用性（Availability）、分區(qū)容錯性（Partition tolerance）。CAP 原則指的是，這三個要素最多只能同時實現(xiàn)兩點，不可能三者兼顧。參考 阮一峰博客。
Consistency 一致性:所有數(shù)據(jù)備份，在同一時刻是否同樣的值。（等同于所有節(jié)點訪問同一份最新的數(shù)據(jù)副本）Availability 可用性:在集群中一部分節(jié)點故障后，集群整體是否還能響應客戶端的讀寫請求。（對數(shù)據(jù)更新具備高可用性）Partition Tolerance 容錯性:以實際效果而言，分區(qū)相當于對通信的時限要求。系統(tǒng)如果不能在時限內(nèi)達成數(shù)據(jù)一致性，就意味著發(fā)生了分區(qū)的情況，必須就當前操作在C和A之間做出選擇。
CAP原則的精髓就是要么AP，要么CP，要么AC，但是不存在CAP。如果在某個分布式系統(tǒng)中數(shù)據(jù)無副本， 那么系統(tǒng)必然滿足強一致性條件， 因為只有獨一數(shù)據(jù)，不會出現(xiàn)數(shù)據(jù)不一致的情況，此時C和P兩要素具備，但是如果系統(tǒng)發(fā)生了網(wǎng)絡(luò)分區(qū)狀況或者宕機，必然導致某些數(shù)據(jù)不可以訪問，此時可用性條件就不能被滿足，即在此情況下獲得了CP系統(tǒng)，但是CAP不可同時滿足。
因此在進行分布式架構(gòu)設(shè)計時，必須做出取舍。當前一般是通過分布式緩存中各節(jié)點的最終一致性來提高系統(tǒng)的性能，通過使用多節(jié)點之間的數(shù)據(jù)異步復制技術(shù)來實現(xiàn)集群化的數(shù)據(jù)一致性。通常使用類似 memcached 之類的 NOSQL 作為實現(xiàn)手段。雖然 memcached 也可以是分布式集群環(huán)境的，但是對于一份數(shù)據(jù)來說，它總是存儲在某一臺 memcached 服務器上。如果發(fā)生網(wǎng)絡(luò)故障或是服務器死機，則存儲在這臺服務器上的所有數(shù)據(jù)都將不可訪問。由于數(shù)據(jù)是存儲在內(nèi)存中的，重啟服務器，將導致數(shù)據(jù)全部丟失。當然也可以自己實現(xiàn)一套機制，用來在分布式 memcached 之間進行數(shù)據(jù)的同步和持久化，但是實現(xiàn)難度是非常大的
CAP定理關(guān)注的粒度是數(shù)據(jù)，而不是整體的架構(gòu)。
例如，根據(jù)CAP定理將NoSql數(shù)據(jù)分成了滿足CA原則、滿足CP原則和滿足AP原則的三大類:
CA-單點集群，滿足一致性可用性的系統(tǒng)，擴展能力不強CP-滿足一致性和容錯性系統(tǒng)，性能不高AP-滿足可用性、容錯性的系統(tǒng)，對一致性要求低一些。
喜歡，在看