quanzhan_King的博客

这些行为类似于标准服务查询，但提供更丰富的功能集，例如通过多个 tag 过滤，并且如果本地数据中心 中没有可用的健康节点，则自动故障切换以查找远程数据中心中的 sevices。有一些对 DNS 接口很重要的配置选项，特别是 client_addr、ports.dns，recursors、domain 和 dns_config。另一个选项是将 Consul 设置为节点的 DNS 服务器，并提供 recursors 配置，以便还可以解析非 Consul 查询。如果查找是通过 TCP 完成的，结果不会被截断。

Consul agent 是 Consul 的核心:它运行 agent，执行维护成员信息、运行 check、通知 service、处理 queries 等的重要任务。Agent 必须在作为 Consul 集群一部分运行于每个节点上。Agent 有两种模式:client 或 server。

可以通过更改配置文件并向 agent 发送 SIGHUP 来更新服务定义。这允许您更新服务，而不会出现任何停机或不可用的服务查询。或者，HTTP API 可用于动态添加，删除 和修改服务。此种方式，我们需要事先创建一个目录用于存储服务定义文件，consule 启动加载配置目录中的所有配置文件。在 Unix 系统上，一个常见约定是将目录命名为 /etc/consul.d。

在任何时间点，您的本地 agent 看到的 world view 可能与服务器上的状态不完全匹配。对于一 个强一致性 world view，请使用 HTTP API 做为转发请求转到到 Consul 服务器.为了简单起见，我们现在将以开发模式启动 Consul agent。它不打算在生产中使用，因为它不持续任何状态。中断 agent 后，您应该看到它离开集群并关闭。安装 Consul 很简单，其实际就是一个可执行的二进制包，官网参考文档。HTTP API 接口查询。

从 Consul 的 0.7 版本开始，allow_stale 默认设置为开启状态，并且 max_stale 的默认配置时间为 5 秒，这意味着我们从任意的 Consul server 中读取到的数据都与 leader 中获取到的数据存在 5 秒的偏差。一个简单的例子，操作系统默认会缓存拒绝的响应 15 分钟。如果没有为 Prepared Queries 配置TTL，则它将回退到如上所述的 Consul 代理中定义的服务特定配置，并且如果没有为 Consul 代理中的服务配置 TTL，则最终为 0。

测试Consul server服务的高可用，先停止其中一台Consul server节点的容器，并清理Consul 的持久化数据，其它服务的Consul节点正常，达到预期结果，后来尝试恢复 这个Consul server,恢复后发现从Consul ui查发现 少了一些服务节点，查询过后，正好是清理数据的这台Consul server上的服务在 Consul 中消失了，因此又重新在这个 节点进行相应的服务注册才真正恢复正常。于是就向客户申请开通相应的udp端口，开通后，再进行测试，发现问题还是存在。

Consul的实现Consul使用Consensus协议提供一致性(Consistency)——CAP定义的一致性。Consensus协议是基于“Raft:InsearchofanUnderstandableConsensusAlgorithm”实现的。Raft是基于Paxos的一致性算法。与Paxos相比，Raft被设计为具有更少的状态和更简单，更容易理解的算法。Raft算法是一种基于日志复制实现数据

与其他分布式服务注册与发现的方案， consul 的方案更“一站式”，内置了服务注册 与发现框架、分布一致性协议实现、健康检查、Key/Value 存储、多数据中心方案，不再需要依赖其他工具(比如 ZooKeeper 等。这使得一个新的数据中心可以很容易的加入现存的 WAN gossip。当一个 server 收到来自另一个数据中心的请求时，它随即转发给正确数据中心的一个 server。这使得数据中心之间只有一个很低的合，但是由于故障检测，连接缓存和复用，跨数据中心的请求都是相对快速和可靠的。