[译]Consul架构

翻译自consul文档（https://www.consul.io/docs/in...）。Consul是一个DNS类型的服务发现产品，与常见的自定义协议的服务发现中间件有所不同，有点意思。

1万英尺

从一万英尺看Consul架构师这样的的：

让我们分开看这张图的每一部分。最先，我们可以看到有两个数据中心，标着”one“和“two”。 Consul对多数据中心有一级支持并期望这是个常态。

在每个数据中心，我们有多个客户端和服务端。最好是3到5个服务器。 这兼顾了在服务处问题时的可用性和性能， 大家都知道在加入了更多机器后会变得更慢。 尽管如此，客户端的数量并没有限制， 他们可以很容易的扩展到成千上万。

数据中心中所有的节点都参与gossip协议。 这意味着有一个gossip池子包含所有当前数据中心的节点。 这有几个原因：一，不需要为客户端配置服务的地址；发现是自动的。二，检测节点失败的工作不在中心服务而是分布的。这让失败检测扩展性比心跳机制扩展性更强。 三，在选举leader这种重要的事件发生时它使用消息层做通知。

每个数据中心的服务都是完整的Single Raft对等集。 这意味着他们在一起选举单一的leader， 一个被选中的leader服务有更多的职责。 leader有义务处理所有的查询和事物。 事物作为consensus协议的一部分也要被复制到所有的节点。 由于这个需求，当一个非leader服务器收到一个RPC请求， 请求将被转发到集群leader。

服务器节点也被作为一个WAN（广域网）gossip池。 这个池子与LAN（局域网）池的不同之处是他是为互联网的更高的延迟优化的，并且他被认为只保存其他Consul服务器节点。 这个池的目的是允许数据中心间能以一种低频率的方式做发现。 让一个新的数据中心上线就跟加入已存在的WANgossip一样简单。 因为所有的服务器都在这个池中，他还能进行跨数据中心的请求。 当一个服务器收到从另一个数据中心的请求， 它将它转发到正确数据中心的一个随机的服务器。 这个服务器可能再把它转发到本地的leader。

这样数据中心间是相当松耦合的， 但由于失败检测， 连接缓存和多路复用， 跨数据中心的请求相对比较快速和可靠。