Consul集群Server+Client模式

架構示意圖

只使用Consul的Server模式有以下2個問題：

• 因為Consul Server數量受到控制所以壓力承載（擴展性）是個問題。
• Server很少導致一個Server下會注冊很多微服務，當Server掛掉，這個Server節點下注冊的微服務都會視為無效。

基於上述問題我們在架構中加入Consul Client模式，Client因為加入了LAN gossip協議組成網絡中（高速局域網），可以識別故障的Server節點並找到可用的Server節點繼續工作，其實Server模式負責的是用WAN gossip協議組成的網絡進行跨廣域網的數據同步（多個數據中心），這點Client模式是做不到的，Client模式也提供服務的注冊和查詢，但Client模式不存儲節點數據，Client將請求轉發給Server進行處理，節點注冊數據在Server端是持久化保存的，Client的數量可以無限多，Server的數量是受控制的。總之：Client模式+LAN gossip協議組成了一個數據中心中的各個節點，Server負責投票選出Leader進行數據中心內的數據同步，這個Leader還負責利用WAN gossip協議跨廣域網的與其他數據中心進行數據同步。
PS：在Client注冊的服務心跳監控檢查由Client負責。

搭建環境

獲得Docker鏡像（bluersw/spring-cloud-consul-consumer 是服務消費者鏡像里面運行的程序項目叫spring-cloud-consul-client，因為名字的起的不講究導致了混亂，spring-cloud-consul-client不是Consul Client。）：

docker pull consul
docker pull bluersw/spring-cloud-consul-consumer:cc
docker pull bluersw/spring-cloud-provider:cc
docker pull bluersw/spring-cloud-provider:cc
docker pull bluersw/spring-cloud-provider-second:cc

啟動Consul Server(Windows版本的Docker運行命令時參數的IP地址要用"ip地址",比如：-client="0.0.0.0")：

docker run -i -t -p 8500:8500 --name=ConsulServer-C consul agent -server -ui -node=Server-C -bootstrap-expect=3 -client=0.0.0.0

docker run -i -t -p 8501:8500 --name=ConsulServer-A consul agent -server -ui -node=Server-A -bootstrap-expect=3 -client=0.0.0.0 -join=172.17.0.2

docker run -i -t -p 8502:8500 --name=ConsulServer-B consul agent -server -ui -node=Server-B -bootstrap-expect=3 -client=0.0.0.0 -join=172.17.0.2

啟動spring-cloud-provider：

docker run --name=spring-cloud-provider  -d  -p 9001:9001 bluersw/spring-cloud-provider:cc /opt/consul/./consul agent -data-dir=/opt/consul/data -config-dir=/opt/consul/config -node=privider-cc  -join 172.17.0.3

在啟動此Docker的同時運行Consul Client模式，並加入Consul Server A（加入那個Consul Server都可以）,TAG為CC的鏡像文件里已經包含了Consul程序。

spring-cloud-provider的配置文件內容：

spring.application.name=spring-cloud-provider-01
server.port=9001
spring.cloud.consul.host=127.0.0.1
spring.cloud.consul.port=8500
#注冊到consul的服務名稱
spring.cloud.consul.discovery.serviceName=service-provider
#以下兩項如果不配置健康檢查一定失敗
spring.cloud.consul.discovery.prefer-ip-address=true
spring.cloud.consul.discovery.health-check-path=/actuator/health

配置中的注冊服務地址已經改成了127.0.0.1，其他服務項目的配置文件都改成了在本機的Consul Client中注冊。
啟動服務：

docker exec  spring-cloud-provider /usr/local/java/bin/java -jar /opt/spring-cloud-provider-0.0.1-SNAPSHOT.jar

service-provider服務在privider-cc節點被注冊成功。

用同樣的方法啟動spring-cloud-provider-second和spring-cloud-consul-consumer。

docker run --name=spring-cloud-provider-second -d -p 9002:9002 bluersw/spring-cloud-provider-second:cc  /opt/consul/./consul agent -data-dir=/opt/consul/data -config-dir=/opt/consul/config -node=provider-second-cc  -join 172.17.0.4

docker exec  spring-cloud-provider-second /usr/local/java/bin/java -jar /opt/spring-cloud-provider-second-0.0.1-SNAPSHOT.jar

docker run --name=spring-cloud-consul-consumer -d -p 9003:9003 bluersw/spring-cloud-consul-consumer:cc /opt/consul/./consul agent -data-dir=/opt/consul/data -config-dir=/opt/consul/config -node=consumer-cc  -join 172.17.0.2

docker exec  spring-cloud-consul-consumer /usr/local/java/bin/java -jar /opt/spring-cloud-consul-client-0.0.1-SNAPSHOT.jar

模擬服務器故障

關閉Consul Server B：

因為service-provider在本機的Consul Client中注冊，並Client可以利用LAN gossip協議找到可用的Server，所以關閉Consul Server B絲毫造成不了影響,如果Client或者服務本身掛掉了，那么Server端會將此節點或服務標記故障並不再使用，請求者就請求不到這個故障的節點了,同樣的修復故障節點后所有服務和功能恢復如初。

源碼

Github倉庫:https://github.com/sunweisheng/spring-cloud-example