Consul 架构
此篇文章主要对consul的相关内部技术细节进行简要概述。
»术语
- 代理 - 代理是指consul集群中运行的consul实例，通过执行
consul agent 命令来启动. 代理可以运行于客户端或者服务端。通过执行DNS或者HTTP接口来执行健康检查和服务同步。 - 客户节点 - 客户节点负责将向服务节点发送RPC请求，相对来说是无状态的.。客户节点唯一要执行的后台活动是参与LAN gossip pool。当然这只会消耗很少的资源和网络带宽。
- 服务节点 - 服务节点主要职责包括参与Raft算法，维护集群状态，处理RPC查询，和其它的数据中心交换WLAN gossip及向领导者或者远程数据中心转发查询请求。
- 数据中心 – …
- 维护一致性- 包括领导者选举及事务执行顺序方面的一致性。
- Gossip - Consul是建立在Serf之上的，支持全部的gossip protocol（节点间随机通信，主要通过UDP）。Serf 提供关系管理, 失败检测及事件分发功能. Consul gossip应用详情可以访问连接gossip documentation。
- LAN Gossip - 本地局域网或数据中心节点间Gossip应用.
- WAN Gossip – WAN 范围（不同数据中心，主要通过internet或者wan通信）内服务器节点间Gossip应用。
- RPC - 远程过程调用，请求/回复机制。
»基本架构
如上图所示，Consul先天支持多数据中心应用：multiple datacenters 。
数据中心中包含客户节点和服务节点，通常建议三到五个服务节点。因为随着节点的增加，服务同步会变得相对更慢，同时考虑到服务失败和性能要求等方面因素。但是对于客户节点数量，则没有限制。
数据中心中的所有节点都会参数gossip protocol. 也就是说包括数据中心中所有的节点。这样做有几个目的，首先, 无需给客户节点配置服务节点地址，就可以自动发现。其次，失效节点检测是分布式的，相对于心跳检测模式更具伸缩性。最后，事件分发是以消息模式分发处理的。
节点之间利用Raft协议选举领导者，领导者负责处理所有的查询和事务请求。同时根据Gossip协议，事务请求需要分发到所有的协议节点。所有当一个非领导者服务节点收到一个Rpc请求时，它会将其转发至集群领导者进行后续处理。
服务节点同时也是WAN gossip pool的一部分。相对于LAN pool，WAN pool是专门为高延迟因特网而优化使用的，它只包含服务节点，提供数据中心之间低接触式发现机制。它支持跨数据中心请求，当一个数据中心接到请求其它数据中心数据的请求时，它会将其转发至目标数据中心中随机的一个服务节点。
由此，大大的降低了数据中心的耦合度。但是，因为有相应的失败检测，连接缓存和复用，数据中心之间的交互也相对快捷可靠。
通常来说，数据中心之间是不进行数据交换的，当一个数据中心接收到一个请求其它数据中心资源的请求时，它会将其进行转发，由相应的数据中心进行处理。当目标数据中心不可用，也就意味着所请求的资源不可用。但也有一些特俗情况，会造成数据的分发，如，consul的内置ACL replication功能，及其它相关的外部工具。
一致性模型：
默认（特定的旧leader的时间窗口内，旧leader处理读请求）：Raft使用leader leasing，提供一个时间窗口，这个时间内，leader假定他的leader角色是稳定的。然而，如果这个leader和余下的节点分隔开。在旧leader持有时间窗口的同时，集群就会选出一个新的leader。这就意味着，集群有两个leader节点。发生裂闹现象并没有风险，因为旧leader不能提交新的条目。然而，对于只读请求，旧leader很大可能性上会返回过期数据。默认的一致性模型依赖于leader leasing，客户端有可能会获取到过期的数据的风险。我们之所以做这种妥协是因为，只读请求通常很快，并且是强一致性的。只会在hard-to-trigger情况下会返回过期数据。会返回过期数据的时间窗口长度也是有限的，因为旧的leader会因为分裂的发生降级。
一致性（consistent）：强一致性模型，这个模型需要leader处理读请求钱，通过询问quorum检查自己的leader合法性，因此增加了一轮RPCs，好处是，读请求的一致性，但是却增加了延迟。
过期（stale）：这种模型，允许所有的节点处理客户端的读请求。无论是否是leader节点。这就意味着读取过期数据更加普遍，但是也仅仅是在leader的最小超时时间50ms内。好处是，处理只读请求块，适用于大规模请求，但是伴随着普遍的过期数据。模型在没有leader的情况下依然可以处理来此客户端的读请求。
Consul Agent：
consul agent是consul的核心，负责维护成员关系信息，注册服务，运行健康检查，提供查询等。每个集群的节点都需要部署consul agent。
两种模式：client，server。相较于client，serer模式agent，参与Raft一致性算法。负责提供，保持集群的强一致性及可用性。server agent和数据及系统资源有更多的交互，因此需要运行在专用的节点上。client agent则比较轻量，大多数操作只需要请求server agent去完成，只需要维护相对很少的状态。
D:consul>consul agent -server -bootstrap-expect=1 -data-dir=data -node=server0 -bind=127.0.0.1 -client 0.0.0.0 -ui
BootstrapExpect is set to 1; this is the same as Bootstrap mode.
bootstrap = true: do not enable unless necessary
==> Starting Consul agent...
==> Consul agent running!
Version: 'v1.0.2'
Node ID: '1ad0d5d0-80df-29ed-e795-ce50bfd70f2f' //节点唯一ID
Node name: 'server0' //节点名称，默认为机器的主机名，可以通过 -node 进行设置
Datacenter: 'dc1' (Segment: '<all>') //所在数据中心，单数据中心默认为dc1，可以通过 -datacenter 设置。
Server: true (Bootstrap: true) //运行模式，
Client Addr: [0.0.0.0] (HTTP: 8500, HTTPS: -1, DNS: 8600) // 客户端地址，服务于HTTP DNS接口，默认绑定localhost
Cluster Addr: 127.0.0.1 (LAN: 8301, WAN: 8302) // 和集群内成员通信的地址和端口，LAN WAN
Encrypt: Gossip: false, TLS-Outgoing: false, TLS-Incoming: false
==> Log data will now stream in as it occurs:
停止：
gracefully：ctrl-c 和 kill -INT。agent告知集群自己将要离开集群。建议
forcefully：kill -9 立即停止实例，集群通过失败检测发现
生命周期：
节点启动
=》join命令，或者通过配置，加入集群
=》成员变更信息通过gossip协议传播到集群其它成员，最终所有其它成员都将获悉节点的加入
=》如果是server 节点，则其它服务几点将进行日志复制
=》如果发生网络问题，节点信息无法获悉（无论是因为网络问题无法通讯还是节点宕机）。则失联节点标记为失效，其它节点更新集群成员信息
=》节点离开，则集群标记节点状态为“已离开”，区别于节点失败（所有节点上注册的服务会立即被注销），如果是server节点，则复制过程停止
=》为了防止死节点信息的堆积，consul会自动将这些信息从成员信息列表中移除，称之为收割。目前配置的时间隔72小时执行一次，当此时，类似于节点失败，移除的节点信息上注册的服务会被注销。
