三种主要选项是 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,浏览器 | 内部热路径 | 解耦,事件 |
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; }
Order Service ─publish→ [ "OrderPlaced" topic ] ─▶ Inventory
└────▶ Notifications
(producer doesn't know or wait for consumers)
到处使用同步 gRPC/REST 会重新造成紧耦合;为用户的即时读取使用异步会增加不必要的延迟。
传输选择为每个交互设置了耦合和性能上限,因此按用例选择——而不是全局统一——才是保持系统既快速又有弹性的关键。
成熟的系统故意混合所有三种:在内部热路径上使用 gRPC、在边界使用 REST、为工作流使用队列。