Consul架构
一个节点可以有客户端模式和服务器模式。主要的名词解释如下：
客户端Client：客户端节点是无状态的，完全依赖服务端节点；通过LAN gossip（一种通信协议）与其他客户端交互；通过RPC与服务端进行交互。
服务端Server：服务器节点负责存储节点状态；运行一致性协议；与其他数据中心的进行交互（WAN）；响应RPC请求。
数据中心Datacenter：由多个节点组成的一个集群。
纵观上图，我们看到有两个数据中心，说明Consul是支持多数据中心的。在每个数据中心有多个客户端和服务器。建议服务器的是3~5个，这是为了平衡可用性与效率，如果服务器太少，无法保证某些节点失败时集群可用，如果服务器太多，会导致达到一致性的时间变慢。但是对于客户端数量是没有限制的，可以轻松地扩容到成千上万个客户端。
同一个数据中心中的所有节点都参与gossip协议，这意味着每个数据中心有一个gossip池(LAN gossip pool)，这样有几个好处：第一，每个客户端没必要配置服务器的地址，服务器节点是自动发现的。第二，节点的故障检测工作也不用放在服务器节点，而是分布式的，这使得故障检测比本地的心跳机制更加具有可扩展性。第三，这个gossip池可以作为消息层，用来广播消息，比如发生leader选举等重要事件。
在每个数据中心的所有服务端节点都属于一个Raft集（一种选举算法），这意味着这些服务器节点共同选举出一个领导节点，被选出的领导处理一些特殊的事情：领导节点负责处理所有的查询和事务。所有的事务必须被复制到其他服务端节点。
每个服务端节点也属于WLAN(广域网)gossip池，这个池与上面提到的LAN pool 不同。WLAN pool针对互联网更高的延迟进行了优化，用来与其他远程的进行交互。这使跨数据中心的请求成为可能。当一个服务器节点收到一个其他数据中心的请求时，它会把这个请求转发到正确的数据中心的随机的一个服务器节点，然后这个服务器会转发到本地的leader节点（这里的转发是指发起RPC请求来获取结果）。这会导致数据库中心之间的低耦合。由于故障检测、连接缓存和复用、跨数据中心的请求是相对快和可靠的。
总之，数据是不能在不同的数据中心复制的。但是也有一些特殊的情况可以进行一部分数据的复制，比如Consul内置的访问控制列表（ACL）复制功能，以及外部工具consul-replicate。
在某些情况下，客户端节点是可以从服务器节点缓存一些数据的，比如连接证书和结果缓存。这样可以在服务器节点暂时不可用时，提高整体的可靠性。
喜欢请关注，更多原创
