4. 服务间通信选型：REST vs gRPC vs 消息队列，交易场景下的延迟与一致性权衡

服务间通信，说白了就是微服务之间怎么“说话”。

在交易系统里，这个选择特别要命。我见过不少团队，一开始图省事全用REST，结果到了高并发场景下，延迟一上来，整个链路就崩了。也见过有人迷信gRPC，结果为了一个简单的异步通知，硬生生把架构搞复杂了。

今天咱们就聊聊这三种通信方式，在交易场景下到底该怎么选。

4.1 三种通信方式的核心差异

先看一张图，帮你快速建立整体认知：

4.2 REST：简单但不够快

REST 的好处不用多说，大家都懂。JSON 格式，人类可读，调试方便。

但在交易系统里，它的缺点也很明显。

• 序列化开销大：JSON 是文本协议，解析起来比二进制慢得多。我测过，同样一个订单对象，JSON 序列化比 Protobuf 慢了 3-5 倍。
• 没有强类型约束：接口文档全靠写，一不留神就出现字段名拼写错误。我曾经因为一个字段名大小写问题，排查了整整一个下午。
• HTTP 头部冗余：每次请求都带着一堆 Header，在高频调用下，网络带宽浪费不少。

4.3 gRPC：高性能但有点重

gRPC 用 Protobuf 做序列化，基于 HTTP/2，性能确实好。

我记得在一个风控项目中，把核心链路的 REST 换成 gRPC 后，接口延迟从平均 15ms 降到了 3ms 左右。效果立竿见影。

但 gRPC 也有坑：

• 调试不方便：Protobuf 是二进制格式，不能直接用 curl 调。你得装 grpcurl 或者用专门的客户端。
• 版本管理麻烦：proto 文件一改，所有依赖的服务都得重新生成代码。我见过一个团队因为 proto 文件版本没对齐，线上出了好几次兼容性问题。
• 浏览器支持差：gRPC-Web 虽然有了，但功能有限。前端直接调 gRPC 还是不太现实。

4.4 消息队列：异步解耦的利器

消息队列在交易系统里，主要解决两个问题：削峰填谷和异步解耦。

举个例子，用户下单后，需要做一系列操作：扣库存、发短信、更新统计、推送通知。如果全部同步做，下单接口的响应时间会很长。用消息队列，下单服务只管发一条消息，其他服务各自消费，互不干扰。

但消息队列也有代价：

• 最终一致性：消息可能延迟，极端情况下可能丢失（虽然概率很低）。你需要做好幂等处理和补偿机制。
• 运维复杂度：Kafka、RocketMQ 这些中间件，部署和调优都不简单。我见过一个小团队，为了省事直接用 Redis 的 List 做消息队列，结果丢消息丢到怀疑人生。
• 调试困难：消息流是异步的，出了问题很难追踪。你得搭配链路追踪工具（如 Zipkin、SkyWalking）才能看清全貌。

4.5 交易场景下的选型策略

说了这么多，到底怎么选？我总结了一个简单的决策矩阵：

场景	推荐方式	原因
订单创建（核心链路）	gRPC + 消息队列	gRPC 保证低延迟同步，MQ 做异步兜底
账户余额查询	gRPC	高频查询，需要强一致和低延迟
交易流水查询	REST	低频查询，对外暴露，方便调试
风控规则判断	gRPC	延迟敏感，毫秒级响应要求
短信/邮件通知	消息队列	异步执行，允许延迟，失败可重试
行情数据推送	gRPC 双向流	低延迟、高吞吐、实时推送
日志采集	消息队列	海量数据，异步写入，不影响主流程

4.6 混合架构：没有银弹

你想想看，一个真实的交易系统，不可能只用一种通信方式。

我现在的做法是：

1. 核心同步链路用 gRPC：订单、风控、账户这些对延迟和一致性要求高的，必须用 gRPC。
2. 异步事件用消息队列：状态变更通知、日志、短信这些，走 MQ 解耦。
3. 对外 API 用 REST：给第三方或者前端调用的接口，还是 REST 最方便。

说白了，没有完美的通信方式，只有最适合场景的选择。你需要在延迟、一致性、运维复杂度之间找到平衡点。

嗯，这一章就聊到这里。通信选型没有标准答案，关键是你得理解每种方式的优缺点，然后根据业务场景做权衡。下次遇到类似问题，不妨先画个决策树，再动手。