在上一篇文章中，我讲解了反向代理中的负载均衡，一个上游主机要想被使用到的前提：就是这该主机必须可用？那么怎么才算可用呢？这涉及到Caddy的健康检查，和Nginx的类似。

什么是健康检查

比如我们做体验，其实就是对我们自己身体做一个健康检查，判断身体是否健康。那么对于我们的上游主机服务，其实也一样，只要做了健康检查，才能知道这个上游是否健康，是否可用。

健康检查根据方式不同，又分为主动健康检查和被动健康，同样的Caddy也支持这两种检查方式，下面就先为你介绍主动健康检查。

主动健康检查

主动，从字面上看，是主动发起的，所以主动健康检查，也就是Caddy主动发起的对上游主机服务的健康检查，它的Caddyfile配置格式如下所示：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

reverse_proxy [<matcher>] [<upstreams...>] {
    # backends
    to <upstreams...>
	...
    # active health checking
    health_uri      <uri>
    health_port     <port>
    health_interval <interval>
    health_timeout  <duration>
    health_status   <status>
    health_body     <regexp>
	health_headers {
		<field> [<values...>]
	}
}
  1. health_uri ：设置Caddy主动发起健康检查的URI，可以有path和query查询参数
  2. health_port ：设置健康检查URL的端口，如果和上游主机端口一样，就不用单独设置，一般不设置。
  3. health_interval ：主动健康检查的周期，也就是多久发起一次主动健康检查，默认是30秒。
  4. health_timeout ：检查的超时时间，如果返回的响应超过这个值就认为是不健康的，默认是5秒。
  5. health_status ：对于一个健康的上游服务，预期的状态码，可以是一个三位数的值，也可以使用 2xx 这种写法，默认是 200 ,当然你写成 2xx 也可以，这样返回 204 也被认为是健康的。
  6. health_body : 和 health_status 差不多，只不过它是返回的内容，如果匹配，则认为是健康的，否则则认为不健康。
  7. health_headers ：这个主要用于设置发起健康检查请求头的头信息，比如需要鉴权的信息等。

下面通过一个例子，来看下主动健康检查的使用：

1
2
3
4
5
6

reverse_proxy /api/* node1:80 node2:80 node3:80 {
	health_uri /health?ready=1
    health_status 2xx
    health_interval 20s
    health_timeout 3s
}

以上设置后，每隔 20s Caddy就会向每个upstream的 /health?ready=1 发起一次健康检查的请求，只要该URI返回的HTTP Status Code为2开头的，那么就认为是该upstream是健康的。

被动健康检查

有主动就有被动，从上面的文章我们可以看到，主动检查是Caddy定时主动发起的，不受其他因素限制，但是被动检查就不一样了，被动检查只有在Caddy接收到用户请求时，才会对上游（后端）主机进行检查探测，这就是Caddy的被动健康检查。

和主动健康检查一样，Caddy的被动检查也有几个设置：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

reverse_proxy [<matcher>] [<upstreams...>] {
    # backends
    to <upstreams...>
	...
    # passive health checking
    fail_duration     <duration>
    max_fails         <num>
    unhealthy_status  <status>
    unhealthy_latency <duration>
    unhealthy_request_count <num>
}
  1. fail_duration :这是一个时间区间，它表示记录一次失败的请求多久，什么意思呢？当一次失败的请求后，caddy会把失败计数器+1，在过了fail_duration 时间后，会把失败计数器-1，也就是恢复了。所示就是请求失败了没事，过了fail_duration 时间后，就认为你这次失败又恢复正常了。
  2. max_fails ：这个是允许最大失败的次数，如果经常失败，通过fail_duration 减的次数，赶不上失败增加的次数，导致失败次数达到了max_fails ,那么Caddy就会认为你的上游（后端）主机不可用。
  3. unhealthy_status ：设置一个状态码, 比如 404 或者 5xx 都行，如果上游返回的状态是unhealthy_status ,那么Caddy就认为这次访问失败，失败计数器会+1（fail_duration 时间后会-1），一直到max_fails 会认为该上游主机不可用。
  4. unhealthy_latency : 这也是一个时间，它表示上游主机的相应时间如果超过unhealthy_latency 这个值，失败计数器也会+1，一直到max_fails 会认为该上游主机不可用。
  5. unhealthy_request_count :这个其实用来设置上游主机允许的最大请求数，如果请求数超过这个值，那么Caddy就会认为该上游主机不可用。

从以上每个配置的解释说明，相信你已经了解了Caddy的被动检查，它其实非常简单，就这么几个配置，并且是根据接收到的请求触发的（非Caddy自己主动），所以叫做被动检查。

这里需要注意的是，只有当fail_duration 的值大于0，Caddy才启动被动检查。

小结

这篇主要介绍Caddy的健康检查，从机制上了解它的运作，这对于我们更好的配置Caddy可以提供很大的帮助。

其实Caddy的思路不止可以用于Caddy，也可以用于你自己的代码开发中，比如你调用其他的微服务，也可以采用这里面的思路，做更好的优化，让你的程序更健壮。

本文为原创文章，转载注明出处,欢迎扫码关注公众号flysnow_org或者网站asf http://www.flysnow.org/ ，第一时间看后续精彩文章。觉得好的话，请猛击文章右下角「好看」，感谢支持。

扫码关注