什么是 RPCRPC 的英文全称是Remote Procedure Call中文常见翻译远程过程调用。「过程」这个词着实让人费解也不知道最开始是谁翻译过来的个人觉得应该翻译成程序、方法、服务这几个都比「过程」要好。后面为了方便理解我们统一一下术语RPC 翻译为远程服务调用。这里的「服务」是指程序接口、方法这一类资源。那到底什么是 RPC 呢比较正式的定义是一种通过网络从远程计算机程序上请求服务而不需要了解底层网络技术的思想。没看懂说的通俗一点就是客户端在不知道调用细节的情况下调用存在于远程计算机上的某个对象就像调用本地应用程序中的对象一样。听懂了一些好像又没完全懂那说人话吧。比如说有两台服务器A 和 B一个应用部署在 A 服务器上想要调用 B 服务器上某个应用提供的函数/方法由于跨应用跨服务器不能直接调用需要通过网络来表达调用的语义和传达调用的数据这种调用的方式就是 RPC如下图所示。如果在一个应用内直接调用 这就是本地调用了如下图所示。为什么需要 RPC上面简单介绍了一下 RPC 是什么那大家有没有想过为什么需要 RPC一项新技术出来总是为了解决某些实际的业务或架构问题。下面以电商业务为例介绍一下技术架构的演变。单体架构通俗地讲「单体应用」就是将应用程序的所有功能都打成一个部署包。从上面的架构图总结一下单体架构的特点所有的功能集成在一个项目工程中通过分层架构上层调用下层接口所有的调用都在应用内完成所有的功能打一个 war 包部署到服务器应用与数据库分开部署当网站流量很小时只需一个应用将所有功能都部署在一起以减少部署节点和成本。当流量稍微大一点可以通过部署应用集群和数据库集群来提高系统的性能。随着业务逐渐复杂应用的外部流量压力增加团队成员越来越多单体应用架构的缺点也就慢慢暴露了。缺点一持续交付周期拉长单体应用变大后构建和部署时间也相应地延长不利于频繁部署阻碍持续交付。即使在仅仅更改了一行代码的情况下软件开发人员需要花费几十分钟甚至超过一个小时的时间对所有代码进行编译并接下来花费大量的时间重新部署刚刚生成的产品以验证自己的更改是否正确。缺点二高耦合某个模块出现了死循环导致内存溢出整个应用都会挂掉。缺点三伸缩性差系统的扩容只能针对应用进行扩容不能做到对某个功能模块进行扩容扩容后必然带来资源浪费的问题。缺点四技术栈受限单应用内一般只会选择同一种技术栈比如说很少在一个应用内同时才用 Java 和 Go 语言。为了解决这些问题微服务架构就应运而生了。微服务架构目前我们所说的微服务架构是经过了多年的迭代发展而形成像以前用的 SOAP、ESB 等技术这里就不再赘述了。单体架构发展到一定阶段必然会遇到瓶颈怎么解决呢首先想到的办法就是把单体架构进行拆分大的问题难以解决就把它拆分成小的问题逐个解决这就是分而治之的思想。我们试着把前面的单体架构根据业务模块拆分为多个微服务商品服务、购物车服务、订单服务、用户服务等等。这些微服务在之前的单体应用架构中可能是一个业务模块业务模块之前的调用直接使用本地调用即可。服务拆分后这些微服务可能部署在不同的机器节点上那服务间如何调用呢这个时候就该我们的女主角 RPC 闪亮登场了RPC 就是为了解决远程服务间调用问题。关于RPC 如何实现调用以及内部原理后面的文章会详细讲解这里只是简单引入一下大家有个大致的概念即可。服务间调用的问题解决了我们会发现微服务架构有很多优点优点一团队独立团队根据微服务划分职责微服务可独立编译、测试、部署依赖关系清晰明了。优点二技术栈独立各服务可根据业务特点自行选择技术栈对外暴露的接口与具体实现无关。优点三易伸缩业务团队可根据实际的负载情况动态决定部署规模避免资源浪费。小结RPC 是一种思想客户端在不知道调用细节的情况下调用存在于远程计算机上的某个对象就像调用本地应用程序中的对象一样。RPC 的主要功能目标是让构建分布式计算应用更容易在提供强大的远程调用能力时不损失本地调用的语义简洁性。为实现该目标RPC 框架需提供一种透明调用机制让使用者不必显式的区分本地调用和远程调用。