当你开始构建现代支付基础设施时，资金转移看起来似乎简单得具有欺骗性。
用户发起一笔付款。你的系统调用银行应用程序接口。银行返回成功或失败的响应。你相应地更新数据库。
至少，在架构图中看起来是这样的。
实际上，付款系统运行在一个充满部分失败、延迟确认、网络超时以及并不总是按软件工程师预期方式运行的传统银行基础设施的世界中。
多年来，一个架构原则始终被证明是区分弹性付款平台与昂贵运营事故的关键：
除非你有确凿的证据证明付款已失败，否则永远不要假设付款已失败。
乍一看，这似乎违反直觉。工程师受过训练，要积极地处理错误并保持系统运行。如果应用程序接口调用超时或返回意外响应，自然的本能是将交易标记为失败，退还资金，并允许用户重试。
在付款系统中，这种本能可能会造成真正的资金损失。
同步支付的错觉
大多数软件系统以同步方式运行。
你发送一个请求。
你接收一个响应。
该响应成为事实来源。
银行基础设施并不总是这样工作。
许多支付渠道涉及多个内部系统、结算层、队列、批处理器、欺诈引擎和对账工作流。在某一层看似失败的请求，可能仍在另一层中继续处理。
考虑一个简化的付款流程：
应用程序
│
▼
支付网关
│
▼
银行网络
│
▼
收款银行
作为工程师，我们通常假设第一个集成点的响应准确反映了交易的最终状态。
不幸的是，情况并非总是如此。
你的平台与支付合作伙伴之间的超时并不一定意味着付款失败。
意外的状态码并不一定意味着付款失败。
暂时的服务中断并不一定意味着付款失败。
请求可能已经越过了不可回退的点。
一旦资金转移启动，不确定性就成为系统的一部分。
最危险的状态：未知
大多数工程师以成功和失败的角度思考问题。
支付系统有第三种状态：
未知。
未知意味着：
付款可能已成功。
付款可能已失败。
付款可能仍在处理中。
最终结果尚无法确定。
许多生产环境事故始于团队试图将未知状态强制归类为失败状态。
想象一笔经历超时的付款请求。
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
