Consul实现原理系列文章3: Consul的整体架构

术语表

1. 代理(agent)： 
   代理是Consul集群上每个成员的守护进程，它是由consul agent开始运行。代理能够以客户端或服务器模式运行。由于所有节点都必须运行代理，所以将节点引用为客户端或服务器更为简单，但还有其他实例的代理。所有代理可以运行DNS或HTTP接口，并负责运行检查和保持服务同步。

2. 客户端： 
   客户端可以将所有RPC请求转发到服务器的代理。客户端是相对无状态的。客户端执行的唯一后台活动是LANgossip池。它消耗最小的资源开销和少量的网络带宽。

3. 服务器端： 
   服务器端是具有扩展的功能的代理，它主要参与维护集群状态，响应RPC查询，与其他数据中心交换WAN gossip ，以及向leader节点或远程数据中心转发查询。

4. 数据中心： 
   虽然数据中心的定义似乎很明显，但仍有一些细微的细节必须考虑。比如说，在EC2中，多个可用中心（EC2和AZ是AWS里的概念，不了解的话可以去看看AWS文档）是否应该被人是一个单个的数据中心呢？我们将一个数据中心定义为一个私有、低延迟和高带宽的网络环境,这不包括通过公共互联网的通信。但是为了我们的目的，单个EC2区域内的多个可用区域将被视为单个数据中心的一部分。

5. 一致性 ： 
   在我们的文档中，“一致性”的意思是对于被选举出的leader以及事物的顺序的认同。因为这些事件被应用到有限状态机上，我们对一致性的定义又暗含了复制备份的状态机的一致性。

6. Gossip： 
   consul是建立在serf之上的，它提供了一个完整的gossip协议，用在很多地方。Serf提供了成员管理，故障检测和事件广播的功能。Gossip的节点到节点之间的通信使用了UDP协议。

7. LAN Gossip： 
   指在同一局域网或数据中心的节点上的LAN Gossip池。

8. WAN Gossip： 
   指包含服务器的WAN Gossip池，这些服务器在不同的数据中心，通过网络进行通信。

9. RPC 
   远程过程调用。这种请求/响应机制允许客户端向服务器端发一个请求。

概览

让我们把这个图拆解开来分别讲述。

首先，图中有两个数据中心，分别为Datacenter1和Datacenter2。Consul非常好的支持多个数据中心，每个数据中心内，有客户端和服务器端，服务器一般为3~5个，这样可以在稳定和性能上达到平衡，因为更多的机器会使数据同步很慢。不过客户端是没有限制的，可以有成千上万个。

数据中心内的所有节点都会加入到Gossip协议。这就意味着有一个Gossip池，其中包含这个数据中心所有的节点。客户端不需要去配置服务器地址信息，发现工作会自动完成。检测故障节点的工作不是放在服务器端，而是分布式的；这使得失败检测相对于本地化的心跳机制而言，更具可拓展性。在选择leader这种重要的事情发生的时候，数据中心被用作消息层来做消息广播。

每个数据中心内的服务器都是单个Raft中节点集的一部分。这意味着他们一起工作，选择一个单一的领导者——一个具有额外职责的选定的服务器。leader负责处理所有查询和事物。事物也必须作为同步协议的一部分复制到节点集中的所有节点。由于这个要求，当非leader服务器接收到RPC请求时，就会将请求其转发给集群leader。

服务器端节点同时也作为WAN Gossip池的一部分，WAN池和LAN池不同的是，它针对网络高延迟做了优化，而且只包含其他Consul服务器的节点。这个池的目的是允许数据中心以最少的消耗方式发现对方。启动新的数据中心与加入现有的WAN Gossip一样简单。因为这些服务器都在这个池中运行，它还支持跨数据中心请求。当服务器收到对不同数据中心的请求时，它会将其转发到正确数据中心中的随机服务器。那个服务器可能会转发给本地的leader。

这样会使数据中心的耦合非常低。但是由于故障检测，连接缓存和复用，跨数据中心请求相对快速可靠。

总的来说，数据不会在不同的数据中心之间做复制备份。当收到一个请求处于别的数据中心的资源时，本地的Consul服务器会发一个RPC请求到远端的Consul服务器，然后返回结果。如果远端数据中心处于不可用状态，那么这么资源也会不可用，但这不影响本地的数据中心。在一些特殊的情况下，有限的数据集会被跨数据中心复制备份，比如说Consul内置的ACL复制能力，或者像consul-replicate这样的外部工具。

参考文章： 
1. https://www.consul.io/docs/internals/architecture.html 
2. http://www.cnblogs.com/Summer7C/p/7327109.html