Unix/Linux编程：既然有了HTTP请求，为什么还要RPC调用

ゝ一纸荒年。 2022-09-12 06:59 196阅读 0赞

# 回答 #

首先HTTP和RPC并不是一个并行概念

**rpc是远程过程调用，其调用协议通常包含传输协议和序列化协议**。

传输协议包含: 如著名的 \[gRPC\](grpc / grpc.io) 使用的 http2 协议，也有如dubbo一类的自定义报文的tcp协议。

序列化协议包含: 如基于文本编码的 xml json，也有二进制编码的 protobuf hessian等。

因此我理解的你想问的问题应该是：**为什么要使用自定义 tcp 协议的 rpc 做后端进程通信**？

要解决这个问题就应该搞清楚http使用的tcp协议和我们自定义的tcp协议在报文上的区别。

首先要否认的一点就是http协议相较于自定义tcp报文协议，增加的开销在于连接的建立和断开。http协议是支持连接池复用的，也就是建立一定数量的连接不断开，并不会频繁的创建和销毁连接。二要说的是http也可以使用protobuf这种二进制编码协议对内容进行编码，因此二者最大的区别还是在传输协议上。

通用定义的http1.1协议包含太多废信息，一个POST协议的格式大致如下：

HTTP/1.0 200 OK 
    Content-Type: text/plain
    Content-Length: 137582
    Expires: Thu, 05 Dec 1997 16:00:00 GMT
    Last-Modified: Wed, 5 August 1996 15:55:28 GMT
    Server: Apache 0.84
    
    <html>
      <body>Hello World</body>
    </html>

即使编码协议也就是body是使用二进制编码协议，报文元数据也就是header头的键值对却用了文本编码，非常占字节数。如上图所使用的报文中有效字节数仅仅占约 30%，也就是70%的时间用于传输元数据废编码。当然实际情况下报文内容可能会比这个长，但是报头所占的比例也是非常可观的。

那么假如我们使用自定义tcp协议的报文如下  
![在这里插入图片描述][7d7fb0f1824148049eb7832a3678337a.png]  
报头占用的字节数也就只有16个byte，极大地精简了传输内容。

这也就是为什么后端进程间通常会采用自定义tcp协议的rpc来进行通信的原因。

--------------------

这里所谓的效率优势是针对http1.1协议来讲的，http2.0协议已经优化编码效率的问题，像grpc这种rpc库使用的就是http2.0协议。这么来说吧http容器的性能测试单位通常是kqps，自定义tpc协议则通常是以10kqps到100kqps为基准

简单来说成熟的rpc库相对于http容器，更多的是封装了“服务发现”、“负载均衡”、“熔断降级”一类面向服务的高级特性。可以这么理解，rpc框架是面向服务的更高级的封装。如果把一个http servlet容器上封装一层服务发现和函数代理调用，那么它就已经可以做一个rpc框架了。

所以为什么要用rpc调用？

因为良好的rpc调用是面向服务的封装，针对服务的可用性和效率等都做了优化。单纯使用http调用则缺少了这些特性。

# 回答 #

首先，实名赞扬题主的问题。这个问题非常好。

但是，该提问也确实有点问题：**HTTP和RPC不是对等的概念**。

**RPC是一个完整的远程调用方案，它包括了：接口规范+序列化反序列化规范+通信协议等**

而**HTTP只是一个通信协议，工作在OSI的第七层**，不是一个完整的远程调用方案。

所以，要向回答这个问题，应该拉平为一个对等的概念。比如，**HTTP+Resuful规范+序列化和反序列化**，构成一个完整的远程调用方案，再和**RPC**进行比较。而**单纯的HTTP，只是一个通信协议，自然无法和RPC比较**

这就像是牛（HTTP）不能和马车（RPC）比较。要想比较，就应该将牛补齐为牛车，然后和马车比较。

感觉题主应该问：**基于HTTP的远程调用方案（包含了接口规范、序列化反序列化等）和使用RPC的远程调用方案有什么不同。有了前者，为什么还要有后者**。

下面我们来解答这个问题。

我们先介绍基于HTTP的远程调用方案

*  HTTP+Resuful，其优势很大，它**可读性好**，而且**可以得到防火墙/跨语言的支持**。而且，在近几年的报告中，Restful大有超过RPC的趋势。

但是使用该方案也有其确定，这是与其中优点相对应的

*  首先是**有用信息占比少**，毕竟HTTP工作在第七层，包含了大量的HTTP头等信息
 *  其次是**效率低**，还是因为第七层的缘故，必须按照HTTP协议进行层层封装
 *  还有，其**可读性似乎没有必要**，因为我们可以引入网关增加可读性
 *  此外，使用HTTP协议**调用远程方法比较复杂**，要封装各种参数名和参数值

而RPC则与HTTP互补，我们详细介绍下

看完这篇回答，能让你对RPC的产生、原理、实现代码都有着比较清晰的了解。这样，也能在业务系统中，在RPC和HTTP之间做好选择。

但需要再说一句，不是说RPC好，也不是说HTTP好，两者各有千秋，还在比拼中。

要问我站谁？我根据业务场景，灵活站位……

RPC的英文全称是Remote Procedure Call，翻译为中文叫“远程过程调用”。其中稍显晦涩的其实就是“过程”，过程其实就是方法。所以，可以把RPC理解为“**远程方法调用”**。

要了解远程过程调用，那先理解过程调用。非常简单，如下图，就是调用一个方法。  
![在这里插入图片描述][b51ae670fc504bdba70fbba89ac9d3f4.png]  
而在分布式系统中，因为每个服务的边界都很小，很有可能调用别的服务提供的方法。这就出现了服务A调用服务B中方法的需求，即远程过程调用。

要想让服务A调用服务B中的方法，最先想到的就是通过HTTP请求实现。是的，这是很常见的，例如服务B暴露Restful接口，然后让服务A调用它的接口。基于Restful的调用方式因为可读性好（服务B暴露出的是Restful接口，可读性当然好）而且HTTP请求可以通过各种防火墙，因此非常不错。

然而，如前所诉，基于Restful的远程过程调用有着明显的缺点，主要是效率低、封装调用复杂。当存在大量的服务间调用时，这些缺点变得更为突出。

**服务A调用服务B的过程是应用间的内部过程，牺牲可读性提升效率、易用性是可取的。基于这种思路，RPC产生了**。

通常，RPC要求在调用方中放置被调用的方法的接口，**调用方只要调用了这些接口，就相当于调用了被调用方的实际方法，十分易用**。于是，调用方可以向调用内部方法一样调用远程的方法，而不用封装参数名和参数值等操作。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_14_color_FFFFFF_t_70_g_se_x_16]  
那要想实现这个过程该怎么办呢？别急，我们一步步来。

首先，调用方调用的是接口，必须得为接口构造一个假的实现。显然，要使用动态代理。这样，调用方的调用就被动态代理接收到了。

第二，动态代理接收到调用后，应该想办法调用远程的实际实现。这包括下面几步

*  识别具体要调用的远程方法的IP、端口
 *  将调用方法的入参进行序列化
 *  通过通信将请求发送到远程的方法中

这样，远程的服务就接收到来调用方的请求，它应该：

*  反序列化各个调用参数
 *  定位到实际要调用的方法，然后输入参数、执行方法
 *  按照调用的路径返回调用的结果。

整个过程如下所示。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_16_color_FFFFFF_t_70_g_se_x_16]  
这样，RPC操作就完成了。

**调用方调用内部的一个方法，但是被RPC框架偷梁换柱为远程的一个方法。之间的通信数据可读性不需要好，只需要RPC框架能读懂即可，因此效率可以更高。通常使用UDP或者TCP作为通讯协议，当然也可以使用HTTP**

问题：

1、**HTTP和RPC同一级别，还是被RPC包含**？

2、**Restful也属于RPC么**？

对于以上两点，我画图来一一说明。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16]

上图是一个比较完整的关系图，这时我们发现HTTP(图中蓝色框)出现了两次。其中一个是和RPC并例的，都是跨应用方法的解决方案；另一个则是被RPC包含的，是RPC通信过程的可选协议之一。

因此，**第一个问题的答案就是都对。看指的是哪一个蓝色框**。从题主的提问看，既然题主在纠结这两者，应该是指与RPC并列的蓝色框。所以，题主所述的HTTP请求应该是指：基于HTTP的远程调用方案（包含了接口规范、序列化反序列化等）。这样，它才是和RPC同一级别的概念。

第二个问题是在问远程过程调用（红色框）是不是包含了Restful（黄色框），这种理解的关键在于对RPC的理解。RPC字面理解是远程过程调用，即在一个应用中调用另一个应用的方法。那Restful是满足的，通过它可以实现在一个应用中调用另一个应用的方法。但是，上述理解使得RPC的定义过于宽泛。RPC通常特指在一个应用中调用另一个应用的接口而实现的远程调用，即红色框所指的范围。这样，RPC是不包含Restful的。

因此，**第二个问题的答案是Restful不属于RPC，除非对RPC有着非常规的宽泛理解**。

[7d7fb0f1824148049eb7832a3678337a.png]: /images/20220828/c6042e51b425412b93cc27697a0e2258.png
[b51ae670fc504bdba70fbba89ac9d3f4.png]: /images/20220828/d7813eb1d21e46959664e90f489d11e6.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_14_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/e6e95e06b41940de92c43146980d4a60.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_16_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/940919a081994eac8d01fcebe0dfe741.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/7b4f3d5088c847ed8ea965a88ee3146a.png