为什么有HTTP还要RPC

为什么有HTTP还要RPC

简单来说，尽管 HTTP 协议应用广泛且通用性强，但在分布式系统中，RPC 凭借其在使用便捷性、性能效率以及服务治理等方面的优势，成为了 HTTP 的一种重要补充，满足了不同场景下远程调用的需求。

通信语义与使用便捷性方面

• HTTP： HTTP 是一种基于请求 / 响应模型的应用层协议，主要用于在 Web 浏览器和 Web 服务器之间传递超文本信息等，它更偏向于资源的获取和展示，使用的是统一资源定位符（URL）来定位资源，通过不同的请求方法（如 GET、POST、PUT、DELETE 等）来进行操作。例如，浏览器向服务器发送 GET 请求获取网页内容，操作方式相对通用但较为固定，对于复杂的业务逻辑调用来说不够直接和便捷。

• RPC： RPC 旨在让开发者像调用本地函数一样去调用远程服务器上的函数或方法，它隐藏了网络通信的细节，将远程调用抽象成了类似本地过程调用的形式，使用起来更加自然、简便，尤其适合在分布式系统中不同服务间进行方法调用，便于实现复杂的业务逻辑交互，不需要像使用 HTTP 那样要考虑很多请求方式、URL 构建以及数据格式转换等细节问题。

2. 性能效率方面

• HTTP： HTTP 协议由于其通用性和广泛的应用场景，包含了很多通用的头部信息（如 User-Agent、Accept 等）用于各种不同的目的，这使得其消息相对 “臃肿”，传输效率在一些对性能要求高的场景下稍显不足。而且 HTTP 通常基于文本格式（如 JSON、XML 等）进行数据传输，在数据序列化和反序列化时也会消耗一定的时间成本，尤其是处理大量数据或者频繁交互的场景。

• RPC： RPC 协议可以根据具体的应用场景进行定制化设计，在性能优化上有更大的灵活性。比如可以选择更高效的二进制序列化方式（如 Protocol Buffers、Thrift 等），减少数据传输的大小，提高传输速度。并且 RPC 框架往往会针对网络通信进行专门的优化，像连接池管理、减少网络请求次数等，使得在分布式服务间频繁调用时能有更好的性能表现，更适合对响应速度和吞吐量要求较高的业务场景。

3. 服务治理方面

• HTTP： 虽然 HTTP 也可以通过一些手段实现服务发现、负载均衡等服务治理功能（比如借助反向代理服务器、服务注册中心等），但这些往往是额外配置搭建的，相对来说不够集成化和自动化。而且对于服务的版本管理、服务之间的依赖关系梳理等深层次的服务治理需求，使用 HTTP 时处理起来比较复杂。

• RPC： 多数 RPC 框架自身内置了完善的服务治理功能，例如自动的服务注册与发现，能够让服务提供者自动将自己注册到注册中心，服务调用者也能方便地从注册中心查找并调用目标服务；还具备负载均衡功能，根据不同的算法（如轮询、加权轮询等）将请求合理分配到多个服务实例上，同时也便于进行服务的版本控制、流量控制、熔断降级等操作，更有利于构建大规模、复杂的分布式服务架构，保障系统整体的稳定性和高效性。