註冊中心Consul產線部署架構

一、Consul官方架構圖和說明

Consul 提供了高可用的kv存儲，集羣架構，這點和etcd zookeeper相似。 另外也提供了自動服務發現註冊的套件，而且可否對服務進行健康檢查。 結合consul-template能夠實現服務提供方信息更新(好比增長了API服務器)時，自動生成配置文件給服務使用方自動更新配置。

從圖中可看到的是Consul支持跨數據中心，在每一個數據中心有client和server。通常server是3-5個，少了會影響可靠性，多了會影響速度。client則沒有數量的限制。

集羣經過goosip協議管理全部node成員和廣播集羣消息，client須要配置文件就能發現急羣衆全部的server，節點故障檢測被分不到整個集羣，不須要server的參與。全部server經過Raft協議進行選主(leader), leader負責處理全部的查詢和事務。

server還負責與其餘數據中心交互來處理跨數據中心的請求，當server收到這種請求它會將請求轉發到相應的數據中心活本地的leader。

二、純Server模式

client和server本質都是consul的agent，只是角色不一樣（在啓動時指定參數便可）。以前咱們產線環境並無徹底按照官方架構圖（即client-server模式）進行部署，而是採用了所有server的模式，以下圖：

三、純Server模式帶來的問題

這種架構下帶來的問題有兩個：

1. 高可用
   服務實例註冊時配置的consul-host是負載均衡的地址，服務註冊到集羣中後，由集羣中的一個節點負責對該實例進行健康檢查。假如存在一下狀況：（1）某個服務有兩個節點實例，這兩個節點經過負載均衡進行註冊後都由server1進行健康檢查（2）server1節點不可用（多是server1掛了，也多是server1所在機器出現問題）。這樣就會致使服務在註冊中心中消失致使服務沒法訪問到，而服務自己並不存在問題。
2. 服務註銷
   由於集羣中的某一個節點（好比server1）負責服務的健康檢查，在服務從註冊中心註銷時，經過負責均衡註銷時的代碼以下：

ConsulClient client = new ConsulClient("負載均衡地址");
client.agentServiceDeregister("當前服務在註冊中心的Id");
複製代碼

因爲負載均衡，註銷時定位到的集羣節點多是server2，這樣就會致使服務的註銷失敗。解決的辦法是遍歷集羣中的全部節點（members）進行註銷，具體可參考：使用Consul時，服務沒法正常註銷

四、用Client-Server模式

目前consul的總體架構升級爲client-server模式，服務註冊時再也不向consul-server集羣進行註冊，而是向服務所在機器的consul-client進行註冊，有consul-client將註冊信息同步到consul-server集羣中，架構以下：

回顧以上兩個問題：

1. 高可用
   服務實例註冊時向本級consul-client進行註冊，若是consul-client不可用，隻影響這個consul-client所在機器的全部服務實例（若是機器掛了則全部這臺機器上的實例不能訪問就很合理）。由於服務實例自己的高可用會分佈在不一樣的機器上，因此不會影響另一臺機器上的實例（不要把雞蛋放在一個籃子裏）。

注意：consul-client掛了，服務的註冊信息不會轉移到另一個consul-client中。因此要求服務自己處於不一樣的機器上來保證高可用。

2. 服務註銷
   服務從註冊中心註銷時，只須要鏈接到本地的consul-client進行註銷便可，一臺機器就一個consul-client，不須要通過負載均衡：

ConsulClient client = new ConsulClient("local-consul-client-ip");
client.agentServiceDeregister("當前服務在註冊中心的Id");
複製代碼