SpringCloud服務註冊中心比較:Consul vs Zookeeper vs Etcd vs Eureka

原文連接地址：http://luyiisme.github.io/2017/04/22/spring-cloud-service-discovery-products/

這裏就平時常常用到的服務發現的產品進行下特性的對比，首先看下結論:

Feature	Consul	zookeeper	etcd	euerka
服務健康檢查	服務狀態，內存，硬盤等	(弱)長鏈接，keepalive	鏈接心跳	可配支持
多數據中心	支持	—	—	—
kv存儲服務	支持	支持	支持	—
一致性	raft	paxos	raft	—
cap	ca	cp	cp	ap
使用接口(多語言能力)	支持http和dns	客戶端	http/grpc	http（sidecar）
watch支持	全量/支持long polling	支持	支持 long polling	支持 long polling/大部分增量
自身監控	metrics	—	metrics	metrics
安全	acl /https	acl	https支持（弱）	—
spring cloud集成	已支持	已支持	已支持	已支持

• 服務的健康檢查

Euraka 使用時須要顯式配置健康檢查支持；Zookeeper,Etcd 則在失去了和服務進程的鏈接狀況下任務不健康，而 Consul 相對更爲詳細點，好比內存是否已使用了90%，文件系統的空間是否是快不足了。

• 多數據中心支持

Consul 經過 WAN 的 Gossip 協議，完成跨數據中心的同步；並且其餘的產品則須要額外的開發工做來實現；

• KV 存儲服務

除了 Eureka ,其餘幾款都可以對外支持 k-v 的存儲服務，因此後面會講到這幾款產品追求高一致性的重要緣由。而提供存儲服務，也可以較好的轉化爲動態配置服務哦。

• 產品設計中 CAP 理論的取捨

Eureka 典型的 AP,做爲分佈式場景下的服務發現的產品較爲合適，服務發現場景的可用性優先級較高，一致性並非特別緻命。其次 CA 類型的場景 Consul,也能提供較高的可用性，並能 k-v store 服務保證一致性。 而Zookeeper,Etcd則是CP類型 犧牲可用性，在服務發現場景並沒太大優點；

• 多語言能力與對外提供服務的接入協議

Zookeeper的跨語言支持較弱，其餘幾款支持 http11 提供接入的可能。Euraka 通常經過 sidecar的方式提供多語言客戶端的接入支持。Etcd 還提供了Grpc的支持。 Consul除了標準的Rest服務api,還提供了DNS的支持。

• Watch的支持（客戶端觀察到服務提供者變化）

Zookeeper 支持服務器端推送變化，Eureka 2.0(正在開發中)也計劃支持。 Eureka 1,Consul,Etcd則都經過長輪詢的方式來實現變化的感知；

• 自身集羣的監控

除了 Zookeeper ,其餘幾款都默認支持 metrics，運維者能夠蒐集並報警這些度量信息達到監控目的；

• 安全

Consul,Zookeeper 支持ACL，另外 Consul,Etcd 支持安全通道https.

• Spring Cloud的集成

目前都有相對應的 boot starter，提供了集成能力。

總的來看，目前Consul 自身功能，和 spring cloud 對其集成的支持都相對較爲完善，並且運維的複雜度較爲簡單（沒有詳細列出討論），Eureka 設計上比較符合場景，但還需持續的完善。

 

名詞解釋：http://www.jdon.com/37625

補充：http://blog.csdn.NET/chen77716/article/details/30635543

 

分佈式領域CAP理論，
Consistency(一致性), 數據一致更新，全部數據變更都是同步的
Availability(可用性), 好的響應性能
Partition tolerance(分區容錯性) 可靠性

定理：任何分佈式系統只可同時知足二點，無法三者兼顧。
忠告：架構師不要將精力浪費在如何設計能知足三者的完美分佈式系統，而是應該進行取捨。

關係數據庫的ACID模型擁有 高一致性 + 可用性 很難進行分區：
Atomicity原子性：一個事務中全部操做都必須所有完成，要麼所有不完成。
Consistency一致性. 在事務開始或結束時，數據庫應該在一致狀態。
Isolation隔離層. 事務將假定只有它本身在操做數據庫，彼此不知曉。
Durability. 一旦事務完成，就不能返回。
跨數據庫事務：2PC (two-phase commit)， 2PC is the anti-scalability pattern (Pat Helland) 是反可伸縮模式的，JavaEE中的JTA事務能夠支持2PC。由於2PC是反模式，儘可能不要使用2PC，使用BASE來回避。

BASE模型反ACID模型，徹底不一樣ACID模型，犧牲高一致性，得到可用性或可靠性：
Basically Available基本可用。支持分區失敗(e.g. sharding碎片劃分數據庫)
Soft state軟狀態 狀態能夠有一段時間不一樣步，異步。
Eventually consistent最終一致，最終數據是一致的就能夠了，而不是時時高一致。

BASE思想的主要實現有
1.按功能劃分數據庫
2.sharding碎片 

BASE思想主要強調基本的可用性，若是你須要High 可用性，也就是純粹的高性能，那麼就要以一致性或容錯性爲犧牲，BASE思想的方案在性能上仍是有潛力可挖的。

如今NOSQL運動豐富了拓展了BASE思想，可按照具體狀況定製特別方案，好比忽視一致性，得到高可用性等等，NOSQL應該有下面兩個流派：
1. Key-Value存儲，如Amaze Dynamo等，可根據CAP三原則靈活選擇不一樣傾向的數據庫產品。
2. 領域模型 + 分佈式緩存 + 存儲 （Qi4j和NoSql運動），可根據CAP三原則結合本身項目定製靈活的分佈式方案，難度高。 這二者共同點：都是關係數據庫SQL之外的可選方案，邏輯隨着數據分佈，任何模型均可以本身持久化，將數據處理和數據存儲分離，將讀和寫分離，存儲能夠是異步或同步，取決於對一致性的要求程度。 不一樣點：NOSQL之類的Key-Value存儲產品是和關係數據庫頭碰頭的產品BOX，能夠適合非Java如PHP RUBY等領域，是一種能夠拿來就用的產品，而領域模型 + 分佈式緩存 + 存儲是一種複雜的架構解決方案，不是產品，但這種方式更靈活，更應該是架構師必須掌握的。