Consul集群Server模式

架构示意图

Consul在生产环境下运行模式分为两种：Server模式和Client模式（dev模式属于开发模式不在这里讨论），我们先用Server模式搭建一个Consul集群,示意图如下：

Consul Server A、B、C是启动的三个Consul服务运行于Server模式下，其中Consul Server C 是“总指挥”，他们的Leader，Consul Server A和B是Follower当“替补”，他们都可以提供注册和查询微服务器的功能。Leader负责给其他Follower同步数据和监控各个节点的健康，Leader是由他们仨根据Raft一致性算法选举出来的，Server模式运行的Consul服务不能太多，推荐3或5个，因为太多开会选举性能不佳，并且个数要求是奇数（选举算法要求）。

spring-cloud-provider是模拟的服务提供者程序，spring-cloud-provider-second也是模式的服务提供者程序只是返回内容上不太一样（便于区分是哪个服务返回），他们都在Consul中注册同一个服务名称：service-provider，spring-cloud-consul-consumer是模拟服务消费者程序，负责使用service-provider服务。

搭建环境

为了测试方便我们使用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:v1

docker pull bluersw/spring-cloud-provider:v1

docker pull bluersw/spring-cloud-provider-second:v1

启动Consul脚本(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

bootstrap-expect是指最少几个Server模式下的Consul服务，整个集群才启动。

join=172.17.0.2这个地址就是Server-C的IP地址，Server-C是Leader。

启动后查看127.0.0.1:8500端口查看后台：

然后启动消费者和生产者docker：

docker run -t -i --name=spring-cloud-provider  -p 9001:9001 bluersw/spring-cloud-provider:v1

source /etc/profile

cd /opt

java -jar spring-cloud-provider-0.0.1-SNAPSHOT.jar

docker run -t -i --name=spring-cloud-provider-second  -p 9002:9002 bluersw/spring-cloud-provider-second:v1

source /etc/profile

cd /opt

java -jar spring-cloud-provider-second-0.0.1-SNAPSHOT.jar

docker run -t -i --name=spring-cloud-consul-consumer  -p 9003:9003 bluersw/spring-cloud-consul-consumer:v1

source /etc/profile

cd /opt

java -jar spring-cloud-consul-client-0.0.1-SNAPSHOT.jar

注册服务示例：

spring.application.name=spring-cloud-provider-01

server.port=9001

#172.17.0.3是Server-A

spring.cloud.consul.host=172.17.0.3

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

spring.application.name=spring-cloud-provider-02

server.port=9002

#172.17.0.4是Server-B

spring.cloud.consul.host=172.17.0.4

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

启动后Docker容器内容：

service-provider服务已经注册完毕：

访问127.0.0.1:9003/TestHello 测试部署结果：

模拟服务器故障

关闭Consul Server B

Consul Server B 已经不能访问：

从Leader上看Server-B节点已经故障：

从Leader上看服务service-provider的注册节点检查已经出现红叉：

因为Consul处理机制consul节点故障其中注册的服务都视为不可用，所以spring-cloud-provider-second服务虽然没有出问题，但已经不再被轮询到，两次访问都是访问的spring-cloud-provider服务。

恢复Consul Server B

重新启动Consul Server B后，一切自动恢复：

关闭Consul Server C

因为关闭Consul Server C是Leader，所以Consul Server C被关闭之后，Leader被Consul Server B接管：

此时如果spring-cloud-consul-consumer程序不重新启动，那么因为其保留着上次查询服务的缓存所以还可以继续显示正常：

如果重新启动因为找不到注册服务的Consul Server C会在访问时发生异常：

恢复Consul Server C

Consul Server C之后，Leader仍然是Consul Server B

相关服务恢复正常，由上面的测试可以知道Consul大致的故障处理策略：

源码

Github仓库:https://github.com/sunweisheng/spring-cloud-example