【2019 Java面試】Consul和Eureka區別
1. 前言
Consul 和 Eureka 在微服務架構中都是作爲 服務註冊和服務發現 組件。
在微服務應用中，服務的實例數量和網絡地址都是動態變化的，這對運維提出來了巨大的挑戰，因此動態的服務註冊和服務發現尤爲重要
2. 解決問題
在一個分佈式系統中，服務註冊與發現組件主要解決兩個問題：服務註冊和服務發現。
-
服務註冊：服務實例將自身服務信息註冊到註冊中心。這部分服務信息包括服務所在主機IP和提供服務的Port，以及暴露服務自身狀態以及訪問協議等信息。
-
服務發現：服務實例請求註冊中心獲取所依賴服務信息。服務實例通過註冊中心，獲取到註冊到其中的服務實例的信息，通過這些信息去請求它們提供的服務。
除此之外，服務註冊與發現需要關注監控服務實例運行狀態、負載均衡等問題。
- 監控：微服務應用中，服務處於動態變化的情況，需要一定機制處理無效的服務實例。一般來講，服務實例與註冊中心在註冊後通過心跳的方式維繫聯繫，一旦心跳缺少，對應的服務實例會被註冊中心剔除。
- 負載均衡：同一服務可能同時存在多個實例，需要正確處理對該服務的負載均衡。
3. 分佈式系統的CAP原理
CAP原則，指的是在一個分佈式系統中，Consistency(一致性)、Availability(可用性)、Partition Tolerance(分區容錯性)，不能同時成立。
- 一致性：它要求在同一時刻點，分佈式系統中的所有數據備份都處於同一狀態。
- 可用性：在系統集羣的一部分節點宕機後，系統依然能夠響應用戶的請求。
- 分區容錯性：在網絡區間通信出現失敗，系統能夠容忍。
一般來講，基於網絡的不穩定性，分佈容錯是不可避免的，所以我們默認CAP中的P總是成立的。
一致性的強制數據統一要求，必然會導致在更新數據時部分節點處於被鎖定狀態，此時不可對外提供服務，影響了服務的可用性，反之亦然。因此一致性和可用性不能同時滿足。
我們接下來介紹的服務註冊和發現組件中，Eureka滿足了其中的 AP(可用性和分區容錯性)，Consul和Zookeeper滿足了其中的CP(一致性和分區容錯性)。
4. Eureka和Consul的區別
最大的區別是：
Eureka保證AP，Consul保證CP。
Consul強一致性©:
1. 服務註冊相對Eureka會稍慢一些。因爲Consul的raft協議要求必須過半的節點寫入數據成功才認爲註冊成功。
2. Leader 掛掉之後，重新選舉期間，整個Consul不可用，Consul保證一致性的前提下犧牲了可用性。
Eureka保證高可用性和最終一致性：
1. 服務註冊相對較快，因爲不需要等註冊信息 replicate 到其他節點，也不保證註冊信息能否 replicate 成功。
2. 當數據出現不一致的時候，雖然A，B上的註冊信息不一致，但每個 Eureka節點依然能夠正常提供服務，這會出現查詢服務時，如果A查不到，但請求B可以查到。如此保證了可用性但是犧牲了一致性
| 組件名 | 語言 | CAP | 一致性算法 | 服務健康檢查 | 對外暴露接口 | Spring Cloud集成 |
|---|---|---|---|---|---|---|
| Eureka | Java | AP | 無 | 可配支持 | ||
| Consul | Go | CP | Raft | 支持 | HTTP/DNS | 已集成 |
| Zookeeper | Java | CP | Paxos | 支持 | 客戶端 | 已集成 |
參考：