设计生产支付引擎 (Designing A Production Payment Engine)

本系列从提供者抽象开始，继续介绍 Webhook 可靠性、幂等性、传奇、租赁、共识、可观察性、恢复管道和一次有效处理。最后一个技术部分是该旅程的综合：如果您正在设计一个在生产中运行的支付引擎，您应该做出哪些决定以及以什么顺序？

检查表不是功能列表。每一项都是对该系列的一个或多个部分所倡导的原则的可衡量的测试。这不是“是否存在幂等性？”问题是“幂等密钥 API、webhook 重复数据删除和数据库唯一性三重奏是否可以协同工作？”```text Production Payment Engine ├─ Boundaries (orchestrator ↔ gateway) ├─ State & Evidence ├─ Reliability (retry, lease, outbox) ├─ Recovery (reconciliation, runbooks) └─ Observability (payment id, step log, metrics)

## 第一次提到的概念```text
📦 Checkout Orchestrator
Ödeme niyetini yöneten, semantik sonuç gören, PSP detayı bilmeyen servis.

📦 Provider Gateway
PSP SDK'sını, webhook çevirisini ve provider'a özgü akışları sahiplenen servis.

📦 Production Readiness
Sistemin sadece happy path'te değil, arıza, yarış ve sürüklenme anlarında da doğru davranması.

📦 Architectural Checklist
Tasarım kararlarının ölçülebilir, evet/hayır testlerine dönüştürülmüş hali.
```生产支付引擎并不意味着“收费API正在工作”；它是为了回答“当充电失败、webhook 延迟到达、worker 崩溃时会发生什么？”这个问题。

## 1. 限制：无 SDK 泄漏

- [ ] Checkout Orchestrator 是否不导入任何 PSP SDK 类型？
- [ ] Orchestrator 是否只能看到语义 `ChargeRequest` / `ChargeResult`？
- [ ] webhook 是否作为原始提供程序负载或语义事件到达下游？
- [ ] 提供商网关是否是提供商事件→语义事件映射表的唯一所有者？
- [ ] 添加新的 PSP 是否需要对协调器代码进行零行更改？

本集是该系列的第 9 集至第 10 集。是其各部分的本质。如果边界被打破，剩余的每一层都会建立在泄漏的顶部。

## 2. 状态与证据：状态≠证据

- [ ] 支付状态机是否明确定义（处理中、FinalizePending、Captured、Failed、Expired）？
- [ ] 终端状态不可逆转吗？
- [ ] 付款快照（金额、币种、篮子）是否不可更改？
- [ ] 来自 PSP 的证据（webhook、同步响应）是否存储在单独的证据表中？
- [ ] 状态转换是基于证据还是假设？

## 3.可靠性：重试、租用、发件箱

- [ ] 是否定义了错误分类（BusinessDecline、Timeout、RateLimited、Infra设施）？
- [ ] 是否对每个类别应用不同的重试策略？
- [ ] DB 支持的作业是否在租赁下处理？
- [ ] webhook 处理程序是否同时使用租约 + 版本令牌？
- [ ] 该事件是否与状态更改的发件箱模式处于同一事务中？
- [ ] 幂等性关键API、消费者重复数据删除和数据库唯一性三重奏是否在一起？

## 4. 恢复：之前自动化，之后运行手册

- [ ] 调节清理器是否老化 FinalizePending/Expired 扫描记录？
- [ ] 孤儿收费场景可以通过关联id解决吗？
- [ ] 多用途购物车是否有购物车锁定功能？
- [ ] 独特性墙手册是否写入审核队列？- [ ] Runbook 是否基于证据（步骤日志 + PSP 查询 + 审核）？
- [ ] 治疗/退款决定是一个程序，而不是条件反射吗？

## 5. 可观察性：支付 ID 主干

- [ ] 每个日志、跟踪和指标是否都带有付款 ID？
- [ ] 步骤事件日志是否仅附加且是否涵盖每个有意义的步骤？
- [ ] 是否定义了 `deferred_finalize_count` 和 `deferred_finalize_age_seconds` 指标？
- [ ] 漂移计数突然增加时是否会产生警报？
- [ ] 是否可以使用支付 ID 跟踪从结帐到终端状态的完整路径？

## 6.一致性模型：最终的、中等的、可观察的

- [ ] 是有意识地选择了传奇+和解模式而不是2PC吗？
- [ ] 是否定义了每个 saga 步骤的补偿操作？
- [ ] 最终一致性窗口是否已测量并与产品团队共享？
- [ ] 目标是“短时间内一致”，而不是“始终一致”的幻想吗？```text
Checklist tamamlandığında sorulacak son soru:
  'Bu sistemin en kötü gününde ne olur?'
  → Cevap runbook'ta, metriklerde ve reconciliation'da yazılı olmalı.

经常混淆的区别```text

❌ Checklist = feature tamamlandı demek ✓ Checklist = mimari ilkenin ölçülebilir testi

❌ Production ready = load test geçti ✓ Production ready = arıza anında doğru davranış kanıtlandı

❌ Daha fazla PSP = daha fazla karmaşıklık ✓ İyi sınırlar varsa, yeni PSP yalnızca gateway'i etkiler

|部分|系列剧集|基本问题|
| --- | --- | --- |
|边框| 9-10 | Orchestrator了解PSP吗？ |
|情况与证据| 1-4, 6 |是基于国家证据吗？ |
|可靠性| 5、7-8、11、17、20 |如果出现故障怎么办？ |
|恢复| 12-16、19 |如何捕捉漂移？ |
|可观察性| 18 | 18被冻结的付款是否可见？ |
|一致性| 3, 16 | 2PC 还是佐贺？ |

## 生产准备评估

1. 在设计评审中一一检查清单的六个部分；对每个项目回答是/否/部分。
2. 在技术债务列表中添加“部分”答案；根据业务影响确定优先级。
3. 运行最糟糕的一天场景（PSP 5xx、webhook 滞后、worker 崩溃、孤立充电）作为桌面练习。
4. 注意练习期间哪些清单项目保持空白——这些是最初的改进目标。
5. 保留清单作为活文件；每次生产事件后更新相关文章。

## 本系列中值得记住的内容

1. 生产支付引擎是通过失败行为来衡量的，而不是快乐路径。
2. 清单是该系列 22 集的可衡量综合，而不是功能列表。
3. 如果边界（协调器↔网关）被打破，其他一切都建立在该漏洞之上。
4. 最糟糕的一天问题的答案应写在操作手册、指标和调节中。

> 设计生产支付引擎并不是要“编写收费 API”——而是要缩小捕获与完全受控、可观察和可恢复之间的差距。

在最后一集中，我们从职业角度来看待这个系列：金融科技公司真正在寻找什么？