1、什么是RPC协议：

RPC：远程过程调用，一种进程间通信方式。允许像调用本地服务一样调用远程服务。

RPC架构：

包含四个核心组件。

客户端(client)：服务的调用方
服务端(server)：服务提供方
客户端存根(client stub，即，助手)：将客户端请求参数打包成网络消息，再发给服务方
服务端存根(server stub，即，助手)：接收客户端发来的消息，将消息解包，并调用本地方法

2、前言

网上很多博客都是在说HTTP与RPC采取不同的协议，RPC所传输的数据是经过压缩的二进制数据，但是HTTP协议同样支持gzip压缩算法。其次，另一个说法就是HTTP的报头所占的有太多无效信息，但是20-60字节的首部长度会对业务有很大影响吗？以现阶段计算机处理及网络传输速度，应该并无影响。

这也是我在网上所看到大部分的答案，之前也一直被这个带偏，直到一次面试被指正。

3、RPC与HTTP并不位于同一层面，两者概念截然不同：

RPC与HTTP并不位于同一层面，两者的概念截然不同，RPC远程方法调用，即一个应用调用另一个应用的接口。

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

所以，RPC是如何实现服务间的通信，而HTTP可以视为服务间通信采取的一种数据传输格式。

4、为什么许多大公司还要自研 RPC 框架？

HTTP 既然也是 RPC 的一种实现？为什么公司还要自研 RPC 框架？

HTTP协议可以说是目前最为主流的一种网络通信协议，但是很多大厂依然自研RPC框架，如字节、阿里以及腾讯等？为什么他们的应用进程不之间通过HTTP协议完成交互？

最主要的原因还是RPC框架包含了重试机制，路由策略，负载均衡策略，高可用策略，流量控制策略等等。

如果应用进程之间只使用HTTP协议通信，显然是无法完成上述功能的。

一般来说，HTTP服务主要是针对小企业的，因为虽然RPC效率和性能更高，但是HTTP服务开发迭代会更快。

而且在接口不多、系统与系统交互较少的情况下，Http通信是常使用的一种通信手段；优点就是简单、直接、开发方便。利用现成的http协议就可以进行服务间的数据传输。

接口可能返回一个JSON字符串，然后客户端再去处理这个返回的信息，从而可以比较快速地进行开发。

但是对于大型企业来说，内部子系统较多、接口非常多的情况下，RPC框架的好处就显示出来了。

首先是长链接，不必每次通信都要像http一样去3次握手，减少了网络开销；

其次，RPC框架一般都有注册中心，有丰富的监控管理；发布、下线接口、动态扩展等，对调用方来说是无感知、统一化的操作。

4、RPC和HTTP的区别：

1> 功能侧重点不同：

SpringCloud：Spring公司开源的微服务框架，SpirngCloud 定位为微服务架构下的一站式解决方案。

Dubbo：阿里巴巴开源的RPC框架，Dubbo 是 SOA 时代的产物，它的关注点主要在于服务的调用和治理，流量分发、流量监控和熔断。

2> 生态环境不同：

SpringCloud依托于Spring平台，具备更加完善的生态体系；

而Dubbo一开始只是做RPC远程调用，生态相对匮乏，现在逐渐丰富起来。

Spring Cloud 的功能很明显比 Dubbo 更加强大，涵盖面更广，而且作为 Spring 的旗舰项目，它也能够与 Spring Framework、Spring Boot、Spring Data、Spring Batch 等其他 Spring 项目完美融合，这些对于微服务而言是至关重要的。

使用 Dubbo 构建的微服务架构就像组装电脑，各环节选择自由度很高，但是最终结果很有可能因为一条内存质量不行就点不亮了，总是让人不怎么放心，但是如果使用者是一名高手，那这些都不是问题。

而 Spring Cloud 就像品牌机，在 Spring Source 的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性，但是如果要在使用非原装组件外的东西，就需要对其基础原理有足够的了解。

SpringCloud生态丰富，功能完善，更像是品牌机；

Dubbo则相对灵活，可定制性强，更像是组装机。

3> 调用方式不同：

SpringCloud是采用Http协议做远程调用，接口一般是Rest风格，比较灵活；

Dubbo是采用Dubbo协议，接口一般是Java的Service接口，格式固定。但调用时采用Netty的NIO方式，性能较好。

4> Dubbo和Feign远程调用的差异：

Feign是SpringCloud中的远程调用方式，基于成熟Http协议，所有接口都采用Rest风格。因此接口规范更统一，而且只要符合规范，实现接口的微服务可以采用任意语言或技术开发。

但受限于http协议本身的特点，请求和响应格式臃肿，其通信效率相对会差一些。

Dubbo框架默认采用Dubbo自定义通信协议，与Http协议一样底层都是TCP通信。

但是Dubbo协议自定义了Java数据序列化和反序列化方式、数据传输格式，因此Dubbo在数据传输性能上会比Http协议要好一些。

不过这种性能差异除非是达极高的并发量级，否则这种区别，无需过多考虑。

5> 市场不同：

一般来说，RPC服务主要是针对大型企业的；
而HTTP服务主要是针对小企业的，因为虽然RPC效率和性能更高，但是HTTP服务开发迭代会更快。
而且在接口不多、系统与系统交互较少的情况下，Http通信是常使用的一种通信手段；优点就是简单、直接、开发方便。利用现成的http协议就可以进行服务间的数据传输。可以比较快速地进行开发。
但是对于大型企业来说，内部子系统较多、接口非常多的情况下，RPC框架的好处就显示出来了。首先是长链接，不必每次通信都要像http一样去3次握手，减少了网络开销；其次，RPC框架一般都有注册中心，有丰富的监控管理；发布、下线接口、动态扩展等，对调用方来说是无感知、统一化的操作。