這兩年微服務越來越火，使用Consul的人也越來越多，經常有人問一些問題，比如：服務註冊到節點後，其他節點為什麼沒有同步？Client是幹什麼的？等等。這篇乾貨分享就談一下Consul做服務發現的方式，答疑解惑一番。
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端口完成。
Consul服務發現原理
首先需要有一個正常的Consul集群，有Server，有Leader。這裡在服務器Server1、Server2、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和端口。
Consul的其它部署架構
如果你實在不想在每個主機部署Consul Client，還有一個多路註冊的方案可供選擇，這是交流群中獲得的思路。
如圖所示，在專門的服務器上部署Consul Client，然後每個服務都註冊到多個Client，這裡為了避免服務單點問題還是每個服務部署多份，需要服務發現時，程序向一個提供負載均衡的程序發起請求，該程序將請求轉發到某個Consul Client。這種方案需要注意將Consul的8500端口綁定到私網IP上，默認只有127.0.0.1。
這個架構的優勢：
Consul節點服務器與應用服務器隔離，互相干擾少；
不用每臺主機都部署Consul，方便Consul的集中管理；
某個Consul Client掛掉的情況下，註冊到其上的服務仍有機會被訪問到。
但也需要注意其缺點：
引入更多技術棧：負載均衡的實現，不僅要考慮Consul Client的負載均衡，還要考慮負載均衡本身的單點問題。
Client的節點數量：單個Client如果註冊的服務太多，負載較重，需要有個算法（比如hash一致）合理分配每個Client上的服務數量，以及確定Client的總體數量。
服務發現要過濾掉重複的註冊，因為註冊到了多個節點會認為是多個部署（DNS接口不會有這個問題）。
是否可以只有Server？
這個問題的答案還是有關服務數量的問題，首先Server的節點數量不是越多越好，3個或者5個是推薦的數量，數量越多數據同步的處理越慢（強一致性）；然後每個節點可以註冊的服務數量是有上限的，這個受限於軟硬件的處理能力。所以如果你的服務只有10個左右，只有Server問題是不大的，但是這時候有沒有必要使用Consul呢？因此正常使用Consul的時候還是要有Client才好，這也符合Consul的反熵設計。
大家可以將這個部署架構與前文提到的普適架構對比下，看看哪個更適合自己。
文章部分素材來源： 分佈式實驗室
