服務註冊發現技術對比

技術對照表

	Zookeeper	Etcd	Consul	Eureka
CAP模型	CP	CP	CP	AP
數據一致性算法	ZAB	Raft	Raft	❌
多數據中心	❌	❌	✅	❌
多語言支持	客戶端	Http/gRPC	Http/DNS	Http
Watch	TCP	Long Polling	Long Polling	Long Polling
KV存儲	✅	✅	✅	❌
服務健康檢查	心跳	心跳	服務狀態，<br/>內存，硬盤等	自定義
自身監控	❌	metrics	metrics	metrics
SpringCloud 支持	✅	✅	✅	✅
自身開發語言	Java	Go	Go	Java

CAP模型

CAP 這3個字母表明：

• Consistence（一致性）
• Availability（可用性）
• Partition Tolerance（分區容錯性）

在一個分佈式系統中，這3者不可兼得。

因爲網絡的緣由，分佈式系統中 P 是必備的，意味着只能選擇 AP 或者 CP。

CP 表明數據一致性是第一位的，AP 表明可用性是第一位的。

他們4個只有 Eureka 是 AP 的，Eureka 在數據不一致的狀況下也可使用，只要數據最終一致便可。

若是想更多的瞭解 CAP 能夠參見：

架構設計中的 CAP 和 BASE 理論

數據一致性

ZAB 是 zookeeper 的原子廣播協議，基於 Paxos 算法改的。

Raft 是工程上使用較爲普遍的強一致性、去中心化、高可用的分佈式協議。

這兩個算法都沒毛病，均可以實現分佈式一致性，只是實現方式不一樣。

Eureka 選擇的是 AP，不要求強一致性，天然沒有使用數據一致性算法。

Paxos 和 Raft 參考資料：

分佈式一致性算法 Paxos

分佈式一致性算法 Raft

多數據中心

就是多機房，只有 Consul 支持。

zookeeper 不支持多數據中心是指，若是你跨多個機房部署了一套 zookeeper，一旦出現網絡劃分，那麼就不可用了。

Consul 是經過 Gossip 協議實現的。

Gossip 協議中的消息會以一傳10、十傳百的指數級速度在網絡中快速傳播。

網絡中任何節點的異常都不會影響 Gossip 消息傳播，分佈式系統容錯性極強。

Gossip 協議是去中心化的，全部節點對等，節點無需知道整個網絡情況，只要網絡是連通的，任意一個節點就能夠把消息散播到全網。

Watch

Zookeeper 的 watch 實現比較簡單，就是 TCP Ping。

Long Polling（長輪詢）是拉模式，客戶端每隔一段時間請求拉取一次數據。

客戶端發起 Long Polling，若是服務端沒有數據，會等待，直到服務端有數據，或者等待到超時，返回後，客戶端會再次發起 Long Polling。

多語言支持

Zookeeper 多語言客戶端比較成熟。

Consul 支持 DNS 比較有意思，若是你第一次看到可能不太理解。

DNS 方式容許應用程序使用服務發現，而無需與Consul進行任何高度集成。

例如，不須要向 Consul 發送 HTTP 請求，可使用 DNS 服務器直接經過名字查找，如 redis.service.us-east-1.consul，就會自動轉查找位於 us-east-1 這個數據中心提供 redis 服務的節點。

使用DNS的方式能夠在程序中集成一個DNS解析庫，也能夠自定義本地的DNS Server。

自定義本地 DNS Server 是指將 .consul 域的請求所有轉發到 Consul Agent。

服務健康檢查

心跳方式比較簡單，客戶端上報本身的存活狀態便可。

但存活不表明健康，例如一個應用的服務層沒問題，但數據庫鏈接故障了，那麼就沒法正常提供服務，這就是存活但不健康。

Eureka 支持服務自定義健康檢查邏輯。

Consul 支持的很全面，能夠配置服務自定義的健康檢查接口地址，還有完善的管理界面，能夠查看全部服務和節點的健康檢查狀態。

推薦閱讀：

• Zookeeper vs Etcd
• 前端開發利器 - Wep Replay
• kafka 中 zookeeper 具體是作什麼的？
• 分佈式惟一ID的生成方案
• 如何判斷一個元素是否存在於一個億級數據集中？