1. 课程导论：支付订单系统面临的通信挑战，RPC与MQ的核心区别与适用场景总览
1.1 支付订单系统的通信困境
在构建高并发、高可用的支付订单系统时，服务间通信是架构设计的核心难题。一个典型的支付流程涉及订单服务、账户服务、库存服务、风控服务、通知服务等多个微服务，它们之间需要高效、可靠地交换数据。以下是支付系统面临的主要通信挑战：
| 挑战维度 | 具体问题 | 典型场景 |
|---|---|---|
| 高并发与低延迟 | 秒杀、大促期间，订单创建请求量瞬间激增，要求毫秒级响应。 | 用户点击“立即支付”，需同步扣减库存、校验账户余额。 |
| 数据一致性 | 支付成功需同时更新订单状态、账户流水、积分，任一环节失败都可能导致资损。 | 支付回调后，需保证“订单状态更新”与“账户扣款”的最终一致性。 |
| 服务解耦与削峰填谷 | 上游订单创建速度远高于下游库存/风控的处理能力，直接调用会导致下游被压垮。 | 下单后发送短信通知、异步对账、推送物流信息。 |
| 故障隔离与容错 | 下游服务（如短信网关）临时不可用，不能阻塞主支付链路。 | 支付核心链路需与弱依赖服务（如积分、推荐）隔离。 |
核心矛盾： 支付系统既需要“实时同步”的强一致性保障（如扣款），又需要“异步解耦”的高吞吐与容错能力（如通知、对账）。单一通信模式无法同时满足所有需求。
1.2 RPC 与 MQ：两种通信范式的核心区别
RPC（远程过程调用）和 MQ（消息队列）是解决上述问题的两种基础中间件通信机制。它们的本质区别在于通信模式与耦合程度。
| 对比维度 | RPC（远程过程调用） | MQ（消息队列） |
|---|---|---|
| 通信模式 | 同步请求-响应（Request-Response） | 异步消息传递（Message Passing） |
| 耦合关系 | 强耦合：调用方需知道被调方的接口、地址、超时策略 | 弱耦合：发送方与接收方通过Topic/Queue间接关联，互不知晓对方存在 |
| 时序要求 | 实时：调用方阻塞等待结果，要求双方同时在线 | 准实时/延迟：消息可暂存，接收方可在任意时刻消费 |
| 数据一致性 | 强一致性（通过分布式事务框架如Seata实现） | 最终一致性（通过本地消息表、事务消息等实现） |
| 典型协议 | Dubbo（Java）、gRPC（HTTP/2）、Thrift | Kafka、RocketMQ、RabbitMQ、Pulsar |
| 适用场景 | 实时查询、状态校验、数据写入后需立即返回结果 | 事件通知、异步解耦、流量削峰、日志采集 |
一句话总结： RPC 适合“你问我答，立刻要结果”的场景；MQ 适合“我告诉你，你什么时候处理都行”的场景。
1.3 支付订单系统中的选型总览
在支付订单系统中，RPC 与 MQ 并非二选一，而是协同作战。下图展示了典型支付链路中两种通信机制的分工与交互。
1.4 选型决策矩阵
在实际架构设计中，我们可以根据以下矩阵快速判断使用 RPC 还是 MQ：
| 业务需求 | 推荐通信方式 | 支付系统示例 |
|---|---|---|
| 需要立即获取处理结果 | RPC | 用户支付时校验账户余额、风控规则 |
| 需要严格的事务回滚 | RPC + 分布式事务 | 下单同时扣库存、扣优惠券（TCC模式） |
| 下游处理慢，不想阻塞主流程 | MQ | 支付成功后发送短信、邮件、App Push |
| 流量突发，需要削峰填谷 | MQ | 秒杀订单写入消息队列，库存服务慢慢消费 |
| 一对多广播通知 | MQ（发布/订阅） | 订单状态变更通知给物流、积分、推荐等多个服务 |
| 数据最终一致性要求高，但允许短暂延迟 | MQ（事务消息） | 支付成功 → 更新订单状态 → 异步增加用户积分 |
避坑提示： 不要将 MQ 当作 RPC 使用（例如发送消息后立即轮询等待结果），这会丧失 MQ 的解耦优势，反而引入额外的复杂度与延迟。同样，也不要用 RPC 处理海量异步通知，否则会导致调用方线程池耗尽、系统雪崩。
1.5 本章小结
支付订单系统的通信选型，本质是在强一致性与高可用性之间寻找平衡。RPC 提供了同步、强一致的调用能力，适合核心交易链路；MQ 提供了异步、解耦、削峰的能力，适合非核心、可延迟的业务。在后续课程中，我们将深入 Dubbo/gRPC 的 RPC 实战，以及 RocketMQ/Kafka 的 MQ 实战，并最终通过一个完整的支付订单案例，展示如何将两者有机融合。