是什么
Consul 是一个分布式、高可用的数据中心解决方案，可在动态、分布式的基础设施上连接和配置应用程序，由HashiCorp公司推出的开源项目。github.com/hashicorp/c… www.consul.io/，Consul使用go…
consul 提供了多种基础能力，包括：
- 多数据中心（Multi-Datacenter） - Consul 就是用来构建数据中心的，通过很简单的配置就可以支持多region。
- 安全服务通信（Secure Service Communication） - 生成并分发TLS认证来建立相互的TLS连接。提供了ACL能力（在consul中叫intentions）来定义服务间的访问授权。可以更实时的intentions来管理微服务，而不是使用复杂的网络拓扑和静态的防火墙规则。
- 服务发现 （ Service Discovery ）- 使“服务”注册自己和通过DNS和HTTP接口发现其他“服务”变得很简单，外部的服务例如saas提供者也同样可以注册。
- 健康检查（Health Checking） - 健康检查使consul可以快速的发现和报告集群中的任意问题(例如5xx错误、机器内存/cpu利用率达到了xx%)。将健康检查和服务发现集成起来可以防止将流量路由到不健康的实例并且可以启用服务级别的断路器（circuit breakers）。
- 键值存储（Key/Value Storage） - 灵活的键值存储可以用来存储动态的配置、特性(feature)标识、协调信息、选主等。使用简单的http api就能在任意地方应用。
CAP定理
1998年，加州大学的计算机科学家 Eric Brewer 提出，分布式系统有三个指标
Consistency 一致性
Availability 可用性
Partition tolerance 分区容错性
但是这三个指标不能同时满足，因为这三个指标的首字母分别是C、A、P，所以也叫CAP定理。
Partition tolerance
大多数的分布式系统内都是有多个子网络。每个子网络就叫做一个分区（Partition）。Partition tolerance 的中文翻译是分区容错，分区容错的意思就是分区间的通信是可能失败的，比如在分布式系统中位于A城市和B城市的服务器就有可能会因为网络问题无法通信。
一般来说，分区容错是无法避免的（非一般情况下，量子通信？），因此可以认为CAP中的P总是成立的，所以依据CAP定理，剩下的C和A是无法同时做到的。
Consistency
Consistency，中文翻译是一致性，一致性的意思是，写操作之后的读操作，都是必须观测到该写操作（和golang memory model里的happen before原则很像）。通俗一点就是写某值后，后续都应该读到该值。
如上图，A和B是分布式系统中的两个节点，所以当client写a=hello，如果client再从b去读a，读到的值如果是hello，那么这个分布式系统就是consistency的。为了做到这一点，这就需要node A和node B之间需要有数据同步机制。
Availability
Availability的翻译是“可用性”，意思是只要收到用户的请求，分布式系统必须给出回应。用户可以选择向A或B发起读操作，不管是哪个node，只要收到请求，必须响应对应的值，否则就不满足可用性。
AP or CP?
分布式系统一定会存在网络问题，所以P（分区容错）一定是成立的。所以能满足的只有CP和AP两种条件。而为什么说C和A无法同时满足？
因为如果要保持A的一致性，那么必须在写B时，对A的读写操作进行锁定，等到数据从B同步到A时再开放读写，而这期间对A的读写操作都会失败，也就不满足可用性。两者一定是互斥的。所以A和C无法同时做到满足，也就是说分布式系统只存在CP和AP两种选择。
相对于可用性，consul更偏爱一致性，所以consul选择的就是CP，也就是保持强一致性和分区容错性。保证强一致性带来的后果就是服务注册（数据写入）相对来说慢一点，consul的raft协议要求必须过半数的节点都写入成功才认为服务注册成功。例如当consul的learder挂掉时，重新选举期间整个consul都是不可用的，在保证强一致性的同时也牺牲掉了可用性。
架构
分布式协议
Raft
共识(Consensus)就是一个cluster的各个节点通过顺序的事务来达成一致的选主决策，也就是通俗一点的一致性协议。由于这些事务可以被定义为FST（有限状态自动机），所以共识的实现其实就是复制状态机。
consul的一致性协议由Raft保证，在故障的情况下依然能提供强大的一致性和可用性。
Gossip
gossip 协议（gossip protocol）又称 epidemic 协议（epidemic protocol），是基于流行病传播方式的节点或者进程之间信息交换的协议，在分布式系统中被广泛使用，比如我们可以使用 gossip 协议来确保网络中所有节点的数据一样。
Agent
ageent负责维护成员信息，注册服务，执行check，响应查询等等。在cluster上的每一个节点上都必须有一个runing状态的agent。一个agent就是一个在consul cluster上每一个节点上持续运行的守护进程，通过consul agent命令来启动一个agent。Consul Agent包含两种模式，分别是client agent和server agent。
Client
客户端，无/低状态的agent，负责将HTTP和DNS请求转发给局域网内的服务端集群，是一个cluster的主要组成部分。client agent负责与server agent进行交互，并且维护自身的一小部分状态。client agent的数量没有限制，可以轻松的扩展到成千上万个节点，一般来说，每一台物理机(服务)上都会有一个consul client agent。本物理机的各个服务的服务注册和服务发现。
Server
服务端，有状态，保存配置信息，server agent构成了高可用集群。一般来说，每个数据中心的server的数量推荐为3个或者5个（raft协议要求半数以上的节点选主，所以这也是为什么节点的数量一般推荐是奇数个），这也是可用性和性能的一个权衡点，因为当server的实例过多时，为了维护强一致性的成本就会非常高。除了核心的agent操作，每一个server节点都参与共识决策（consensus quorum）。与client节点一般以proxy形式去部署到业务节点上不同的是，server节点应该在专有实例上运行，因为他们相对于客户端节点对各项资源的开销更密集。
Lifecycle
中文为生命周期，每一个节点都经过了lifecycle。了解生命周期对于构建agent与cluster交互模型是非常有帮助的以及集群是如何处理节点。以下描述了在已存在的cluster上，一个agent的生命周期。
- 启动1个agent， 无论是手动或者自动化的编排过程，新启动的节点是感知不到该集群内其他节点的信息的。
- 这个anget加入cluster， 这使得agent能够发现彼此。手动执行join命令或者符合自动join的配置时，agent会在启动时自动加入到集群。
- 将这个agent的信息gossiped到整个已知集群， 结果，该节点会跟所有节点互相感知到。
- 已存在的server开始将信息复制到新的节点， 如果这是一个server agent。
