作者：戴濤
導讀
近日，平凱星辰解決方案技術部總經理戴濤在 2024 數據技術嘉年華活動中，做了主題爲“構建面向未來的金融核心系統”的分享，本文爲戴濤演講實錄的全文。
文章分析了中國金融行業的發展趨勢，並且基於這些趨勢對數據庫選擇從架構、運維和開發三個視角進行展開。通過平凱星辰多年的金融行業實施經驗和豐富案例，基於 TiDB 構建金融核心系統是一條可重複、可複製、具備先天技術優勢的路徑。
金融核心系統的發展對分佈式架構提出更高要求
1 從業務視角看當前中國金融行業處於三浪疊加的階段
隨着金融科技的興起，銀行業正面臨着深刻的變革。知名金融科技專家和作家布萊特·金（Brett King）在多部著作中提出，銀行經歷了四個發展階段：1.0 網點銀行，以物理網點爲中心提供基本的存貸款服務；2.0 渠道銀行，拓展線上渠道，例如 ATM、網上銀行、手機銀行等；3.0 平臺銀行，基於移動隨時隨地獲得金融服務；4.0 開放銀行，嵌入生產、生活，無所不在的智能銀行。當前，中國銀行的業務發展呈現出三浪疊加的態勢：從 1.0 到 2.0 做網點轉型，2.0 到 3.0 做渠道轉型，3.0 到 4.0 做開放銀行的轉型。
三浪疊加的業務，對於當前的銀行提出了更高的發展要求。銀行的 IT 部門如何面對這些需求？唯有加速數字化轉型。在技術方面加快技術融合場景，加速體驗創新；技術架構升級推動科技創新，特別是採用分佈式、微服務的架構，並且通過 DevOps 體系搭建數字化 IT 生產線；最後需要加大金融 IT 科技投入和人才組織創新。
2 從技術發展看，金融業對於金融科技提出更高的要求
這些轉型的背後對業務和 IT 都提出了巨大挑戰，以銀行技術舉例，銀行發展的週期和 IT 技術是密不可分的，需要綜合考慮業務需求和 IT 技術的演進。 追溯到 60 年代，半導體技術的突破使得電子數據取代人工記錄，銀行業務邁入信息化時代。 70 年代小型機、大型機出現，實現了銀行業務的系統化批處理，提高了工作效率。 80 年代終端 PC 的普及，推動了銀行業務的遠程化和自動化，客戶服務體驗得到顯著提升。 90 年代局域網的應用，開創了銀行數據中心公司網時代，爲集中化數據管理奠定了基礎。 2000 年至今，銀行業開啓了互聯網新時代，金融服務變得更加便捷、高效。
金融科技經歷了從金融電子化、互聯網化到金融科技融合與創新的演變歷程。在金融科技融合與創新階段，未來的新技術趨勢可以濃縮爲 ABCDIR5 七項：即 A 人工智能技術、B 區塊鏈技術、C 雲計算及平臺、D 大數據相關技術、I 物聯網和平臺、R 機器人技術、5G 通信技術，這些新技術被廣泛應用於越來越多的金融業務場景，對數據和數據庫技術提出了新的挑戰和要求。
3 IT 架構和業務需求雙輪驅動推動銀行核心系統升級
業務需求和 IT 架構是銀行數字化轉型的雙輪驅動。傳統金融核心系統以技術爲中心，面向業務流程，產品開發週期長，數據龐大且業務繁雜，信息交換和共享效率低。而金融數字化升級需求則以用戶爲中心，強調架構的靈活性、敏捷性和海量業務的承接能力。以互聯網支付處理爲例，業務需求的快速變化如何承接？渠道和用戶的體驗如何優化？營銷成本如何降低？IT 基礎設施的升級重構是銀行數字化轉型成功的關鍵。銀行需要構建一個敏捷、彈性、數據驅動、安全可靠的 IT 基礎設施，以滿足業務需求和數字化升級的需求。
4 分佈式架構成爲銀行核心轉型的必然路徑
分佈式架構已經成爲銀行核心轉型的必然路徑。 在早 期 WTO 時代，銀行核心系統採用胖核心架構，將記賬、數據分析、審計、監管等多種功能集成在一個系統中，以滿足銀行全面的業務需求。 隨着金融業務的複雜性和多樣性不斷提升，傳統胖核心架構難以滿足敏捷性和彈性需求。 銀行逐步轉向採用瘦核心架構，將核心業務功能與非核心業務功能分離，以 SOA 架構爲基礎，把非核心業務功能模塊化，通過服務接口進行調用，提升了系統的靈活性和可擴展性。
互聯網技術的興起，對銀行業務產生了深遠的影響。傳統銀行核心系統難以滿足互聯網業務的敏捷性和彈性需求，因此出現了雙核心架構。雙核心架構是指銀行同時運行傳統核心系統和互聯網核心系統，以滿足不同業務場景的需求。傳統核心系統主要負責處理核心交易和數據管理，而互聯網核心系統則主要負責處理互聯網業務，例如網上銀行、在線支付等。
近幾年，隨着微服務架構的興起，銀行核心系統開始向分佈式架構演進。分佈式架構將核心業務系統拆解爲多個微服務，每個微服務獨立開發、部署和運行，通過 API 接口進行通信，具有敏捷開發、彈性擴展、高可用等優點，稱爲分佈式核心或者無核心。在此基礎上結合自主可控的要求，分佈式核心能夠更好地支持業務的創新和可持續發展。
2023 年 11 月，TiDB 助力杭州銀行新一代核心系統成功投產。杭州銀行的資產規模約爲 1.6 萬億，在中國銀行排名在二十名左右。新核心系統是業內首個實際投產的雲原生、分佈式、全棧國產化的銀行核心系統，標誌着杭州銀行核心業務系統實現完全自主可控和架構升級。
自上線以來，新核心運行高效穩定，日均交易量 1500 萬筆，服務調用 5500 萬次。客戶體驗顯著優化，與上一代相比，新核心的聯機交易性能大幅提升，平均響應時間小於 100 毫秒，提升了 1.5 倍；日終批量處理效率翻倍提升，爲原系統的 2.1 倍，整個批處理在一小時之內完成。杭州銀行採用了 TiDB 兩地三中心架構部署，實現了雙活數據中心雙寫並行、災難快速自動恢復且數據零丟失。
杭州銀行堅持應用與基礎設施解耦的架構思想，秉承分佈式、透明化的設計開發理念，這對於同行業來說具有重要的參考價值。在此次核心系統改造中，杭州銀行並未對業務架構進行大幅調整，而是將業務邏輯平移至新的技術平臺之上，既保留了原有的使用習慣，又爲整體架構路線奠定了可持續創新的基礎。
面向未來的金融核心系統對數據庫的要求
總結下來，構建面向未來的金融核心系統對數據庫的要求有三大維度。
- 從架構視角看，核心業務對數據庫的要求除了穩定性以外，一定要考慮到數據庫的通用性和開發透明性。
- 從運維視角看，除了同城雙活以外，需要考慮到更好的線性可擴展，運維便捷以及更好的易用性。
- 從研發視角看，需要關注在開發和業務實踐過程中，對於分佈式事務、熱點等問題的解決方案，以及技術生態是否健全等。
1 架構視角看，優先考慮開發透明性和遷移路徑
從架構視角看，銀行核心系統歷經二十多年發展，積累了大量業務資產和應用系統，涉及多家供應商，數據庫架構的選擇需要以開發透明化爲核心。傳統分庫分表方案對開發團隊提出了較高要求，且造成技術棧和業務邏輯的複雜化。爲了降低開發複雜度，提高開發效率，原生分佈式架構的數據庫產品是更好的選擇，開發團隊可以像使用傳統數據庫一樣設計應用和開發代碼。其次，選擇對運維擴容更加透明的數據庫產品，應用無需擔心數據庫表容量問題，單表大小可無限擴展且無性能拐點。第三，利用 HTAP 能力提供查詢分析的透明性，提供更高性能的 SQL 執行效率。此外，數據庫還應提供熱點數據自動感知且自動打散的能力，從而降低應用設計的複雜度。
系統遷移 5R 模型爲系統遷移規劃提供了三個主要途徑：平遷、改造遷移和新架構重構。調研數據顯示，金融行業採用技術平移方式的比例爲 56%，而採用新系統架構重構方式的比例爲 44%。根據我們服務大量金融客戶的經驗，對於構建金融核心系統而言，平遷並非最佳選擇。平遷雖然看似簡單直接，但往往無法爲業務帶來顯著收益。因此，在進行系統遷移決策時，應結合業務需求的主線進行綜合考量。
對於大量的邊緣化非核心繫統，平遷是一種更爲經濟便捷的方式。它可以有效降低遷移成本，並減少對業務運營的影響。然而，對於核心系統而言，新架構重構纔是收益最大的方式。重構意味着採用全新的架構、軟硬件和設計開發理念，是實現核心系統升級和業務轉型的重要途徑。
在過去幾年，隨着互聯網業務的興起，一些銀行採用分庫分表單元化的架構來構建核心系統。如下圖所示，單元化架構採用總分總結構，將全球業務分成三個業務單元。不管單元怎麼劃分，你會發現總是需要匯聚的，比如說全局管理單元、全局批量單元和全局數據匯聚單元等。單元化架構需要對應用代碼、基礎設施、數據存儲做大量的改造和重新設計，導致架構複雜度大幅提升，維護難度隨之增加。單元化架構本質上並非易於橫向擴展的架構，隨着業務量的增長，系統擴展難度會顯著增加。跨地域數據同步一致性是單元化架構面臨的重大挑戰，需要複雜的解決方案來確保數據的一致性。
單元化架構並非構建金融核心系統的最佳選擇，其高複雜度、低擴展性和數據同步挑戰等問題制約了系統的長期發展。我們優先考慮在數據庫級別採用橫向擴展的技術，相比於單元化架構更具優勢。對於擁有強大技術實力和資源儲備的大型銀行，單元化架構是一個可行的方案，其開發成本和週期可控。對於大多數中小銀行，微服務架構搭配原生分佈式數據庫的組合更具優勢。微服務架構可以提升開發的敏捷性和靈活性，原生分佈式數據庫則能提供彈性擴展、高可用和強一致性等特性，可以幫助中小銀行構建高效、可靠且成本可控的核心繫統。
2 運維視角看，優先考慮擴展性和真同城雙活架構
從運維視角看，TiDB 原生分佈式架構支持基於單節點的在線擴縮容。傳統分庫分表數據庫的擴容非常複雜，往往需要做多個節點的擴容，例如從 8 個節點到 16 個節點，從 16 個節點到 32 個節點。TiDB 支持按需的單節點擴容，無數次客戶側 PoC 的結果表明，隨着節點的增加，TiDB 的性能呈現準線性的增長。在銀行季度結息場景下，可動態增加 TiDB 的計算節點，提升處理效率，縮短結算時間。
TiDB 在業界率先實現了銀行核心系統的分佈式數據庫雙活架構，爲金融機構的業務連續性提供了堅實的保障。分佈式數據庫通常需要三中心部署才能實現雙活，但對於大部分金融機構而言，由於數據中心地理位置限制，難以滿足三中心部署條件。TiDB 創新性地推出了“3-2-1”雙中心架構，在生產主中心部署 3 個 TiKV 節點，在同城副中心部署 2 個 TiKV 節點和 1 個 Learner 節點。該架構以更低的成本實現同城雙活，已在多家銀行成功落地。
除了兩中心雙活方案之外，TiDB 還提供金融級高可用的兩地三中心方案。當主集羣發生故障時，可以快速切換到災備集羣提供對外服務能力。通過引入只讀集羣、測試集羣、近線庫、逃生庫等多種災備擴展方案，全面滿足金融機構的容災備份需求。
3 研發視角看，需要端到端的各種場景解決方案
從研發視角看，分佈式事務處理無疑是一個首要難題。目前，業界主流的分佈式事務模型主要有 XA 鎖，SAGA 模型、 TCC 模型和 MQ 事務消息機制。針對金融行業的業務特點，我們採用了 SAGA 模型幫助用戶做賬務的處理，利用 MQ 事務消息機制來輔助用戶完成異步覈算任務。在銀行進行分佈式系統改造的過程中，爲了滿足對數據實時性的要求，我們不僅需要優化數據庫性能，還需要對應用架構進行相應的調整，以確保數據的低延遲傳輸和處理。
在研發領域，除了分佈式事務處理之外，讀寫熱點問題也是我們關注的重點。無論是傳統數據庫還是分佈式數據庫，寫熱點問題都是一個普遍存在的挑戰。對於寫熱點的處理，我們建議採用 TiDB 數據庫的散列寫入策略。對於讀熱點問題，我們需要從兩個層面進行優化。在數據庫層，通過引入高效的緩存機制，提升熱點數據的訪問速度；在應用層，通過合理的緩存策略，進一步減輕數據庫的訪問壓力。
在中國銀行業，熱點賬戶問題尤爲突出，這要求我們在業務設計上做出一定的調整和妥協。同時，在 SQL 語句的編寫上，儘量採用批量提交的方式，以減少對熱點賬戶的頻繁更新操作。在極端情況下，我們還需要與銀行業界共同努力，不斷完善相關應用的臺賬管理，以應對熱點賬戶帶來的挑戰。
在跑批場景，TiDB 提供核心批處理解決方案。以微衆銀行爲例，批量數據每天通過單元化數據庫 TDSQL 近實時的同步到 TiDB 集羣進行彙總，由批量應用程序在 TiDB 集羣進行批量計算和加工。得益於 TiDB 出色的匯聚能力和可擴展性，以及豐富的工具生態系統，TiDB 上線之後，主要貸款業務的核心批量耗時顯著減少，較原有系統提升了 3.8 倍。在面對大促銷等高流量場景時，TiDB 展現出了卓越的水平擴展能力，能夠輕鬆應對突增的數據處理需求。
TiDB 原生分佈式的架構與傳統集中式數據庫相比具有顯著的差異。銀行核心系統對性能、穩定性、跨地域的高可用性都有着嚴苛的要求。因此，TiDB 建立了混沌工程體系，通過混沌測試來探索系統的性能邊界、驗證高可用性和容災能力、評估擴展性、優化監控和告警機制、檢驗應急預案有效性，評估外圍作業對系統的影響等。平凱星辰攜手杭州銀行，基於風洞實驗室的生產仿真環境進行了大量的測試和驗證工作，通過場景提煉開發 10 餘項產品新特性。
在經歷了二十多年的發展後，銀行業的信息技術已經達到了一個相對成熟的階段。然而，在當前不斷變化的技術環境中，銀行科技部門面臨着新的挑戰，包括採用新技術、構建新架構和實施新工程。銀行科技部門需要走出現有的舒適區，積極擁抱變革，重新構建一個完整的 IT 技術生態系統。這包括從需求分析，到開發、測試、發佈，再到監控和運維的整個生命週期，形成一個面向未來的業務演進和規劃的閉環系統。
4 TiDB 是面向未來的金融核心數據庫
TiDB 是一款自主研發的原生分佈式 HTAP 數據庫，爲金融機構打造了高性能、高可用、彈性擴展的現代化數據基礎設施，其架構設計有以下特點：第一，存算分離，解決了高性能、高併發和在線擴容問題，且不依賴於特定的硬件和雲平臺。第二，TiKV 行存和 TiFlash 列存來應對 OLTP 和 OLAP 場景需求，TiSpark 提供大數據處理能力。第三，數據三副本機制，天然具備集羣級的高可用。TiDB 提供了多種數據遷移工具，支持 MySQL 和 Oracle 數據庫的平滑遷移。通過 TiCDC 同步工具，TiDB 的數據可同步至 MySQL、Kafka、對象存儲等。此外，TiDB 還提供豐富的監控和企業管理工具，構建了一個完善的數據庫技術生態。
攜手 TiDB 構建面向未來的金融核心系統
作爲一款廣受全球用戶青睞的開源分佈式數據庫，TiDB 贏得了國際社會的廣泛認可。在 2022 和 2023 年，TiDB 連續兩年入選 Gartner 雲數據庫“客戶之聲”，獲評“卓越表現者”最高分。在沙利文頭豹研究院發佈的“2023 年中國金融級分佈式數據庫市場報告”中，TiDB 躋身市場領導者梯隊。在 DB-Engines 最新 4 月的關係型數據庫榜單中，TiDB 排名第 40 位，是中國唯一進入 Top 50 排名的數據庫。
在構建一個面向未來的金融核心系統時，選擇合適的數據庫至關重要。以下是從不同角度出發，對理想數據庫產品選擇的總結：
- 架構層面：應優先考慮採用原生分佈式架構的數據庫，以確保系統具備良好的擴展性和彈性。同時，數據庫應提供高透明度的開發環境，讓開發者能夠清晰地理解和掌握其工作原理和行爲模式。
- 運維角度：理想的數據庫應支持線性擴展，以便於系統運維團隊能夠輕鬆地進行擴容和管理。此外，數據庫應提供高效的同城雙活災備方案，確保在面臨災難性事件時，系統的穩定性和數據的安全性。
- 開發角度：在分佈式事務處理和讀寫熱點問題上，數據庫應有成熟的解決方案和最佳實踐。這意味着數據庫不僅要能夠處理高併發的讀寫操作，還要能夠提供有效的策略來分散熱點，避免系統瓶頸。
TiDB 在國有大行 PB 級別的數據服務平臺、城商行核心系統、保險公司保單系統等金融核心場景，成功實現了經典數據庫和 MySQL 數據庫的升級替換。在服務金融行業客戶的過程中，TiDB 已經積累了豐富的最佳實踐和經驗。我相信未來能幫助更多的城商行、券商和保險公司，基於 TiDB 數據庫來構建面向未來的核心繫統。
通過平凱星辰多年的金融實際案例和實施經驗，基於 TiDB 構建金融企業核心系統是一條可重複、可複製、具備先天技術優勢的路徑。