服务发现之Consul

consul是一个可以提供服务发现，健康检查，多数据中心，Key/Value存储等功能的分布式服务框架

用于实现分布式系统的服务发现与配置。与其他分布式服务注册与发现的方案，Consul的方案更”一站式”，内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value存储、多数据中心方案，不再需要依赖其他工具（比如ZooKeeper等）。使用起来也较为简单。Consul用Golang实现，因此具有天然可移植性(支持Linux、Windows和Mac OS X)；安装包仅包含一个可执行文件，方便部署，与Docker等轻量级容器可无缝配合。

Consul 的使用场景

docker 实例的注册与配置共享
coreos 实例的注册与配置共享
vitess 集群
SaaS 应用的配置共享
与 confd 服务集成，动态生成 nginx 和 haproxy 配置文件

Consul 的优势

使用 Raft 算法来保证一致性, 比复杂的 Paxos 算法更直接. 相比较而言, zookeeper 采用的是 Paxos, 而 etcd 使用的则是 Raft.
支持多数据中心，内外网的服务采用不同的端口进行监听。多数据中心集群可以避免单数据中心的单点故障,而其部署则需要考虑网络延迟, 分片等情况等. zookeeper 和 etcd 均不提供多数据中心功能的支持.
支持健康检查. etcd 不提供此功能.
支持 http 和 dns 协议接口. zookeeper 的集成较为复杂, etcd 只支持 http 协议.
官方提供web管理界面, etcd 无此功能.

综合比较, Consul 作为服务注册和配置管理的新星, 比较值得关注和研究.

Consul 的角色

client: 客户端, 无状态, 将 HTTP 和 DNS 接口请求转发给局域网内的服务端集群.
server: 服务端, 保存配置信息, 高可用集群, 在局域网内与本地客户端通讯, 通过广域网与其他数据中心通讯. 每个数据中心的 server 数量推荐为 3 个或是 5 个.

Consul 基础组件

Agent: 在consul集群上每个节点运行的后台进程，在服务端模式和客户端模式都需要运行该进程。
client: 客户端是无状态的，负责把RPC请求转发给服务端，占用资源和带宽比较少
server: 维持集群状态，相应rpc请求，选举算法
Datacenter：数据中心，支持多个数据中心
Consensus：一致性协议
Gossip protocol： consul是基于Serf, Serf为成员规则，失败检测，节点通信提供了一套协议，
LAN Gossip：在同一个局域网或者数据中心中所有的节点

Refers to the LAN gossip pool which contains nodes that are all located on the same local area network or datacenter.
Server和Client。客户端不存储配置数据，官方建议每个Consul Cluster至少有3个或5个运行在Server模式的Agent，Client节点不限，如下图

支持多个数据中心，上图有两个数据中心
每个数据中心一般有3-5个服务器，服务器数目要在可用性和性能上进行平衡，客户端数量没有限制。分布在不同的物理机上
一个集群中的所有节点都添加到 gossip protocol（通过这个协议进行成员管理和信息广播）中， a客户端不用知道服务地址， b节点失败检测是分布式的，不用只在服务端完成；c
数据中心的所有服务端节点组成一个raft集合，他们会选举出一个leader，leader服务所有的请求和事务，如果非leader收到请求，会转发给leader. leader通过一致性协议（consensus protocol），把所有的改变同步(复制)给非leader.
所有数据中心的服务器组成了一个WAN gossip pool，他存在目的就是使数据中心可以相互交流，增加一个数据中心就是加入一个WAN gossip pool，
当一个服务端节点收到其他数据中心的请求，会转发给对应数据中心的服务端。