《RPC实战与核心原理》学习笔记Day8

09 | 健康检测：这个节点挂了，为啥还要疯狂发请求？

服务调用方在每次调用服务提供方的服务时，RPC框架会根据路由和负载均衡算法选择一个具体的IP地址，为了保证请求成功，我们需要确保每次选择出来的IP对应的连接是健康的。

调用方和集群节点之间的网络状况是瞬息万变的，两者之间可能会出现闪断或者网络设备损坏的情况，为了解决这个问题，我们的终极解决方案就是让调用方实时感知到节点的变化。

业内经常用来检测服务节点是否可用的方法是用心跳机制。心跳机制就是服务调用方每隔一段时间就问一下服务提供方，“兄弟，你还好吗？”，然后服务提供方诚实地告诉调用方它目前的状态。

服务提供方的状态一般会有三种情况：

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

上述三种状态是可以变转变的。

一个节点从健康状态过渡到亚健康状态的前提是连续“心跳失次数必须达到某个阈值。

只关心服务节点网络稳定，会有2个问题：

1. 调用方每个接口的调用频次不一样，有的接口可能1秒内调用上百次，有的接口可能半个小时才会被调用一次，所以我们不能简单的把失败总次数当做判断条件。
2. 服务的借口响应时间也不一样，有的接口可能1ms，有的可能是10s，我们不能使用TPS来作为谈判条件。

我们可以使用”可用率“，它的计算方式是某一个时间窗口内接口调用的成功次数的百分比。当可用率低于某个比例就认为这个节点存在问题，需要把它转移到亚健康列表，这样既考虑了高低频的调用接口，也兼顾了接口响应时间不同的问题。

我们在部署时，需要注意将检测程序部署到多个机器里面，分布在不同的机架，甚至不同的机房。