一文读懂：跨服务调用，用HTTP还是RPC？

技术选型不再纠结，详解两者本质区别与选型依据

在分布式系统和微服务架构大行其道的今天，服务间的通信变得至关重要。面对跨服务调用，许多开发者都会遇到一个经典问题：选择 HTTP 还是 RPC？这篇文章将带你彻底弄清两者的区别，并提供实用的选型建议。

本质区别：协议与调用方式

HTTP（HyperText Transfer Protocol）是一种应用层协议，主要用于 Web 浏览器和服务器之间的通信。它遵循请求-响应模型，是一种无状态的、基于资源的协议。

RPC（Remote Procedure Call）不是协议，而是一种调用方式或通信模型。它允许程序调用另一个地址空间（通常是远程服务器）上的函数或方法，就像调用本地方法一样简单。

值得注意的是，RPC 可以通过不同的协议实现，包括 TCP、UDP 甚至 HTTP/2。例如，gRPC 就是基于 HTTP/2 的 RPC 框架。

核心差异对比

工作机制探秘

HTTP 调用流程

1. 客户端构建HTTP请求：包括请求方法、URL、请求头和请求体
2. 通过网络发送请求：通常基于TCP连接
3. 服务器处理请求：解析请求，执行相应操作
4. 服务器发送HTTP响应：包含状态码、响应头和响应体
5. 客户端解析响应：处理结果数据

RPC 调用流程

1. 客户端调用本地存根（stub）：就像调用本地方法一样
2. 存根序列化参数：将参数序列化为二进制格式
3. 通过网络发送数据：使用自定义或标准协议传输
4. 服务端反序列化参数：将二进制数据还原为原始参数
5. 服务端执行实际方法：调用真正的实现方法
6. 将结果返回客户端：逆向执行上述过程

如何选择：HTTP 还是 RPC？

选择 HTTP 的场景

1. 对外提供公共 API：为浏览器、移动App、第三方合作伙伴提供服务时，HTTP是通用标准，任何人都能轻松集成
2. 技术栈异构环境：当你的服务使用多种语言和框架编写，或者你无法控制所有调用方时，HTTP的通用性是巨大优势
3. 需要极高可观测性和易调试性：在开发测试阶段，能用 curl 或 Postman 直接发送请求并看到明文响应，极大提升开发效率
4. 对网络环境有严格要求：需要穿越严格的公司防火墙或代理，这些设备通常对HTTP有最好的支持

选择 RPC 的场景

1. 高性能要求的内部服务调用：在微服务集群内部，服务间调用频繁，二进制协议带来的性能提升（低延迟、高吞吐量）和带宽节省非常可观
2. 强接口契约和代码生成：定义好接口描述文件（如.proto）后，自动生成客户端和服务端代码，保证API一致性，减少手动编写代码的错误
3. 需要高效的流式通信：服务间有大量实时数据流、消息推送、长连接等需求（如实时监控、游戏、金融报价），gRPC的流式模式比HTTP的解决方案更原生、高效
4. 同构的技术栈和环境：内部服务主要使用几种主流语言（Go、Java、Python等），并且环境可控，可以轻松部署和统一使用RPC库

混合架构：最佳实践

在现代分布式系统中，一种常见且推荐的模式是混合使用 HTTP 和 RPC：

• 对外暴露：使用 HTTP（REST/GraphQL）
• 内部通信：使用 RPC（如 gRPC）

所有对终端用户和第三方的API都通过一个 API 网关 暴露为标准的HTTP接口。微服务集群内部的所有服务间调用，则使用高性能的RPC（如gRPC）进行通信。API网关负责协议转换，将外部的HTTP请求转换为内部服务的RPC调用，并将响应转换回HTTP。

这种模式结合了两者的优点：对外保持通用和友好，外部系统无需关心内部实现；对内追求性能和效率，内部系统享受RPC的高性能和高开发效率。

常见 RPC 框架

1. gRPC：由Google开发，支持多种语言，使用Protocol Buffers作为接口描述语言
2. Apache Thrift：最初由Facebook开发，支持多种语言
3. Dubbo：阿里巴巴开源的高性能Java RPC框架，提供了丰富的服务治理功能

总结

选择 HTTP 还是 RPC 本质上是在通用性和性能之间做权衡。

• HTTP 更像是一种"世界语"，通用性强，被广泛支持和理解，适合系统边界和对外接口。
• RPC 则像是"方言"，针对特定环境优化，性能更高但耦合性更强，适合系统内部通信。

在实际项目中，不要局限于二选一。混合使用 HTTP 和 RPC，对外提供 HTTP API，内部使用 RPC 通信，往往能带来最佳效果。最重要的是根据你的具体需求、团队技术背景和运维能力做出合理决策。