我們知道，Eureka 2.X因遇到問題，已停止研發。Spring Cloud官方建議遷移到Consul或者Zookeeper等其他服務發現中間件。

下面是 Spring Cloud 支持的服務發現軟件以及特性對比：

一、Consul 介紹

Consul 是 HashiCorp 公司推出的開源工具，用于實現分布式系統的服務發現與配置。與其它分布式服務注冊與發現的方案，Consul 的方案更“一站式”，內置了服務注冊與發現框架、分布一致性協議實現、健康檢查、Key/Value 存儲、多數據中心方案，不再需要依賴其它工具（比如 ZooKeeper 等）。使用起來也較為簡單。Consul 使用 Go 語言編寫，因此具有天然可移植性(支持Linux、windows和Mac OS X)；安裝包僅包含一個可執行文件，方便部署，與 Docker 等輕量級容器可無縫配合。

Consul 的優勢：

• 使用 Raft 算法來保證一致性, 比復雜的 Paxos 算法更直接. 相比較而言, zookeeper 采用的是 Paxos, 而 etcd 使用的則是 Raft。
  支持多數據中心，內外網的服務采用不同的端口進行監聽。 多數據中心集群可以避免單數據中心的單點故障,而其部署則需要考慮網絡延遲, 分片等情況等。 zookeeper 和 etcd 均不提供多數據中心功能的支持。
• 支持健康檢查。 etcd 不提供此功能。
• 支持 http 和 dns 協議接口。 zookeeper 的集成較為復雜, etcd 只支持 http 協議。
• 官方提供 web 管理界面, etcd 無此功能。
• 綜合比較, Consul 作為服務注冊和配置管理的新星, 比較值得關注和研究。

特性：

• 服務發現
• 健康檢查
• Key/Value 存儲
• 多數據中心

Consul 角色

• client: 客戶端, 無狀態, 將 HTTP 和 DNS 接口請求轉發給局域網內的服務端集群。
• server: 服務端, 保存配置信息, 高可用集群, 在局域網內與本地客戶端通訊, 通過廣域網與其它數據中心通訊。 每個數據中心的 server 數量推薦為 3 個或是 5 個。

Consul 客戶端、服務端還支持夸中心的使用，更加提高了它的高可用性。

Consul 工作原理：

• 1、當 Producer 啟動的時候，會向 Consul 發送一個 post 請求，告訴 Consul 自己的 IP 和 Port
• 2、Consul 接收到 Producer 的注冊后，每隔10s（默認）會向 Producer 發送一個健康檢查的請求，檢驗Producer是否健康
• 3、當 Consumer 發送 GET 方式請求 /api/address 到 Producer 時，會先從 Consul 中拿到一個存儲服務 IP 和 Port 的臨時表，從表中拿到 Producer 的 IP 和 Port 后再發送 GET 方式請求 /api/address
• 4、該臨時表每隔10s會更新，只包含有通過了健康檢查的 Producer

Spring Cloud Consul 項目是針對 Consul 的服務治理實現。Consul 是一個分布式高可用的系統，它包含多個組件，但是作為一個整體，在微服務架構中為我們的基礎設施提供服務發現和服務配置的工具。

二、Consul VS Eureka

Eureka 是一個服務發現工具。該體系結構主要是客戶端/服務器，每個數據中心有一組 Eureka 服務器，通常每個可用區域一個。通常 Eureka 的客戶使用嵌入式 SDK 來注冊和發現服務。對于非本地集成的客戶，官方提供的 Eureka 一些 REST 操作 API，其它語言可以使用這些 API 來實現對 Eureka Server 的操作從而實現一個非 jvm 語言的 Eureka Client。

Eureka 提供了一個弱一致的服務視圖，盡可能的提供服務可用性。當客戶端向服務器注冊時，該服務器將嘗試復制到其它服務器，但不提供保證復制完成。服務注冊的生存時間（TTL）較短，要求客戶端對服務器心跳檢測。不健康的服務或節點停止心跳，導致它們超時并從注冊表中刪除。服務發現可以路由到注冊的任何服務，由于心跳檢測機制有時間間隔，可能會導致部分服務不可用。這個簡化的模型允許簡單的群集管理和高可擴展性。

Consul 提供了一些列特性，包括更豐富的健康檢查，鍵值對存儲以及多數據中心。Consul 需要每個數據中心都有一套服務，以及每個客戶端的 agent，類似于使用像 Ribbon 這樣的服務。Consul agent 允許大多數應用程序成為 Consul 不知情者，通過配置文件執行服務注冊并通過 DNS 或負載平衡器 sidecars 發現。

Consul 提供強大的一致性保證，因為服務器使用 Raft 協議復制狀態 。Consul 支持豐富的健康檢查，包括 TCP，HTTP，Nagios / Sensu 兼容腳本或基于 Eureka 的 TTL。客戶端節點參與基于 Gossip 協議的健康檢查，該檢查分發健康檢查工作，而不像集中式心跳檢測那樣成為可擴展性挑戰。發現請求被路由到選舉出來的 leader，這使他們默認情況下強一致性。允許客戶端過時讀取取使任何服務器處理他們的請求，從而實現像 Eureka 這樣的線性可伸縮性。

Consul 強烈的一致性意味著它可以作為領導選舉和集群協調的鎖定服務。Eureka 不提供類似的保證，并且通常需要為需要執行協調或具有更強一致性需求的服務運行 ZooKeeper。

Consul 提供了支持面向服務的體系結構所需的一系列功能。這包括服務發現，還包括豐富的運行狀況檢查，鎖定，密鑰/值，多數據中心聯合，事件系統和 ACL。Consul 和 consul-template 和 envconsul 等工具生態系統都試圖盡量減少集成所需的應用程序更改，以避免需要通過 SDK 進行本地集成。Eureka 是一個更大的 Netflix OSS 套件的一部分，該套件預計應用程序相對均勻且緊密集成。因此 Eureka 只解決了一小部分問題，可以和 ZooKeeper 等其它工具可以一起使用。

Consul 強一致性?帶來的是：

服務注冊相比 Eureka 會稍慢一些。因為 Consul 的 raft 協議要求必須過半數的節點都寫入成功才認為注冊成功 Leader 掛掉時，重新選舉期間整個 Consul 不可用。保證了強一致性但犧牲了可用性。

Eureka 保證高可用(A)和最終一致性：

服務注冊相對要快，因為不需要等注冊信息 replicate 到其它節點，也不保證注冊信息是否 replicate 成功 當數據出現不一致時，雖然 A, B 上的注冊信息不完全相同，但每個 Eureka 節點依然能夠正常對外提供服務，這會出現查詢服務信息時如果請求 A 查不到，但請求 B 就能查到。如此保證了可用性但犧牲了一致性。

其它方面，eureka 就是個 servlet 程序，跑在 servlet 容器中; Consul 則是 go 編寫而成。

三、Consul的使用

http://www.ityouknow.com/springcloud/2018/07/20/spring-cloud-consul.html

總結

以上是生活随笔為你收集整理的Spring Cloud——Consul——架构体系的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。