作者 | 鄧正威

apache/dubbo-go committer、seata-go 計畫發起人
GitHub：jasondeng1997

前五百強外企全球創新業務技術負責人，GOTC 特邀嘉賓，目前服務於國內某Top證券交易機構，負責核心交易系統開發。

什麽是核心交易系統

核心交易系統包括後台交易系統、中台系統、前台系統等，按照架構層次可分為網路架構，儲存架構，主機架構，套用架構。

為什麽要分這麽細

交易系統架構中的服務管理、流量管理、配置管理、故障容錯和可觀測性問題，如何去解決、選用什麽架構來解決、系統之間是否會存在沖突等等，相信已經讓不少前輩開發者難以招架。

在交易系統中，需要解決這些交易系統架構中的問題，通常都會部署以下服務。

可以發現，要解決這些問題不得不部署多個架構，並且每個架構都有各自的管控平台，數據聯動性差，不細分，難以有一個全域的視角讓使用者可以很好的管理。

為什麽還要使用匯流排架構

1. 微服務架構有其特點，但交易系統是異步的復雜事務，需要高流動性，匯流排架構更適合。

2. 券商類系統對吞吐量要求不高，匯流排架構更能滿足需求。

3. 選擇匯流排架構需面臨服務和治理問題，需加強匯流排管理。

4. 匯流排架構易導致管理混亂，需收緊管理來補足。

整體技術架構

競價撮合平台（MTP）：

競價撮合平台為市場參與者提供股票、基金交易業務。目前競價撮合平台包括A股和B股兩個市場，支持的業務包括核心撮合交易、IPO申購、融資融券、指定/撤銷指定等。

競價撮合平台的報單軟體是交易閘道器TDGW、EzOES。

綜合業務平台（ATP）：

綜合業務平台主要為市場參與者提供創新類業務支持，包括大宗交易、轉融通、盤後固定價格、非公開發行優先股、貨幣式基金申購贖回、ETF申購贖回、LOF申購贖回、國債預發行、約定購回、報價回購、股票質押式回購、網路投票等業務。

綜合業務平台的報單軟體是EzStep。

期權業務平台（DTP）：

期權業務平台主要為市場參與者提供股票、ETF標準化期權合約的核心撮合交易、行權業務。

期權業務平台的報單軟體是EzStep、TDGW。

港股通平台（ITP）：

港股通平台主要為市場參與者提供香港聯合交易所規定範圍的港股交易業務。

港股通平台的報單軟體是EzStep。

券商傳統資訊系統多采用單體架構模式開發，把所有的功能都打包在一個獨立單元中，並當作一個整體來開發、測試和部署。

然而，隨著業務的爆炸性增長，套用系統規模不斷增大，單體架構將給業務系統的開發、維護、部署帶來巨大的問題。

為何叫核心交易系統？

證券交易系統由分散走向集中。90 年代，證券經紀業務以營業部為單位，每家營業部都有自己的系統和數據。

粗放的管理模式導致風險事件頻發。2004 年左右，行業風險集中爆發，促使國家開始整治證券行業。

隨後，證券公司開始部署集中式證券交易系統，由技術部門統一管理，這一代系統被稱為 「核心交易系統」 ，沿用至今。

核心交易系統承載哪些職能

核心交易系統是按照滿足券商經紀業務來設計的，因此承載了很多業務職能。大致可以分為如下幾大類：

1、帳戶業務 。可以為客戶進行帳戶開戶、銷戶、管理業務許可權、處理與交易相關的適當性管理、合規報送等。

2、資金業務 。早期透過銀證轉帳實作，後來全面實行了客戶保證金三方存管制度。

3、證券交易業務 。處理投資者送出的各類交易指令，按照交易規則進行資金和證券的處理，並實作與交易所的委托和成交指令的對接。

4、信用交易業務 。2010年證監會推出融資融券業務試點，投資者可以透過向證券公司融資買入股票，也可以融券賣出股票，實作了杠桿交易。系統需要按照信用交易的業務規則處理各類交易指令。

5、基金代銷業務 。投資者可以透過證券帳戶購買開放式基金產品，系統處理投資者的產品申購贖回指令，並實作與相應基金公司的指令互動和資金、份額結算。

6、清算業務 。負責與交易所、登記結算公司進行數據互動和業務核對，完成客戶在交易所內產品的資金、股份清算和結算。

7、查詢業務 。滿足客戶需要的各種交易流水、對賬單、交割單等業務數據。

8、理財產品銷售 。券商為擴大客戶投資品種範圍，自行提供的各類理財產品的銷售。

9、現金余額理財業務 。可將客戶投資帳戶上的現金余額自動申購為貨幣基金，提高客戶的資金收益。

10、其他管理職能 。系統參數設定、客戶帳號安全、外圍系統接入、異常交易監控等。

不難看出，核心交易系統是一個綜合性的業務系統，它的技術架構經歷了怎樣的演進，設計過程需要考慮哪些要素，又遇到到哪些挑戰呢？

核心交易業務有哪些特點？

核心交易系統架構的理解，需先明晰其所承載業務的特點。與其他金融業務相較，證券交易業務具有 時效性 這一顯著行業特點，具體表現為：

1. 交易時段受限 ：交易所開盤時間僅為 4 小時，僅在此時間段內的指令會被處理。

2. 競價交易規則 ：交易透過競價實作，遵循價格優先與時間優先原則。若指令送出過慢，可能錯失最佳成交時機。

「時效性」特點決定了核心交易系統在設計時需滿足以下特性：

1. 極強的穩定性與高可用性 ：尤其在交易時段，需確保高可用性。

2.卓越的效能指標 ：保障客戶交易指令快速抵達交易所。

3. 主要業務集中於開盤時間處理 ，因此系統需具備充足容量，並能隨業務規模擴大靈活擴充套件。

證券業務的第二個行業特點為業務的 外部性 。 證券開戶需透過登記結算公司，交易需透過證券交易所，資金轉賬需借助存管銀行，基金交易需連線基金公司，交易清算則依賴交易所與登記結算公司提供的結算檔。

「外部性」特點決定了核心交易系統在設計時，需充分考慮與外部系統的互動邏輯及業務規則的對應關系。

第三個特點是金融產品的 多樣性 。各類金融產品的交易、結算、交收規則各異，要求業務系統具備出色的靈活性，以適應不同金融產品的業務處理要求。

第四個特點是業務的 合規性 。依據資本市場主體責任劃分，券商需對交易合規性進行前置檢查，嚴禁證券賣空、資金透支等交易風險，因此業務系統需確保業務邏輯的一致性。

證券交易系統技術架構演進之路

第一代的核心交易系統主要供應商包括恒生電子、金證股份、金仕達軟體等，基本都采用了三層架構。如下圖所示：

系統共分為三層：

1. 接入層 ：通常為高效能訊息中介軟體，負責渠道系統的接入和業務訊息傳輸。

2. 業務邏輯層 ：一般包含業務處理中介軟體框架，負責將業務訊息分配至不同業務處理模組進行處理。各業務模組透過與資料庫互動，處理相應業務請求。與外部系統相關的業務，則產生相應業務請求並行送至外部系統，如交易所報盤、銀行轉賬、登記結算公司帳戶開戶等。

3. 資料庫（數據層） ：透過傳統關系型資料庫儲存所有業務數據，部份系統透過儲存過程實作部份業務邏輯。

這一代核心交易系統通常具備以下特點：

1. 利用資料庫事務一致性原理，實作業務邏輯的強一致性。如證券交易要求客戶資金凍結和訂單委托保持一致，系統會將這兩個資料庫操作封裝在一個事務中處理，確保其一致性。

2. 資料庫承擔大量業務處理邏輯，為滿足交易系統對容量和延時的要求，需配置高效能軟硬體裝置。軟體基本采用 Oracle、DB2 等資料庫，硬體則采用 IBM 小型機裝置，並配備 EMC 高端儲存，是典型的 IOE 架構。

3. 業務中介軟體負責業務流程的組織，擁有統一的業務處理框架，透過將不同業務分拆為可動態載入的模組，實作系統功能擴充套件，但其核心邏輯仍為對資料庫的操作。中介軟體一般設計為無狀態模式，可任意增加，單台故障不影響業務連續性和數據一致性。

4. 透過資料庫復制軟體將業務數據復制到備機和災備機，實作業務系統的備份和災備。正常情況下，備份系統僅執行查詢業務，不處理交易指令。如主機發生故障，可啟用備份系統。如主備系統均不可用，可切換至災備機。系統的可用性水平（如 RTO，RPO）主要取決於資料庫復制的速度。

第一代核心交易系統架構簡單，穩定性良好，但也面臨巨大挑戰：

第一代證券交易系統采用資料庫事務強一致性方案，導致資源爭用嚴重，資料庫成為系統容量和效能瓶頸，券商被迫使用高效能硬體裝置提高系統容量，降低交易延時，增加了系統部署和維護成本。

同時，單台資料庫系統容量存在上限，交易處理延時下降也存在理論下限。由於每項證券業務均使用客戶資金資訊，資金資訊成為資源爭用的焦點。資料庫事務易造成數據資源死結，對業務邏輯編寫要求高，加劇業務耦合，使系統研發和維護成本不斷增加。

第一代證券交易系統自 2005 年進入券商，基本滿足當時市場業務需求。但隨著資本市場快速發展，尤其在經歷 2008 年牛市行情，市場成交量逐步放大的背景下，部份券商開始嘗試解決核心交易系統可能面臨的容量和效能問題。

第一個思路是尋找支持事務一致性的分布式資料庫系統，試圖從資料庫層面解決容量問題，DB2 曾釋出類似產品，但最終未獲供應商支持。而 Oracle RAC 架構的推出，解決了主備資料庫的數據同步和高可用問題，因此得到全面實施。

第二個思路是業務邏輯前移，將主要計算邏輯從資料庫遷移至業務中介軟體處理，降低資料庫負載。但由於證券業務並非計算密集型套用，而是數據操作性套用，最終仍需與數據打交道，該方案只能部份降低資料庫負載。

第三個思路是將客戶按一定規則分拆，透過部署多個交易中心，解決單交易中心的效能容量問題。該方案得到供應商支持，紛紛釋出新的核心交易產品，可稱為第二代核心交易系統。如圖：

客戶分拆可提升系統容量，但受資料庫事務強一致性約束，單筆交易延時仍大。為解決此問題，供應商嘗試使用弱事務一致性處理交易邏輯，將交易分解為兩步，降低事務原子級別，異常時透過反向交易回沖賬務，保證業務正確性。

弱一致性可提高系統吞吐量，降低單筆業務延時。恒生電子 UF2.0 綜合采用客戶分拆、弱一致性事務等機制，在券商中廣泛套用。但由於資料庫限制，交易延時仍為 10ms 量級。

弱一致性雖帶來好處，但降低了系統數據一致性，局部故障時可能導致資金和證券數據不一致，需透過日誌和流水恢復狀態。

在供應商的推動下，券商從2009年開始全面部署第二代核心交易系統，隨後證券市場開始出現了新的變化，包括：

1、部份券商將帳戶系統、數據查詢功能、理財產品銷售功能、清算子系統從核心交易系統中剝離，以最佳化經紀業務營運體系、完善客戶服務、提高系統效能和穩定性。

2、不同券商在如何給核心交易系統進行架構最佳化上有不同的思路，因此沒有形成行業統一的產品形態。

3、瘦身後的核心交易系統功能更加純粹，聚焦在高效穩定支持各種場內業務的交易、清算、合規管理等職能。

4、快速交易系統將交易延時縮短到 100 微秒左右，但數據全部保存在記憶體中，損失了一定的高可用性，且吞吐量也受到了一定限制。

5、券商交易系統進入了一種融合的架構模式，即核心交易系統與快速交易系統並存。

雖然以資料庫為中心的交易系統經過了各種架構最佳化，但交易延時只能縮短到 10ms 左右，仍無法滿足專業投資者的需求。

因此，供應商開始推出全記憶體化的快速交易系統，專門服務少量的專業投資者。這種系統只有交易功能，帳戶業務、資金劃撥、清算等均依托核心交易系統。所有業務全部在記憶體中完成處理，且每個客戶的業務均采用序列化處理，以確保數據的一致性。

快速交易系統將交易延時提升了一個量級，達到了 100 微秒左右，有些供應商的系統甚至更快。

然而，由於數據全部保存在記憶體中，系統的高可用性有所損失，並且由於業務序列化處理，吞吐量也受到了一定限制。

因此，單個節點的快速交易無法承載很多客戶，券商會根據需要部署多套快速交易系統，有些甚至會部署不同供應商的快速交易系統。

這樣，券商交易系統就進入了一種融合的架構模式。如下圖所示：

這種融合架構的核心交易系統部署方案，已在大部份券商的生產系統得到實施。

未來會怎樣？

可以明確的是，於資本市場即將到來的未來：

1、投資者結構必定會持續朝著機構化的方向演進，將服務好機構投資者視為關鍵要點。

2、專業投資者對於交易系統的核心需求依舊是高吞吐量以及低延時，且會愈發提升。

3、監管部門針對交易系統的業務連續性監管必定會愈發嚴格，標準亦會越來越高。

4、在大環境以及國際形勢不明朗的情況下，開源節流也成為券商主流，導致了交易系統更加信創化，國產化。

END