RPC实战与核心原理
何小锋
京东技术架构部首席架构师
立即订阅
3925 人已学习
课程目录
已更新 19 讲 / 共 28 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 别老想着怎么用好RPC框架,你得多花时间琢磨原理
免费
基础篇 (6讲)
01 | 核心原理:能否画张图解释下RPC的通信流程?
02 | 协议:怎么设计可扩展且向后兼容的协议?
03 | 序列化:对象怎么在网络中传输?
04 | 网络通信:RPC框架在网络通信上更倾向于哪种网络IO模型?
05 | 动态代理:面向接口编程,屏蔽RPC处理流程
06 | RPC实战:剖析gRPC源码,动手实现一个完整的RPC
进阶篇 (11讲)
07 | 架构设计:设计一个灵活的RPC框架
08 | 服务发现:到底是要CP还是AP?
09 | 健康检测:这个节点都挂了,为啥还要疯狂发请求?
10 | 路由策略:怎么让请求按照设定的规则发到不同的节点上?
11 | 负载均衡:节点负载差距这么大,为什么收到的流量还一样?
12 | 异常重试:在约定时间内安全可靠地重试
13 | 优雅关闭:如何避免服务停机带来的业务损失?
14 | 优雅启动:如何避免流量打到没有启动完成的节点?
15 | 熔断限流:业务如何实现自我保护?
16 | 业务分组:如何隔离流量?
答疑课堂 | 基础篇与进阶篇思考题答案合集
高级篇 (1讲)
17 | 异步RPC:压榨单机吞吐量
RPC实战与核心原理
登录|注册

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

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

一个需求

在进入主题之前,我想先和你分享一个需求,这是我们公司的业务部门给我们提的。
他们反馈的问题是这样的:有一次碰上流量高峰,他们突然发现线上服务的可用率降低了,经过排查发现,是因为其中有几台机器比较旧了。当时最早申请的一批容器配置比较低,缩容的时候留下了几台,当流量达到高峰时,这几台容器由于负载太高,就扛不住压力了。业务问我们有没有好的服务治理策略?
业务部门问题示意图
这个问题其实挺好解决的,我们当时给出的方案是:在治理平台上调低这几台机器的权重,这样的话,访问的流量自然就减少了。
但业务接着反馈了,说:当他们发现服务可用率降低的时候,业务请求已经受到影响了,这时再如此解决,需要时间啊,那这段时间里业务可能已经有损失了。紧接着他们就提出了需求,问:RPC 框架有没有什么智能负载的机制?能否及时地自动控制服务节点接收到的访问量?
这个需求其实很合理,这也是一个比较普遍的问题。确实,虽说我们的服务治理平台能够动态地控制线上服务节点接收的访问量,但当业务方发现部分机器负载过高或者响应变慢的时候再去调整节点权重,真的很可能已经影响到线上服务的可用率了。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《RPC实战与核心原理》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(8)

  • 楼下小黑哥
    以 Dubbo 为例,常用的负载均衡方法有:
    1.基于权重随机算法
    2.基于最少活跃调用数算法
    3.基于 hash 一致性
    4.基于加权轮询算法

    Dubbo 默认使用基于权重随机算法。

    轮询算法与随机算法相对来说编码比较简单,适用于集群中各个节点提供服务能力等同且无状态的场景。两个方法将服务节点性能当成一样,但是实际复杂环境,服务节点处能力不一样。这就需要我们有比重分发请求,于是加入权重属性,就有了权重的随机算法与加权轮询算法。

    另外如果某个服务节点出现问题,服务处理缓慢。轮询算法与随机算法还会持续的将请求发分到服务节点,进一步加重服务节点情况。这是一个比较大的缺点。

    最少活跃调用数算法,将会记录服务节点的活跃数,活跃数越少,表明该服务提供者效率越高,单位时间内可处理更多的请求,可以有效改善上面说的情况。

    hash 一致性算法,适用于服务有状态的的场景,但是实很少需要有状态的场景,该算法比较少使用。

    作者回复: 课代表👍

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

    作者回复: 很棒!

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

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

    2020-03-13
    2
    1
  • 一只苦逼
    打卡

    作者回复: 收到。

    2020-03-26
  • 鸳鸯戏水蝶双飞
    讲的很清楚。
    2020-03-22
  • FATMAN89
    请问老师再后续的课程中,是否会增加更多的代码实现,比如实现一个mini的rpc framework,当然老师对理论的讲解是非常精彩的
    2020-03-17
    3
  • 小鱼儿
    老师,你好。 请问,有没有具体的框架可供实施呢?比如:consul,nginx,gRPC这些。

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

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

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

    2020-03-13
    2
收起评论
8
返回
顶部