前言

服務注冊中心本質上是為了解耦服務提供者和服務消費者。對于任何一個微服務，原則上都應存在或者支持多個提供者，這是由微服務的分布式屬性決定的。更進一步，為了支持彈性擴縮容特性，一個微服務的提供者的數量和分布往往是動態變化的，也是無法預先確定的。因此，原本在單體應用階段常用的靜態LB機制就不再適用了，需要引入額外的組件來管理微服務提供者的注冊與發現，而這個組件就是服務注冊中心。

CAP理論

CAP理論是分布式架構中重要理論

一致性(Consistency) (所有節點在同一時間具有相同的數據)
可用性(Availability) (保證每個請求不管成功或者失敗都有響應)
分隔容忍(Partition tolerance) (系統中任意信息的丟失或失敗不會影響系統的繼續運作)

關于P的理解，我覺得是在整個系統中某個部分，掛掉了，或者宕機了，并不影響整個系統的運作或者說使用，而可用性是，某個系統的某個節點掛了，但是并不影響系統的接受或者發出請求，CAP 不可能都取，只能取其中2個原因是如果C是第一需求的話，那么會影響A的性能，因為要數據同步，不然請求結果會有差異，但是數據同步會消耗時間，期間可用性就會降低。

如果A是第一需求，那么只要有一個服務在，就能正常接受請求，但是對與返回結果變不能保證，原因是，在分布式部署的時候，數據一致的過程不可能想切線路那么快。

再如果，同事滿足一致性和可用性，那么分區容錯就很難保證了，也就是單點，也是分布式的基本核心，好了，明白這些理論，就可以在相應的場景選取服務注冊與發現了。

服務注冊中心解決方案

設計或者選型一個服務注冊中心，首先要考慮的就是服務注冊與發現機制。縱觀當下各種主流的服務注冊中心解決方案，大致可歸為三類：

應用內：直接集成到應用中，依賴于應用自身完成服務的注冊與發現，最典型的是Netflix提供的Eureka
應用外：把應用當成黑盒，通過應用外的某種機制將服務注冊到注冊中心，最小化對應用的侵入性，比如Airbnb的SmartStack，HashiCorp的Consul
DNS：將服務注冊為DNS的SRV記錄，嚴格來說，是一種特殊的應用外注冊方式，SkyDNS是其中的代表

注1：對于第一類注冊方式，除了Eureka這種一站式解決方案，還可以基于ZooKeeper或者Etcd自行實現一套服務注冊機制，這在大公司比較常見，但對于小公司而言顯然性價比太低。

注2：由于DNS固有的緩存缺陷，本文不對第三類注冊方式作深入探討。

除了基本的服務注冊與發現機制，從開發和運維角度，至少還要考慮如下五個方面：

測活：服務注冊之后，如何對服務進行測活以保證服務的可用性？
負載均衡：當存在多個服務提供者時，如何均衡各個提供者的負載？
集成：在服務提供端或者調用端，如何集成注冊中心？
運行時依賴：引入注冊中心之后，對應用的運行時環境有何影響？
可用性：如何保證注冊中心本身的可用性，特別是消除單點故障？

主流注冊中心產品

軟件產品特性并非一成不變，如果發現功能特性有變更，歡迎評論指正

	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集成	支持	不支持	支持	支持	不支持

Consul是支持自動注銷服務實例，請見文檔： https://www.consul.io/api-docs/agent/service，在check的 DeregisterCriticalServiceAfter 這個參數-- 感謝@超帥的菜鳥博主提供最新信息
新版本的Dubbo也擴展了對 Consul 的支持。參考: https://github.com/apache/dubbo/tree/master/dubbo-registry

Apache Zookeeper -> CP

與 Eureka 有所不同，Apache Zookeeper 在設計時就緊遵CP原則，即任何時候對 Zookeeper 的訪問請求能得到一致的數據結果，同時系統對網絡分割具備容錯性，但是 Zookeeper 不能保證每次服務請求都是可達的。

從 Zookeeper 的實際應用情況來看，在使用 Zookeeper 獲取服務列表時，如果此時的 Zookeeper 集群中的 Leader 宕機了，該集群就要進行 Leader 的選舉，又或者 Zookeeper 集群中半數以上服務器節點不可用（例如有三個節點，如果節點一檢測到節點三掛了，節點二也檢測到節點三掛了，那這個節點才算是真的掛了），那么將無法處理該請求。所以說，Zookeeper 不能保證服務可用性。

當然，在大多數分布式環境中，尤其是涉及到數據存儲的場景，數據一致性應該是首先被保證的，這也是 Zookeeper 設計緊遵CP原則的另一個原因。

但是對于服務發現來說，情況就不太一樣了，針對同一個服務，即使注冊中心的不同節點保存的服務提供者信息不盡相同，也并不會造成災難性的后果。

因為對于服務消費者來說，能消費才是最重要的，消費者雖然拿到可能不正確的服務實例信息后嘗試消費一下，也要勝過因為無法獲取實例信息而不去消費，導致系統異常要好（淘寶的雙十一，京東的618就是緊遵AP的最好參照）。

當master節點因為網絡故障與其他節點失去聯系時，剩余節點會重新進行leader選舉。問題在于，選舉leader的時間太長，30~120s，而且選舉期間整個zk集群都是不可用的，這就導致在選舉期間注冊服務癱瘓。

在云部署環境下，因為網絡問題使得zk集群失去master節點是大概率事件，雖然服務能最終恢復，但是漫長的選舉事件導致注冊長期不可用是不能容忍的。

Spring Cloud Eureka? -> AP

Spring Cloud Netflix 在設計 Eureka 時就緊遵AP原則（盡管現在2.0發布了，但是由于其閉源的原因，但是目前 Ereka 1.x 任然是比較活躍的）。

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 當前所知的其它所有節點中。

?

Consul：

Consul 是 HashiCorp 公司推出的開源工具，用于實現分布式系統的服務發現與配置。Consul 使用 Go 語言編寫，因此具有天然可移植性（支持Linux、windows和Mac OS X）。

Consul 內置了服務注冊與發現框架、分布一致性協議實現、健康檢查、Key/Value 存儲、多數據中心方案，不再需要依賴其他工具（比如 ZooKeeper 等），使用起來也較為簡單。

Consul 遵循CAP原理中的CP原則，保證了強一致性和分區容錯性，且使用的是Raft算法，比zookeeper使用的Paxos算法更加簡單。雖然保證了強一致性，但是可用性就相應下降了，例如服務注冊的時間會稍長一些，因為 Consul 的 raft 協議要求必須過半數的節點都寫入成功才認為注冊成功；在leader掛掉了之后，重新選舉出leader之前會導致Consul 服務不可用。

?Consul本質上屬于應用外的注冊方式，但可以通過SDK簡化注冊流程。而服務發現恰好相反，默認依賴于SDK，但可以通過Consul Template（下文會提到）去除SDK依賴。

Consul Template

Consul，默認服務調用者需要依賴Consul SDK來發現服務，這就無法保證對應用的零侵入性。

所幸通過Consul Template，可以定時從Consul集群獲取最新的服務提供者列表并刷新LB配置（比如nginx的upstream），這樣對于服務調用者而言，只需要配置一個統一的服務調用地址即可。

Consul強一致性(C)帶來的是：

服務注冊相比Eureka會稍慢一些。因為Consul的raft協議要求必須過半數的節點都寫入成功才認為注冊成功
Leader掛掉時，重新選舉期間整個consul不可用。保證了強一致性但犧牲了可用性。

Eureka保證高可用(A)和最終一致性：

服務注冊相對要快，因為不需要等注冊信息replicate到其他節點，也不保證注冊信息是否replicate成功
當數據出現不一致時，雖然A, B上的注冊信息不完全相同，但每個Eureka節點依然能夠正常對外提供服務，這會出現查詢服務信息時如果請求A查不到，但請求B就能查到。如此保證了可用性但犧牲了一致性。

其他方面，eureka就是個servlet程序，跑在servlet容器中; Consul則是go編寫而成。