链接复制成功!
健康检查概述
服务会定期向成员发送请求以测试其运行状态,这些测试称为健康检查。通过健康检查来判断成员是否可用。
服务如果判断成员健康检查异常,就不会将流量分发到异常的成员,而是分发到健康检查正常的成员,从而提高了业务的可靠性。当异常的成员恢复正常运行后,服务会将其自动恢复到服务中,承载业务流量。
服务如果判断成员组中所有成员健康检查异常,就不会将流量分发到这个成员组。
如果服务某一区域所有成员组中所有成员健康检查异常,就不会将流量分到这个服务的区域,而是将流量引到正常的服务正常的区域。
如果您的业务对负载比较敏感,过于频繁的健康检查报文可能会对您的正常业务产生影响。您可以根据实际的业务情况,通过增大健康检查间隔等方式来降低对业务的影响。如果您的业务系统自身有健康检查机制,也可以关闭服务的健康检查,但是为了保障业务的持续可用,不建议这样做。
健康检查协议
您可以在创建服务路由规则时为成员组选择健康检查,根据业务需要选择不同的健康检查协议,健康检查支持TCP/HTTP协议。
健康检查源IP
健康检查以成员组后端子网内的IP为健康检查源地址,向成员组中的成员发起健康检查探测请求。
TCP健康检查
对于四层(TCP)和七层(HTTP/HTTPS)后端协议,您可以配置TCP健康检查,通过发起TCP三次握手来获取后端服务器的状态信息,如图1所示。
TCP健康检查的机制如下:
- 服务节点根据健康检查配置,向成员(IP+健康检查端口)发送TCP SYN报文。
- 成员收到请求报文后,如果相应的端口已经被正常监听,则会返回SYN+ACK报文。
- 如果在超时时间内没有收到成员的SYN+ACK报文,则判定健康检查失败。随后发送RST报文给成员中断TCP连接。
- 如果在超时时间内收到了SYN+ACK报文,则判定健康检查成功,并进一步发送ACK报文给成员。随后发送RST报文给成员中断TCP连接。
正常的TCP三次握手后,会进行数据传输,但是在健康检查时会发送RST中断建立的TCP连接。该实现方式可能会导致成员中的应用认为TCP连接异常退出,并打印错误信息,如“Connection reset by peer”。解决方案如下:
- 采用HTTP健康检查。
- 成员忽略健康检查的连接错误。
HTTP健康检查
对于四层(TCP)和七层(HTTP)后端协议,您可以配置HTTP健康检查,通过HTTP GET请求来获取状态信息。检查原理如图2所示。
HTTP健康检查机制如下:
- 服务节点根据健康检查配置,向后端服务器(IP+端口+检查路径)发出HTTP GET请求(可以选择设置域名)。
- 成员收到请求后,根据服务的情况返回相应的HTTP状态码。
- 如果服务节点在响应超时时间内收到了成员的响应,将HTTP状态码与预置的状态码进行对比,如果匹配则认为健康检查成功,成员运行正常。
- 如果服务节点在响应超时时间内没有收到成员的响应,则判定健康检查失败。
在HTTP健康检查请求中,User-Agent头字段主要用于标识此类请求为健康检查发出的探测请求。User-Agent的值可能随业务需求而动态调整,建议客户的成员请勿根据此header头做检验和判断。
健康检查时间窗
健康检查机制的引入,有效提高了业务服务的可用性。但是,为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有连续多次检查成功或失败后,才会进行状态切换。
健康检查时间窗由表1中的因素决定:
影响因素 |
说明 |
|
---|---|---|
检查间隔 |
每隔多久进行一次健康检查。 |
|
超时时间 |
等待服务器返回健康检查的时间。 |
|
最大成功重试次数 |
判定健康检查结果正常时,所需的健康检查连续成功的次数。 |
|
最大失败重试次数 |
判定健康检查结果异常时,所需的健康检查连续失败的次数。 |
健康检查时间窗的计算方法如下:
- 健康检查成功时间窗 = 超时时间×最大成功重试次数 + 检查间隔×(最大成功重试次数-1)
- 健康检查失败时间窗 = 超时时间×最大失败重试次数 + 检查间隔×(最大失败重试次数-1)
如图3所示:
- 检查间隔:4s
- 超时时间:2s
- 健康检查异常阈值:3次
健康检查检测到成员从正常到失败状态,健康检查失败时间窗 = 超时时间×最大失败重试次数+检查间隔×(最大失败重试次数-1) = 2 x 3+4 x (3-1) = 14s。