面试里有个经典问题：微服务之间调用，用 HTTP 还是 RPC？

我第一次被问懵了——HTTP 不就是接口嘛，RPC 又是啥，俩不是一回事吗？

后来真正做了几个服务拆分，才慢慢摸清这俩的定位。它们不是对立的，很多时候还搅在一起。这篇把 HTTP 和 RPC 到底是什么、差在哪、各自什么时候用，讲清楚。

先给个直观印象

一句话先立个靶子：

• HTTP 是一个协议，规定了请求和响应长什么样、怎么传。
• RPC 是一种思想/模式，让你"调用远程的方法像调用本地方法一样"。

注意这俩不在一个维度上。HTTP 是具体协议，RPC 是一种调用风格。

所以严格说，拿它俩直接对比有点关公战秦琼。但大家平时说的"HTTP 还是 RPC"，其实对比的是：基于 HTTP 的接口调用（比如 REST） 和 传统的 RPC 框架调用（比如 gRPC、Dubbo）。下面就按这个来聊。

RPC 想解决什么

RPC 全称 Remote Procedure Call，远程过程调用。

它的理想很朴素：我想调另一台机器上的一个方法，希望写起来跟调本地方法一模一样。

// 本地调用，天经地义
result := userService.GetUser(1001)

// RPC 的理想：这行代码背后其实是调了另一台服务器上的 GetUser
// 但我写代码时感觉不到网络的存在
result := userClient.GetUser(1001)
​

为了做到"感觉不到网络"，RPC 框架在背后帮你干了一堆脏活：

1. 把方法名、参数打包（序列化）。
2. 通过网络发给远端。
3. 远端解包、找到对应方法、执行。
4. 把返回值打包传回来。
5. 本地解包，把结果交给你。

这一整套叫"透明化远程调用"。你只管调方法，网络传输、序列化这些细节框架包了。

它们到底差在哪

把基于 HTTP 的接口和 RPC 框架摆一起，差异主要在这几块。

传输和协议

• HTTP 接口：走 HTTP 协议，大多基于 HTTP/1.1，文本协议，带一堆 header。
• RPC 框架：很多用自定义的 TCP 协议（Dubbo），或者基于 HTTP/2（gRPC），协议更精简。

HTTP 的 header 是有开销的，每个请求都带一堆元信息。RPC 的自定义协议能把这些压到最小。

数据格式

• HTTP 接口：通常用 JSON，可读性好，人眼能看懂，调试方便。
• RPC 框架：常用二进制序列化（Protobuf、Hessian），体积小、编解码快，但人看不懂。

JSON 是文本，一个数字 12345 要占 5 个字符；Protobuf 是二进制，同样的数据能压得更小。性能上 RPC 占优。

耦合和跨语言

• HTTP 接口：天然跨语言、跨平台，任何能发 HTTP 请求的都能调，前端、第三方、各种语言通吃。
• RPC 框架：通常要双方用同一套框架、共享接口定义（比如 proto 文件），耦合更紧。gRPC 靠 proto 也能跨语言，但要生成代码。

开发体验

• HTTP 接口：直接，一个 URL 一个 Postman 就能测，门槛低。
• RPC 框架：要定义接口、生成桩代码，前期配置多，但调用时像本地方法一样顺手。

一张对比

那到底怎么选

别纠结"谁更先进"，看场景。

倾向 HTTP/REST 的场景：

• 对外开放的接口，给前端、给第三方、给 App 用。对方环境你控制不了，HTTP 通用性最稳。
• 团队技术栈杂、服务用不同语言写，HTTP 的跨语言省心。
• 接口不多、性能要求不极致，图个开发快、调试方便。

倾向 RPC 的场景：

• 内部微服务之间的大量互相调用。调用频繁、对延迟和吞吐敏感，RPC 的二进制 + 精简协议能省不少。
• 服务都在一个技术栈里（比如全是 Go 或全是 Java），共享接口定义不是负担。
• 想要"调远程像调本地"的开发体验，少写一堆 HTTP 客户端的样板代码。

实际项目里经常是混用：对外的网关层用 HTTP/REST 接客，内部服务之间用 RPC 高效互通。两边各司其职。

PS：现在 gRPC 这类基于 HTTP/2 的 RPC，其实已经把 HTTP 和 RPC 的界线搅得挺模糊了——它既是 RPC，底层又是 HTTP。所以别太教条，理解它们各自解决什么问题比贴标签重要。

小结

HTTP 是协议，RPC 是"远程调用像本地调用"的模式，严格说不在一个维度，日常对比的其实是 REST 接口和 RPC 框架。

差异集中在：协议精简度、数据格式（JSON vs 二进制）、跨语言、耦合度、开发调试体验。RPC 胜在性能和体验，HTTP 胜在通用和简单。

选型看场景：对外、跨栈、求简单用 HTTP；内部高频调用、同栈、求性能用 RPC。多数系统两者混用，网关 HTTP、内部 RPC。

搞懂它们各自为了解决什么问题，比记住谁快谁慢更有用。