RPC vs REST
⚔️ RPC vs REST 对比¶
| 对比维度 | RPC | REST |
|---|---|---|
| 架构风格 | 面向过程 | 面向资源 |
| 通讯协议 | HTTP/2 或自定义协议 | HTTP/1 |
| 数据格式 | Protocol Buffers、MessagePack 等二进制序列化格式（也支持 JSON, XML 等格式） | JSON, XML 等格式 |
| 相关 Framework | gRPC、Dubbo、Thrift 等 | HttpClient、RestTemplate 等 |
| 使用场景 | 微服务内部，注重性能和效率，对服务调用的实时性和低延迟要求高 | 对外提供的 API，方便不同客户端（如 Web 应用、移动应用）接入 |
🏗️ 架构选型建议¶
在微服务架构中，通常采用混合模式：
- 内部服务间： 使用 RPC 可提高系统整体性能。
- 对外提供服务： 使用 RESTful API 能让更多类型的客户端轻松接入，提升系统的开放性和扩展性。
🚀 RPC 比 REST 快的主要原因¶
RPC（特别是基于 HTTP/2 的 gRPC）之所以高性能，主要归功于以下几点：
- ✅ 二进制数据格式： 比 JSON 更紧凑，序列化/反序列化速度更快。
- ✅ 多路复用： 单个连接可以并发处理多个请求，减少连接开销。
- ✅ 直接调用方法： 减少了协议层面的冗余开销。
- ✅ 连接复用： 减少 TCP 握手和请求时延。
- ✅ 支持流式通信： 适用于大数据传输和实时双向通信。
⚖️ RPC 的优缺点权衡¶
虽然 RPC 性能卓越，但也存在一定的门槛：
缺点：
- ❌ 调试难度大： 不像 REST 可以直接用浏览器或简单的 curl 命令访问，通常需要专门的工具或代码。
- ❌ 协议复杂： 往往需要代码生成器（如
.proto文件），不如 REST 直接使用 HTTP 语义简单直观。
总结建议：
- 如果追求高性能、低延迟、实时通信，RPC（特别是 gRPC）通常是更好的选择。
- 如果追求简单、跨语言兼容性好、易于调试，REST 可能更适合。