银行 Python 的架构：专有金融系统的口述历史

大型投资银行的基础设施通常依赖于庞大的专有生态系统，这些系统将 Python 等通用语言与定制构建的对象存储和执行环境相结合。这些系统旨在解决在创建时现成软件无法处理的大规模金融问题，从而导致了“替代 IT 现实”的出现，在这种现实中，开发人员使用的工具无法通过 Google 搜索或由 AI 提供支持。

核心架构：Python 与专有对象存储

投资银行经常构建集成了编程语言与全局对象数据库的内部平台。一个主要的例子是使用 Python 配对像 "Barbara" 这样的系统，它作为整个银行的全局对象存储。

对象存储的角色

在这些环境中，对象存储（例如 Barbara）不仅仅是一个数据库；它是应用程序状态、数据甚至系统自身源代码的中央仓库。

• 源代码存储： 在某些配置中，系统的源代码存储在对象存储本身（例如，在特殊的 "sourcecode" ring 中），而不是存储在传统的磁盘上。
• 状态管理： 应用程序通常通过将 dataclasses 直接写入对象存储来存储内部状态，且锁或事务开销极小。
• 全局访问： 这些系统通常具有默认的 "ring" 或全局区域，允许在整个银行范围内广泛访问数据，尽管需要特定的权限系统来管理敏感交易。

血统与影响

这些以 Python 为中心的系统（例如 JPM 的 "Alpha" 或 Merrill 的 "Quartz"）通常是早期专有语言的后裔。许多系统起源于高盛的 SecDB/Slang 生态系统，其中 SecDB 作为对象存储，而 Slang 是一种类似于 C 的语言，允许非传统的特性，例如变量名中包含空格。

金融领域遗留系统迁移的挑战

由于与金融基础设施相关的极高风险回报比，从这些专有系统迁移是一个在历史上非常困难的过程。

风险 vs. 收益

开发人员和架构师在尝试现代化遗留系统时面临着显著的不平衡：

• 收益上限有限： 成功迁移的主要收益通常是晋升或专业认可。
• 高额下行风险： 迁移过程中的失败可能导致巨大的停机，从而“摧毁业务”。

“大爆炸”式迁移 vs. 渐进式重构

虽然通常更倾向于渐进式重构，但一些金融系统集成得如此之深，以至于它们需要“大爆炸”式的迁移。这往往导致一种情况，即经过实战检验、性能良好的遗留系统被“闪亮的新系统”所取代，而这些新系统可能会引入更多 Bug，这通常是由工程师希望拥有更出色的简历而驱动的。

专有银行技术的运营现实

在这些生态系统中工作会产生一系列独特的技术和运营约束，这些约束对于软件行业的其他部分来说通常是不可见的。

软件考古学

工程师经常遇到按现代标准来看似乎冗余或低效的组件。然而，这些通常是“软件考古学”的结果，即代码是在开发时由于成熟的现成解决方案根本不存在而编写的。

极端边缘情况

金融系统必须处理超出标准编码范畴的复杂性：

• 监管约束： 例如，韩国交易可能要求服务器物理位于韩国，且交易员必须持有韩国执照，即使他们是在纽约进行操作。
• 交易差异 (Trade Breaks)： 整个系统都致力于跟踪“交易差异”（银行之间对特定成交价的歧见），其中一些由于诉讼或公司破产而保持开启状态多年。
• 长期订单持久性： 一些系统在历史上曾维持着可以追溯到几十年前的“撤单前有效 (Good Till Cancel)”订单（例如，1997 年的订单）。

“替代 IT 现实”

由于这些 systems 是专有的，工程师开发的技能集与单一公司绑定。这创造了一批无法依靠外部文档、Stack Overflow 或 AI 助手，因为他们使用的工具在公共领域并不存在。由于缺乏全面的文档，这使得内部知识转移高度依赖于少数几个人。