HTTP 和 RPC 的区别

一句话概括

RPC代表：Feign、Dubbo

RPC 主要用于公司内部的服务调用，性能消耗低，传输效率高，服务治理方便。

HTTP 代表：RestTemplate、HttpClient

HTTP 主要用于对外的异构环境，浏览器接口调用，APP接口调用，第三方接口调用等。

有了HTTP调用之后，为什么还需要RPC

HTTP 调用使用起来非常的简洁、方便、优雅，但是有一点，在调用接口的时候，相比较 RPC 框架而言，性能堪忧。

虽说在微服务架构中，会讲按照业务划分的微服务独立部署，并且运行在各自的进程中。微服务之间的通信更加倾向于使用 HTTP 这种简答的通信机制，大多数情况都会使用 REST API。这种通信方式非常的简洁高效，并且和开发平台、语言无关，但是通常情况下，HTTP 并不会开启 KeepAlive 功能，即当前连接为短连接，短连接的缺点是每次请求都需要建立 TCP 连接，这使得其效率变的相当低下。

对外部提供 REST API 服务是一件非常好的事情，但是如果内部调用也是使用 HTTP 调用方式，就会显得显得性能低下，Spring Cloud 默认使用的 Feign 组件进行内部服务调用就是使用的 HTTP 协议进行调用，这时，我们如果内部服务使用RPC调用，对外使用 REST API，将会是一个非常不错的选择，恰巧，Dubbo Spring Cloud给了我们这种选择的实现方式。

HTTP和RPC的优缺点

传输协议

RPC: 可以基于TCP协议，也可以基于HTTP协议

HTTP: 基于HTTP协议

传输效率

RPC: 使用自定义的 TCP 协议，可以让请求报文体积更小，或者使用 HTTP2 协议，也可以很好的减少报文的体积，提高传输效率

HTTP: 如果是基于 HTTP1.1 的协议，请求中会包含很多无用的内容，如果是基于 HTTP2.0，那么简单的封装以下是可以作为一个 RPC 来使用的，这时标准 RPC 框架更多的是服务治理

性能消耗

RPC: 可以基于 thrift 实现高效的二进制传输

HTTP: 大部分是通过 json 来实现的，字节大小和序列化耗时都比thrift要更消耗性能

负载均衡

RPC：基本都自带了负载均衡策略

HTTP：需要配置 Nginx 来实现

服务治理

RPC：能做到自动通知，不影响上游

HTTP: 需要事先通知，修改 Nginx 配置