Consul是一个复杂的系统,它有不少不一样的可组装的部分。为了帮助Consul的用户和开发者造成一个它如何工做的运转模型,本文介绍它的系统架构。html
注意:本文覆盖了Consul的内部技术细节。高效的操做和使用Consul并不须要你知道这些细节。这些细节记录在这里是为了方便那些但愿学些Consul,可是并无去探寻源码的人的。因为每一个节点都必须运行一个agent,缓存
在描述架构以前,这里提供了一些术语来帮助声明正在探讨的东西:安全
从一万英尺的高空俯视Consul的架构就像这样:网络
让咱们分解这张图并描述每一个部分。首先,咱们能看到有两个数据中心,标记为“1”和“2”。Consul对多数据中心有一流的支持而且但愿这是一个常见的状况。架构
在每一个数据中心,client和server是混合的。通常建议有3-5台server。这是基于有故障状况下的可用性和性能之间的权衡结果,由于越多的机器加入达成共识越慢。然而,并不限制client的数量,它们能够很容易的扩展到数千或者数万台。分布式
同一个数据中心的全部节点都必须加入gossip协议。这意味着gossip协议包含一个给定数据中心的全部节点。这服务于几个目的:第一,不须要在client上配置server地址。发现都是自动完成的。第二,检测节点故障的工做不是放在server上,而是分布式的。这是的故障检测相比心跳机制有更高的可扩展性。第三:它用来做为一个消息层来通知事件,好比leader选举发生时。性能
每一个数据中心的server都是Raft节点集合的一部分。这意味着它们一块儿工做并选出一个leader,一个有额外工做的server。leader负责处理全部的查询和事务。做为一致性协议的一部分,事务也必须被复制到全部其余的节点。由于这一要求,当一个非leader得server收到一个RPC请求时,它将请求转发给集群leader。优化
server节点也做为WAN gossip Pool的一部分。这个Pool不一样于LAN Pool,由于它是为了优化互联网更高的延迟,而且它只包含其余Consul server节点。这个Pool的目的是为了容许数据中心可以以low-touch的方式发现彼此。这使得一个新的数据中心能够很容易的加入现存的WAN gossip。由于server都运行在这个pool中,它也支持跨数据中心请求。当一个server收到来自另外一个数据中心的请求时,它随即转发给正确数据中想一个server。该server再转发给本地leader。spa
这使得数据中心之间只有一个很低的耦合,可是因为故障检测,链接缓存和复用,跨数据中心的请求都是相对快速和可靠的。3d
这里咱们已经覆盖了Consul的高层次架构,可是每一个子系统还有不少的细节。一致性协议的详细文档是gossip协议。使用的安全模型和协议的文档也是可用的。
其余的细节,这么经过查阅代码,在线询问或者发送邮件。