Consul
在 Spring Cloud 體系中，幾乎每個角色都會有兩個以上的産品提供選擇，比如在注冊中心有：Eureka、Consul、zookeeper、etcd 等；網關的産品有 Zuul、Spring Cloud Gateway 等。在注冊中心産品中，最常使用的是 Eureka 和 Consul，兩者各有特點，企業可以根據自述項目情況來選擇。
Consul簡介
Consul 是 HashiCorp 公司推出的開源産品，用于實作分布式系統的服務發現、服務隔離、服務配置，這些功能中的每一個都可以根據需要單獨使用，也可以同時使用所有功能。Consul 官網目前主要推 Consul 在服務網格中的使用。
與其它分布式服務注冊與發現的方案相比，Consul 的方案更“一站式”——内置了服務注冊與發現架構、分布一緻性協定實作、健康檢查、Key/Value 存儲、多資料中心方案，不再需要依賴其它工具。Consul 本身使用 go 語言開發，具有跨平台、運作高效等特點，也非常友善和 Docker 配合使用。
Consul 的主要特點有：
Service Discovery : 服務注冊與發現，Consul 的用戶端可以做為一個服務注冊到 Consul，也可以通過 Consul 來查找特定的服務提供者，并且根據提供的資訊進行調用。
Health Checking: Consul 用戶端會定期發送一些健康檢查資料和服務端進行通訊，判斷用戶端的狀态、記憶體使用情況是否正常，用來監控整個叢集的狀态，防止服務轉發到故障的服務上面。
KV Store: Consul 還提供了一個容易使用的鍵值存儲。這可以用來保持動态配置，協助服務協調、建立 Leader 選舉，以及開發者想構造的其它一些事務。
Secure Service Communication: Consul 可以為服務生成分布式的 TLS 證書，以建立互相的 TLS 連接配接。 可以使用 intentions 定義允許哪些服務進行通信。 可以使用 intentions 輕松管理服務隔離，而不是使用複雜的網絡拓撲和靜态防火牆規則。
Multi Datacenter: Consul 支援開箱即用的多資料中心，這意味着使用者不需要擔心需要建立額外的抽象層讓業務擴充到多個區域。
Consul 角色
Server: 服務端, 儲存配置資訊, 高可用叢集, 在區域網路内與本地用戶端通訊, 通過廣域網與其它資料中心通訊。 每個資料中心的 Server 數量推薦為 3 個或是 5 個。
Client: 用戶端, 無狀态, 将 HTTP 和 DNS 接口請求轉發給區域網路内的服務端叢集。
Consul 旨在對 DevOps 社群和應用程式開發人員友好，使其成為現代、彈性基礎架構的理想選擇。
Consul 的優勢
使用 Raft 算法來保證一緻性, 比複雜的 Paxos 算法更直接。相比較而言, zookeeper 采用的是 Paxos, 而 etcd 使用的則是 Raft。
支援多資料中心，内外網的服務采用不同的端口進行監聽。多資料中心叢集可以避免單資料中心的單點故障，而其部署則需要考慮網絡延遲, 分片等情況等。 zookeeper 和 etcd 均不提供多資料中心功能的支援。
支援健康檢查。 etcd 不提供此功能。
支援 http 和 dns 協定接口。 zookeeper 的內建較為複雜, etcd 隻支援 http 協定。
官方提供 Web 管理界面, etcd 無此功能。
Consul 保持了 CAP 中的 CP，保持了強一緻性和分區容錯性。
Consul 支援 Http\gRPC\DNS 多種通路方式。
Spring Cloud 中注冊中心元件對比
CAP解釋： 分布式系統的CAP理論
CAP理論：一個分布式系統最多隻能同時滿足一緻性（Consistency）、可用性（Availability）和分區容錯性（Partition tolerance）這三項中的兩項。
一緻性(Consistency)，即更新操作成功并傳回用戶端完成後，所有節點在同一時間的資料完全一緻，是以，一緻性，說的就是資料一緻性。
可用性(Availability), 即服務一直可用，而且是正常相應時間。
分區容錯性(Partition Tolerance),即分布式系統在遇到某節點或網絡分區故障的時候，仍然能夠對外提供滿足一緻性和可用性的服務。
Consul–VS–Eureka
Consul和Eureka最大差別在于:Consul保證CA,而Eureka保證了AP；
Consul強一緻性帶來的是：
服務注冊相比Eureka會稍慢一些。因為Consul的raft協定要求必須過半數的節點都寫入成功才認為注冊成功
Leader挂掉時，重新選舉期間整個consul不可用。保證了強一緻性但犧牲了可用性。
Eureka保證高可用(A)和最終一緻性：
服務注冊相對要快，因為不需要等注冊資訊replicate到其他節點，也不保證注冊資訊是否replicate成功
當資料出現不一緻時，雖然A, B上的注冊資訊不完全相同，但每個Eureka節點依然能夠正常對外提供服務，這會出現查詢服務資訊時如果請求A查不到，但請求B就能查到。如此保證了可用性但犧牲了一緻性。
Consul 的調用過程
1、當 Producer 啟動的時候，會向 Consul 發送一個 post 請求，告訴 Consul 自己的 IP 和 Port；
2、Consul 接收到 Producer 的注冊後，每隔 10s（預設）會向 Producer 發送一個健康檢查的請求，檢驗 Producer 是否健康；
3、當 Consumer 發送 GET 方式請求 /api/address 到 Producer 時，會先從 Consul 中拿到一個存儲服務 IP 和 Port 的臨時表，從表中拿到 Producer 的 IP 和 Port 後再發送 GET 方式請求 /api/address；
4、該臨時表每隔 10s 會更新，隻包含有通過了健康檢查的 Producer。
Spring Cloud Consul 項目是針對 Consul 的服務治理實作。Consul 是一個分布式高可用的系統，它包含多個元件，但是作為一個整體，在微服務架構中，為我們的基礎設施提供服務發現和服務配置的工具。
consul內建部署
官網位址連結：可參考相關官方文檔
基礎環境
基礎環境是在Linux centos7.7的基礎環境中進行叢集部署，基礎系統架構為x86_64
[[email protected] ~]# hostname -I
10.252.68.158
[[email protected] ~]# uname -m
x86_64
[[email protected] ~]# cat /etc/redhat-release
CentOS Linux release 7.7.1908 (Core)
IP位址規劃
| IP | 部署節點規劃 | 主機名稱 |
|---|---|---|
| 10.252.68.156 | devops-consul-server01 | hmsc-dev-1-nginx-web |
| 10.252.68.157 | devops-consul-server02 | hmsc-dev-1-db |
| 10.252.68.158 | devops-consul-server03 | hmsc-dev-1-fdfs |
部署安裝
下載下傳源碼
官網下載下傳連結
consul_1.8.0_linux_amd64.zip下載下傳
這裡可以在需要部署的三台機器都下載下傳最新版本的源碼壓縮包consul_1.8.0_linux_amd64.zip
這裡以10.252.68.156機器為例。其他2台機器都一樣的操作
[[email protected] ~]# cd /usr/local/src/
[[email protected] src]# wget https://releases.hashicorp.com/consul/1.8.0/consul_1.8.0_linux_amd64.zip
[[email protected] src]# unzip consul_1.8.0_linux_amd64.zip -d /usr/local/consul
Archive: consul_1.8.0_linux_amd64.zip
inflating: /usr/local/consul/consul
[[email protected] src]# cd /usr/local/consul/
[[email protected] consul]# ll
total 111004
-rwxr-xr-x 1 root root 113666152 Jun 19 02:29 consul
配置環境變量
[[email protected] consul]# echo "export PATH=$PATH:/usr/local/consul" >> /etc/profile
[[email protected] consul]# . /etc/profile
上述的操作需要在部署叢集的機器中全部執行一次
啟動叢集節點
consul agent有兩種運作模式：server和client。這裡的server和client隻是consul叢集層面的區分，與搭建在cluster之上的應用服務無關。
以server模式運作的consul agent節點用于維護consul叢集的狀态，
官方建議每個consul cluster至少有3個或以上的運作在server mode的agent，client節點不限。
我們這裡以安裝三個節點為例
[[email protected] ~]# consul agent -server -data-dir=/tmp/consul -node=server-1 -bind=10.252.68.156 -bootstrap-expect 3 -client=0.0.0.0 -ui &
[[email protected] ~]# consul agent -server -data-dir=/tmp/consul -node=server-2 -bind=10.252.68.157 -join=10.252.68.156 -client=0.0.0.0 -ui &
[[email protected] ~]# consul agent -server -data-dir=/tmp/consul -node=server-3 -bind=10.252.68.158 -join=10.252.68.156 -client=0.0.0.0 -ui &
選項詳解
consul配置參數大全、詳解、總結
| 選項 | 說明 |
|---|---|
| consul anent | 該指令會啟動一個consulAnent |
| -server | 表示該 agent是一個 serverAgent,不添加這個選項則表示是一個 clientAgent |
| -data-dir | 表示相關資料存儲的目錄位置，在 serverAgent上該指令所訓示的目錄下會存儲一些叢集的狀态資訊 |
| -node | 指定該 agent 節點的名稱，該名稱在叢集衆必須是唯一的 |
| -bind | 指定 agent 的 Ip |
| -bootstrap-expect | 該指令通知 consul 準備加入叢集的節點個數 |
| -client 0.0.0.0 -ui | 啟動 consulUI，如不添加該指令，則 UI 隻能在目前機器上通路 |
| -join | 将該節點加入叢集中 |
驗證
驗證叢集是否搭建成功，執行consul members，在任意的一台機器上：
[[email protected] ~]# consul members
Node Address Status Type Build Protocol DC Segment
server-1 10.252.68.156:8301 alive server 1.8.0 2 dc1 <all>
server-2 10.252.68.157:8301 alive server 1.8.0 2 dc1 <all>
server-3 10.252.68.158:8301 alive server 1.8.0 2 dc1 <all>
通過URL驗證