RPC vs HTTP：微服务架构下远程调用技术选型深度解析

很长时间以来，许多开发者可能都没有深入思考过 RPC（Remote Procedure Call，远程过程调用）和 HTTP 调用的本质区别——不都是在服务端写个接口，然后在客户端调用么？本文将从网络协议、架构设计和应用场景等角度，为你厘清两者的差异。

首先，从最根本的协议层来看，RPC 框架通常基于 TCP/IP 协议构建，而常见的 HTTP 服务则基于 HTTP 协议。HTTP 协议本身位于 TCP/IP 协议栈的应用层，其下是作为传输层的 TCP。因此，单从协议栈的“简洁性”和网络开销来看，直接基于传输层的 RPC 在效率上往往更具优势。为了更清晰地理解这一点，我们有必要回顾一下网络分层模型。

OSI 网络七层模型

虽然在实践中我们更多使用 TCP/IP 五层模型，但了解经典的 OSI 七层模型有助于我们从原理上把握不同协议的位置与职责。

该模型从上到下分为：

• 第一层：应用层。 为应用程序提供网络通信接口。
• 第二层：表示层。 负责数据格式转换、编码解码及加密解密。
• 第三层：会话层。 负责建立、管理和终止应用程序之间的会话。
• 第四层：传输层。 提供端到端的可靠或不可靠数据传输服务。
• 第五层：网络层。 负责逻辑寻址和路由选择，将数据包从源主机传送到目的主机。
• 第六层：数据链路层。 在物理链路上提供可靠的数据传输，将网络层的数据包封装成帧。
• 第七层：物理层。 定义物理介质的特性，传输原始的比特流。

在实际的 TCP/IP 五层协议结构中，表示层和会话层的功能通常被合并到了应用层。我们的关注焦点应放在 应用层（如HTTP） 和 传输层（如TCP）。理解了网络分层，我们就能更好地剖析 RPC 服务的独特之处。

RPC 服务详解

我们可以从架构、调用方式和主流框架三个维度来认识 RPC。

RPC 架构

一个典型的 RPC 架构包含四个核心组件：Client（客户端）、Server（服务端）、Client Stub（客户端存根）和 Server Stub（服务端存根）。

• 客户端（Client）：服务的调用方。
• 服务端（Server）：真实服务逻辑的提供者。
• 客户端存根（Client Stub）：存放服务端地址信息，将客户端的调用请求参数序列化、打包成网络消息，并发送给服务端。
• 服务端存根（Server Stub）：接收客户端网络消息，将其反序列化、解包，并调用本地的实际服务方法，然后将结果打包返回。

RPC 在大型企业内部系统中尤为常见。系统繁多、业务复杂，对通信效率要求极高，此时 RPC 的优势得以凸显。在实际的 Java 项目开发中，通常会使用 Maven 进行依赖管理。例如，一个订单处理系统会将其所有服务接口定义在一个独立的 JAR 包中。服务提供方引入该 JAR 并实现接口，服务调用方也仅需引入同一个 JAR 包即可进行调用。这样做的主要目的是减少客户端依赖的臃肿，提升部署效率，同时实现客户端与服务端的解耦，增强代码的可移植性。

同步调用与异步调用

RPC 支持灵活的调用模式：

• 同步调用：客户端发起调用后，会阻塞等待直到服务端返回结果。
• 异步调用：客户端发起调用后立即返回，不等待结果，后续通过回调（Callback）或 Future 等机制获取结果通知。如果客户端完全不关心结果，甚至可以发起单向（Oneway）调用。

这类似于 Java 中的 Runnable 和 Callable 接口。使用 Runnable 执行异步任务时我们不关心返回值；而使用 Callable 配合 Future，则可以在需要时获取异步执行的结果。

流行的 RPC 框架

目前主流的开源 RPC 框架选择多样：

1. gRPC：由 Google 开源，基于 HTTP/2.0 协议，支持多种编程语言。HTTP/2.0 的多路复用、头部压缩等特性赋予了它高性能。其底层通常由 Netty 网络框架提供支持。
2. Thrift：由 Facebook 开源，是一个跨语言的 RPC 服务开发框架。它通过 IDL（接口定义语言）定义服务，并由代码生成器自动生成多语言的服务端和客户端骨架代码，开发者只需关注业务逻辑实现。
3. Dubbo：阿里巴巴开源的知名 RPC 框架，在国内互联网企业广泛应用。其特点是高度可扩展，协议和序列化方式均可插拔。服务接口基于 Java Interface 定义，能与 Spring 框架无缝集成，易于开发部署，其架构理念与当下流行的微服务一致。

HTTP 服务

在早期或中小型项目中，基于 HTTP 协议的 RESTful API 是系统间交互的主流方式。其优点非常突出：简单、直接、开发便捷，利用无处不在的 HTTP 协议即可完成数据传输。

例如，一个典型的 HTTP 接口调用如下：

POST http://api.example.com/v1/order/create

客户端会收到一个 JSON 或 XML 格式的响应，然后进行解析处理。对于接口数量有限、交互逻辑不复杂的场景，这种方式开发迭代速度很快。

然而，在大型企业复杂的微服务架构下，内部子系统众多，服务接口调用频繁，RPC 框架的诸多特性便显示出巨大价值。首先，RPC 框架通常支持长连接，避免了 HTTP 短连接每次通信所需的 TCP 三次握手开销，显著降低了网络延迟。其次，成熟的 RPC 框架往往配套有服务注册与发现中心，提供服务治理能力，如接口的发布、下线、动态扩展、负载均衡和丰富的监控管理，这些对于服务调用方而言是无感知的、统一化的操作，极大提升了分布式系统的可维护性。

总结

RPC 服务和 HTTP 服务各有其适用的土壤。简单来说：

• RPC 更侧重于性能、效率和服务治理，适用于大型、复杂的分布式系统内部通信。
• HTTP（RESTful API）更侧重于简单性、通用性和易用性，适用于对外提供开放 API 或内部快速迭代的中小型项目。

技术选型不应盲目追随潮流。关键在于对项目进行全面的评估，仔细权衡两种通信方式在性能、开发效率、维护成本和团队技能等方面的影响，从而选择最适合当前项目阶段和未来发展的方案。切勿为了使用 RPC 而使用 RPC，因地制宜才是明智之举。

希望这篇对比能帮助你更好地理解 RPC 与 HTTP。如果你想与更多开发者交流此类架构设计话题，欢迎访问云栈社区参与讨论。