RPC 实战与核心原理
何小锋
京东云混合云首席架构师
40244 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 29 讲
RPC 实战与核心原理
15
15
1.0x
00:00/00:00
登录|注册

09 | 健康检测:这个节点都挂了,为啥还要疯狂发请求?

课后思考
总结
具体的解决方案
健康检测的逻辑
遇到的问题
RPC中的健康检测
介绍
RPC框架中的健康检测

该思维导图由 AI 生成,仅供参考

你好,我是何小锋。上一讲我们介绍了超大规模集群“服务发现”的挑战,服务发现的作用就是实时感知集群 IP 的变化,实现接口跟服务集群节点 IP 的映射。在超大规模集群实战中,我们更多需要考虑的是保证最终一致性。其实总结来说,就一关键词,你要记住“推拉结合,以拉为准”。接着昨天的内容,我们再来聊聊 RPC 中的健康检测。
因为有了集群,所以每次发请求前,RPC 框架会根据路由和负载均衡算法选择一个具体的 IP 地址。为了保证请求成功,我们就需要确保每次选择出来的 IP 对应的连接是健康的,这个逻辑你应该理解。
但你也知道,调用方跟服务集群节点之间的网络状况是瞬息万变的,两者之间可能会出现闪断或者网络设备损坏等情况,那怎么保证选择出来的连接一定是可用的呢?
从我的角度看,终极的解决方案是让调用方实时感知到节点的状态变化这样他们才能做出正确的选择。这个道理像我们开车一样,车有各种各样的零件,我们不可能在开车之前先去挨个检查下他们的健康情况,转而是应该有一套反馈机制,比如今天我的大灯坏了,那中控台就可以给我提示;明天我的胎压不够了,中控台也能够收到提示。汽车中大部分关键零件的状态变化,我作为调用方,都能够第一时间了解。
那回到 RPC 框架里,我们应该怎么设计这套机制呢?你可以先停下来想想汽车的例子,看看他们是怎么做的。当然,回到我们 RPC 的框架里,这事用专业一点的词来说就是服务的健康检测。今天我们就来详细聊聊这个话题。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

RPC框架中的健康检测是确保请求成功的关键环节。本文通过讲述一个线上问题的案例,引出了对健康检测逻辑的讨论。作者提到了服务健康状态的三种情况:健康状态、亚健康状态和死亡状态,并介绍了通过心跳机制来实现节点状态的动态变化。文章强调了服务检测机制的重要性,以及如何通过心跳机制来实现对节点状态的实时感知,从而保证请求的可靠性。通过对节点状态转换的解释,读者可以清晰地了解健康检测的逻辑和实现方式。文章内容通俗易懂,为读者提供了对RPC框架中健康检测的深入理解。此外,文章还提到了在设计健康检测方案时,需要考虑业务请求可用率因素,以最大化提升RPC接口可用率。另外,文章还探讨了在其它分布式系统设计中使用心跳探活机制的应用,以及如何减少误判的几率。整体而言,本文为读者提供了对健康检测在RPC框架中的重要性和实现方式的全面了解,同时也引发了读者对于健康检测在其它系统设计中的思考。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《RPC 实战与核心原理》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(36)

  • 最新
  • 精选
  • 楼下小黑哥
    以前做过类似健康检查。 我们有个服务,需要通过银行安装在我们后台软件向银行分发交易。这个软件我们在使用过程发现会无故挂掉,为了能及时检测这种情况。 我通过 openresty 写了一个小插件、通过 http 接口访问银行软件,查看银行软件是否挂了。然后接入 钉钉 webhook,触发机器人报警。 这个健康检查啊我有个特别深刻记忆。由于当时是将 openresty 跟银行软件部署在同一台物理机器上去。某一天,整台机器挂了,报警机制当然也失效了。 通过这件事,我现在每次部署服务时,会注意将服务部署在不同物理机器上,防止意外发生。

    作者回复: 历史总是深刻

    2020-03-11
    3
    47
  • etdick
    成功次数/调用总次数,建议加上总次数阀值。如果2次,一次成功,一次失败,就可能误判。例如调用总数>10次以上,成次数/调用次数<50%,才比较准确

    作者回复: 还是需要分场景对待的,没有最好的,只有最合适的。

    2020-03-12
    2
    29
  • 魔曦
    心跳检测需要分两个纬度,一个机器本身的,一个是应用,单纬度肯定会出问题

    作者回复: 是的

    2020-03-27
    3
    16
  • Darren
    之前使用过返回状态保存在MQ中,有专门的消费者去消费消息,其中要是失败率大于阈值,直接调用注册中心,下线该服务,同时使用agent机制,自动重启有问题的服务,之后要是还会出现失败,则报警发出,人工介入。

    作者回复: 失败率统计是难点,需要考虑是否有网络设备坏或者不同idc问题

    2020-03-17
    13
  • 嘻嘻
    老师,几个问题: 1.上面说的基于失败率统计的方案,不就是熔断吗? 2.心跳检测,这个从调用方发心跳到服务方,会不会太重,基于熔断是不是就可以了 3.后面又说心跳检测可以放在多台机器去综合判断,刚刚不是说由调用方发起心跳吗?又变成第三方心跳检测了? 我理解这里有注册中心做心跳,再加熔断,失败重试等就可以了,不知道对不对

    作者回复: 调用方到提供方之间心跳正常才能保证链路没有问题

    2020-04-24
    2
    7
  • 老师我认为心跳检测不应该接口的调用方来检测,这样的话调用接口的客户端量很大时,只是心跳检测就会把服务提供方的资源打满,而且当接口服务提供方很多时,客户端每个ip去健康检测也是不可能的

    作者回复: 不一定要接口纬度,一般情况下多个接口直接会共享tcp连接的,可以用tcp连接纬度

    2020-03-10
    5
    3
  • 🌀Pick Monster 🌀
    老师,内容看明白了,可用率这个指标具体怎么实现呢?因为一般使用RPC框架都是三方框架,我们是需要自己对三方接口进行重新实现吗?

    作者回复: 看看有没有插件支持

    2020-03-09
    3
  • ant
    心跳检测,单一纬度的标准始终差点意思。还是要结合业务场景,多维度判断,来保证结果准确性。例如 连续失败是最直接的纬度,可以综合考虑变更为 单位时间内失败次数,或单位次数的成功率

    作者回复: 没错

    2020-04-13
    2
  • 每天晒白牙
    想请教老师,RPC 框架的心跳检测怎么做的呢?只听说过心跳检测这个概念,但在代码层面如何做,没有概念。看到老师在最后提到检测应用是否可用,可以在应用实例中开一个 url 供检测程序发 http 请求检测。但非应用级别的心跳检测也是这样做的吗?

    作者回复: 定时发心跳消息是最简单的方法,通过判断是否正常响应

    2020-03-09
    2
    2
  • dancer
    有一个地方没想明白,希望老师能解答一下。如果在多个机房部房部署探活程序,如果部分检测有问题 部分检测没有问题,这个状态需要怎么判断,又该怎样同步给所有探活程序?

    作者回复: 多机房主要担心跨机房网络问题,只要有存活的就认为存活

    2020-04-30
    1
收起评论
显示
设置
留言
36
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部