服務註冊發現技術對比
- 2019 年 12 月 25 日
- 筆記
技術對照表
CAP模型
CAP 這3個字母代表：
- Consistence（一致性）
- Availability（可用性）
- Partition Tolerance（分區容錯性）
在一個分散式系統中，這3者不可兼得。
由於網路的原因，分散式系統中 P 是必備的，意味著只能選擇 AP 或者 CP。
CP 代表數據一致性是第一位的，AP 代表可用性是第一位的。
他們4個只有 Eureka 是 AP 的，Eureka 在數據不一致的情況下也可以使用，只要數據最終一致即可。
如果想更多的了解 CAP 可以參見：
數據一致性
ZAB 是 zookeeper 的原子廣播協議，基於 Paxos 演算法改的。
Raft 是工程上使用較為廣泛的強一致性、去中心化、高可用的分散式協議。
這兩個演算法都沒毛病，都可以實現分散式一致性，只是實現方式不同。
Eureka 選擇的是 AP，不要求強一致性，自然沒有使用數據一致性演算法。
Paxos 和 Raft 參考資料：
多數據中心
就是多機房，只有 Consul 支援。
zookeeper 不支援多數據中心是指，如果你跨多個機房部署了一套 zookeeper，一旦出現網路劃分，那麼就不可用了。
Consul 是通過 Gossip 協議實現的。
Gossip 協議中的消息會以一傳十、十傳百的指數級速度在網路中快速傳播。
網路中任何節點的異常都不會影響 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 支援的很全面，可以配置服務自定義的健康檢查介面地址，還有完善的管理介面，可以查看所有服務和節點的健康檢查狀態。
