金融行業核心系統如何進行分散式改造?

海量資料爆發，創新業務飛速發展，當前金融行業正處在巨大的IT架構變革與緊迫的數字化轉型時期，銀行、保險等金融機構面臨著諸多問題，業務架構如何調整，是集中式，還是分散式?異構系統如何管理?底層資料庫該如何選型?

日前，ITPUB聯合騰訊雲組織了一場小型交流會，邀請了騰訊雲資料庫高階架構師田清波、微眾銀行資料庫平臺負責人胡盼盼、光大銀行資料中臺團隊負責人王磊及眾多銀行專家一起探討交流，尋找答案。

業務系統分散式改造

田清波介紹，在技術架構層面，目前國內大多數銀行主要以國外廠商提供的大型主機和資料庫解決方案來進行系統構建。而以國外大型主機和資料庫為核心的傳統集中式架構已無法滿足日益增長的大規模交易和資料處理的需求。比如，現在很多銀行會組織網際網路理財，其實是一種秒殺性質的活動，可以透過分散式架構彈性擴充套件去彈性支撐此類促銷活動。相較之下：傳統的集中式架構一方面，效能無法滿足業務爆發式增長的處理需求，存在系統過載風險。另一方面，價格比較昂貴，維護成本居高不下。

騰訊雲資料庫高階架構師 田清波

此外，以手機銀行、網上理財、網際網路保險等為代表的金融業務創新快速發展，推動新技術正以前所未有的速度與力度發生深層次變革。技術發展，對金融服務模式帶來重大影響，金融行業向數字化、分散式架構轉型成為必然。“金融業務創新與科技創新正在相互促進，重塑金融行業系統能力。”田清波指出。

與會專家均指出金融行業業務系統進行分散式改造除了技術上的需求，也有政策的原因。隨著外部環境變化，國內對自主可控的要求越來越高，原來的單體集中式架構過度依賴於專有裝置，去IOE的大勢下，大型機的退出已成定局，金融機構在尋找高可靠、高價效比的可替代方案。

國產資料庫產品逐漸成熟，金融機構有了更多選擇。據中信證券預測，到 2024年中國資料庫市場規模為533億元。據安信證券對資料庫國產化市場進行測算，國產化資料庫替換市場總體規模約為3000億元。

國產資料庫突出重圍

從關係型資料庫到NoSQL，再到NewSQL，國產資料庫產品早非吳下阿蒙。“沿著同樣的路線再造一個Oracle根本不可能，也沒有意義”成為國內資料庫從業者的共識，分散式資料庫被認為是變道超車的機會。

未來是分散式資料庫的時代。無論是傳統的資料庫廠商，還是雲廠商，以及新的資料庫創業者，都轉向了分散式資料庫進行相關佈局，經過多年的發展也取得了一些亮眼的成績。去年，騰訊雲資料庫正式進入Gartner雲資料庫管理系統魔力象限，躋身世界級資料庫行列。

騰訊雲企業級分散式資料庫TDSQL隨著騰訊業務規模不斷擴大而發展起來，逐漸對外商用落地。騰訊雲企業級分散式資料庫TDSQL涵蓋分散式、分析型、雲原生等多引擎融合的完整資料庫產品體系。共有三大產品系列，分別為分散式資料庫TDSQL、分析型資料庫TDSQL-A、雲原生資料庫TDSQL-C。

田清波介紹，TDSQL for MySQL和 TDSQL for PG 兩個核心引擎主打差異化的業務場景。其中TDSQL for MySQL專注於聯機交易場景 OLTP，適用於應用程式與資料庫松耦合的場景。TDSQL for PG專注於聯機交易場景和複雜的查詢場景HTAP，適用於應用程式與資料庫緊耦合的場景。去年TDSQL投產平安銀行信用卡核心系統，平安銀行信用卡核心系統由IBM Z系列大型機架構，轉向國產分散式系統遷移全面完成，實現核心銀行系統在國產自研分散式資料庫上的成功生產執行。目前，騰訊雲企業級分散式資料庫TDSQL已經支援了中國銀行、平安銀行、張家港行和微眾銀行等金融機構，此外，TDSQL也支撐了第七次人口普查工作。

微眾銀行資料庫平臺負責人 胡盼盼

談到具體的落地實踐，微眾銀行資料庫平臺負責人胡盼盼表示，分散式資料庫的應用提高了微眾銀行整體 IT 架構的可靠性與容災能力，目前，微眾銀行的TDSQL資料庫規模有近3000個例項，數百個核心系統。整體架構採用TDSQL 3+2五副本，TDSQL No Shard模式，實現了高可靠與高可用，同城IDC之間RPO=0，RTO秒級。

分散式改造怎麼改?

銀行等金融機構對於核心系統的改造都非常謹慎。光大銀行資料中臺團隊負責人王磊介紹，核心系統改造有兩種選擇，一種是從應用層開始整體性進行分散式架構改造，涉及範圍廣，改動大，改造後業務響應更快速，整體更靈活;另一種不需進行系統性改造，應用分散式資料庫，這樣應用側改造少，推進快，較為平滑。

光大銀行資料中臺團隊負責人 王磊

與會專家指出，如何改造還要根據企業組織的業務發展需要，不能為了分散式而分散式，比如，大型銀行進行分散式改造，多是為了對越來越複雜的業務進行劃分，有的小體量銀行可能會面向未來，為了適應業務的增長需求而進行分散式改造。

如果決定了做分散式改造，保證業務連續性始終要放在第一位，田清波總結從技術層面來看，核心系統資料庫替換時一般會考慮以下五個方面：

一是業務遷移。資料能否平滑遷移，遷移效率以及同步效能。遷移後資料一致性的校驗，需要有成熟的遷移工具和遷移方案;

二是安全合規。滿足金融監管要求，實現金融級資料安全，降低資料洩露風險;

三是可靠性、可用性。在各種故障災難下，保障客戶資料零丟失，保證99.999%的可用性。四是相容性。更換資料庫引起的業務SQL改造，相容性適配的額外開發工程;

五是運營風險，資料庫故障時自助定位解決問題的能力，響應時間，排查效率。

在進行核心系統改造時一般分為四個步驟，

第一步，引入雲資料庫，應用垂直拆分解耦，將業務解耦、資料解耦，底層使用分散式架構，增加容錯率，整體業務的穩定性不會有單點風險;

第二步，單體例項垂直擴充套件。當資料庫處理能力不滿足現狀時，可以彈性例項擴容;

第三步，單例項水平擴充套件，當資料庫垂直擴充套件或者讀寫分離遇到瓶頸時，可以進行分散式擴充套件，應用適當調整。

第四步，進行單元化改造。據悉，微眾銀行的核心繫統之一進行了單元化改造，可以在某單元裡做灰度釋出，某個單元裡發生故障也不會影響整個系統。

如今國產資料庫百花齊放，競爭激烈。銀行在選型時除了關注資料庫廠商的產品與技術，還會關注生態建設情況，如資料庫周邊生態，遷移工具等，行業ISV生態、軟硬體廠商生態等。騰訊雲資料庫自研的資料庫遷移工具 DBbridge 可以解決 Oracle 資料遷移工作，已經有了很多落地實踐。

田清波介紹，目前一些大行和股份制銀行更傾向於進行單元化改造。而一些城商行更多選擇分散式改造。他認為核心系統分散式改造應該遵循“先跑通再最佳化，先高頻再跑批，先簡單再複雜”的原則，其中高頻交易佔了總交易量的90%，要優先集中解決高頻交易問題。

在討論的過程中，有專家指出規模不大的小銀行沒有必要進行分散式改造，集中式可能更為合適，分散式所帶來的網路開銷等成本需要一定的規模化才可以覆蓋。不過也有專家認為，受自主可控以及相關政策影響，銀行會選擇使用分散式國產化資料庫，規模不大可以進行單節點部署，未來隨著業務的增長也可以隨時靈活擴充套件。值得一提的是為滿足不同企業組織的不同需求，TDSQL for MySQL和 TDSQL for PG均支援分散式和集中式部署。

道阻且長,行則將至，在銀行核心業務系統改造方面大家都在積極探索，無論是被動還是自主選擇，金融業核心系統的變革以及國產化浪潮正滾滾而來。