RPC框架：10万QPS下如何实现毫秒级的服务调用？

我们已经决定对系统做服务化拆分，以便解决扩展性和研发成本高的问题。与此同时，我们在不断学习的过程中还发现，系统做了服务化拆分 之后，会引入一些新的问题，这些问题我在上节课提到过，归纳起来主要是两点：

• 服务拆分单独部署后，引入的服务跨网络通信的问题；
• 在拆分成多个小服务之后，服务如何治理的问题；

如果想要解决这两方面问题，就需要了解，微服务化所需要的中间件的基本原理，和使用技巧，我们先解决第一点问题的核心组件：RPC 框架。

来思考这样一个场景：我们的系统的 QPS 已经达到了每秒 2 万次，在做了服务化拆 分之后，由于我们把业务逻辑，都拆分到了单独部署的服务中，那么假设你在完成一次完整 的请求时，需要调用 4~5 次服务，计算下来，RPC 服务需要承载大概每秒 10 万次的请 求。那么，你该如何设计 RPC 框架，来承载如此大的请求量呢？我们要做的是：

• 选择合适的网络模型，有针对性地调整网络参数，以优化网络传输性能；
• 选择合适的序列化方式，以提升封包、解包的性能；

RPC

说到 RPC(Remote Procedure Call，远程过程调用)，我们并不陌生，它指的是通过网络，调用另一台计算机上部署服务的技术。

而 RPC 框架就封装了网络调用的细节，让你像调用本地服务一样，调用远程部署的服务。 也许我们觉得只有像 Dubbo、Grpc、Thrift 这些新兴的框架才算是 RPC 框架，其实严格来 说，很早之前就接触到与 RPC 相关的技术了。

RPC 并不是互联网时代的产物，也不是服务化之后才衍生出来的技术，而是一种规范，只要是封装了网络调用的细节，能够实现远程调用其他服务，就可以算作是一种 RPC 技术了。

那么我们的垂直电商项目在使用 RPC 框架之后，会产生什么变化呢？

在性能上的变化是不可忽视的，举个例子。 比方说，你的电商系统中， 商品详情页面需要商品数据、评论数据还有店铺数据，如果在一体化的架构中，你需要从商品库，评论库和店铺库获取数据