Consul 架构简介
Consul 是一款不错的服务注册与发现工具。
Consul 架构图：
图片上 datacenter 分成上下两个部分， 但是这两个部分又不是完全隔离的。他们之间通过 WAN GOSSIP 进行报文交互。
单个 datacenter 中， 节点被划分成两种颜色， 红色的 server, 紫色的 client, 他们之间通过 GRPC 进行通信(业务数据）， 除此之外， Client 和 Server 之间通过还有一条 LAN Gosssip 进行通信，比如，当 Server 节点增加，或者 down 机后，Client 可以获取对应的 Server列表，去除或者增加 Server 列表。
同一个 Consul agent 程序，启动的时候，通过制定不同的参数来运行 Server 和 Client 模式。也就是说 client 和 server 本质上都是 Client Agent
Server:
- 参与共识仲裁（raft）
- 存储机器状态(日志存储）
- 处理查询
- 维护周边（LAN/WAN) 节点之间的关系
Client :
- 负责通过该节点注册到 Consul 微服务的健康检查
- 将客户端的注册请求和查询转换为 server 的 RPC 请求
- 维护周边各节点（LAN/WAN) 的关系
Client-Server 模式
架构图：
目前 Consul 的架构全部升级为 client-Server 模式，服务注册不再向 consul-Server进行注册，而是向服务所在机器的 consul-client 进行注册，通过 Consul-Client 将注册信息同步到 Consul-Server 机器中。
纯 Server 模式
Zookeeper 就是这种模，client server 本质上都是 consul 的 agent, 只是角色不同。
纯 server 模式的架构图：
纯 server 模式架构的问题
- 高可用 服务实例注册时配置的 consul-host 是负载均衡地址，服务注册到集群后，由集群中的一个节点负责对该实例进行健康检查。假如有这样的情况，服务A，服务B，都注册到 Service1 ，也就是由 Service1 对 服务A，服务B 进行健康检查，当 Service1 宕机时，这样会导致 服务A，服务B 在注册列表中消失，导致无法无法访问到，但是其实服务本身没有问题。
- 服务注销 当服务从注册中心注销时，由于是负载均衡的，可能会导致服务注销失败，因为要在Service1 上注销，有可能负载均衡到 Service2 上进行注销，导致注销失败，解决的办法是遍历集群中所有节点进行注销。
Client-Server 架构呢？
- 高可用 服务实例向本级别 consul-client 进行注册，如果 consul-client 不可用，只影响 consul-client 所在机器的服务实例，不影响另外一台机器上的实例。
- 服务注销 服务注销值需要在 consul-client 上进行注销，不需要经过负载均衡。
基于 Client-Server架构服务注册时序图
服务端口
实现原理
核心原理在于亮点：
- 集群信息之间的高效同步机制，保障拓扑变动与控制信号的及时同步
- server 集群内日志存储的强一致性。
他们主要基于两个协议来实现
- Gossip 协议，在集群内消息传递
- 使用 raft 协议保障日志的一致性。
