当用户的要求到来时，我们须要将用户的要求分散到多个做事去各自处理，然后又须要将这些子做事的结果汇总起来呈现给用户。那么做事之间该利用何种办法进行交互便是须要办理的核心问题。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 技能的一个运用组合。我们可以将数据库做事理解为下面这张图：
可以看出，子系统和数据库之间的交互也是通过 RPC 进行的，只不过这里是三个子系统之间繁芜的组合交互罢了。如果再深入进去，你会创造，这里的数据库不是那种单机数据库，而是具备主从复制功能的数据库，比如 MySQL。在互联网企业里一样平常都会利用这种主从读写分离的数据库。一个业务子系统将数据写往主库，主库再将数据同步到从库，然后另一个业务子系统又从库里将数据取出来。这时又可以进一步将它们算作是四个子系统之间进行的更加繁芜的 RPC 数据交互。
