RPC 与 HTTP 分别有什么用途和区别？

核心回答

RPC 是远程过程调用的抽象，目的是让程序通过服务接口调用另一进程中的方法；HTTP 是应用层协议，定义请求、响应、方法、状态码等通信语义。它们处在不同的比较维度，可以组合使用，例如 gRPC 通常基于 HTTP/2，因此“用了 HTTP 就不是 RPC”并不成立。

面试中的“RPC 和 HTTP 区别”，通常是在比较一套 RPC 框架与一套基于 HTTP 的接口方案。这时应明确比较具体协议、序列化、接口契约和治理能力，不能只凭名字判断性能。

一次远程调用发生了什么

以调用订单服务为例，客户端桩或代理把方法名和参数转换成请求，选择服务地址并发送；服务端接收、反序列化、分派到具体实现，再把结果或错误返回。框架往往还提供连接管理、超时、负载均衡、服务发现和拦截器。

HTTP 接口也能具备这些能力：用 OpenAPI 描述契约，用客户端生成器产生调用代码，用注册中心或 DNS 发现地址，再配合网关、连接池和可观测性组件。因此服务发现、长连接、二进制序列化都不是 RPC 独占能力；HTTP 消息体也可以携带 Protobuf，未必是 JSON。

工程上怎样选

• 外部开放接口、浏览器和跨组织集成：基于 HTTP 的接口通常更便于接入现有网关、代理和调试工具，但仍需设计清楚鉴权、状态码、兼容性及幂等性。
• 内部服务、契约明确、需要代码生成或流式通信：可考虑 gRPC 等框架，统一接口描述与治理。但要评估客户端语言支持、代理兼容和排障成本。
• 性能要求高：比较真实负载下的序列化开销、包体、连接复用、并发模型和尾延迟。不能直接推出“RPC 一定比 HTTP 快”。

RPC 的本地调用外观不会消除网络故障。超时可能意味着请求没到，也可能是服务端已完成但响应丢失；写操作重试仍需幂等键、去重或状态查询。接口设计也要避免大量细粒度远程调用形成往返放大。

常见追问

RPC 必须用 TCP 吗？ 不必须，RPC 是调用抽象，具体实现可建立在不同传输和应用协议上。

REST 与 RPC 是同一层面的比较吗？ REST 是围绕资源、统一接口等约束的架构风格，RPC 更强调调用服务操作；实际系统可以混合使用，不能将所有 HTTP 接口直接等同于 REST。

参考资料