RPC 实战与核心原理
何小锋
京东云混合云首席架构师
41883 人已学习
新⼈⾸单¥59
课程目录
已完结/共 29 讲
RPC 实战与核心原理
登录|注册
留言
18
收藏
沉浸
阅读
分享
手机端
回顶部
付费课程,可试看

视频资源获取失败

开篇词 | 别老想着怎么用好RPC框架,你得多花时间琢磨原理
01 | 核心原理:能否画张图解释下RPC的通信流程?
02 | 协议:怎么设计可扩展且向后兼容的协议?
03 | 序列化:对象怎么在网络中传输?
04 | 网络通信:RPC框架在网络通信上更倾向于哪种网络IO模型?
05 | 动态代理:面向接口编程,屏蔽RPC处理流程
06 | RPC实战:剖析gRPC源码,动手实现一个完整的RPC
07 | 架构设计:设计一个灵活的RPC框架
08 | 服务发现:到底是要CP还是AP?
09 | 健康检测:这个节点都挂了,为啥还要疯狂发请求?
10 | 路由策略:怎么让请求按照设定的规则发到不同的节点上?
11 | 负载均衡:节点负载差距这么大,为什么收到的流量还一样?
12 | 异常重试:在约定时间内安全可靠地重试
13 | 优雅关闭:如何避免服务停机带来的业务损失?
14 | 优雅启动:如何避免流量打到没有启动完成的节点?
15 | 熔断限流:业务如何实现自我保护?
16 | 业务分组:如何隔离流量?
答疑课堂 | 基础篇与进阶篇思考题答案合集
17 | 异步RPC:压榨单机吞吐量
18 | 安全体系:如何建立可靠的安全体系?
19 | 分布式环境下如何快速定位问题?
20 | 详解时钟轮在RPC中的应用
21 | 流量回放:保障业务技术升级的神器
22 | 动态分组:超高效实现秒级扩缩容
23 | 如何在没有接口的情况下进行RPC调用?
24 | 如何在线上环境里兼容多种RPC协议?
结束语 | 学会从优秀项目的源代码中挖掘知识
加餐 | 谈谈我所经历过的RPC
加餐 | RPC框架代码实例详解
本节摘要

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

一个需求

在进入主题之前,我想先和你分享一个需求,这是我们公司的业务部门给我们提的。

他们反馈的问题是这样的:有一次碰上流量高峰,他们突然发现线上服务的可用率降低了,经过排查发现,是因为其中有几台机器比较旧了。当时最早申请的一批容器配置比较低,缩容的时候留下了几台,当流量达到高峰时,这几台容器由于负载太高,就扛不住压力了。业务问我们有没有好的服务治理策略?

这个问题其实挺好解决的,我们当时给出的方案是:在治理平台上调低这几台机器的权重,这样的话,访问的流量自然就减少了。

但业务接着反馈了,说:当他们发现服务可用率降低的时候,业务请求已经受到影响了,这时再如此解决,需要时间啊,那这段时间里业务可能已经有损失了。紧接着他们就提出了需求,问:RPC 框架有没有什么智能负载的机制?能否及时地自动控制服务节点接收到的访问量?

这个需求其实很合理,这也是一个比较普遍的问题。确实,虽说我们的服务治理平台能够动态地控制线上服务节点接收的访问量,但当业务方发现部分机器负载过高或者响应变慢的时候再去调整节点权重,真的很可能已经影响到线上服务的可用率了。

登录 后留言

全部留言(18)

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

作者回复: 课代表👍

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

作者回复: 很棒!

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

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

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
收起评论