主动健康检查 VS 被动健康检查，该如何选择？

正如定期体检是保持健康的一种重要手段一样，定期检查应用的健康状态对于确保可靠性能而言至关重要。在对流量进行反向代理和负载均衡时，NGINX 使用被动健康检查（passive health checks），通过自动将流量从不响应请求的服务器转出，保护您的应用用户免受中断的影响。NGINX Plus 增添了主动健康检查（active health checks），可发送特殊探测，及时检测出无法处理请求的不健康的服务器。哪种类型的健康检查适合您的应用呢？本文为您提供了所需的信息，可帮助您准确做出决定。

什么是健康检查？

从最基本的意义上说，健康检查是一种确定服务器能否处理流量的方法。NGINX 使用健康检查来监控正在对流量进行反向代理或负载均衡的服务器，即所谓的“上游服务器（upstream server）”。

被动健康检查

被动健康检查（NGINX 开源版和 NGINX Plus 均有提供）观测服务器在处理连接和流量时的表现——当 NGINX 发现一台服务器不健康时，它会立即将请求转发到其他服务器，停止向不健康的服务器发送请求，并将后续请求分发到上游组中其余健康的服务器。这可以帮助用户避免因服务器超时而遭遇中断的情况。

请注意，被动健康检查仅在上游组拥有多台服务器时才有效。如果仅有一台上游服务器，那么这台服务器永远不会被标记为不可用。而当它处于异常状态时，用户会遭遇中断。

被动健康检查的工作原理

下面详细介绍了被动健康检查的工作原理，如果您对此不感兴趣，请直接跳到下文“主动健康检查”一节。

默认情况下，如果在与 TCP/UDP (stream) 服务器建立连接时出现一次错误或超时，那么 NGINX 会认为该服务器不健康。

如果在与 HTTP 服务器建立连接、向其传递请求或读取响应头时出现一次错误或超时（根本没有收到响应也算作此类错误），NGINX 也会认为该服务器不健康。您可以使用 proxy_next_upstream 指令为 HTTP 代理自定义这些条件，而且还有一个支持 FastCGI、gRPC、memcached、SCGI、TCP/UDP 及 uwsgi 协议的并行指令。

对于 HTTP 和 TCP/UDP，NGINX 默认等待 10 秒，然后再次尝试连接不健康的服务器并向其发送请求。在 server[HTTP][Stream] 指令中使用 fail_timeout 参数即可更改这一时长。

您可以在 server 指令中使用 max_fails 参数来增加在被 NGINX 视为不健康之前服务器所需发生的错误或超时次数；在这种情况下，fail_timeout 参数可设置该错误或超时次数必须发生的时限，以及 NGINX 在将服务器标记为状态异常后等待重试服务器的时长。

主动健康检查

主动健康检查（NGINX Plus 的独有功能）定期向应用端点发送特殊请求，以确保端点正确响应。它独立于被动健康检查，是对被动健康检查的补充。例如，NGINX Plus 可能会定期向应用的 Web 服务器发送 HTTP 请求，以确保该服务器返回有效的响应代码和正确的内容。主动健康检查支持持续监控特定应用组件和进程的健康状态。它构成了应用可用性的直接衡量指标——虽然需要考虑某一次特定的健康检查是否能代表应用的整体健康状态。

您可以自定义主动健康检查的多个方面；请查看下文“主动健康检查用例”一节。

被动健康检查的用例

被动健康检查必不可少。应用开发、DevOps、DevSecOps 及平台运维团队最好将被动健康检查作为其生产基础架构监控计划的一部分。NGINX 默认对负载均衡的流量进行被动健康检查，包括 HTTP、TCP 和 UDP 配置。

被动健康检查的优势包括：

• 支持 NGINX 开源版
• 默认为包含 upstream{} 配置块的服务器启用该功能
• 不会增加上游服务器的负载
• 可配置一段时间内的最少故障次数，如上文“被动健康检查的工作原理”一节中所述
• 提供可配置的慢启动（NGINX Plus 的独有功能）— 当服务器恢复健康状态时，NGINX Plus 会逐渐增加转发给它的流量，让它有时间“热身”

NGINX 开源版的优势在于成本（显然没有成本）、可配置性及包含第三方模块的大型库。鉴于源代码可用，开发人员能够根据其特定需求修改并扩展功能。

对于许多应用（及其开发人员）而言，被动健康检查就足够了。举例来说，对于不面向客户且执行较小任务的微服务，主动健康检查可能会适得其反。同样，有些应用也没有必要进行主动健康检查，例如可通过缓存减少延迟问题发生几率或通过内容分发网络（CDN）接管一些应用的任务。总而言之，单纯的被动健康检查最适合：

• 监控 HTTP 流量
• 分别监控基础架构和应用
• 监控可容忍延迟的应用
• 监控不关注高性能的内部应用

主动健康检查的用例

对于关键任务应用，主动健康检查通常至关重要。因为客户和关键流程会直接受到问题的影响，所以必须要像应用的客户或消费者那样测试此类应用，这就需要主动健康检查。主动健康检查类似于 New Relic 和 AppDynamics 等应用性能监控工具，它们使用带外检查来测量应用延迟和响应。在主动健康检查方面，NGINX Plus 具有一些 NGINX 开源版中没有的特性和功能：

• 针对应用可用性进行带外健康检查
• 测试已配置的端点并查找特定响应
• 测试与处理实际应用流量所用端口不同的端口
• 提供用于健康检查的 keepalive HTTP 连接，无需为每次检查新建连接
• 更好地控制检查失败和通过条件
• 在新增服务器接收实际应用流量之前，可选择对其进行测试

对于主动健康检查，开发人员可以将 NGINX Plus 设置为自动检测后端服务器何时停机或出现问题，然后将流量路由到健康的服务器，直至问题得到解决。主动健康检查的更高可配置性允许执行更复杂的健康检查，可及时检测出应用问题，避免实际应用用户受到影响。这有助于最大限度地缩短停机时间，并防止用户访问应用时发生中断。

如何配置健康检查

默认启用被动健康检查，但您可以自定义其频率以及在将服务标记为状态异常之前服务所需发生的故障次数，如上文“被动健康检查的工作原理”一节中所述。有关被动和主动健康检查的完整配置说明，请参阅我们的文档：

• HTTP 健康检查
• TCP 健康检查
• UDP 健康检查
• gRPC 健康检查

结论：根据您的应用需求选择健康检查

健康检查不仅是确保生产应用平稳运行和快速响应的重要一环，而且还是及时检测出问题并确定不断恶化的延迟源以免最终用户受到影响的最佳方式。对于许多应用而言，被动健康检查就足够了。

但更关键的应用需要直接了解用户级应用行为，因此主动检查是更好的选择。NGINX 开源版可免费使用，并提供了可配置的被动健康检查。NGINX Plus 提供了高级主动健康检查功能及商业支持。

想要试用 NGINX Plus 主动健康检查？立即下载 30 天免费试用版，或联系我们讨论您的用例。