技術文章 » eureka、consul、nacos三大產品對比

eureka、consul、nacos三大產品對比

2020-08-12 22:44:47

設定中心

  • eureka 不支援
  • consul 支援 但用起來偏麻煩，不太符合springBoot框架的命名風格，支援動態重新整理
  • nacos 支援 用起來簡單，符合springBoot的命名風格，支援動態重新整理

註冊中心

  • eureka

    • 應用內/外：直接整合到應用中，依賴於應用自身完成服務的註冊與發現，
    • ACP原則：遵循AP（可用性+分離容忍）原則，有較強的可用性，服務註冊快，但犧牲了一定的一致性。
    • 版本迭代：目前已經不進行升級
    • 整合支援：只支援SpringCloud整合
    • 存取協定：HTTP
    • 雪崩保護：支援雪崩保護
    • 介面：英文介面，不符合國人習慣
    • 上手：容易

  • consul

    • 應用內/外：屬於外部應用，侵入性小
    • ACP原則：遵循CP原則（一致性+分離容忍） 服務註冊稍慢，由於其一致性導致了在Leader掛掉時重新選舉期間真個consul不可用。
    • 版本迭代：目前仍然進行版本迭代
    • 整合支援：支援SpringCloud K8S整合
    • 存取協定：HTTP/DNS
    • 雪崩保護：不支援雪崩保護
    • 介面：英文介面，不符合國人習慣
    • 上手：複雜一點

  • nacos

    • 應用內/外：屬於外部應用，侵入性小
    • ACP原則：通知遵循CP原則（一致性+分離容忍） 和AP原則（可用性+分離容忍）
    • 版本迭代：目前仍然進行版本迭代
    • 整合支援：支援Dubbo 、SpringCloud、K8S整合
    • 存取協定：HTTP/動態DNS/UDP
    • 雪崩保護：支援雪崩保護
    • 介面：中文介面，符合國人習慣
    • 上手：極易，中文文件，案例，社羣活躍

 

主流註冊中心產品 

Apache Zookeeper -> CP

　　與 Eureka 有所不同，Zookeeper 在設計時就緊遵CP原則，即任何時候對 Zookeeper 的存取請求能得到一致的數據結果，同時系統對網路分割具備容錯性，但是 Zookeeper 不能保證每次服務請求都是可達的。從 Zookeeper 的實際應用情況來看，在使用 Zookeeper 獲取服務列表時，如果此時的 Zookeeper 叢集中的 Leader 宕機了，該叢集就要進行 Leader 的選舉，又或者 Zookeeper 叢集中半數以上伺服器節點不可用（例如有三個節點，如果節點一檢測到節點三掛了 ，節點二也檢測到節點三掛了，那這個節點纔算是真的掛了），那麼將無法處理該請求。所以說，Zookeeper 不能保證服務可用性。

就我接觸到的專案基本都不會用zookeeper來做爲服務發現

Spring Cloud Eureka  -> AP

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

　　不知道spring抽什麼風居然將Eureka閉源了，所以就不做過多解釋。

 

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 服務不可用。

　　目前在.net微服務中大多使用它來作爲註冊服務

　　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編寫而成。

Nacos：
　　Nacos是阿裡開源的，Nacos 支援基於 DNS 和基於 RPC 的服務發現。在Spring Cloud中使用Nacos，只需要先下載 Nacos 並啓動 Nacos server，Nacos只需要簡單的設定就可以完成服務的註冊發現。

　　Nacos除了服務的註冊發現之外，還支援動態設定服務。動態設定服務可以讓您以中心化、外部化和動態化的方式管理所有環境的應用設定和服務設定。動態設定消除了設定變更時重新部署應用和服務的需要，讓設定管理變得更加高效和敏捷。設定中心化管理讓實現無狀態服務變得更簡單，讓服務按需彈性擴充套件變得更容易。

　　一句話概括就是Nacos = Spring Cloud註冊中心 + Spring Cloud設定中心。 

　　java架構師大多都採用它，它的確好用