Observability 与 Failure Recovery 在 Distributed Financial Systems 中：当正确的系统仍然崩溃

Source: Dev.to

Abstract

金融系统通常以正确性保证来描述。工程师讨论事务不变式、阈值密码学和确定性状态机。这些属性是必要的，但不足以在生产环境中运行金融基础设施。分布式环境的现实会带来崩溃、消息延迟、状态观察不一致以及运营不确定性。

本文考察分布式金融系统中的可观测性和恢复。我们探讨为何仅有正确性保证不足以使系统可操作，分布式故障如何在金融基础设施中传播，以及为何可观测性必须被视为一等的架构原语，而不是事后监控的附属。

金融系统的评判标准不是它在一切正常时的表现，而是它在不可避免的故障发生时的表现。

运营金融系统的不舒适现实

当你第一次在生产环境中运营真实的金融系统时，有件事会立刻变得清晰：

正确性并不等同于可操作性。

• 你可以设计一个强制价值守恒的账本。
• 你可以使用阈值密码学构建托管基础设施。
• 你可以强制执行强大的事务保证。

然而，第一次生产事故会提出一个不同的问题。

不是“系统是否正确？”
而是“实际发生了什么？”

在分布式系统中，这个问题的答案很少是显而易见的。

• 交易可能已经在账本中提交，但下游服务未观察到。
• 一次托管签名轮可能部分执行后因节点崩溃而中止。
• 结算适配器可能在重试操作，而另一个组件认为交易已经完成。

系统本身可能仍然是正确的，但运维人员已经不再了解系统状态。此时，观测性就成为了架构的核心。

分布式系统隐藏时间上的故障

在集中式系统中，故障通常会立即可见：进程崩溃，请求失败，错误会返回给调用方。

分布式系统的行为则不同。故障可能会 延迟、重新排序或部分被观察到。

• 一个事务可能已被某子系统接受，而另一个子系统尚未观察到该事件。
• 由于网络重试，消息可能会被重复投递两次。
• 由于队列暂时不可用，服务可能在显著延迟后才处理事件。

其结果是 时间不确定性。不同组件在同一时刻可能持有不同的现实视图。金融基础设施若没有强大的追踪与重建机制，无法容忍这种模糊性。缺乏可观测性时，工程师只能调试一个行为无法重建的系统。

监控与可观测性的区别

对于金融基础设施，仅靠监控是不够的。仅仅知道某个服务在运行或延迟在预期范围内并不足够。工程师必须能够在多个服务之间重建金融交易的完整生命周期。

考虑一次取款请求。 生命周期可能包括：

1. 账本验证
2. 风险评估
3. 合规检查
4. 保管签名
5. 结算广播

如果任何一步失败，工程师必须确定故障发生的地点以及系统对交易状态的认知。这不仅需要日志，还需要架构层面的仪表化。

事件可追溯性作为系统不变式

在生产环境的金融系统中，每笔交易都应产生可追溯的事件链。每一次状态转换必须关联一个稳定的标识符，并在服务边界之间传播。

TransactionID = global identifier for the financial operation
TraceID       = request lifecycle across services
EventID       = unique identifier for a state transition

每个子系统都会发出与这些标识符关联的事件。

• Ledger 可能会发出

  • TransactionValidated
  • TransactionCommitted

• Custody 可能会发出

  • SigningRoundStarted
  • SignatureProduced

• Settlement infrastructure 可能会发出

  • BroadcastInitiated
  • BroadcastConfirmed

这些事件共同构成系统行为的可追溯时间线。没有这条时间线，事故分析就只能靠猜测。

Source: …

故障后重建系统状态

分布式金融系统中的故障很少是“干净”的。

• 保管签名过程可能在中途失败。
• 结算广播可能已在区块链上成功，但内部服务在持久化结果之前崩溃。

恢复需要能够从持久记录中重建系统状态。系统必须保留足够的信息，以回答以下问题：

• 交易是否已经进入保管签名阶段？
• 是否已经生成签名但未记录？
• 交易是否已广播到网络？

架构必须支持 确定性重建。在实践中，这通常意味着将状态转变记录为事件，而不是仅仅更新可变的数据库行。当系统仅依赖可变状态时，重建过去会变得极其困难。

Source: …

幂等性和安全重试

一旦发生故障，系统必须安全地重试操作。在分布式系统中，重试是不可避免的：网络会丢失消息，服务会重启，超时会触发重复尝试。

金融基础设施必须保证重试不会产生重复的效果。

• 示例：结算适配器可能会重试广播交易。
• 系统必须确保对该操作的重试 不会 产生重复的账本变更。

这是一项对任何在金融工作流中执行副作用的组件的典型要求。

幂等性保证

Operation(TransactionID) applied multiple times
must produce the same final state as applying it once

如果没有幂等性，恢复过程本身可能会破坏系统状态。

可观测性作为运营安全

可观测性不仅帮助工程师调试事故——它还能主动防止运营失误。

设想一种情形：操作员尝试手动重新执行一次失败的交易。如果缺乏完整的可追溯性，操作员可能没有意识到该交易已经在下游组件中成功。这是生产错误中最危险的一类。

系统必须提供足够的可视性，以防人为干预引入额外的不一致性。在高可靠性的金融基础设施中，可观测性充当防止运营错误的护栏。

可观测性不足的代价

许多分布式系统的失败并非因为算法错误，而是因为工程师无法足够快速地诊断故障。当可观测性薄弱时：

• 事件的解决时间更长
• 恢复过程变为手动
• 需要进行对账
• 对系统的信任度下降

在金融基础设施中，这种退化会带来真实的后果。恢复延迟可能影响客户资金、结算时机以及监管合规。

因此，可观测性 并非 仅仅是开发者的便利；它是系统可靠性合约的一部分。

金融系统必须能够自我解释

一个设计良好的金融系统应能够随时回答以下问题：

“这笔交易发生了什么？”

如果系统无法精确回答该问题，则说明架构不完整。

• 账本正确性 保护金融完整性。
• 托管架构 保护签署权。
• 核心架构 保护系统组合。
• 可观测性 保护运营理解。

没有可观测性，工程师将盲目操作。

结论

构建金融基础设施不仅需要设计正确的算法，还需要构建在故障情况下仍然可理解的系统。

分布式金融系统必须假设组件会崩溃，网络会延迟消息，服务会在不同时间观察到状态转换。可观测性提供了在这种不确定环境中重建真相的机制。

一个无法解释自身行为的系统无法安全运行。在金融基础设施中，可观测性不是调试工具——它是架构的一部分。