一、概述springcloud是一個非常優秀的微服務框架，要管理眾多的服務，就需要對這些服務進行治理，也就是我們說的服務治理,服務治理的作用就是在傳統的rpc遠程調用框架中，管理每個服務與每個服務之間的依賴關係，可以實現服務調用、負載均衡、服務容錯、以及服務的註冊與發現。如果微服務之間存在調用依賴，就需要得到目標服務的服務地址，也就是微服務治理的服務發現。要完成服務發現，就需要將服務信息存儲到某個載體，載體本身即是微服務治理的服務註冊中心，而存儲到載體的動作即是服務註冊。springcloud支持的註冊中心有Eureka、Zookeeper、Consul、Nacos組件名稱所屬公司組件簡介EurekaNetflixspringcloud最早的註冊中心，目前已經進入停更進維了ZookeeperApachezookeeper是一個分布式協調工具，可以實現註冊中心功能ConsulHashicorpConsul 簡化了分布式環境中的服務的註冊和發現流程，通過 HTTP 或者 DNS 接口發現。支持外部 SaaS 提供者等。NacosAlibabaNacos 致力於幫助您發現、配置和管理微服務。Nacos 提供了一組簡單易用的特性集，幫助您快速實現動態服務發現、服務配置、服務元數據及流量管理。1.1 eurekaSpring Cloud Netflix 在設計 Eureka 時就緊遵AP原則,Eureka Server 也可以運行多個實例來構建集群，解決單點問題，但不同於 ZooKeeper 的選舉 leader 的過程，Eureka Server 採用的是Peer to Peer 對等通信。這是一種去中心化的架構，無 master/slave 之分，每一個 Peer 都是對等的。在這種架構風格中，節點通過彼此互相註冊來提高可用性，每個節點需要添加一個或多個有效的 serviceUrl 指向其他節點。每個節點都可被視為其他節點的副本。在集群環境中如果某台 Eureka Server 宕機，Eureka Client 的請求會自動切換到新的 Eureka Server 節點上，當宕機的服務器重新恢復後，Eureka 會再次將其納入到服務器集群管理之中。當節點開始接受客戶端請求時，所有的操作都會在節點間進行複製（replicate To Peer）操作，將請求複製到該 Eureka Server 當前所知的其它所有節點中。Eureka的集群中，只要有一台Eureka還在，就能保證註冊服務可用（保證可用性），只不過查到的信息可能不是最新的（不保證強一致性）。除此之外，Eureka還有一種自我保護機制，如果在15分鐘內超過85%的節點都沒有正常的心跳，那麼Eureka就認為客戶端與註冊中心出現了網絡故障，此時會出現以下幾種情況:Eureka不再從註冊表中移除因為長時間沒有收到心跳而過期的服務；Eureka仍然能夠接受新服務註冊和查詢請求，但是不會被同步到其它節點上（即保證當前節點依然可用）；當網絡穩定時，當前實例新註冊的信息會被同步到其它節點中；因此，Eureka可以很好的應對因網絡故障導致部分節點失去聯繫的情況，而不會像zookeeper那樣使得整個註冊服務癱瘓。關於微服務面試資料，公眾號Java精選，回復java面試，獲取資料。
Eureka保證高可用(A)和最終一致性：
服務註冊相對要快，因為不需要等註冊信息replicate到其他節點，也不保證註冊信息是否replicate成功
當數據出現不一致時，雖然A, B上的註冊信息不完全相同，但每個Eureka節點依然能夠正常對外提供服務，這會出現查詢服務信息時如果請求A查不到，但請求B就能查到。如此保證了可用性但犧牲了一致性。
1.2 zookeeper與 Eureka 有所不同，Apache Zookeeper 在設計時就緊遵CP原則，即任何時候對 Zookeeper 的訪問請求能得到一致的數據結果，同時系統對網絡分割具備容錯性，但是 Zookeeper 不能保證每次服務請求都是可達的。從 Zookeeper 的實際應用情況來看，在使用 Zookeeper 獲取服務列表時，如果此時的 Zookeeper 集群中的 Leader 宕機了，該集群就要進行 Leader 的選舉，又或者 Zookeeper 集群中半數以上服務器節點不可用（例如有三個節點，如果節點一檢測到節點三掛了 ，節點二也檢測到節點三掛了，那這個節點才算是真的掛了），那麼將無法處理該請求。所以說，Zookeeper 不能保證服務可用性。1.3 consulConsul 是 HashiCorp 公司推出的開源工具，用於實現分布式系統的服務發現與配置。Consul 使用 Go 語言編寫，因此具有天然可移植性（支持Linux、windows和Mac OS X）。Consul 內置了服務註冊與發現框架、分布一致性協議實現、健康檢查、Key/Value 存儲、多數據中心方案，不再需要依賴其他工具（比如 ZooKeeper 等），使用起來也較為簡單。Consul 遵循CAP原理中的CP原則，保證了強一致性和分區容錯性，且使用的是Raft算法，比zookeeper使用的Paxos算法更加簡單。雖然保證了強一致性，但是可用性就相應下降了，例如服務註冊的時間會稍長一些，因為 Consul 的 raft 協議要求必須過半數的節點都寫入成功才認為註冊成功 ；在leader掛掉了之後，重新選舉出leader之前會導致Consul 服務不可用。
Consul強一致性(C)帶來的是：
服務註冊相比Eureka會稍慢一些。因為Consul的raft協議要求必須過半數的節點都寫入成功才認為註冊成功
Leader掛掉時，重新選舉期間整個consul不可用。保證了強一致性但犧牲了可用性。
1.4 NacosNacos是阿里開源的，Nacos 支持基於 DNS 和基於 RPC 的服務發現。Nacos除了服務的註冊發現之外，還支持動態配置服務。動態配置服務可以讓您以中心化、外部化和動態化的方式管理所有環境的應用配置和服務配置。動態配置消除了配置變更時重新部署應用和服務的需要，讓配置管理變得更加高效和敏捷。配置中心化管理讓實現無狀態服務變得更簡單，讓服務按需彈性擴展變得更容易。一句話概括就是Nacos = 註冊中心 + 配置中心。二、功能異同這四個組件雖然都實現了註冊中心的功能，但是他們的功能和實現方式都有不同的地方，也各有各的優點,單從註冊中心方面來比價四個註冊中心(如果不了解CAP定理可先閱讀下一章節):2.1 基本實現不同eureka:https://github.com/Netflix/eurekazookeeper:https://zookeeper.apache.org/consul:https://www.consul.io/nacos:https://nacos.io/zh-cn/組件名稱實現語言CAP健康檢查EurekaJavaAP可配ZookeeperJavaCP支持ConsulGolangCP支持NacosJavaAP支持
eureka就是個servlet程序，跑在servlet容器中; Consul則是go編寫而成。
2.2 功能支持度不同NacosEurekaConsulCoreDNSZookeeper一致性協議CP+APAPCP—CP健康檢查TCP/HTTP/MYSQL/Client BeatClient BeatTCP/HTTP/gRPC/Cmd—Keep Alive負載均衡策略權重/metadata/SelectorRibbonFabioRoundRobin—雪崩保護有有無無無自動註銷實例支持支持不支持不支持支持訪問協議HTTP/DNSHTTPHTTP/DNSDNSTCP監聽支持支持支持支持不支持支持多數據中心支持支持支持不支持不支持跨註冊中心同步支持不支持支持不支持不支持SpringCloud集成支持支持支持不支持不支持Dubbo集成支持不支持不支持不支持支持K8S集成支持不支持支持支持不支持
三、CAP定理
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定理將NoSql數據分成了滿足CA原則、滿足CP原則和滿足AP原則的三大類:CA-單點集群，滿足一致性可用性的系統，擴展能力不強AP-滿足可用性、容錯性的系統，對一致性要求低一些。公眾號「Java精選」所發表內容註明來源的，版權歸原出處所有（無法查證版權的或者未註明出處的均來自網絡，系轉載，轉載的目的在於傳遞更多信息，版權屬於原作者。如有侵權，請聯繫，筆者會第一時間刪除處理！最近有很多人問，有沒有讀者交流群！加入方式很簡單，公眾號Java精選，回復「加群」，即可入群！
Java精選面試題（微信小程序）：3000+道面試題，包含Java基礎、並發、JVM、線程、MQ系列、Redis、Spring系列、Elasticsearch、Docker、K8s、Flink、Spark、架構設計等，在線隨時刷題！
特別推薦：專注分享最前沿的技術與資訊，為彎道超車做好準備及各種開源項目與高效率軟件的公眾號，「大咖筆記」，專注挖掘好東西，非常值得大家關注。點擊下方公眾號卡片關注。
留言列表