2. 中间件层角色：中间件在分布式系统中的地位、API网关与事务边界的交互、消息中间件的事务支持

2.1 中间件在分布式系统中的核心地位

在分布式系统架构中，中间件层并非简单的“胶水代码”，而是承担着状态协调、通信抽象、事务边界管理三大核心职责的独立基础设施层。它位于业务服务与底层基础设施之间，屏蔽了网络分区、节点故障、时钟偏差等分布式难题，为上层提供统一的编程模型。

2.2 API 网关与事务边界的交互

API 网关作为流量的统一入口，是事务边界治理的前置哨兵。它需要在请求进入分布式系统时，完成事务上下文的初始化与传播，并在响应返回时进行边界收口。

2.2.1 事务上下文传播机制

网关通过 HTTP 头或自定义协议字段，将全局事务 ID（Global Transaction ID, GTID）注入请求链路。下游服务通过中间件 SDK 自动提取并传递该 ID，形成完整的调用链。

// 网关层注入全局事务 ID 示例（伪代码）
public class TransactionFilter implements GlobalFilter {
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        String gtid = UUID.randomUUID().toString();
        exchange.getRequest().mutate()
            .header("X-Global-Transaction-Id", gtid)
            .header("X-Transaction-Timeout", "30000");
        return chain.filter(exchange);
    }
}

2.2.2 网关层事务边界治理清单

• 超时熔断：网关配置全局事务超时阈值（如 30s），超时后直接返回 503，避免下游长时间挂起。
• 幂等校验：对写请求生成幂等键（Idempotency-Key），网关层去重，防止重复提交导致事务状态混乱。
• 部分成功处理：当网关收到部分下游成功、部分失败的响应时，触发补偿请求（如 TCC 的 Cancel 调用）。
• 事务标签透传：将事务类型（XA/TCC/SAGA）作为标签传递，下游据此选择对应的恢复策略。

2.3 消息中间件的事务支持

消息中间件在分布式事务中扮演着异步协调者的角色。它通过“半消息”机制和“事务回查”协议，实现了最终一致性的事务模型，避免了同步二阶段提交带来的性能损耗和资源锁定。

2.3.1 消息事务的核心模型

以 RocketMQ 为例，消息事务分为三个阶段：

1. 半消息发送：生产者发送一条“半消息”到 Broker，该消息对消费者不可见。
2. 本地事务执行：生产者执行本地数据库事务。
3. 事务状态提交/回滚：根据本地事务结果，向 Broker 提交 Commit 或 Rollback 指令。若生产者宕机，Broker 通过回查接口确认事务状态。

2.3.2 消息中间件的事务边界治理策略

• 事务消息与本地事务绑定：将消息发送与本地数据库操作放在同一个本地事务中，利用数据库的 ACID 特性保证“要么都成功，要么都回滚”。
• 回查超时与重试：设置合理的回查超时（如 60s），超时后 Broker 自动回滚半消息。回查失败时采用指数退避重试，最大重试次数建议为 3 次。
• 死信队列（DLQ）处理：超过最大重试次数的消息转入死信队列，人工介入或自动化补偿脚本处理。
• 消息去重消费：消费者侧维护已处理消息 ID 的幂等表，防止消息重复投递导致的事务状态不一致。

2.4 中间件层事务边界治理的协同原则

API 网关与消息中间件在事务边界治理中并非孤立工作，而是形成“同步边界 + 异步协调”的协同模式：

• 同步路径：API 网关负责短事务（< 30s）的边界标记与超时熔断，适用于 TCC 或 XA 模型。
• 异步路径：消息中间件负责长事务（> 30s）的最终一致性协调，适用于 SAGA 或可靠消息模型。
• 混合模式：网关将长事务请求转换为事件消息，由消息中间件异步驱动下游服务，网关只关注事件是否成功入队，不等待最终结果。