企業級java springboot b2bc商城系統開源源碼二次開發(十三)：註冊中心 Consul 使用詳解

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 工做原理：

一、當 Producer 啓動的時候，會向 Consul 發送一個 post 請求，告訴 Consul 本身的 IP 和 Port
二、Consul 接收到 Producer 的註冊後，每隔10s（默認）會向 Producer 發送一個健康檢查的請求，檢驗Producer是否健康
三、當 Consumer 發送 GET 方式請求 /api/address 到 Producer 時，會先從 Consul 中拿到一個存儲服務 IP 和 Port 的臨時表，從表中拿到 Producer 的 IP 和 Port 後再發送 GET 方式請求 /api/address
四、該臨時表每隔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 強一致性(C)帶來的是：

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

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

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

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

總體架構以下：

完整項目的源碼來源

Spring Cloud大型企業分佈式微服務雲構建的B2B2C電子商務平臺源碼請加企鵝求求：一零三八七七四六二六