Consul是由HashiCorp基于Go语言开发的，用于微服务下的服务治理，采用Raft算法保证服务的一致性，采用主从模式的设计可横向扩展，集群间通过RPC调用(HTTP和DNS)。
Consul主要特点：服务发现、健康检查、Key/Value存储、安全服务通信、多数据中心。
Consul的应用场景：服务发现、服务隔离、服务配置。
架构介绍
- Client：是一个无状态代理，负责转发数据请求到Server和健康检查。
- Follower-Server：参与Raft选举、维护集群状态、响应RPC查询并转发给Leader-Server等。
- Leader-Server：一个数据中心只有一个Leader。Leader-Server负责所有的查询和事务(如服务注册)，同时这些事务也会被复制到所有其他的节点。
- DataCenter：数据中心是一个私有的网络环境，通过WAN GOSSIP在Internet上交互。每个数据中心都存在Consul集群，为了提高通信效率，只有Server节点才加入跨数据中心的通信。
服务器状态
- 领导者（Leader）：领导者处理所有客户端的交互以及日志的复制同步，在任何时候只能有一个领导者。
- 跟随者（Follower）：完全被动，不会主动发起任何RPC调用，只能对其他服务器发起的RPC调用做出响应。
- 候选者（Candidate）：是处于领导者（Leader）与跟随者（Follower）之间的一种状态，只在选举新领导者的过程中临时出现。
Raft算法
Raft通过选举出一个Leader，接受所有请求并将变更同步给其他Follower，从而达到一致的系统。当Leader无法正常提供服务时启动崩溃恢复流程进行重新选举，新Leader将数据同步给到Follower。
Follower节点选举时会将自己的状态切换为Candidate，然后向集群中其它Follower节点发送请求，询问其是否选举自己成为Leader。当收到来自集群中过半数节点的接受投票后，节点即成为Leader，开始接收Client的事务处理和查询并向其它的Follower节点同步事务。Leader节点会定时向Follower发送心跳来保持其地位。
Gossip协议
Gossip协议是为了解决分布式环境下监控和事件通知的瓶颈。Gossip协议中的每个Agent会利用Gossip协议互相检查在线状态，分担了服务器节点的心跳压力，通过Gossip广播的方式发送消息。
所有的Agent都运行着Gossip协议。服务器节点和普通Agent都会加入这个Gossip集群，收发Gossip消息。每隔一段时间，每个节点都会随机选择几个节点发送Gossip消息，其他节点会再次随机选择其他几个节点接力发送消息。这样一段时间过后，整个集群都能收到这条消息。
基于Raft算法，Consul提供强一致性的注册中心服务，但是由于Leader节点承担了所有的处理工作，势必加大了注册和发现的代价，降低了服务的可用性。通过Gossip协议，Consul可以很好地监控Consul集群的运行，同时可以方便通知各类事件，如Leader选择发生、Server地址变更等。
ps：Agent是Consul中的核心程序，它将以守护进程的方式在各个节点运行，有Client和Server启动模式。每个Agent维护一套服务和注册发现以及健康信息。