深刻理解RPC——你看或没看见 它都在那里

随着企业 IT 服务的不断发展，单台服务器逐渐没法承受用户日益增加的请求压力时，就须要多台服务器联合起来构成「服务集群」共同对外提供服务。同时业务服务会随着产品需求的增多愈来愈肿，架构上必须进行服务拆分，一个完整的大型服务会被打散成不少不少独立的小服务，每一个小服务会由独立的进程去管理来对外提供服务，这就是「微服务」。

当用户的请求到来时，咱们须要将用户的请求分散到多个服务去各自处理，而后又须要将这些子服务的结果汇总起来呈现给用户。那么服务之间该使用何种方式进行交互就是须要解决的核心问题。RPC 就是为解决服务之间信息交互而发明和存在的。

什么是 RPC ？

RPC (Remote Procedure Call)即远程过程调用，是分布式系统常见的一种通讯方法，已经有 40 多年历史。当两个物理分离的子系统须要创建逻辑上的关联时，RPC 是牵线搭桥的常见技术手段之一。除 RPC 以外，常见的多系统数据交互方案还有分布式消息队列、HTTP 请求调用、数据库和分布式缓存等。

其中 RPC 和 HTTP 调用是没有通过中间件的，它们是端到端系统的直接数据交互。HTTP 调用其实也能够当作是一种特殊的 RPC，只不过传统意义上的 RPC 是指长链接数据交互，而 HTTP 通常是指即用即走的短连接。

RPC 在咱们熟知的各类中间件中都有它的身影。Nginx/Redis/MySQL/Dubbo/Hadoop/Spark/Tensorflow 等重量级开源产品都是在 RPC 技术的基础上构建出来的，咱们这里说的 RPC 指的是广义的 RPC，也就是分布式系统的通讯技术。RPC 在技术中的地位比如咱们身边的空气，它无处不在，可是又有不少人根本不知道它的存在。

Nginx 与 RPC

Ngnix 是互联网企业使用最为普遍的代理服务器。它能够为后端分布式服务提供负载均衡的功能，它能够将后端多个服务地址聚合为单个地址来对外提供服务。如图，Django 是 Python 技术栈最流行的 Web 框架。

Nginx 和后端服务之间的交互在本质上也能够理解为 RPC 数据交互。也许你会争辩说 Nginx 和后端服务之间使用的是 HTTP 协议，走的是短链接，严格上不能算是 RPC 调用。

你说的没错，不过 Nginx 和后端服务之间还能够走其它的协议，好比 uwsgi 协议、fastcgi 协议等，这两个协议都是采用了比 HTTP 协议更加节省流量的二进制协议。如上图所示，uWSGI 是著名的 Python 容器，使用它能够启动 uwsgi 协议的服务器对外提供服务。

uwsgi 通信协议在 Python 语言体系里使用很是广泛，若是一个企业内部使用 Python 语言栈搭建 Web 服务，那么他们在生产环境部署 Python 应用的时候不是在使用 HTTP 协议就是在使用 uwsgi 协议来和 Nginx 之间创建通信。

Fastcgi 协议在 PHP 语言体系里很是常见，Nginx 和 PHP-fpm 进程之间通常较常使用 Fastcgi 协议进行通信。

Hadoop 与 RPC

在大数据技术领域，RPC 也占据了很是重要的地位。大数据领域普遍应用了很是多的分布式技术，分布式意味着节点的物理隔离，隔离意味着须要通讯，通讯意味着 RPC 的存在。大数据须要通讯的量比业务系统更加庞大，因此在数据通讯优化上作的更深。

好比最多见的 Hadoop 文件系统 hdfs，通常包括一个 NameNode 和多个 DataNode，NameNode 和 DataNode 之间就是经过一种称为 Hadoop RPC 的二进制协议进行通信。

TensorFlow 与 RPC

在人工智能领域，RPC 也很重要，著名的 TensorFlow 框架若是须要处理上亿的数据，就须要依靠分布式计算力，须要集群化，当多个分布式节点须要集体智慧时，就必须引入 RPC 技术进行通信。Tensorflow Cluster 的 RPC 通信框架使用了 Google 内部自研的 gRPC 框架。

HTTP 调用其实也是一种特殊的 RPC

HTTP1.0 协议时，HTTP 调用还只能是短连接调用，一个请求来回以后链接就会关闭。HTTP1.1 在 HTTP1.0 协议的基础上进行了改进，引入了 KeepAlive 特性能够保持 HTTP 链接长时间不断开，以便在同一个链接之上进行屡次连续的请求，进一步拉近了 HTTP 和 RPC 之间的距离。

当 HTTP 协议进化到 2.0 以后，Google 开源了一个创建在 HTTP2.0 协议之上的通讯框架直接取名为 gRPC，也就是 Google RPC，这时 HTTP 和 RPC 之间已经没有很是明显的界限了。因此在后文咱们再也不明确强调 RPC 和 HTTP 请求调用之间的细微区别了，直接统一称之为 RPC。

HTTP VS RPC （普通话 VS 方言）

HTTP 与 RPC 的关系就比如普通话与方言的关系。要进行跨企业服务调用时，每每都是经过 HTTP API，也就是普通话，虽然效率不高，可是通用，没有太多沟通的学习成本。可是在企业内部仍是 RPC 更加高效，同一个企业公用一套方言进行高效率的交流，要比通用的 HTTP 协议来交流更加节省资源。整个中国有很是多的方言，正若有不少的企业内部服务各有本身的一套交互协议同样。虽然国家一直在提倡使用普通话交流，可是这么多年过去了，你回一趟家乡探个亲什么的就会发现身边的人仍是流行说方言。

若是再深刻一点说，普通话本质上也是一种方言，只不过它是官方的方言，使用最为普遍的方言，相比而言其它方言都是小语种，小语种之中也会有几个使用比较普遍比较特点的方言占比也会比较大。这就比如开源 RPC 协议中 Protobuf 和 Thrift 同样，它们两应该是 RPC 协议中使用最为普遍的两个。

换个角度看世界

若是两个子系统没有在网络上进行分离，而是运行在同一个操做系统实例之上的两个进程时，它们之间的通讯手段还能够更加丰富。除了以上提到的几种分布式解决方案以外，还有共享内存、信号量、文件系统、内核消息队列、管道等，本质上都是经过操做系统内核机制来进行数据和消息的交互而无须通过网络协议栈。

但在现代企业服务中，这种单机应用已经很是少见了，由于单机应用意味着单点故障 —— “一人摔跤全家跌倒”。业务子系统每每都须要经物理网络栈进行隔离，所以分布式解决方案在要求高可用无间断服务的企业环境里便大有做为，这也让 RPC 迎来本身大放异彩的时代。

前文提到的分布式子系统交互方案，除了 RPC 技术以外还有数据库、消息队列和缓存。但其实这三者本质上是 RPC 技术的一个应用组合。咱们能够将数据库服务理解为下面这张图：

能够看出，子系统和数据库之间的交互也是经过 RPC 进行的，只不过这里是三个子系统之间复杂的组合消息交互罢了。若是再深刻进去，你会发现，这里的数据库不是那种单机数据库，而是具有主从复制功能的数据库，好比 MySQL。在互联网企业里通常都会使用这种主从读写分离的数据库。一个业务子系统将数据写往主库，主库再将数据同步到从库，而后另外一个业务子系统又从从库里将数据取出来。这时又能够进一步将它们当作是四个子系统之间进行的更加复杂的 RPC 数据交互。

小结

如今，读者应该能够深入理解 RPC 在互联网企业技术中的重要地位。从技术复杂性角度，也应该能够明白为何说对 RPC 技术的理解水平是评判一个程序员是否是高级程序员的重要标准之一。

在下一节，咱们将对 RPC 的交互原理进行深刻的学习，先把地基打牢，再开始实战开发。

思考题

请读者思考一下，在平时的后端开发中，还有哪些地方用到了「类 RPC」技术？

注：关注做者微信公众号，了解更多分布式架构、微服务、netty、MySQL、spring、JVM、性能优化、等知识点。

公众号：《 Java大蜗牛 》