健康检查

本节，我们进一步为 节点 和 服务 添加 检查检查 ( health check )。健康检查 是 服务发现 ( service discovery )的重要组成部分，可避免访问不健康的服务实例。

我们在 上节 搭建的集群基础上进行试验，这是一个双节点集群。

与 类似，健康检查可通过 配置文件 或 HTTP 接口调用进行注册。

这里我们还是采用配置文件的方式，因为跟服务配置一样，这种方式 最常用 。

Consul0.9.0 以后， 代理 ( agent )需要将 配置设置为 true ，以开启脚本检查。

第一个配置 ping 是 节点检查 ( host-level check )，每隔 30 秒调用 一次。脚本式 ( script-based )检查执行用户与启动 Consul 的用户一致。如果命令返回值大于 2 ，则认为检查 失败 ，对应的服务也是 不健康 的。如果返回值是 1 ，则认为服务处于 预警 ( warning )状态。这个约定对于所有 脚本式 检查均适用。

第二个配置在 web 服务基础上，为其添加检查定义，每隔 10 秒钟调用 curl 判断服务是否可用。与 节点检测 一样，如果命令返回值大于 2 ，则认为检查 失败 ，对应的服务将被标记为 不健康 。

现在，通过 consul reload 或者发送 信号重启第二个 代理 。接下来， 代理 将出现以下日志：

前几行表明， 代理 已经同步了新配置。最后一行表明，我们为 web 服务添加的健康检查发现严重错误。这是因为，我们并没有运行 Web 服务， curl 检查一定会失败。

我们已经添加了两个健康检查定义，现在可以通过 HTTP 查看结果。首先，我们用以下命令查看所有 不通过 的检查(可以在任意节点运行)：

此外，我们尝试通过 DNS 查询 服务， Consul 并不返回任何地址因为服务不健康。

本节，我们通过亲身试验发现，添加健康查也非常简单。更新检查定义只需编辑配置文件，并向 代理 发送 SIGHUP 信号。另外，也可以使用 HTTP 接口动态 添加 、 删除 、 以及 修改 检查定义。API 还支持 失知制动 ( dead man’s switch )，一种基于 的检查。TTL 检查让应用与 Consul 集成更紧密，业务逻辑判断可成为健康检查的一部分。

下一节，我们介绍： 键值数据 。

订阅更新，获取更多学习资料，请关注我们的 ：

小菜学编程