JavaEdge全是干货的技术号

TPS一直上不去，压测时CPU压到40%～50%就再也压不上去，TPS也不提高，咋办？看业务逻辑，在执行较为耗时的业务逻辑基础上，又同步调用了好几个其它服务。由于这几个服务的耗时较长，导致服务业务逻辑耗时也长，CPU大部分时间都在等待，没得到充分利用，因此CPU利用率和服务吞吐量上不去。影响RPC调用的吞吐量主要原因：服务端的业务逻辑比较耗时，并且CPU大部分时间都在等待而没有去计算，导致CPU利用率不够，而提升单机吞吐量的最好办法就是使用异步RPC。RPC框架的异步策略主要是调用端异步与服务端异步。

RPC常用于解决内网应用之间的调用，内网环境相对公网也没有那么恶劣，也要去建立一套可控的安全体系，去防止一些错误行为。对RPC，我们所关心的安全问题不会有公网应用那么复杂，我们只要保证让服务调用方能拿到真实的服务提供方IP地址集合，且服务提供方可以管控调用自己的应用就够了。安全级别较低，服务端直接提供或者网关代劳。

灰度发布可通过路由功能完成像定点调用、黑白名单等一些高级服务治理功能。在RPC里，不管是哪种路由策略，核心思想都一样：让请求按设定规则发到目标节点，实现流量隔离。

我们都知道软件开发的过程很复杂，不仅是因为业务需求经常变化，更难的是在开发过程中要保证团队成员的目标统一。我们需要用一种可沟通的话语、可“触摸”的愿景达成目标，我认为这就是软件架构设计的意义。但仅从功能角度设计出的软件架构并不够健壮，系统不仅要能正确地运行，还要以最低的成本进行可持续的维护，因此我们十分有必要关注系统的可扩展性。只有这样，才能满足业务变化的需求，让系统的生命力不断延伸。

实现了这两个过程，我们就可以完成一个点对点的 RPC 功能，但在实际使用的时候，我们的服务提供方通常都是以一个集群的方式对外提供服务的，所以在 gRPC 里面你还可以看到负载均衡、服务发现等功能。而且 gRPC 采用的是 HTTP/2 协议，我们还可以通过 Stream 方式来调用服务，以提升调用性能。总的来说，其实我们可以简单地认为gRPC 就是采用 HTTP/2 协议，并且默认采用 PB 序列化方式的一种 RPC。

因为代理类是在运行中生成的，那么代理框架生成代理类的速度、生成代理类的字节码大小等等，都会影响到其性能——生成的字节码越小，运行所占资源就越小。还有就是我们生成的代理类，是用于接口方法请求拦截的，所以每次调用接口方法的时候，都会执行生成的代理类，这时生成的代理类的执行效率就需要很高效。最后一个是从我们的使用角度出发的，我们肯定希望选择一个使用起来很方便的代理类框架，比如我们可以考虑：API设计是否好理解、社区活跃度、还有就是依赖复杂度等。

RPC里协议的作用就类似文字中的符号，作为应用拆解请求消息的边界，保证二进制数据经过网络传输后，还能被正确地还原语义，避免调用方跟被调用方之间的“鸡同鸭讲”。