关于java:有了HTTP为什么还要RPC

很长时间以来都没有怎么好好搞清楚 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 协定进行传输。咱们记得之前本科实习在公司做后盾开发的时候，次要就是进行接口的开发，还要写一大份接口文档，严格地表明输入输出是什么？说分明每一个接口的申请办法，以及申请参数须要留神的事项等。

比方上面这个例子：

POST http://www.httpexample.com/re…

接口可能返回一个 JSON 字符串或者是 XML 文档。而后客户端再去解决这个返回的信息，从而能够比拟疾速地进行开发。

然而对于大型企业来说，外部子系统较多、接口十分多的状况下，RPC 框架的益处就显示进去了，首先就是长链接，不用每次通信都要像 HTTP 一样去 3 次握手什么的，缩小了网络开销。

其次就是 RPC 框架个别都有注册核心，有丰盛的监控治理；公布、下线接口、动静扩大等，对调用方来说是无感知、统一化的操作。

总结

RPC 服务和 HTTP 服务还是存在很多的不同点的，一般来说，RPC 服务次要是针对大型企业的，而 HTTP 服务次要是针对小企业的，因为 RPC 效率更高，而 HTTP 服务开发迭代会更快。

总之，选用什么样的框架不是依照市场上风行什么而决定的，而是要对整个我的项目进行残缺地评估，从而在认真比拟两种开发框架对于整个我的项目的影响，最初再决定什么才是最适宜这个我的项目的。

肯定不要为了应用 RPC 而每个我的项目都用 RPC，而是要就地取材，具体情况具体分析。