有HTTP为什么还要RPC

 RPC80年代诞生，HTTP90年代诞生。所以准确来说是有RPC为什么还需要HTTP。

跨微服务的远程调用（RPC，即Remote Produce Call）

RPC的实现方式有很多，比如：

• 基于Http协议

• 基于Dubbo协议

[ 都只是定义了不同消息格式的 应用层协议 而已。RPC本身并不是一个具体的协议，而是一种 调用方式 （grpc这种具体实现才是协议）。可以屏蔽掉一些网络细节 ]RPC长连接复用且有连接池。-----OpenFeign 进行远程调用不需要开发人员手动构造 HTTP 请求对象、设置请求参数等

RPC，因为它定制化程度更高，可以采用体积更小的 Protobuf 或其他序列化协议去保存结构体数据，同时也不需要像 HTTP 那样考虑各种浏览器行为，比如 302 重定向跳转啥的。因此性能也会更好一些，这也是在公司内部微服务中抛弃 HTTP，选择使用 RPC 的最主要原因。

主要区别：

• RPC：需要中间服务获取IP端口、TCP-Keep Alive + 连接池、体积更小的Probul序列化结构体 + 不需要考虑浏览器行为例如重定向【定制化程度更高】

• HTTP：DNS获取IP端口、TCP保持Keep-Alive、JSON序列化消息体（冗余） + 消息头重复

历史原因：

• RPC 其实比 HTTP 出现的要早，且比目前主流的 HTTP/1.1 性能要更好，所以大部分公司内部都还在使用 RPC。

• HTTP/2.0 在 HTTP/1.1 的基础上做了优化，性能可能比很多 RPC 协议都要好，但由于是这几年才出来的，所以也不太可能取代掉 RPC。