1.9 KiB
1.9 KiB
Context
API 与 Worker 分别创建订单服务。Worker 已为订单服务注入停复机模块，API 未注入；因此支付回调调用支付后自动复机入口时没有可执行的回调。支付后自动复机入口在事务提交后查询本订单的已生效主套餐，再异步调用停复机模块。
Goals / Non-Goals
Goals:
- 使 API 支付回调复用既有的支付后自动复机入口。
- 保持“仅已生效主套餐触发”的现有查询语义和停复机资格判断。
Non-Goals:
- 不改变套餐权益状态、支付事务范围、Gateway 重试和轮询调度。
- 不让支付回调等待 Gateway 复机结果。
- 不新增队列、端口、数据表或配置。
Decisions
在 API Composition Root 注入既有回调
在 API 创建订单服务后调用既有的 SetResumeCallback(stopResumeService)。这是 Worker 已使用的装配方式；复用同一模块可将卡/设备载体解析、有效套餐、剩余流量、实名、停机原因、分布式锁和 Gateway 调用保持在一个实现内。
不在支付回调中直接调用 Gateway，也不复制资格判断。直接调用会绕过已存在的幂等锁、设备多卡处理和审计/观测写入。
以事务提交后的已生效权益为复机前置条件
保留订单服务当前的查询：仅本订单 status=Active 且 master_usage_id IS NULL 的主套餐权益可触发复机。查询发生在支付与权益事务成功返回后，避免使用未提交或排队权益快照。复机模块在异步执行时重新读取卡及权益事实，防止并发状态变化导致错误复机。
Risks / Trade-offs
- Gateway 调用仍是异步副作用；支付成功不等于复机成功。该取舍保持支付事实可靠落库，不将外部网络延迟或失败耦合到支付回调。
- API 进程现在可发起复机；其依赖已由同一 Composition Root 配置，且执行路径与 Worker 一致。