为什么需要健康检测
客户端在进行请求时需要选出一个健康的服务提供方IP,但是网络本身是不稳定的,我们无法保证提供的IP一定是健康的。因此我们需要引入健康检测机制,让调用方实时感知到服务节点的状态变化。(这里的客户端指注册中心)
如何实现健康检测
最常用的方法就是「心跳机制」,即调用方每隔一段时间给服务提供方发一个心跳包,询问节点状态。
首先需要引入节点的三种状态:
- 健康状态:建立连接成功,并且心跳探活也一直成功
- 亚健康状态:建立连接成功,但是心跳请求连续失败
- 死亡状态:建立连接失败
Q: 为什么需要引入一个「亚健康」的状态?
A: 如果不将半死不活的节点移出健康实例列表的话,请求可能会持续打到这个不正常的节点,导致出现错误。
在初始化的时候,如果建立连接成功,那就是健康状态,否则就是死亡状态。这里没有亚健康这样的中间态。紧接着,如果健康状态的节点连续出现几次不能响应心跳请求的情况,那就会被标记为亚健康状态,也就是说,服务调用方会觉得它生病了。
生病之后(亚健康状态),如果连续几次都能正常响应心跳请求,那就可以转回健康状态,证明病好了。如果病一直好不了,那就会被断定为是死亡节点,死亡之后还需要善后,比如关闭连接。
如果某个时间点里,死亡的节点能够重连成功,那它就可以重新被标记为健康状态。
实现过程中的一些细节
- 健康状态和亚健康状态的切换时机?
我们不能简单的根据失败次数或响应时间来进行判断。因为不同接口的调用频率和响应时间是不同的,这时我们可以考虑用「可用率」(即某个时间窗口中接口调用成功次数的百分比)来进行判断。如果可用率低于某个比例,就认为这个节点存在问题,将其移到亚健康列表中。这样既考虑了高低频的调用接口,也兼顾了接口响应时间不同的问题。
参考:何小峰老师《RPC实战与核心原理》极客时间专栏(墙裂推荐==)