【Consul】Consul架构-Gossip协议

       Consul使用gossip协议管理成员关系、广播消息到整个集群。详情可参考Serf library，Serf使用到的gossip协议可以参阅"SWIM: Scalable Weakly-consistent Infection-styleProcess Group Membership Protocol"，

       本节主要讲解consul内部技术细节，使用consul不需要必须了解这些细节的。这些文章是为那些不愿意深入源代码但是希望技术细节的人准备的。

1.1 Gossip in Consul

       Consul利用两个不同的gossip pool。我们分别把他们称为局域网池(LAN Pool)或广域网池(WAN Pool)。每个Consul数据中心都有一个包含所有成员（Server和Client）的LANgossip pool。LAN Pool有如下几个目的：首先，成员关系允许Client自动发现Server节点，减少所需的配置量。然后，分布式故障检测允许的故障检测的工作在某几个Server几点执行，而不是集中整个集群所有节点上。最后，gossip允许可靠和快速的事件广播，比如，Leader选举。

       WAN Pool是全局唯一的，无论属于哪一个数据中心，所有Server应该加入到WAN Pool。由WAN Pool提供会员信息让Server可节电执行跨数据中心的请求。集成中故障检测允许Consul妥善处理整个数据中心失去连接，或在远程数据中心只是单个的Server节点。

       所有这些功能都是通过利用Serf提供。从用户角度来看，它是作为一个嵌入式库提供这些功能。但其被Consul屏蔽，用户无需关心。作为开发人员可以去了解这个库是如何利用。

 

1.2 Lifguard增强

       SWIM假设本地节点是健康的，是的软实时处理数据包称为可能。然而，当本地节点正CPU或网络耗尽时，该假设就称为了现实。结果是，serfhealth状态就会“抖动”——摆来摆去，造成虚假报警，增加噪声遥测，简单可预见的结果就是——导致集群浪费CPU和网络资源的来处理不存在的故障。

       Lifeguard通过SWIM完美的解决了该问题，Serf's gossip protocolguide。