（二十五）java版spring cloud+spring boot 社交電子商務平臺-服務發現consul

電子商務平臺源碼請加企鵝求求：一零三八七七四六二六。 Consul是分佈式的、高可用、橫向擴展的。

consul提供的一些關鍵特性：

service discovery：consul經過DNS或者HTTP接口使服務註冊和服務發現變的很容易，一些外部服務，例如saas提供的也能夠同樣註冊。

health checking：健康檢測使consul能夠快速的告警在集羣中的操做。和服務發現的集成，能夠防止服務轉發到故障的服務上面。

key/value storage：一個用來存儲動態配置的系統。提供簡單的HTTP接口，能夠在任何地方操做。

multi-datacenter：無需複雜的配置，便可支持任意數量的區域。

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

Consul內部原理

下面這張圖來源於Consul官網，很好的解釋了Consul的工做原理，先大體看一下。

首先Consul支持多數據中心，在上圖中有兩個DataCenter，他們經過Internet互聯，同時請注意爲了提升通訊效率，只有Server節點才加入跨數據中心的通訊。

在單個數據中心中，Consul分爲Client和Server兩種節點（全部的節點也被稱爲Agent），Server節點保存數據，Client負責健康檢查及轉發數據請求到Server；Server節點有一個Leader和多個Follower，Leader節點會將數據同步到Follower，Server的數量推薦是3個或者5個，在Leader掛掉的時候會啓動選舉機制產生一個新的Leader。

集羣內的Consul節點經過gossip協議（流言協議）維護成員關係，也就是說某個節點了解集羣內如今還有哪些節點，這些節點是Client仍是Server。單個數據中心的流言協議同時使用TCP和UDP通訊，而且都使用8301端口。跨數據中心的流言協議也同時使用TCP和UDP通訊，端口使用8302。

集羣內數據的讀寫請求既能夠直接發到Server，也能夠經過Client使用RPC轉發到Server，請求最終會到達Leader節點，在容許數據輕微陳舊的狀況下，讀請求也能夠在普通的Server節點完成，集羣內數據的讀寫和複製都是經過TCP的8300端口完成。

如今咱們只看DataCenter，能夠看出Consul的集羣是由N個SERVER，加上M個CLIENT組成的。而不論是SERVER仍是CLIENT，都是consul的一個節點，全部的服務均可以註冊到這些節點上，正是經過這些節點實現服務註冊信息的共享。除了這兩個，在看下面的一些小細節。

CLIENT

CLIENT表示Consul的client模式，就是客戶端模式。是Consul節點的一種模式，這種模式下，全部註冊到當前節點的服務會被轉發到SERVER，自己是不持久化這些信息。

SERVER

SERVER表示Consul的server模式，代表這個Consul是個server，這種模式下，功能和CLIENT都同樣，惟一不一樣的是，它會把全部的信息持久化的本地，這樣遇到故障，信息是能夠被保留的。

SERVER-LEADER

中間那個SERVER下面有LEADER的字眼，代表這個SERVER是它們的老大，它和其它SERVER不同的一點是，它須要負責同步註冊的信息給其它的SERVER，同時也要負責各個節點的健康監測。

其它信息

其它信息包括它們之間的通訊方式，還有一些協議信息，算法。它們是用於保證節點之間的數據同步，實時性要求等等一系列集羣問題的解決。這些有興趣的本身看看官方文檔。

Consul服務發現原理

下面這張圖基本描述了服務發現的完整流程，先大體看一下。

首先須要有一個正常的Consul集羣，有Server，有Leader。這裏在服務器Server一、Server二、Server3上分別部署了Consul Server，假設他們選舉了Server2上的Consul Server節點爲Leader。這些服務器上最好只部署Consul程序，以儘可能維護Consul Server的穩定。

而後在服務器Server4和Server5上經過Consul Client分別註冊Service A、B、C，這裏每一個Service分別部署在了兩個服務器上，這樣能夠避免Service的單點問題。服務註冊到Consul能夠經過HTTP API（8500端口）的方式，也能夠經過Consul配置文件的方式。Consul Client能夠認爲是無狀態的，它將註冊信息經過RPC轉發到Consul Server，服務信息保存在Server的各個節點中，而且經過Raft實現了強一致性。

最後在服務器Server6中Program D須要訪問Service B，這時候Program D首先訪問本機Consul Client提供的HTTP API，本機Client會將請求轉發到Consul Server，Consul Server查詢到Service B當前的信息返回，最終Program D拿到了Service B的全部部署的IP和端口，而後就能夠選擇Service B的其中一個部署並向其發起請求了。若是服務發現採用的是DNS方式，則Program D中直接使用Service B的服務發現域名，域名解析請求首先到達本機DNS代理，而後轉發到本機Consul Client，本機Client會將請求轉發到Consul Server，Consul Server查詢到Service B當前的信息返回，最終Program D拿到了Service B的某個部署的IP和端口。

圖中描述的部署架構筆者認爲是最普適最簡單的方案，從某些默認配置或設計上看也是官方但願使用者採用的方案，好比8500端口默認監聽127.0.0.1，固然有些同窗不贊同，後邊會提到其餘方案。