09 | 健康检测:这个节点都挂了,为啥还要疯狂发请求?
何小锋
该思维导图由 AI 生成,仅供参考
你好,我是何小锋。上一讲我们介绍了超大规模集群“服务发现”的挑战,服务发现的作用就是实时感知集群 IP 的变化,实现接口跟服务集群节点 IP 的映射。在超大规模集群实战中,我们更多需要考虑的是保证最终一致性。其实总结来说,就一关键词,你要记住“推拉结合,以拉为准”。接着昨天的内容,我们再来聊聊 RPC 中的健康检测。
因为有了集群,所以每次发请求前,RPC 框架会根据路由和负载均衡算法选择一个具体的 IP 地址。为了保证请求成功,我们就需要确保每次选择出来的 IP 对应的连接是健康的,这个逻辑你应该理解。
但你也知道,调用方跟服务集群节点之间的网络状况是瞬息万变的,两者之间可能会出现闪断或者网络设备损坏等情况,那怎么保证选择出来的连接一定是可用的呢?
从我的角度看,终极的解决方案是让调用方实时感知到节点的状态变化,这样他们才能做出正确的选择。这个道理像我们开车一样,车有各种各样的零件,我们不可能在开车之前先去挨个检查下他们的健康情况,转而是应该有一套反馈机制,比如今天我的大灯坏了,那中控台就可以给我提示;明天我的胎压不够了,中控台也能够收到提示。汽车中大部分关键零件的状态变化,我作为调用方,都能够第一时间了解。
那回到 RPC 框架里,我们应该怎么设计这套机制呢?你可以先停下来想想汽车的例子,看看他们是怎么做的。当然,回到我们 RPC 的框架里,这事用专业一点的词来说就是服务的健康检测。今天我们就来详细聊聊这个话题。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
RPC框架中的健康检测是确保请求成功的关键环节。本文通过讲述一个线上问题的案例,引出了对健康检测逻辑的讨论。作者提到了服务健康状态的三种情况:健康状态、亚健康状态和死亡状态,并介绍了通过心跳机制来实现节点状态的动态变化。文章强调了服务检测机制的重要性,以及如何通过心跳机制来实现对节点状态的实时感知,从而保证请求的可靠性。通过对节点状态转换的解释,读者可以清晰地了解健康检测的逻辑和实现方式。文章内容通俗易懂,为读者提供了对RPC框架中健康检测的深入理解。此外,文章还提到了在设计健康检测方案时,需要考虑业务请求可用率因素,以最大化提升RPC接口可用率。另外,文章还探讨了在其它分布式系统设计中使用心跳探活机制的应用,以及如何减少误判的几率。整体而言,本文为读者提供了对健康检测在RPC框架中的重要性和实现方式的全面了解,同时也引发了读者对于健康检测在其它系统设计中的思考。
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《RPC 实战与核心原理》,新⼈⾸单¥59
《RPC 实战与核心原理》,新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(36)
- 最新
- 精选
- 楼下小黑哥以前做过类似健康检查。 我们有个服务,需要通过银行安装在我们后台软件向银行分发交易。这个软件我们在使用过程发现会无故挂掉,为了能及时检测这种情况。 我通过 openresty 写了一个小插件、通过 http 接口访问银行软件,查看银行软件是否挂了。然后接入 钉钉 webhook,触发机器人报警。 这个健康检查啊我有个特别深刻记忆。由于当时是将 openresty 跟银行软件部署在同一台物理机器上去。某一天,整台机器挂了,报警机制当然也失效了。 通过这件事,我现在每次部署服务时,会注意将服务部署在不同物理机器上,防止意外发生。
作者回复: 历史总是深刻
2020-03-11347 - etdick成功次数/调用总次数,建议加上总次数阀值。如果2次,一次成功,一次失败,就可能误判。例如调用总数>10次以上,成次数/调用次数<50%,才比较准确
作者回复: 还是需要分场景对待的,没有最好的,只有最合适的。
2020-03-12229 - 魔曦心跳检测需要分两个纬度,一个机器本身的,一个是应用,单纬度肯定会出问题
作者回复: 是的
2020-03-27316 - Darren之前使用过返回状态保存在MQ中,有专门的消费者去消费消息,其中要是失败率大于阈值,直接调用注册中心,下线该服务,同时使用agent机制,自动重启有问题的服务,之后要是还会出现失败,则报警发出,人工介入。
作者回复: 失败率统计是难点,需要考虑是否有网络设备坏或者不同idc问题
2020-03-1713 - 嘻嘻老师,几个问题: 1.上面说的基于失败率统计的方案,不就是熔断吗? 2.心跳检测,这个从调用方发心跳到服务方,会不会太重,基于熔断是不是就可以了 3.后面又说心跳检测可以放在多台机器去综合判断,刚刚不是说由调用方发起心跳吗?又变成第三方心跳检测了? 我理解这里有注册中心做心跳,再加熔断,失败重试等就可以了,不知道对不对
作者回复: 调用方到提供方之间心跳正常才能保证链路没有问题
2020-04-2427 - 奕老师我认为心跳检测不应该接口的调用方来检测,这样的话调用接口的客户端量很大时,只是心跳检测就会把服务提供方的资源打满,而且当接口服务提供方很多时,客户端每个ip去健康检测也是不可能的
作者回复: 不一定要接口纬度,一般情况下多个接口直接会共享tcp连接的,可以用tcp连接纬度
2020-03-1053 - 🌀Pick Monster 🌀老师,内容看明白了,可用率这个指标具体怎么实现呢?因为一般使用RPC框架都是三方框架,我们是需要自己对三方接口进行重新实现吗?
作者回复: 看看有没有插件支持
2020-03-093 - ant心跳检测,单一纬度的标准始终差点意思。还是要结合业务场景,多维度判断,来保证结果准确性。例如 连续失败是最直接的纬度,可以综合考虑变更为 单位时间内失败次数,或单位次数的成功率
作者回复: 没错
2020-04-132 - 每天晒白牙想请教老师,RPC 框架的心跳检测怎么做的呢?只听说过心跳检测这个概念,但在代码层面如何做,没有概念。看到老师在最后提到检测应用是否可用,可以在应用实例中开一个 url 供检测程序发 http 请求检测。但非应用级别的心跳检测也是这样做的吗?
作者回复: 定时发心跳消息是最简单的方法,通过判断是否正常响应
2020-03-0922 - dancer有一个地方没想明白,希望老师能解答一下。如果在多个机房部房部署探活程序,如果部分检测有问题 部分检测没有问题,这个状态需要怎么判断,又该怎样同步给所有探活程序?
作者回复: 多机房主要担心跨机房网络问题,只要有存活的就认为存活
2020-04-301
收起评论