33 lines
1.9 KiB
Markdown
33 lines
1.9 KiB
Markdown
## 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 一致。 |