健康检查新特性介绍
在 API7 企业版 3.2.9 版本中，我们对健康检查的配置交互体验进行了全面优化。
将原本分散的配置项进行了合理的聚合，比如探针设置、健康与不健康节点的判定条件等，使其更加结构化。
将一些原本抽象的配置项名称转化为更直观、语义化的表述，通过填空的方式让用户直接输入相关参数，从而更清晰地理解配置带来的实际效果。
在配置上游节点和健康检查过程中，我们增加了更多的提示信息，帮助用户更好地理解上游节点与健康检查之间的内在联系，从而更轻松地完成配置工作。
健康检查基本概念
在 API7 企业版中，上游节点的优先级设置与负载均衡及健康检查机制紧密相连。当用户为网关配置了多个具有不同优先级的上游节点时，网关在进行负载均衡时会优先考虑优先级最高的节点。这意味着，只要最高优先级的节点保持健康状态，网关就会持续将流量路由到这些节点上。
仅当所有最高优先级的节点由于健康检查失败而被判定为不可用时，网关才会自动降级，将流量重定向到次高优先级的上游节点。这种设计确保了流量的高效利用和系统的高可用性。
需要注意的是，如果服务中配置了多个优先级的上游节点，但健康检查功能被禁用，那么所有的客户端请求将始终只会被路由到优先级最高的节点，无论这些节点的实际健康状态如何。
健康检查的配置方式
探针的配置
探针（Probe）用于探测上游节点的存活性和服务状态。探针在 APISIX 中就像是一个“检查员”，它会定期去“敲敲门”，看看上游的服务是否在正常工作。如果发现服务有问题或者“不在家”，它就会告诉 APISIX：“这个服务现在不行哦，先别往这里发请求了。”这样，APISIX 就知道要把用户的请求发送到其他正常的服务上，避免用户遇到问题。这个“敲敲门”的过程，就是通过探针进行的健康检查。
探针主要包含以下这些配置项：
探针协议(Probe Scheme)：健康检查探针使用的协议类型，支持 TCP，HTTP，HTTPS 三种。
并发量 (Concurrency)：并发量配置项允许你设定同时进行健康检查的请求数量。换句话说，这就是你希望同时“敲门”的次数，以检查上游服务的响应能力。通过调整并发量，你可以模拟实际场景中可能的并发请求，从而更好地评估上游服务的性能和稳定性。
主机名 (Host)：指定要检查的上游服务器的主机地址。这就是你要“敲门”的那户人家。
端口号 (Port)：上游服务的端口号。相当于你知道“敲门”时应该敲哪个门。
请求路径 (Path)：如果你是用 HTTP 探针，这个配置项就是指定你要访问的 URL 路径。就像是在告诉探针：“进去之后，要去哪个房间检查”。
健康节点的判定条件
关于健康节点的判定，系统会依照用户所设定的时间间隔（单位为秒）定期检查先前被标记为不健康的节点，以确保任何短暂的节点异常都能被及时发现并妥善处理。
若探针使用的是 TCP 协议，在探针连续成功连接上游节点达到用户设定的次数后，该节点便会被判定为健康状态。
而如果探针采用的是 HTTP/HTTPS 协议，系统则会在节点连续接收到带有指定状态码（如图中的 200 和 302）的探查请求时，才将其视为健康状态。这表示，仅当节点持续返回这些特定的状态码，我们才会认定该节点正在正常工作。
不健康节点的判定条件
关于不健康节点的判定，其配置方式与判定健康节点相似。系统会根据用户设定的时间间隔定期检查当前被标记为健康的节点。一旦这些节点满足预设的不健康条件，它们便会被重新标记为不健康状态。
与健康节点判定略有不同的是，在不健康节点的判定过程中，系统增加了一个额外的配置项：客户端请求校验。当启用这一功能时，网关不仅会依赖探针的检查结果，还会深入观察并分析来自客户端的请求以及上游服务的实际响应。基于这些数据和用户自定义的判定条件，网关能够更精确地评估上游服务的运行状态。
健康检查最佳实践
选择合适的探针类型
TCP 探针：适用于那些仅需要确认服务端口是否开放、服务是否可达的场景。例如，一个数据库服务可能只需要 TCP 探针来确认端口开放即可。
HTTP/HTTPS 探针：对于那些需要验证服务不仅网络连接正常，而且能正确处理请求的场景更为合适。例如，一个 Web 服务器或 API 服务，我们需要确保它不仅能接收连接，还能返回正确的页面或数据。
合理的健康检查配置参数
配置健康检查时，要关注几个关键参数：
检查间隔：不应太短，以免造成不必要的开销；也不应太长，以免在出现问题时反应过慢。例如高流量的电商网站，每 30 秒检查一次是一个相对合理的选择。这个间隔既不会过于频繁地消耗系统资源，也能在网站出现问题时及时发现并处理。当然，这个间隔并不是绝对的，具体还需要根据网站的实际情况进行调整。例如，如果网站的流量波动较大，或者在某些特定时段（如促销活动期间）流量激增，可能需要调整检查间隔以适应这些变化。
超时时间：探针等待服务响应的时间。如果服务在这个时间内没有响应，探针就会认为服务不健康。这个值需要根据服务的实际响应时间来设置。
重试次数：在判定服务不健康之前，探针会尝试连接的次数。这个值要适中，避免误判。
根据业务调节策略
健康检查的策略应根据业务的实际情况进行调整。如果一个服务通常在特定时间段内负载较高，那么在这个时间段内可以适当增加健康检查的间隔或减少重试次数，以避免给服务带来额外压力。
酌情开启客户端请求验证
客户端请求验证可以基于实际的业务请求来判定服务状态，因此对于识别与业务逻辑紧密相关的问题特别有效。但也并不是每种业务情况都适合开启。
低流量服务：如果服务流量较低，那么基于客户端请求的被动健康检查可能无法提供足够的数据点来准确评估服务状态。在这种情况下，依赖主动探针检查可能更为可靠。
高并发环境下的性能考虑：被动健康检查需要监听并处理每一个客户端请求，这在高并发环境下可能会增加额外的性能开销。如果性能是首要考虑因素，且服务已经通过其他方式进行了充分的监控，那么可以考虑关闭被动健康检查。
当存在其他监控系统：如果企业已经部署了其他成熟的监控系统，能够实时捕获和分析服务状态，那么被动健康检查可能不是必需的，以避免数据冗余和额外的复杂性。
总结
健康检查是确保 API 网关高可用性的关键环节。在 API7 企业版 3.2.9 版本中，我们对健康检查的交互配置进行了全面优化，简化了操作并提升了用户体验。通过合理配置探针、设定健康与不健康节点的判定条件，以及根据业务实际调整策略，用户能更有效地监控上游服务的状态，确保流量始终被路由到健康的节点上。这不仅提高系统的稳定性和可用性，同时也保障了用户请求能够得到及时、准确的响应。