视频资源获取失败
你好,我是何小锋。从今天开始,我们就正式进入高级篇了。
在上个篇章,我们学习了 RPC 框架的基础架构和一系列治理功能,以及一些与集群管理相关的高级功能,如服务发现、健康检查、路由策略、负载均衡、优雅启停机等等。
有了这些知识储备,你就已经对 RPC 框架有了较为充分的认识。但如果你想要更深入地了解 RPC,更好地使用 RPC,你就必须从 RPC 框架的整体性能上去考虑问题了。你得知道如何去提升 RPC 框架的性能、稳定性、安全性、吞吐量,以及如何在分布式的场景下快速定位问题等等,这些都是我们在高级篇中重点要讲解的内容。难度有一定提升,希望你能坚持学习呀!
那么今天我们就先来讲讲,RPC 框架是如何压榨单机吞吐量的。
在我运营 RPC 的过程中,“如何提升吞吐量”是我与业务团队经常讨论的问题。
记得之前业务团队反馈过这样一个问题:我们的 TPS 始终上不去,压测的时候 CPU 压到 40%~50% 就再也压不上去了,TPS 也不会提高,问我们这里有没有什么解决方案可以提升业务的吞吐量?
之后我是看了下他们服务的业务逻辑,发现他们的业务逻辑在执行较为耗时的业务逻辑的基础上,又同步调用了好几个其它的服务。由于这几个服务的耗时较长,才导致这个服务的业务逻辑耗时也长,CPU 大部分的时间都在等待,并没有得到充分地利用,因此 CPU 的利用率和服务的吞吐量当然上不去了。

作者回复: 总结的很好。
作者回复: 异步对于服务提供方来说,rpc线程所要处理的事情就变少了
作者回复: 应用层异步跟网络没有关系
作者回复: 可以更灵活
作者回复: 可能用处不大,需要提高接口性能或者扩容解决