健康检查（Health Check）是应用型负载均衡（ALB）保障业务高可用的核心机制。开启健康检查后，ALB 会持续探测目标组内各后端服务的运行状况，自动将客户端请求只转发到健康检查正常的后端服务，并在某台后端服务异常时自动将其从流量分发中屏蔽，待其恢复后再自动重新纳入，从而避免单点故障影响整体业务。
本文介绍 ALB 健康检查的工作机制、各项参数含义，以及如何在控制台配置和修改健康检查。
前提条件
已创建应用型负载均衡 ALB 实例。如未创建，请参见 创建 ALB 实例。
已创建目标组并向目标组中添加了后端服务。如未创建，请参见 创建和管理目标组。
健康检查工作机制
ALB 以目标组为维度配置健康检查，每个目标组可独立开启并配置健康检查策略。其工作机制如下：
开启健康检查后，ALB 通过健康探测源 IP 周期性地向目标组内每个后端服务发起探测请求，根据响应结果判定后端服务的健康状态。
后端服务需连续多次（健康阈值）探测成功才会被判定为健康，以避免网络抖动造成的误判；连续多次（不健康阈值）探测失败则被判定为异常。
当某台后端服务被判定为异常时，ALB 自动将其从流量分发中剔除，新的请求会按调度策略分发到其他健康的后端服务；当其恢复正常后，ALB 自动将其重新纳入流量分发。
健康检查为短连接探测，每次探测完成后连接即关闭。
当目标组内所有后端服务均为异常时，ALB 仍会按调度策略尝试将请求转发至这些后端服务，以最大程度避免业务完全中断。
说明：
权重为0的后端服务不接收新请求，也不参与健康检查。
健康检查方式
ALB 目标组支持以下健康检查方式。检查方式的可选项与目标组的后端协议联动：
后端协议选择 HTTP、HTTPS 时，检查方式支持 TCP、HTTP、HTTPS；
后端协议选择 gRPC 时，检查方式支持 TCP、gRPC；
后端协议选择 gRPCs 时，检查方式支持 TCP、gRPCs。
检查方式 | 检查原理 | 适用场景 |
TCP | 通过向后端服务发起 TCP 三次握手（SYN 包）来探测端口是否存活，仅校验端口连通性，不感知应用层状态。 | 后端为通用 TCP 服务或仅需确认端口可达的场景。性能开销小，是默认的检查方式。 |
HTTP | 通过向后端服务发送 HTTP 请求（HEAD 或 GET），根据返回的 HTTP 状态码判定后端应用是否正常。 | 后端为 HTTP 应用，需要从应用层确认服务可用性的场景。 |
HTTPS | 通过向后端服务发送基于 TLS 加密的 HTTP 请求，根据返回的 HTTP 状态码判定后端应用是否正常。 | 后端为 HTTPS 应用，需要在加密链路上确认服务可用性的场景。 |
gRPC | 通过向后端服务发送 gRPC 健康检查请求，根据返回的 gRPC 状态码判定后端应用是否正常。 | 后端为 gRPC 应用的场景。 |
gRPCs | 通过向后端服务发送基于 TLS 加密的 gRPC 健康检查请求，根据返回的 gRPC 状态码判定后端应用是否正常。 | 后端为加密 gRPCs 应用的场景。 |
配置健康检查
1. 登录 应用型负载均衡控制台，在左侧导航栏选择应用型负载均衡 ALB > 目标组管理。
2. 在页面上方选择地域后，单击新建，在创建目标组窗口中完成基本信息配置，单击下一步：健康检查。
3. 在健康检查步骤中，按下表配置健康检查参数，配置完成后单击完成。
基础参数
参数 | 说明 |
健康检查 | 是否开启健康检查。开启后 ALB 会自动检查并移除异常的后端服务。建议保持开启。 |
检查方式 | 选择健康检查使用的协议。可选项随目标组后端协议联动： 后端协议选择 HTTP、HTTPS 时，检查方式支持 TCP、HTTP、HTTPS； 后端协议选择 gRPC 时，检查方式支持 TCP、gRPC； 后端协议选择 gRPCs 时，检查方式支持 TCP、gRPCs。 |
检查端口 | 健康检查探测使用的端口。默认为后端服务的端口；若后端服务的健康检查端口与业务端口不同，可在此指定特定端口。 除特殊需要外建议留空。 |
HTTP/HTTPS 检查方式专属参数
当检查方式选择 HTTP 或 HTTPS 时，除基本参数外还需配置以下应用层参数：
参数 | 说明 |
检查域名 | 长度限制：1 - 80个字符。 默认为转发域名。 不支持正则表达式，当您的转发域名为通配域名时，需要指定某一固定域名（非正则）为健康检查域名。 支持的字符集为：a-z 0-9 . -。 |
检查路径 | 健康检查路径可设置为后端服务器根目录或指定的 URL： 长度限制：1 - 200个字符。 默认为 /，且必须以 / 开头。 不支持正则表达式，建议指定某个固定 URL 路径（静态页面）进行健康检查。 支持的字符集为：a-z A-Z 0-9 . - _ / = ?。 |
HTTP 请求方式 | 健康检查选择 HTTP 请求方式，可选：GET 或 HEAD，默认为 HEAD。 若使用 HEAD 方法，服务器仅返回 HTTP 头部信息，可降低后端开销，提升请求效率，对应的后端服务需支持 HEAD。 若使用 GET 方法，则后端服务支持 GET 即可。 |
HTTP 状态码检测 | 判定后端服务存活的响应状态码集合，探测返回命中其中任一即视为存活。可勾选 http_1xx、http_2xx、http_3xx、http_4xx、http_5xx。当返回状态码命中所勾选的任一类别时，认为后端服务器存活。 |
gRPC/gRPCs 检查方式专属参数
当检查方式选择 gRPC 或 gRPCs 时，除基本参数外还需配置以下参数：
参数 | 说明 |
检查域名 | 长度限制：1 - 80个字符。 默认为转发域名。 不支持正则表达式，当您的转发域名为通配域名时，需要指定某一固定域名（非正则）为健康检查域名。 支持的字符集为：a-z 0-9 . -。 |
检查路径 | 健康检查选择 gRPC 协议时，路径默认为 /TCLOUD.CLB/healthcheck，同时可按/Package.Class/method格式进行自定义设置。 |
gRPC 状态码检测 | 判定后端服务存活的 gRPC 状态码，默认值为12，数值范围为0 - 99。 输入值可为单个数值、多个数值、范围以及相互组合，如20、20,25、0-99或12，25，30-40的组合。当 gRPC 返回状态码与设置的状态码匹配时，认为后端服务器存活。 |
高级选项
单击显示高级选项，可通过滑块调整健康检查的探测频率与判定阈值：
参数 | 说明 | 取值范围 | 默认值 |
响应超时 | 单次健康检查的最大等待时间。若后端服务在该时间内未正确响应，则判定本次探测失败。 | 2 - 60 秒 | 2 秒 |
检测间隔 | 相邻两次健康检查之间的时间间隔。间隔越短，异常发现越及时，但探测开销越大。 | 2 - 300 秒 | 5 秒 |
不健康阈值 | 连续探测失败达到该次数后，将后端服务判定为异常并剔除流量。 | 2 - 10 次 | 3 次 |
健康阈值 | 连续探测成功达到该次数后，将后端服务判定为健康并恢复流量。 | 2 - 10 次 | 3 次 |
说明：
响应超时时间应小于检测间隔。若后端服务启动较慢，可适当增大检测间隔或不健康阈值，避免服务启动期间被误判为异常；若网络延迟较高，可适当增大响应超时时间。
查看健康检查状态
为目标组开启健康检查并将其关联到监听器后，您可在监听器管理页面中查看各后端服务的健康检查状态。
1. 登录 应用型负载均衡控制台，进入目标实例，
2. 进入目标实例后，切换到监听器管理页面，在健康状态列中可见健康状态。后端服务的健康检查状态含义如下：
状态 | 说明 |
健康 | 后端服务连续通过健康检查（达到健康阈值），正常参与流量分发。 |
异常 | 后端服务连续未通过健康检查（达到不健康阈值），已被剔除出流量分发。 |
未知 | 绑定的目标组内无后端服务。 |
探测中 | 新绑定的后端服务器在检查间隔 × 健康阈值时间内的状态。 |
已关闭 | 关闭健康检查。CLB 向所有后端服务转发流量。 |
修改健康检查
目标组创建后，您可随时修改健康检查配置。
1. 在目标组管理列表中单击目标组 ID 进入详情页。
2. 在基本信息页的健康检查区域单击编辑。
3. 修改完成后，单击保存。
注意：
关闭健康检查后，ALB 将不再探测后端服务。一旦某台后端服务故障，流量无法自动切换至其他正常后端服务，可能导致业务受损，请谨慎操作。
增大检测间隔会延长异常后端服务被发现的时间，请结合业务对故障切换时效的要求合理设置。
