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

视频资源获取失败

开篇词 | 别老想着怎么用好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 框架有了较为充分的认识。但如果你想要更深入地了解 RPC,更好地使用 RPC,你就必须从 RPC 框架的整体性能上去考虑问题了。你得知道如何去提升 RPC 框架的性能、稳定性、安全性、吞吐量,以及如何在分布式的场景下快速定位问题等等,这些都是我们在高级篇中重点要讲解的内容。难度有一定提升,希望你能坚持学习呀!

那么今天我们就先来讲讲,RPC 框架是如何压榨单机吞吐量的。

如何提升单机吞吐量?

在我运营 RPC 的过程中,“如何提升吞吐量”是我与业务团队经常讨论的问题。

记得之前业务团队反馈过这样一个问题:我们的 TPS 始终上不去,压测的时候 CPU 压到 40%~50% 就再也压不上去了,TPS 也不会提高,问我们这里有没有什么解决方案可以提升业务的吞吐量?

之后我是看了下他们服务的业务逻辑,发现他们的业务逻辑在执行较为耗时的业务逻辑的基础上,又同步调用了好几个其它的服务。由于这几个服务的耗时较长,才导致这个服务的业务逻辑耗时也长,CPU 大部分的时间都在等待,并没有得到充分地利用,因此 CPU 的利用率和服务的吞吐量当然上不去了。

登录 后留言

全部留言(25)

  • 最新
  • 精选
楼下小黑哥
RPC 这里远程方法调用方式,大致可以分成四种方式: - sync 默认方式,但是这只是『方法』内部同步,实际上 RPC 框架内部还是异步处理。 - future 方式,RPC 消费者得到 future,自行决定何时获取返回结果 - callback 方式,RPC 调用端不需要同步处理响应结果,可以直接返回。最后返回结果将会在回调线程异步处理 - oneway 方式,调用端发送请求之后不需要接受响应 其中 Dubbo 2.7 之后的版本,使用 CompletableFuture 提升异步的处理的能力,支持以上四种方式。

作者回复: 总结的很好。

2020-04-04
3
49
石佩
使用异步的时候返回的速度变快了,但是后台所需要的线程数会变少么?,线程池我理解应该是该被打满还是被打满

作者回复: 异步对于服务提供方来说,rpc线程所要处理的事情就变少了

2020-03-30
4
4
那个谁
rpc框架是作用于调用方服务方两端?实际上是在服务端有service, 客户端有client?然后客户端发起异步rpc调用,是说客户端本身不等待返回继续处理自身业务,而对服务端来讲,并不知道客户端是不是异步,然后服务端也是正常处理自己的业务逻辑。如果也是异步,那返回的结果是在服务端框架,然后服务端的rpc框架等完成后,返回给客户端?网络传输是不区分异步不异步,还是要等服务端执行完成,拿到正常结果后序列化到网络返回给调用方,是这么理解吗?

作者回复: 应用层异步跟网络没有关系

2020-03-30
2
1
嘻嘻
服务端异步感觉意义不大,拆分再多的线程池,最终要打满的还是会有一个线程池被打满,除非做线程池隔离。不知道理解对不对?

作者回复: 可以更灵活

2020-04-25
Josey
老师你上面说到的如果“业务线程池的线程数配置到 200”,线程池被打满了,如果单存增加线程数量有用吗?200个线程都处理不了的情况下,配置到300或者500不是只会增加cpu上下文切换的时间吗?

作者回复: 可能用处不大,需要提高接口性能或者扩容解决

2020-03-30
4
vuiolpg
我觉得作者有一部分的描述会有点误导新人,就是CPU 大部分的时间都在等待,并没有得到充分地利用,因此 CPU 的利用率和服务的吞吐量当然上不去了这段话,其实线程处于等待状态时是不占用cpu资源的,所以更准确的描述应该是浪费了宝贵的线程资源,大量线程处于等待状态,可能(不是一定)导致cpu利用率低。
2020-07-08
1
24
landon30
异步的最佳解决方案是coroutine
2020-05-27
13
JDY
老师说的是java版的rpc设计,我现在也知道了最好要用异步的方式来进行调用,但是c++的怎么实现呢?
2020-04-15
1
5
Geek_09d497
异步虽然能提高性能,但是遇到有的业务有先后顺序,如果所有请求异步,那如何保证时序呢
2020-11-19
2
4
rainj2013
我们直接用mq来做的通信,实现纯异步的rpc
2020-06-19
2
4
收起评论