consul 簡介
consul 是 hashicorp 公司推出的開源工具，用于實作分布式系統的服務發現與配置。與其他分布式服務注冊與發現的方案，consul的方案更“一站式” ，内置了服務注冊與發現框 架、具有以下性質：
分布一緻性協定實作、
健康檢查、
key/value存儲、
多資料中心方案，
不再需要依賴其他工具（比如zookeeper等）。
使用起來也較 為簡單。consul使用go語言編寫，是以具有天然可移植性(支援linux、windows和mac os x)；安裝包僅包含一個可執行檔案，友善部署，與docker等輕量級容器可無縫配合 。 基于 mozilla public license 2.0 的協定進行開源. consul 支援健康檢查,并允許 http 和 dns 協定調用 api 存儲鍵值對. 一緻性協定采用 raft 算法,用來保證服務的高可用. 使用 gossip 協定管理成員和廣播消息, 并且支援 acl 通路控制.
服務注冊與發現
配置中心
使用 raft 算法來保證一緻性, 比複雜的 paxos 算法更直接. 相比較而言, zookeeper 采用的是 paxos, 而 etcd 使用的則是 raft. 支援多資料中心，内外網的服務采用不同的端口進行監聽。 多資料中心叢集可以避免單資料中心的單點故障,而其部署則需要考慮網絡延遲, 分片等情況等. zookeeper 和 etcd 均不提供多資料中心功能的支援. 支援健康檢查. etcd 不提供此功能. 支援 http 和 dns 協定接口. zookeeper 的內建較為複雜, etcd 隻支援 http 協定. 官方提供web管理界面, etcd 無此功能.
下面這張圖來源于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端口完成。
client: 用戶端, 無狀态, 将 http 和 dns 接口請求轉發給區域網路内的服務端叢集.server: 服務端, 儲存配置資訊, 高可用叢集, 在區域網路内與本地用戶端通訊, 通過廣域網與其他資料中心通訊. 每個資料中心的 server 數量推薦為 3 個或是 5 個.
由于spring cloud consul項目的實作，我們可以輕松的将基于spring boot的微服務應用注冊到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和端口。
在 windows powershell中執行指令拉取最新版本的consul鏡像：
然後就可以啟動叢集了，這裡啟動4個consul agent，3個server（會選舉出一個leader），1個client。
第1個啟動容器的ip一般是172.17.0.2，後邊啟動的幾個容器ip會排着來：172.17.0.3、172.17.0.4、172.17.0.5。
這些consul節點在docker的容器内是互通的，他們通過橋接的模式通信。但是如果主機要通路容器内的網絡，需要做端口映射。在啟動第一個容器時，将consul的8500端口映射到了主機的8900端口，這樣就可以友善的通過主機的浏覽器檢視叢集資訊。
進入容器consul1：
服務注冊
自己寫一個web服務，用最熟悉的開發語言就好了，不過需要在容器中能夠跑起來，可能需要安裝運作環境，比如python、java、.net core等的sdk及web伺服器，需要注意的是consul的docker鏡像基于alpine系統，具體運作環境的安裝請搜尋一下。
這裡寫了一個hello服務，通過配置檔案的方式注冊到consul，服務的相關資訊：
name：hello，服務名稱，需要能夠區分不同的業務服務，可以部署多份并使用相同的name注冊。
id：hello1，服務id，在每個節點上需要唯一，如果有重複會被覆寫。
address：172.17.0.5，服務所在機器的位址。
port：5000，服務的端口。
健康檢查位址：http://localhost:5000/，如果傳回http狀态碼為200就代表服務健康，每10秒consul請求一次，請求逾時時間為1秒。
請将下面的内容儲存成檔案services.json，并上傳到容器的/consul/config目錄中。
複制到consul config目錄：
重新加載consul配置：
然後這個服務就注冊成功了。可以将這個服務部署到多個節點，比如部署到consul1和consul4，并同時運作。
服務發現
服務注冊成功以後，調用方擷取相應服務位址的過程就是服務發現。consul提供了多種方式。
http api方式：
傳回的資訊包括注冊的consul節點資訊、服務資訊及服務的健康檢查資訊。這裡用了一個參數passing=false，會自動過濾掉不健康的服務，包括本身不健康的服務和不健康的consul節點上的服務，從這個設計上可以看出consul将服務的狀态綁定到了節點的狀态。
如果服務有多個部署，會傳回服務的多條資訊，調用方需要決定使用哪個部署，常見的可以随機或者輪詢。為了提高服務吞吐量，以及減輕consul的壓力，還可以緩存擷取到的服務節點資訊，不過要做好容錯的方案，因為緩存服務部署可能會變得不可用。具體是否緩存需要結合自己的通路量及容錯規則來确定。
上邊的參數passing預設為false，也就是說不健康的節點也會傳回，結合擷取節點全部服務的方法，這裡可以做到擷取全部服務的實時健康狀态，并對不健康的服務進行報警處理。
dns方式：
hello服務的域名是：hello.service.dc1.consul，後邊的service代表服務，固定；dc1是資料中心的名字，可以配置；最後的consul也可以配置。