Spring Cloud微服務架構實戰之Consul註冊中心01

Netflix Eureka 2.X 官方宣告中止開發，但其實對國內的用戶影響甚小，一方面國內大都使用的是 Eureka 1.X 系列，而且官方也在積極維護 1.X。

 The existing open source work on eureka 2.0 is discontinued. The code base and artifacts that were released as part of the existing repository of work on the 2.x branch is considered use at your own risk.
Eureka 1.x is a core part of Netflix's service discovery system and is still an active project.

翻譯：

有關 eureka 2.0 的現有開源工做已中止。在 2.x 分支上做爲現有工做資料庫的一部分發布的代碼庫和工件被視爲使用後果自負。
Eureka 1.x 是 Netflix 服務發現系統的核心部分，仍然是一個活躍的項目。

雖然 Eureka，Hystrix 等再也不繼續開發或維護，可是目前來講不影響使用，無論怎麼說感謝開源，向 Netflix 公司的開源致敬。

另外一方面 Spring Cloud 支持不少服務發現的軟件，Eureka 只是其中之一，好比咱們今天要講的主角 Consul。下面是 Spring Cloud 支持的服務發現軟件以及特性對比。

一、常見的註冊中心

• Netflix Eureka
• Alibaba Nacos
• HashiCorp Consul
• Apache ZooKeeper
• CoreOS Etcd
• CNCF CoreDNS

 

二、Consul 介紹

Consul 是 HashiCorp 公司推出的開源工具，用於實現分佈式系統的服務發現與配置。與其它分佈式服務註冊與發現的方案，Consul 的方案更「一站式」，內置了服務註冊與發現框架、分佈一致性協議實現、健康檢查、Key/Value 存儲、多數據中心方案，再也不須要依賴其它工具（好比 ZooKeeper 等），使用起來也較爲簡單。

Consul 使用 Go 語言編寫，所以具備自然可移植性（支持Linux、Windows 和 Mac OS）；安裝包僅包含一個可執行文件，方便部署，與 Docker 等輕量級容器可無縫配合。

 

三、Consul 特性

•  Raft 算法
• 服務發現
• 健康檢查
• Key/Value 存儲
• 多數據中心
• 支持 http 和 dns 協議接口
• 官方提供 web 管理界面

四、Consul 角色

client：客戶端，無狀態，將 HTTP 和 DNS 接口請求轉發給局域網內的服務端集羣。
server：服務端，保存配置信息，高可用集羣，每一個數據中心的 server 數量推薦爲 3 個或者 5 個。

首先，圖中有兩個數據中心，分別爲 Datacenter1 和 Datacenter2 。Consul 很是好的支持多個數據中心，每一個數據中心內，有客戶端和服務器端，服務器通常爲 3~5 個，這樣能夠在穩定和性能上達到平衡，由於更多的機器會使數據同步很慢。不過客戶端是沒有限制的，能夠有成千上萬個。

數據中心內的全部節點都會加入到 Gossip (流言)協議。這就意味着有一個 Gossip 池，其中包含這個數據中心全部的節點。客戶端不須要去配置服務器地址信息，發現服務工做會自動完成。檢測故障節點的工做不是放在服務器端，而是分佈式的；這使得失敗檢測相對於本地化的心跳機制而言，更具可拓展性。在選擇 leader 這種重要的事情發生的時候，數據中心被用做消息層來作消息廣播。

每一個數據中心內的服務器都是單個 Raft 中節點集的一部分。這意味着他們一塊兒工做，選擇一個單一的領導者——一個具備額外職責的選定的服務器。leader 負責處理全部查詢和事物。事物也必須做爲同步協議的一部分複製到節點集中的全部節點。因爲這個要求，當非 leader 服務器接收到 RPC 請求時，就會將請求其轉發給集羣 leader。

服務器端節點同時也做爲 WAN Gossip 池的一部分，WAN 池和 LAN 池不一樣的是，它針對網絡高延遲作了優化，並且只包含其餘Consul 服務器的節點。這個池的目的是容許數據中心以最少的消耗方式發現對方。啓動新的數據中心與加入現有的 WAN Gossip 同樣簡單。由於這些服務器都在這個池中運行，它還支持跨數據中心請求。當服務器收到對不一樣數據中心的請求時，它會將其轉發到正確數據中心中的隨機服務器。那個服務器可能會轉發給本地的 leader。

這樣會使數據中心的耦合很是低。可是因爲故障檢測，鏈接緩存和複用，跨數據中心請求相對快速可靠。

總的來講，數據不會在不一樣的數據中心之間作複製備份。當收到一個請求處於別的數據中心的資源時，本地的 Consul 服務器會發一個 RPC 請求到遠端的 Consul 服務器，而後返回結果。若是遠端數據中心處於不可用狀態，那麼這麼資源也會不可用，但這不影響本地的數據中心。在一些特殊的狀況下，有限的數據集會被跨數據中心複製備份，好比說 Consul 內置的 ACL 複製能力，或者像 consul-replicate 這樣的外部工具。

 

五、Consul 工做原理

 

5.1 服務發現以及註冊

當服務 Producer 啓動時，會將本身的 Ip/host 等信息經過發送請求告知 Consul，Consul 接收到 Producer 的註冊信息後，每隔 10s（默認）會向 Producer 發送一個健康檢查的請求，檢驗 Producer 是否健康。

 

5.2 服務調用

當 Consumer 請求 Product 時，會先從 Consul 中拿到存儲 Product 服務的 IP 和 Port 的臨時表(temp table)，從temp table 表中任選一個· Producer 的 IP 和 Port， 而後根據這個 IP 和 Port，發送訪問請求；temp table 表只包含經過了健康檢查的 Producer 信息，而且每隔 10s（默認）更新。

 

六、總結

本節講述了常見註冊中心，Consul介紹、特性、角色及工做原理，下一節將繼續給你們講述Consul 入門案例，請繼續關注我，有須要微服務架構實戰視頻教程，請點擊  Spring Cloud微服務架構