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

11 | 负载均衡:节点负载差距这么大,为什么收到的流量还一样?

课后思考
总结
如何设计自适应的负载均衡?
RPC框架中的负载均衡
什么是负载均衡?
负载均衡

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

你好,我是何小锋。上一讲我讲解了“多场景的路由选择”,其核心就是“如何根据不同的场景控制选择合适的目标机器”。今天我们来聊一个新的话题,看看在 RPC 中如何实现负载均衡。

一个需求

在进入主题之前,我想先和你分享一个需求,这是我们公司的业务部门给我们提的。
他们反馈的问题是这样的:有一次碰上流量高峰,他们突然发现线上服务的可用率降低了,经过排查发现,是因为其中有几台机器比较旧了。当时最早申请的一批容器配置比较低,缩容的时候留下了几台,当流量达到高峰时,这几台容器由于负载太高,就扛不住压力了。业务问我们有没有好的服务治理策略?
业务部门问题示意图
这个问题其实挺好解决的,我们当时给出的方案是:在治理平台上调低这几台机器的权重,这样的话,访问的流量自然就减少了。
但业务接着反馈了,说:当他们发现服务可用率降低的时候,业务请求已经受到影响了,这时再如此解决,需要时间啊,那这段时间里业务可能已经有损失了。紧接着他们就提出了需求,问:RPC 框架有没有什么智能负载的机制?能否及时地自动控制服务节点接收到的访问量?
这个需求其实很合理,这也是一个比较普遍的问题。确实,虽说我们的服务治理平台能够动态地控制线上服务节点接收的访问量,但当业务方发现部分机器负载过高或者响应变慢的时候再去调整节点权重,真的很可能已经影响到线上服务的可用率了。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

RPC框架中的负载均衡是如何实现的?本文从实际需求出发,探讨了负载均衡在RPC框架中的重要性和实现方式。首先介绍了负载均衡的基本概念,包括软负载和硬负载的区别以及常见的负载均衡算法。对比了传统Web服务和RPC框架中的负载均衡策略,指出RPC框架的负载均衡完全由框架自身实现,不再依赖于负载均衡设备,且具有灵活的负载均衡策略配置和流量控制能力。提出了解决动态、智能控制线上服务节点请求流量的关键在于设计一种自适应的负载均衡策略。通过对RPC框架的负载均衡机制的了解,读者可以更好地理解并解决类似的业务需求。 文章详细讲解了RPC框架的负载均衡,强调了其与传统Web服务的不同之处,以及自适应负载均衡的重要性。通过打分策略和权重调整,实现了智能的负载均衡,使得服务调用者可以根据服务节点的状态智能地控制请求流量,提升整个服务集群的可用率。这一自适应负载均衡的实现方案不仅适用于RPC框架,也是一个智能负载的解决方案,可供读者在工作中参考应用。 总结来说,本文深入探讨了RPC框架中负载均衡的实现和自适应负载均衡的重要性,为读者提供了深入了解和应用该技术的指导。

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

全部留言(18)

  • 最新
  • 精选
  • 楼下小黑哥
    以 Dubbo 为例,常用的负载均衡方法有: 1.基于权重随机算法 2.基于最少活跃调用数算法 3.基于 hash 一致性 4.基于加权轮询算法 Dubbo 默认使用基于权重随机算法。 轮询算法与随机算法相对来说编码比较简单,适用于集群中各个节点提供服务能力等同且无状态的场景。两个方法将服务节点性能当成一样,但是实际复杂环境,服务节点处能力不一样。这就需要我们有比重分发请求,于是加入权重属性,就有了权重的随机算法与加权轮询算法。 另外如果某个服务节点出现问题,服务处理缓慢。轮询算法与随机算法还会持续的将请求发分到服务节点,进一步加重服务节点情况。这是一个比较大的缺点。 最少活跃调用数算法,将会记录服务节点的活跃数,活跃数越少,表明该服务提供者效率越高,单位时间内可处理更多的请求,可以有效改善上面说的情况。 hash 一致性算法,适用于服务有状态的的场景,但是实很少需要有状态的场景,该算法比较少使用。

    作者回复: 课代表👍

    2020-03-13
    2
    60
  • 雨霖铃声声慢
    谈谈GRPC的负载均衡策略,grpc官方并未提供服务发现注册的功能实现,但是为不同语言的gRPC代码实现提供了可扩展的命名解析和负载均衡接口。其基本原理是:服务启动后grpc客户端向命名服务器发出名称解析请求,名称会解析为一个或多个ip地址,每个ip地址会标识它是服务器地址还是负载均衡地址,以及标识要使用的那个客户端的负载均衡策略或服务配置。客户端实例化负载均衡策略,如果解析返回的地址是负载均衡器的地址,则客户端将使用扩展的负载均衡策略,反之客户端使用服务器配置请求的负载均衡策略。负载均衡策略为每个服务器地址创建一个子通道,当有rpc请求时,负载均衡策略决定那个子通道即grpc服务器将接收请求,当可用服务器为空时客户端的请求将被阻塞。 这种方式好处是灵活,支持扩展,可以扩展满足自己需求的策略,缺点是需要自己集成,需要一定的工作量,对技术人员有一定的要求。

    作者回复: 很棒!

    2020-03-14
    21
  • 吴小智
    有点疑惑,路由策略和负载均衡的结果都是选择一个合适的服务节点,那这两个有什么区别呢?

    作者回复: 路由一般是规则设定,一般都是路由之后,负载再生效

    2020-03-13
    11
    9
  • 密码123456
    从心跳检测,到路由策略,再到本节。有个问题。心跳检测我理解,让服务提供方消耗少量的性能,来评估性能并判定是健康还是亚健康。后来说到有一个检测服务专门做这件事,然后推给服务调用方。这里又说是服务调用方,直接心跳检测。如果调用方直接调用心跳检测,对服务调用方来说检测及时。但对于提供方来说,随着调用方的增多会增加性能的损耗,如果用注册中心,感知不及时。怎么处理比较好呢?一般都是怎么做?

    作者回复: “冷暖自知”,调用方比第三方更准确知道对方状态

    2020-05-13
    3
    6
  • 第一次提问,如果系统包含一些处理时间较长的请求,例如下载一个大数据量的报表,这种请求会大大提高该服务提供者的平均请求耗时,而发现这种耗时会存在时延,调用者仍然发送了很多请求到该服务器,这种情况怎么看?

    作者回复: 可以考虑背压

    2020-04-10
    2
    6
  • 忆水寒
    老师, CPU 核数、CPU 负载以及内存等指标 有什么比较好的获取方式吗? 计算 每个服务节点的权重 这个是周期性统计计算然后在负载均衡器中更新吗?

    作者回复: 周期性实现起来最简单

    2020-04-21
    2
    5
  • 安排
    是不是每个rpc调用方,也就是客户端都存在一个智能负载均衡?那就是每个rpc调用方都能掌握全局的负载信息了,要不然无法做负载均衡?其实还是对"负载均衡由rpc框架来做"不理解,这个rpc框架是每个rpc调用方都会有一份吗?

    作者回复: 负载均衡一般都需要内置在rpc里面,用于也可以进行扩展

    2020-03-13
    8
    5
  • 一只苦逼
    打卡

    作者回复: 收到。

    2020-03-26
  • FATMAN89
    请问老师再后续的课程中,是否会增加更多的代码实现,比如实现一个mini的rpc framework,当然老师对理论的讲解是非常精彩的

    作者回复: 在文章里面输入太多代码会影响阅读和理解

    2020-03-17
    5
  • 小鱼儿
    老师,你好。 请问,有没有具体的框架可供实施呢?比如:consul,nginx,gRPC这些。

    作者回复: 选择一些支持自定义扩展的

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