比较 REST、gRPC 和消息队列在服务间通信中的应用。

Question

Accepted Answer

三种主要选项是 **REST**（HTTP/JSON）、**gRPC**（HTTP/2 + Protobuf）和 **message queues**（Kafka/RabbitMQ）。REST 和 gRPC 是同步的；队列是异步的。

## 比较

| 方面 | REST | gRPC | Message Queue |
|---|---|---|---|
| 风格 | Sync | Sync | Async |
| 载荷 | JSON (text) | Protobuf (binary) | Any (通常 binary) |
| 性能 | 良好 | 高 | 高吞吐量 |
| 契约 | OpenAPI (宽松) | `.proto` (严格) | Schema/event |
| 流式处理 | 有限 | 原生 (bidi) | Pub/sub |
| 最适合 | 公共 APIs，浏览器 | 内部热路径 | 解耦，事件 |

## gRPC 契约示例

```proto
service OrderService {
  // strongly-typed RPC, generated client + server stubs
  rpc GetOrder (OrderId) returns (Order);
}
message OrderId { string id = 1; }
message Order  { string id = 1; double total = 2; }
```

## 消息示例

```text
Order Service ─publish→ [ "OrderPlaced" topic ] ─▶ Inventory
                                              └────▶ Notifications
(producer doesn't know or wait for consumers)
```

## 选择

- **REST** — 外部客户端、广泛兼容性、可读性强。
- **gRPC** — 内部、低延迟、高容量调用；强契约；流式处理。
- **Queues** — 解耦、缓冲、事件驱动流、抵御故障。

## 陷阱

到处使用同步 gRPC/REST 会重新造成紧耦合；为用户的即时读取使用异步会增加不必要的延迟。

## 为什么这很重要

传输选择为每个交互设置了耦合和性能上限，因此按用例选择——而不是全局统一——才是保持系统既快速又有弹性的关键。

成熟的系统故意混合所有三种：在内部热路径上使用 gRPC、在边界使用 REST、为工作流使用队列。

风格	Sync	Sync	Async
载荷	JSON (text)	Protobuf (binary)	Any (通常 binary)
性能	良好	高	高吞吐量
契约	OpenAPI (宽松)	`.proto` (严格)	Schema/event
流式处理	有限	原生 (bidi)	Pub/sub
最适合	公共 APIs，浏览器	内部热路径	解耦，事件