浅谈RPC中的健康检测

为什么需要健康检测

客户端在进行请求时需要选出一个健康的服务提供方IP，但是网络本身是不稳定的，我们无法保证提供的IP一定是健康的。因此我们需要引入健康检测机制，让调用方实时感知到服务节点的状态变化。（这里的客户端指注册中心）

如何实现健康检测

最常用的方法就是「心跳机制」，即调用方每隔一段时间给服务提供方发一个心跳包，询问节点状态。

首先需要引入节点的三种状态：

• 健康状态：建立连接成功，并且心跳探活也一直成功
• 亚健康状态：建立连接成功，但是心跳请求连续失败
• 死亡状态：建立连接失败

Q: 为什么需要引入一个「亚健康」的状态?

A: 如果不将半死不活的节点移出健康实例列表的话，请求可能会持续打到这个不正常的节点，导致出现错误。

在初始化的时候，如果建立连接成功，那就是健康状态，否则就是死亡状态。这里没有亚健康这样的中间态。紧接着，如果健康状态的节点连续出现几次不能响应心跳请求的情况，那就会被标记为亚健康状态，也就是说，服务调用方会觉得它生病了。

生病之后（亚健康状态），如果连续几次都能正常响应心跳请求，那就可以转回健康状态，证明病好了。如果病一直好不了，那就会被断定为是死亡节点，死亡之后还需要善后，比如关闭连接。

如果某个时间点里，死亡的节点能够重连成功，那它就可以重新被标记为健康状态。

实现过程中的一些细节

• 健康状态和亚健康状态的切换时机？

我们不能简单的根据失败次数或响应时间来进行判断。因为不同接口的调用频率和响应时间是不同的，这时我们可以考虑用「可用率」（即某个时间窗口中接口调用成功次数的百分比）来进行判断。如果可用率低于某个比例，就认为这个节点存在问题，将其移到亚健康列表中。这样既考虑了高低频的调用接口，也兼顾了接口响应时间不同的问题。

参考：何小峰老师《RPC实战与核心原理》极客时间专栏（墙裂推荐==）