很长时间以来都没有怎么好好搞清楚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” 即可收费获取，每日干货分享