天达银行云原生事件驱动架构实践：金融行业的经验与教训

天达银行（Investec）的Chris Tacey-Green分享了在银行业实施云原生事件驱动架构（EDA）的实战经验，监管约束、可靠性要求和文化阻力带来了独特挑战。

为什么银行业需要EDA？

解耦：支付监控可独立于支付执行运行。监控宕机不影响支付流程。

不可变活动日志：事件作为可审计的业务记录，满足监管合规需求。

扇出：单个支付事件可触发多个独立流程：限额更新、通知、对账。

容错能力：分层重试策略、受控退避、死信处理，应对不可靠的外部依赖（如欺诈引擎）。

即插即用：新功能（如奖励计划）订阅现有事件流，无需修改核心系统。

关键区分

• 命令vs事件：命令请求执行操作；事件陈述已发生的事实。混淆两者会导致更紧密的耦合。
• EDA不等于事件溯源：事件溯源将状态建模为不可变事件序列（复杂）；EDA仅通过事件通信（简单）。两者经常被混淆但是独立概念。

最大挑战：人而非技术

• 新团队成员在EDA+事件溯源领域需要约6个月才能达到资深同事的交付效率
• 团队往往过度设计非关键方面，同时低估一致性、重试和故障处理
• 解决方案：投资开发者平台（模板、共享模块），加上实操培训（赋能团队与交付团队结对）远比文档有效

可靠性设计模式

• 收件箱/发件箱模式：确保可靠的事件发布
• 稳定事件契约：防止破坏性变更波及消费者
• 受控事件负载：事件只应包含与状态变更直接相关的数据

核心结论

事件驱动架构在银行业可行，但成功更多取决于组织在培训和工具上的投入，而非技术本身。从同步到异步思维的文化转变才是真正的瓶颈。