本文已参与「新人创作礼」活动，一起开启掘金创作之路

引言

在微服务中，什么时候用HTTP协议？什么时候用RPC协议？

我们通常采用的原则为：向系统外部暴露采用HTTP，向系统内部暴露调用采用RPC方式。 也就是说前后端之间（网关之前）用http，各个服务之间用rpc。

那么为什么这样用呢？

有人说HTTP与RPC采取不同的协议，RPC所传输的数据是经过压缩的二进制数据，但是HTTP协议同样支持gzip压缩算法。其次，HTTP的报头包括太多无效信息，但是20-60字节的首部长度会对业务有很大影响吗？以现阶段计算机处理及网络传输速度，影响很大吗？或者能用增加服务器的方式去解决的问题，为什么很多公司要自研RPC框架呢？

首先需要解释：RPC是远程方法调用，即一个应用调用另一个应用的接口。 如何在一个应用中调用另一个应用？可以通过HTTP协议，也可以通过自定义的TCP协议实现通信。最终实质上完全相同，都是通过Socket解析调用方的参数，最后再将处理结果通过Socket传输。

HTTP 既然也是 RPC 的一种实现？为什么公司还要自研 RPC 框架？为什么他们的应用进程不之间通过HTTP协议完成交互？

最主要的原因还是RPC框架包含了重试机制，路由策略，负载均衡策略，高可用策略，流量控制策略等等。 如果应用进程之间只使用HTTP协议通信，显然是无法完成上述功能的。

HTTP和RPC的区别

RPC主要用于系统内部服务调用，传输效率高（基于TCP，报文小），性能消耗低（高效的二进制传输、字节小、序列化耗时少），服务治理方便。

http是超文本协议，其包含的信息往往比较臃肿，网关之前一般用http，服务之间能用rpc协议就用rpc协议，除非少部分情况，一些旧的服务它可能只支持http，或者一些node开发团队只能用http，也不太好改成rpc。

1、传输协议：

• 　　RPC框架：可以基于HTTP协议，也可以基于TCP协议
• 　　HTTP框架：基于HTTP协议

从网络协议来说，Http协议与Rpc同属于应用层， 他们的底层都是tcp协议。RPC（即Remote Procedure Call，远程过程调用）和HTTP（HyperText Transfer Protocol，超文本传输协议）他们最本质的区别，就是RPC直接通过自定义TCP协议实现通信，而HTTP服务需要通过HTTP协议，我们都知道HTTP协议是在传输层协议TCP之上的，所以相当于在中间又加了一层，从效率来看的话，RPC当然是要更胜一筹。

2、传输效率：

• 　　RPC：使用自定义的TCP协议，可以让请求报文体积更小，或者使用HTTP2协议，也可以很好的减小报文体积，提高传输效率
• 　　HTTP：如果是基于http1.1的协议，请求中会包含很多无用的内容，如果是基于HTTP2.0，那么简单的封装下可以作为一个RPC来使用，这时标准的RPC框架更多的是服务治理。

http协议其实是属于面向桌面浏览器的一个通信协议，对于缓存，幂等或者Cookies相关的方面做了很多的事情。但是对于服务器之间直接的交互，Rpc就能够体现出来他的优势了。自定义协议，减少数据传输：我们大概看一下http协议。请求行，请求头部，请求数据，空行。很明显对于远程调用场景，我们对于请求行的依赖不是特别的强，那么这一部分在我们应用场景下，将会成为负担，但是http协议又是固定的，我们也不可能随便修改协议的格式。所以，通过rpc协议我们可以精简请求的数据，来尽可能少的传输我们的数据。当前，rpc也可以通过http协议来进行传输。

3、性能消耗：

• 　　RPC：可以基于thrift实现高效的二进制传输
• 　　HTTP：大部分是基于json实现的，字节大小和序列化耗时都比thrift要更消耗性能

4、负载均衡：

• 　　RPC：基本自带了负载均衡策略
• 　　HTTP：需要配置Nginx、HAProxy配置

5、服务治理：（下游服务新增，重启，下线时如何不影响上游调用者）

• 　　RPC：能做到自动通知，不影响上游
• 　　HTTP：需要事先通知，如修改NGINX配置。

6、连接：

• 　　RPC：长连接
• 　　HTTP：短连接

rpc使用长连接：直接基于socket进行连接，不用每个请求都重新走三次握手的流程