rpc编程（《RPC实战与核心原理》学习笔记Day8）
09 | 健康检测：这个节点挂了 ，为啥还要疯狂发请求？
服务调用方在每次调用服务提供方的服务时 ，RPC框架会根据路由和负载均衡算法选择一个具体的IP地址 ，为了保证请求成功 ，我们需要确保每次选择出来的IP对应的连接是健康的 。
调用方和集群节点之间的网络状况是瞬息万变的 ，两者之间可能会出现闪断或者网络设备损坏的情况 ，为了解决这个问题 ，我们的终极解决方案就是让调用方实时感知到节点的变化 。
业内经常用来检测服务节点是否可用的方法是用心跳机制 。心跳机制就是服务调用方每隔一段时间就问一下服务提供方 ，“兄弟 ，你还好吗？ ” ，然后服务提供方诚实地告诉调用方它目前的状态 。
服务提供方的状态一般会有三种情况：
健康状态：建立连接成功 ，并且心跳探活也一直成功 。 亚健康状态：建立连接成功 ，但是心跳请求连续失败 。 死亡状态：建立连接失败 。上述三种状态是可以变转变的 。
一个节点从健康状态过渡到亚健康状态的前提是连续“心跳失次数必须达到某个阈值 。
只关心服务节点网络稳定 ，会有2个问题：
调用方每个接口的调用频次不一样 ，有的接口可能1秒内调用上百次 ，有的接口可能半个小时才会被调用一次 ，所以我们不能简单的把失败总次数当做判断条件 。 服务的借口响应时间也不一样 ，有的接口可能1ms ，有的可能是10s ，我们不能使用TPS来作为谈判条件 。我们可以使用 ”可用率“ ，它的计算方式是某一个时间窗口内接口调用的成功次数的百分比 。当可用率低于某个比例就认为这个节点存在问题 ，需要把它转移到亚健康列表 ，这样既考虑了高低频的调用接口 ，也兼顾了接口响应时间不同的问题 。
我们在部署时 ，需要注意将检测程序部署到多个机器里面 ，分布在不同的机架 ，甚至不同的机房 。
创心域SEO版权声明：以上内容作者已申请原创保护，未经允许不得转载，侵权必究！授权事宜、对本内容有异议或投诉，敬请联系网站管理员，我们将尽快回复您，谢谢合作！