手绘4 张图带你入门 RPC 服务框架

什么是 RPC？

RPC 的英文全称是：Remote Procedure Call，中文常见翻译：远程过程调用。

「过程」这个词着实让人费解，也不知道最开始是谁翻译过来的，个人觉得应该翻译成：程序、方法、服务，这几个都比「过程」要好。

后面为了方便理解，我们统一一下术语，RPC 翻译为：远程服务调用。这里的「服务」是指程序接口、方法这一类资源。

那到底什么是 RPC 呢？比较正式的定义是：一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的思想。

没看懂？说的通俗一点就是：客户端在不知道调用细节的情况下，调用存在于远程计算机上的某个对象，就像调用本地应用程序中的对象一样。

听懂了一些，好像又没完全懂，那说人话吧。比如说有两台服务器：A 和 B，一个应用部署在 A 服务器上，想要调用 B 服务器上某个应用提供的函数/方法，

由于跨应用跨服务器，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据，这种调用的方式就是 RPC，如下图所示。

如果在一个应用内直接调用， 这就是本地调用了，如下图所示。

为什么需要 RPC？

上面简单介绍了一下 RPC 是什么，那大家有没有想过为什么需要 RPC？一项新技术出来总是为了解决某些实际的业务或架构问题。

下面以电商业务为例介绍一下技术架构的演变。

单体架构

通俗地讲，「单体应用」就是将应用程序的所有功能都打成一个部署包。

从上面的架构图总结一下单体架构的特点：

• 所有的功能集成在一个项目工程中；

• 通过分层架构，上层调用下层接口，所有的调用都在应用内完成；

• 所有的功能打一个 war 包部署到服务器；

• 应用与数据库分开部署；

当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。当流量稍微大一点可以通过部署应用集群和数据库集群来提高系统的性能。

随着业务逐渐复杂，应用的外部流量压力增加，团队成员越来越多，单体应用架构的缺点也就慢慢暴露了。

缺点一：持续交付周期拉长

单体应用变大后构建和部署时间也相应地延长，不利于频繁部署，阻碍持续交付。即使在仅仅更改了一行代码的情况下，软件开发人员需要花费几十分钟甚至超过一个小时的时间对所有代码进行编译，并接下来花费大量的时间重新部署刚刚生成的产品，以验证自己的更改是否正确。

缺点二：高耦合

某个模块出现了死循环，导致内存溢出，整个应用都会挂掉。

缺点三：伸缩性差

系统的扩容只能针对应用进行扩容，不能做到对某个功能模块进行扩容，扩容后必然带来资源浪费的问题。

缺点四：技术栈受限

单应用内一般只会选择同一种技术栈，比如说很少在一个应用内同时才用 Java 和 Go 语言。

为了解决这些问题，微服务架构就应运而生了。

微服务架构

目前我们所说的微服务架构是经过了多年的迭代发展而形成，像以前用的 SOAP、ESB 等技术这里就不再赘述了。

单体架构发展到一定阶段必然会遇到瓶颈，怎么解决呢？首先想到的办法就是把单体架构进行拆分，大的问题难以解决就把它拆分成小的问题逐个解决，这就是分而治之的思想。

我们试着把前面的单体架构根据业务模块拆分为多个微服务：商品服务、购物车服务、订单服务、用户服务等等。

这些微服务在之前的单体应用架构中可能是一个业务模块，业务模块之前的调用直接使用本地调用即可。

服务拆分后，这些微服务可能部署在不同的机器节点上，那服务间如何调用呢？

这个时候就该我们的女主角 RPC 闪亮登场了，RPC 就是为了解决远程服务间调用问题。关于RPC 如何实现调用以及内部原理，后面的文章会详细讲解，这里只是简单引入一下，大家有个大致的概念即可。

服务间调用的问题解决了，我们会发现微服务架构有很多优点：

优点一：团队独立

团队根据微服务划分职责，微服务可独立编译、测试、部署，依赖关系清晰明了。

优点二：技术栈独立

各服务可根据业务特点自行选择技术栈，对外暴露的接口与具体实现无关。

优点三：易伸缩

业务团队可根据实际的负载情况动态决定部署规模，避免资源浪费。

小结

RPC 是一种思想，客户端在不知道调用细节的情况下，调用存在于远程计算机上的某个对象，就像调用本地应用程序中的对象一样。

RPC 的主要功能目标是让构建分布式计算（应用）更容易，在提供强大的远程调用能力时不损失本地调用的语义简洁性。

为实现该目标，RPC 框架需提供一种透明调用机制让使用者不必显式的区分本地调用和远程调用。