银行业不受欢迎的工程真相 | AI生成和翻译
问题：银行和金融服务行业的工程领域有哪些不受欢迎或反主流的观点？
答案：
以下是银行领域的一些工程理念，它们在技术上是可靠的，但在银行、监管机构和传统工程团队中仍旧非常不受欢迎（或采用缓慢）：
-
对于核心银行系统，单体架构通常优于微服务架构
大多数银行追求微服务架构，但许多核心银行功能（分类账、支付、风险）本质上是事务性的，并且需要严格的一致性。一个模块化良好、边界清晰的单体架构在可靠性、延迟和开发速度方面往往优于分散的微服务混乱局面。不受欢迎的真相是：过早分解会带来比解决更多的问题。 -
事件溯源 + CQRS 是总账的正确架构
尽管这是以不变方式建模复式记账在学术上“正确”的方法，但几乎没有一家主要银行在核心总账层面完全致力于此。银行仍然更喜欢可变关系表，因为“COBOL 就是这样做的”，而且审计师也理解它们。 -
大多数“实时”银行服务实际上不需要实时
对于 99% 的用例（余额更新、欺诈警报、奖励），客户可以接受最终一致性。真正的即时结算既昂贵又复杂。不受欢迎的观点是：对于大多数交易量而言，批处理仍然是王道，假装不是只会浪费金钱。 -
特性开关和灰度发布比 CI/CD 流水线更重要
银行痴迷于 Jenkins/GitLab 流水线，但通常通过“大爆炸式”发布和手动批准进行部署。采用特性开关的渐进式交付比任何华丽的流水线更能降低风险，但却遭到抵制，因为“我们无法切换生产环境”。 -
不可变基础设施和“宠物”→“牛”模式对于核心银行而言基本不切实际
大型机和受严格监管的中端系统（例如 Tandem、IBM i）仍然是“宠物”是有充分理由的：零停机时间要求、严格的审计跟踪和特定于硬件的许可。将它们视为“牛”常常会以惨败告终。 -
区块链/分布式账本的大部分问题已经通过数据库解决了
区块链解决的协调和共识问题在分布式数据库（Paxos、Raft、Spanner）中早已有了几十年的解决方案。不受欢迎的看法是：银行中的私有区块链大多是营销噱头。 -
开源核心银行系统（Mifos、Mojaloop、Fineract）足以满足许多用例
构建或购买一个耗资 1 亿美元以上的专有核心系统通常被“我们是独一无二的”所辩解，然而大多数零售银行逻辑都已商品化。很少有现有机构愿意承认这一点。 -
大多数机器学习欺诈模型都过于复杂
简单地使用速度 + 规则引擎仍然能以极低的成本和可解释性问题捕获超过 95% 的欺诈。深度学习通常是为了彰显复杂性而部署，而不是为了实际的投资回报率。 -
COBOL 不是问题；围绕它的组织结构才是问题
代码枯燥、可读且极其可靠。真正的问题是 40 年的发布周期和变更审批委员会，而不是语言本身。 -
“云优先”有时对一级银行而言是鲁莽的
延迟、数据主权和供应商锁定仍然使得本地部署或混合部署成为某些工作负载（高频支付、核心分类账）的合理选择。在 2025 年大声说出这些话会让你得到奇怪的目光。
这些观点在大银行内部往往会限制职业发展，但许多经验丰富的工程师在目睹了多次“转型”举措失败后，会悄悄地持有这些观点。
参考资料：
- ThoughtWorks Technology Radar – Monoliths vs Microservices debates
- Event Sourcing in Banking – Greg Young presentations
- [The COBOL is not the problem rant – multiple industry blogs circa 2020-2024]