很长时间以来都没有怎么好好搞清楚 RPC（即 Remote Procedure Call，近程过程调用）和 HTTP 调用的区别，不都是写一个服务而后在客户端调用么？这里请容许我迷之一笑~Naive！
援用
本文简略地介绍一下两种模式的 C / S 架构，先说一下他们最实质的区别，就是 RPC 次要是基于 TCP/IP 协定的，而 HTTP 服务次要是基于 HTTP 协定的，咱们都晓得 HTTP 协定是在传输层协定 TCP 之上的，所以效率来看的话，RPC 当然是要更胜一筹啦！上面来具体说一说 RPC 服务和 HTTP 服务。
OSI 网络七层模型
在说 RPC 和 HTTP 的区别之前，我觉的有必要理解一下 OSI 的七层网络结构模型（尽管理论利用中基本上都是五层），它能够分为以下几层：（从上到下）
- 第一层：应用层。定义了用于在网络中进行通信和传输数据的接口；
- 第二层：表示层。定义不同的零碎中数据的传输格局，编码和解码标准等；
- 第三层：会话层。治理用户的会话，管制用户间逻辑连贯的建设和中断；
- 第四层：传输层。治理着网络中的端到端的数据传输；
- 第五层：网络层。定义网络设备间如何传输数据；
- 第六层：链路层。将下面的网络层的数据包封装成数据帧，便于物理层传输；
- 第七层：物理层。这一层次要就是传输这些二进制数据。
理论利用过程中，五层协定构造外面是没有表示层和会话层的。应该说它们和应用层合并了。咱们应该将重点放在应用层和传输层这两个层面。因为 HTTP 是应用层协定，而 TCP 是传输层协定。好，晓得了网络的分层模型当前咱们能够更好地了解为什么 RPC 服务相比 HTTP 服务要 Nice 一些！
RPC 服务
从三个角度来介绍 RPC 服务：别离是 RPC 架构，同步异步调用以及风行的 RPC 框架。
RPC 架构
先说说 RPC 服务的根本架构吧。容许我可耻地盗一幅图哈~ 咱们能够很分明地看到，一个残缺的 RPC 架构外面蕴含了四个外围的组件，别离是 Client ,Server,Client Stub 以及 Server Stub，这个 Stub 大家能够了解为存根。别离说说这几个组件：
-
- 客户端（Client），服务的调用方。
- 服务端（Server），真正的服务提供者。
客户端存根，寄存服务端的地址音讯，再将客户端的申请参数打包成网络音讯，而后通过网络近程发送给服务方。
服务端存根，接管客户端发送过去的音讯，将音讯解包，并调用本地的办法。
RPC 次要是用在大型企业外面，因为大型企业外面零碎繁多，业务线简单，而且效率劣势十分重要的一块，这个时候 RPC 的劣势就比拟显著了。理论的开发当中是这么做的，我的项目个别应用 maven 来治理。
比方咱们有一个解决订单的零碎服务，先申明它的所有的接口（这里就是具体指 Java 中的 interface），而后将整个我的项目打包为一个 jar 包，服务端这边引入这个二方库，而后实现相应的性能，客户端这边也只须要引入这个二方库即可调用了。
为什么这么做？次要是为了缩小客户端这边的 jar 包大小，因为每一次打包公布的时候，jar 包太多总是会影响效率。另外也是将客户端和服务端解耦，进步代码的可移植性。
同步调用与异步调用
什么是同步调用？什么是异步调用？同步调用就是客户端期待调用执行实现并返回后果。异步调用就是客户端不期待调用执行实现返回后果，不过仍然能够通过回调函数等接管到返回后果的告诉。如果客户端并不关怀后果，则能够变成一个单向的调用。
这个过程有点相似于 Java 中的 callable 和 runnable 接口，咱们进行异步执行的时候，如果须要晓得执行的后果，就能够应用 callable 接口，并且能够通过 Future 类获取到异步执行的后果信息。如果不关怀执行的后果，间接应用 runnable 接口就能够了，因为它不返回后果，当然啦，callable 也是能够的，咱们不去获取 Future 就能够了。
风行的 RPC 框架
目前风行的开源 RPC 框架还是比拟多的。上面重点介绍三种：
gRPC 是 Google 最近颁布的开源软件，基于最新的 HTTP2.0 协定，并反对常见的泛滥编程语言。咱们晓得 HTTP2.0 是基于二进制的 HTTP 协定降级版本，目前各大浏览器都在快马加鞭的加以反对。这个 RPC 框架是基于 HTTP 协定实现的，底层应用到了 Netty 框架的反对。
Thrift 是 Facebook 的一个开源我的项目，次要是一个跨语言的服务开发框架。它有一个代码生成器来对它所定义的 IDL 定义文件主动生成服务代码框架。用户只有在其之前进行二次开发就行，对于底层的 RPC 通信等都是通明的。不过这个对于用户来说的话须要学习特定畛域语言这个个性，还是有肯定老本的。
Dubbo 是阿里团体开源的一个极为闻名的 RPC 框架，在很多互联网公司和企业应用中宽泛应用。协定和序列化框架都能够插拔是及其显明的特色。同样 的近程接口是基于 Java Interface，并且依靠于 spring 框架不便开发。能够不便的打包成繁多文件，独立过程运行，和当初的微服务概念统一。
HTTP 服务
其实在很久以前，我对于企业开发的模式始终定性为 HTTP 接口开发，也就是咱们常说的 RESTful 格调的服务接口。确实，对于在接口不多、零碎与零碎交互较少的状况下，解决信息孤岛初期常应用的一种通信伎俩；长处就是简略、间接、开发不便。
利用现成的 http 协定进行传输。咱们记得之前本科实习在公司做后盾开发的时候，次要就是进行接口的开发，还要写一大份接口文档，严格地表明输入输出是什么？说分明每一个接口的申请办法，以及申请参数须要留神的事项等。
接口可能返回一个 JSON 字符串或者是 XML 文档。而后客户端再去解决这个返回的信息，从而能够比拟疾速地进行开发。
然而对于大型企业来说，外部子系统较多、接口十分多的状况下，RPC 框架的益处就显示进去了，首先就是长链接，不用每次通信都要像 http 一样去 3 次握手什么的，缩小了网络开销；
其次就是 RPC 框架个别都有注册核心，有丰盛的监控治理；公布、下线接口、动静扩大等，对调用方来说是无感知、统一化的操作。
总结
RPC 服务和 HTTP 服务还是存在很多的不同点的，一般来说，RPC 服务次要是针对大型企业的，而 HTTP 服务次要是针对小企业的，因为 RPC 效率更高，而 HTTP 服务开发迭代会更快。
总之，选用什么样的框架不是依照市场上风行什么而决定的，而是要对整个我的项目进行残缺地评估，从而在认真比拟两种开发框架对于整个我的项目的影响，最初再决定什么才是最适宜这个我的项目的。肯定不要为了应用 RPC 而每个我的项目都用 RPC，而是要就地取材，具体情况具体分析。
以上就是本次分享的所有内容，想要理解更多 python 常识欢送返回公众号：Python 编程学习圈，发送“J”即可收费获取，每日干货分享