注册中心Consul产线部署架构

一、Consul官方架构图和说明

Consul 提供了高可用的kv存储，集群架构，这点和etcd zookeeper相似。 另外也提供了自动服务发现注册的套件，而且可否对服务进行健康检查。 结合consul-template能够实现服务提供方信息更新(好比增长了API服务器)时，自动生成配置文件给服务使用方自动更新配置。

从图中可看到的是Consul支持跨数据中心，在每一个数据中心有client和server。通常server是3-5个，少了会影响可靠性，多了会影响速度。client则没有数量的限制。

集群经过goosip协议管理全部node成员和广播集群消息，client须要配置文件就能发现急群众全部的server，节点故障检测被分不到整个集群，不须要server的参与。全部server经过Raft协议进行选主(leader), leader负责处理全部的查询和事务。

server还负责与其余数据中心交互来处理跨数据中心的请求，当server收到这种请求它会将请求转发到相应的数据中心活本地的leader。

二、纯Server模式

client和server本质都是consul的agent，只是角色不一样（在启动时指定参数便可）。以前咱们产线环境并无彻底按照官方架构图（即client-server模式）进行部署，而是采用了所有server的模式，以下图：

三、纯Server模式带来的问题

这种架构下带来的问题有两个：

1. 高可用
   服务实例注册时配置的consul-host是负载均衡的地址，服务注册到集群中后，由集群中的一个节点负责对该实例进行健康检查。假如存在一下状况：（1）某个服务有两个节点实例，这两个节点经过负载均衡进行注册后都由server1进行健康检查（2）server1节点不可用（多是server1挂了，也多是server1所在机器出现问题）。这样就会致使服务在注册中心中消失致使服务没法访问到，而服务自己并不存在问题。
2. 服务注销
   由于集群中的某一个节点（好比server1）负责服务的健康检查，在服务从注册中心注销时，经过负责均衡注销时的代码以下：

ConsulClient client = new ConsulClient("负载均衡地址");
client.agentServiceDeregister("当前服务在注册中心的Id");
复制代码

因为负载均衡，注销时定位到的集群节点多是server2，这样就会致使服务的注销失败。解决的办法是遍历集群中的全部节点（members）进行注销，具体可参考：使用Consul时，服务没法正常注销

四、用Client-Server模式

目前consul的总体架构升级为client-server模式，服务注册时再也不向consul-server集群进行注册，而是向服务所在机器的consul-client进行注册，有consul-client将注册信息同步到consul-server集群中，架构以下：

回顾以上两个问题：

1. 高可用
   服务实例注册时向本级consul-client进行注册，若是consul-client不可用，只影响这个consul-client所在机器的全部服务实例（若是机器挂了则全部这台机器上的实例不能访问就很合理）。由于服务实例自己的高可用会分布在不一样的机器上，因此不会影响另一台机器上的实例（不要把鸡蛋放在一个篮子里）。

注意：consul-client挂了，服务的注册信息不会转移到另一个consul-client中。因此要求服务自己处于不一样的机器上来保证高可用。

2. 服务注销
   服务从注册中心注销时，只须要链接到本地的consul-client进行注销便可，一台机器就一个consul-client，不须要通过负载均衡：

ConsulClient client = new ConsulClient("local-consul-client-ip");
client.agentServiceDeregister("当前服务在注册中心的Id");
复制代码