RPC异步化机制详解

深入RPC，更好使用RPC，须从RPC框架整体性能考虑问题。得知道如何提升RPC框架的性能、稳定性、安全性、吞吐量及如何在分布式下快速定位问题。RPC框架如何压榨单机吞吐量？

1 前言

TPS一直上不去，压测时CPU压到40%～50%就再也压不上去，TPS也不提高，咋办？

看业务逻辑，在执行较为耗时的业务逻辑基础上，又同步调用了好几个其它服务。由于这几个服务的耗时较长，导致服务业务逻辑耗时也长，CPU大部分时间都在等待，没得到充分利用，因此CPU利用率和服务吞吐量上不去。

2 RPC调用吞吐量的影响因素

根本原因：由于处理RPC请求较耗时，且CPU大部分时间都在等待而没有去计算，导致CPU利用率不够。好比一个人干活，但他没规划好时间，且长时间都闲着，当然也就完不成太多工作。

导致RPC请求耗时的原因主要在RPC框架本身吗？除非在网络较慢或使用方使用不当，否则大多情况，刨除业务逻辑处理的耗时时间，RPC本身处理请求的效率就算在较差环境也不过ms级。可以说RPC请求耗时大部分是业务耗时，如业务逻辑中有访问DB执行慢SQL的操作。所以，大多情况，影响RPC调用吞吐量原因就是业务逻辑处理慢，CPU大部分时间都在等待资源。

找到根因，对症下药，

3 提升单机吞吐量的方案

响应式开发就是为提升业务处理的吞吐量。提升吞吐量的关键：“异步”。我们的RPC框架要做到完全异步化，实现全异步RPC。试想一下，如果我们每次发送一个异步请求，发送请求过后请求即刻就结束了，之后业务逻辑全部异步执行，结果异步通知，这样可以增加多