Consul是一个用来实现分布式系统的服务发现与配置的开源工具。

consul内部原理：

在数据中心中，Consul 分为 Client 和 Server 两种节点（所有的节点也被称为 Agent），Server 节点保存数据，Client 负责健康检查及转发数据请求到 Server。

Server 节点有一个 Leader 和多个 Follower，Leader 节点会将数据同步到 Follower，在 Leader 挂掉的时候会启动选举机制产生一个新的 Leader。集群内的 Consul 节点通过 gossip 协议（流言协议）维护成员关系，也就是说某个节点了解集群内现在还有哪些节点，这些节点是 Client 还是 Server。

单个数据中心的流言协议同时使用 TCP 和 UDP 通信，并且都使用 8301 端口。跨数据中心的流言协议也同时使用 TCP 和 UDP 通信，端口使用 8302。

consul服务发现原理：

这里在服务器 Server1、Server2、Server3 上分别部署了 Consul Server。

假设他们选举了 Server2 上的 Consul Server 节点为 Leader。然后在服务器 Server4 和 Server5 上通过 Consul Client 分别注册 Service A、B、C。服务注册到 Consul 可以通过 HTTP API（8500 端口）的方式，也可以通过 Consul 配置文件的方式。

Consul Client 可以认为是无状态的，它将注册信息通过 RPC 转发到 Consul Server，服务信息保存在 Server 的各个节点中，并且通过 Raft 实现了强一致性。

最后在服务器 Server6 中 Program D 需要访问 Service B，这时候 Program D 首先访问本机 Consul Client 提供的 HTTP API，本机 Client 会将请求转发到 Consul Server。

Consul Server 查询到 Service B 当前的信息返回，最终 Program D 拿到了 Service B 的所有部署的 IP 和端口，然后就可以选择 Service B 的其中一个部署并向其发起请求了。

如果服务发现采用的是 DNS 方式，则 Program D 中直接使用 Service B 的服务发现域名，域名解析请求首先到达本机 DNS 代理，然后转发到本机 Consul Client，本机 Client 会将请求转发到 Consul Server。

Consul Server 查询到 Service B 当前的信息返回，最终 Program D 拿到了 Service B 的某个部署的 IP 和端口。

通过http方式获取服务信息，进行调用。

consul本身提供了一些缓存模式：

一致性模式

严格的说，这个不是一个缓存模式。

默认情况下，所有来自于agent的请求，都会由leader来处理。这样导致leader的负担特别重。如果把一致性模式设置为stale，那么所有的server节点都会处理请求，就可以大幅降低leader的压力。缺点是，只有leader的数据是最新的，其他server返回的数据可能会是过时的数据。但是，这个过时的时间通常也是毫秒级的。

简单缓存

简单缓存通过HTTP请求的 Cache-Control 来控制，只有部分接口提供支持。接口文档里会有明确说明是否支持。

通过max-age来指定过期时间，通过stale-if-error来指定server异常时的缓冲时间。

Server正常的情况下，max-age时间内的数据会直接返回，超出max-age时agent会向server查询新数据。

如果server崩溃了，那么stale-if-error就会产生作用，在这段时间里，agent仍然会返回缓存的数据。stale-if-error的值应该远远大于max-age的值。

自动刷新缓存

这个是最强大的缓存，他会监控server的数据变化，自动跟server保持同步。如果server的数据没有变化，那么缓存就会一直保持，如果server数据有变化，则会自动刷新缓存。所以实际上，这个缓存和server的数据是一致的。server不可用时就会持续使用缓存数据，这个时间可以长达数天，足够server集群恢复工作了。

容错表：

目前采用default模式，读写全部调用leader主机。配置stale模式需要配置项中指定：

dns_config此对象允许设置许多子项，这些子项可以调整DNS查询的服务方式。有关更多详细信息，请参见本DNS缓存指南 。

可以使用以下子项：

• allow_stale-启用对DNS信息的陈旧查询。这允许任何Consul服务器（而不只是领导者）为请求提供服务。这样做的好处是您可以通过Consul服务器获得线性读取可伸缩性。在Consul 0.7之前的版本中，默认情况下为false，这意味着所有请求均由领导者提供服务，从而提供了更强的一致性，但吞吐量更低，延迟更长。在Consul 0.7及更高版本中，为了更好地利用可用服务器，此属性默认为true。
• max_stale- allow_stale 指定时，用于限制允许过时的结果。如果Consul服务器落后于领导者多于max_stale，则查询将重新评估领导者以获取更多最新结果。在Consul 0.7.1之前，该默认值为5秒；在Consul 0.7.1及更高版本中，此默认设置为10年（“ 87600h”），无论使用多长时间，该值均允许任何服务器有效地响应DNS查询。实际上，服务器通常仅比领导者晚几毫秒，因此，Consul可以在无法选择领导者的长时间中断情况下继续处理请求。