銀行 Python 的架構：專有金融系統的口述歷史

大型投資銀行的基礎設施通常依賴於龐大的專有生態系統，這些系統將 Python 等通用語言與自定義的物件儲存與執行環境相結合。這些系統旨在解決在創建之初現成軟體無法處理的高規模金融問題，從而導致了「替代性的 IT 現實」，開發人員在其中使用的工具無法透過 Google 搜尋或由 AI 提供支援。

核心架構：Python 與專有物件儲存

投資銀行經常構建內部平台，將程式語言與全域物件資料庫整合在一起。一個主要的例子是將 Python 與像 "Barbara" 這樣的系統配對使用，該系統作為整個銀行的全域物件儲存。

物件儲存的角色

在這些環境中，物件儲存（例如 Barbara）不僅僅是一個資料庫；它是應用程式狀態、數據以及系統本身原始碼的中央儲存庫。

• 原始碼儲存： 在某些配置中，系統的原始碼本身就儲存在物件儲存中（例如，在一個特殊的 "sourcecode" ring 中），而不是儲存在傳統的磁碟上。
• 狀態管理： 應用程式通常透過將 dataclasses 直接寫入物件儲存，並以極低的鎖定或交易開銷來儲存內部狀態。
• 全域存取： 這些系統通常具有預設的 "ring" 或全域區域，允許在整個銀行內廣泛存取數據，儘管管理敏感交易仍需要特定的權限系統。

血統與影響

這些以 Python 為中心的系統（例如 JPM 的 "Alpha" 或 Merrill 的 "Quartz"）通常是早期專有語言的後裔。許多系統起源於 Goldman Sachs 的 SecDB/Slang 生態系統，其中 SecDB 作為物件儲存，而 Slang 是一種類似 C 的語言，允許非傳統的功能，例如變數名稱中使用空格。

金融業中的遺留系統遷移挑戰

由於與金融基礎設施相關的極端風險與回報比例，從這些專有系統遷移出去是一個歷史上非常困難的過程。

風險與回報

開發人員和架構師在嘗試現代化遺留系統時，面臨著顯著的不平衡：

• 回報上限受限： 成功遷移的主要效益通常只是升職或專業認可。
• 高額下行風險： 遷移過程中的失敗可能導致巨大的停機，進而「摧毀業務」。

「大爆炸式」遷移與漸進式重構

雖然通常偏好漸進式重構，但某些金融系統的整合程度非常深，以至於需要進行「大爆炸式」遷移。這往往導致一種情況：經過實戰檢驗且高效能的遺留系統被「閃亮的新系統」所取代，而這些新系統可能會引入更多錯誤，這通常是由工程師希望擁有更出色的履歷而驅動的。

專有銀行技術的營運實務

在這些生態系統中工作會產生一組獨特的技術與營運限制，這些對軟體產業的其他部分來說往往是不可見的。

軟體考古學

工程師經常遇到根據現代標準來看顯得冗餘或低效的組件。然而，這些通常是「軟體考古學」的結果，因為在開發時，成熟的現成解決方案根本不存在。

極端邊緣案例

金融系統必須處理超出標準編碼範疇的複雜性：

• 監管約束： 例如，韓國的交易可能要求伺服器必須實體位於韓國，且交易員必須持有韓國執照，即使他們是在紐約進行操作。
• 交易差異（Trade Breaks）： 整個系統都致力於追蹤「交易差異」（銀行之間對特定成交價的歧見），其中一些由於訴訟或公司破產而持續數年之久。
• 長期訂單持久性： 某些系統在歷史上一直維持著可以追溯到數十年前的「撤單前有效（Good Till Cancel）」訂單（例如，1997 年的訂單）。

「替代性的 IT 現實」

由於這些系統是專有的，工程師開發的技能組與單一公司緊密相連。這會造成一種由專家構成的勞動力，他們無法依賴外部文件、Stack Overflow 或 AI 助手，因為他們使用的工具並不對外公開。由於缺乏全面的文件，這使得內部知識轉移高度依賴於少數幾個人。