獨家揭秘銀行核心系統首次遷移到國產數據庫的全過程

• 2019 年 10 月 8 日
• 筆記

來源：infoQ 作者：田曉旭

2019 年 9 月 12 日，騰訊雲官方公布了國產分佈式數據庫 TDSQL 的一個新案例——張家港農商行。據了解，張家港行新一代核心系統採用了騰訊雲 TDSQL 來承載核心業務數據，這是銀行傳統核心數據庫首次實現國產化。

張家港行為什麼要遷移核心系統？又是如何選定了國產數據庫 TDSQL 的解決方案？整個遷移過程是如何做的? 遷移完成之後，效果如何？張家港行案例對其它銀行核心系統改造有哪些借鑒意義？…… 為了搞清楚以上問題，我們獨家專訪了參與張家港行國產數據庫遷移全過程的騰訊雲 TDSQL 首席架構師——張文。

業務特點：一套核心系統支撐多種業務

行業內通常認為銀行的業務分為兩部分，傳統業務和互聯網業務。其中，傳統業務指的是和實際卡相關的業務，而互聯網業務指的是與實際卡無關的業務，例如電子賬戶、無卡支付等業務。通常來說，針對這兩種業務銀行會有兩套不同的核心系統，分別為互聯網核心和傳統核心。互聯網核心大多為近幾年的新系統，沒有太多歷史包袱，所以針對於互聯網核心的數據庫改造相對傳統核心無論風險還是難度都小得多，並且在行業內已有成功案例。但是張家港行比較特殊，沒有區分互聯網核心和傳統核心，而是出於業務複雜度和用戶規模等等的考慮，把互聯網核心放到了傳統核心裏面。

張文用一句話總結了張家港行的業務特點，那就是一套核心系統支撐了全行的傳統業務和互聯網業務。

張家港行的系統非常多，我們可以簡單的劃分為兩大部分，核心系統和外圍系統。如果把核心系統比作心臟，那麼外圍系統就是四肢，所有與錢相關的操作都要經過核心系統。核心系統的業務邏輯是最為關鍵的，因為它與銀行核心資產數據是直接相關的，而外圍更像是一個渠道，最後都要去核心系統中進行核算和清算，比較典型的外圍系統：手機銀行、貸款、網銀、ATM 等等。

遷移過程：集中式、分佈式兩套系統並行

據了解，本次遷移的核心系統的數據量在 TB 級，包括了賬戶、賬目、流水、賬單、日誌等數據。張家港行系統建設方長亮科技表示其核心系統主要分為兩大部分，一個為交易子系統，總共有 70 多個結構，覆蓋銀行卡、資金管理等等；另一個為會計子系統，主要是資金的交易分離、清算總賬。

綜上所述，核心系統不僅本身系統結構複雜，且還與各個系統都有聯繫，因此它的數據庫遷移是最複雜、難度最大的。

張家港行對於數據庫的要求

在遷移之前，張家港行使用的是 Sybase 數據庫，從業務系統到數據庫的整體架構大概還是十多年前的架構，不可避免地會遇到性能瓶頸問題，尤其是在高峰時段，數據庫的吞吐量低，機器負載高，業務響應緩慢，已無法滿足當前的用戶請求量。在張文看來，性能問題是當時張家港行當時的最大痛點。

在選擇數據庫時，張家港行有哪些關注點呢？

• 數據一致性以及分佈式事務可靠性。銀行數據關係著金錢，任何一條錯誤數據造成的損失都無法估量；
• 性能。高峰期能否扛得住業務壓力，各項業務響應時耗能否滿足要求，跑批類業務能否在規定時間內完成；
• 高可用。出現故障多久可以切換，切換過程能否保證數據不丟不錯；
• 穩定性。TDSQL 首先基於 MySQL 生態進行研發，MySQL 作為全世界最流行的數據庫之一，在全世界範圍內有無數使用者，同時其背後有無數社區的開源愛好者作為強大的技術後盾；其二，TDSQL 在騰訊內部經過數十年的持續研發和驗證，支撐內部海量支付交易場景，踩了足夠多的坑，積累了大量的實踐經驗，所以穩定性有保障。
• 業務改造量。從集中式遷移到分佈式，這其中的改造量必須可控，如果工作量太大超過預期時間，那麼就必須考慮其它方案了；

以上是一些比較重要的關注點，除此之外，還有一些其它考慮事項，例如運營成本、員工培訓、上手難易程度等等。

遷移方案：分佈式與集中式並存

2018 年年初，騰訊雲首次接觸到了張家港行，當時張家港行的一個繳存水電費的外圍系統想要嘗試國產分佈式數據庫，經過若干輪 POC 測試最終選擇了 TDSQL。2018 年 8 月左右，張家港行準備對核心系統進行改造，原計劃數據庫採用國外某商用數據庫，但是張家港行科技部考慮到目前已有一個外圍系統使用了國產分佈式數據庫，並且運行期間非常穩定，那麼這次核心改造是否也可以考慮分佈式數據庫？

據張文介紹，「當時張家港行有兩個選擇，一是集中式數據庫，二是分佈式數據庫。大部分銀行在做核心系統升級時都會選擇國外集中式的商業數據庫，雖然技術掌握在別人手中，但它是國內無數銀行普遍使用的數據庫，並且國內銀行核心系統也沒有使用國產分佈式數據庫的先例。」

在改造時，張家港行做了一個大膽的決定：同時開發兩套新核心業務系統，一套基於國外某商用數據庫而另外一套則基於 TDSQL，然後進行「內部賽馬」，一年之後對兩個系統的穩定性、性能進行對比測試，根據測試結果再決定使用哪套。張文表示：「經過整整一年的改造，無論是從性能成本，還是易用性，分佈式數據庫都表現出明顯優勢，進而最終新核心系統採用了 TDSQL 分佈式數據庫，而之前採用集中式數據庫的核心系統則保留為災備系統。」

核心系統遷移遇到的挑戰

相信很多人都很好奇張家港行核心系統的整個遷移過程，在採訪中，張文講到：「整個實施過程分為兩個階段，第一個階段是功能性改造，第二個階段是性能優化。整個改造過程是從簡單到複雜，我們是先從高頻交易入手，集中處理與高頻交易相關的業務以及子系統，然後是跑批類交易，跑批與高頻交易相比，SQL 相對複雜冗餘但是佔總交易類的比重較低。解決了高頻交易其實就已經解決了 99% 的問題，這個過程積累了豐富的調優經驗，這些經驗再應用到其它業務系統中可以更方便迅速地解決問題。」

當然，從集中式數據庫轉變到分佈式數據庫由於數據組織方式的差異，不可避免地帶來一系列問題，例如語法差異、性能差異、兼容性問題等。

• 從集中式架構轉變到分佈式架構，要求所有的庫表都要重新設計，這是所有數據庫做分佈式改造時都無法避免的問題。之所以需要重新設計庫表，是因為分佈式數據庫引入了分片關鍵字的概念，如何根據全局業務，選擇最佳的數據分佈策略，是分佈式改造需要面對的首要問題。即使確定了分片關鍵字，還需要對該分片關鍵字以及索引做持續優化調整以尋求最佳實踐；
• 兼容性差異，包括兩部分：Oracle 生態與 MySQL 生態、集中式架構與分佈式架構的差異，如何解決這個問題呢？針對 Oracle 支持的語法但 MySQL 不支持這個問題，TDSQL 做了大量對 Oracle 語法兼容性的優化。對於一些不太適合分佈式場景下的使用特性如：存儲過程、視圖、觸發器等，業務之所以用到這些特性，是因為將很多業務邏輯也放在了數據庫中，這一定程度上導致了擴展性不足，TDSQL 團隊與行方、核心系統開發商長亮科技進行了仔細的分析與評估，將更合適放到應用層的部分邏輯上移，實現了更為徹底的分佈式架構，極大提升了整體的水平擴展性。
• 複雜 SQL，在集中式數據庫中，由於數據集中存儲在一個節點上，SQL 無需考慮跨多個節點關聯問題。而在分佈式數據庫中，數據是打散在多個節點上的，一條複雜 SQL 可能會涉及到多個數據節點，此時會導致數據庫性能急劇下降。針對複雜 SQL 問題，業務側通過調整分片關鍵字和複雜 SQL 拆分兩個方面做優化，讓 SQL 儘可能限制在一個數據節點內。當然，必定會有一些 SQL 由於其業務邏輯的特殊性（如：銀行跑批類業務），無法避免跨多個數據節點的表關聯。針對這種情況，TDSQL 做了大量針對複雜 SQL 的優化，如：子查詢上提、左連接消除、豐富下推邏輯以及基於統計信息的條件推導邏輯等，儘可能提高處理這種複雜 sql 的性能。

遷移完成之後的運行效果

2019 年 8 月 16 日下午 6 點，張家港行掛牌停業，正式開始進行新核心系統的上線工作。首先進行的是數據庫割接，在割接期間完成了原有數據的倒出、TDSQL 數據的倒入以及中間數據的加工校驗。48 小時之後，也就是 2019 年 8 月 18 日下午 6 點，整個改造工作結束，新核心系統成功跑在了 TDSQL 數據庫上，張家港行正式對外開業。從正式上線至今已有一個多月，在這一個多月的時間裏，數據庫運行穩定各項指標均正常，即使業務高峰期數據庫也維持極低負載。

在性能方面，遷移後的核心系統也有了很大的提升，張文列舉了一些性能方面的具體數據指標：

• 高頻賬戶類交易耗時在 300 毫秒之內
• 查詢類交易耗時在 100 毫秒之內
• 20 秒內可以完成 1 萬筆批量代發代扣業務
• 日終跑批耗時 14 分鐘
• 存款結息耗時 11 分鐘
• 貸款結息耗時 3 分鐘

張文表示：「批量業務進行時，數據庫負載均保持在 10% 以下，這樣的性能完全可以滿足張家港行未來五到十年業務發展需求。TDSQL 還能發揮分佈式數據庫在線橫向擴展的優勢，如果後續業務發展有需要時，只需加入硬件資源，便能夠自動水平擴展化解性能瓶頸。」

在成本方面，張文表示不太方便透露具體的數據，但是他給我們算了一筆賬，「張家港行在硬件層面採用傳統的 X86 服務器，取代了大型機、小型機。以近期上線核心系統的某商業銀行為例，傳統的商業數據庫都得用大型機、小型機，綜合硬件成本大概在 4000 萬 -5000 萬，系統處理能力大約為 8000 TPS。而張家港行這邊的硬件成本不到 1000w，綜合降低成本 75% 以上，吞吐量達到了 6200 TPS，並且支持橫向擴展。」

經驗總結：先跑通再優化

張家港行的案例對於其它銀行有哪些借鑒意義呢？張文表示：「最重要的一個經驗就是先跑通再優化。」具體來說，就是先要跑通兼容性問題，兼容性問題解決後再攻克性能問題，並且從兼容性到性能是一個持續優化的過程，同時也是一個尋找分佈式數據庫最佳實踐的過程。根據 TDSQL 團隊的經驗，按照從高頻交易到批量業務的順序來解決問題是效率最高的，問題的複雜度會逐步降低。

核心系統與外圍系統在重要性、業務邏輯複雜度等方面有很大的差異，因而也決定了其改造難度的不同。從重要性來講，核心系統是所有系統的心臟，所有和錢有關係的操作都要經過核心核算、清算，因而核心系統出現問題會導致全行業務中斷甚至癱瘓；相對來說外圍系統一般都只關聯一個特定業務，其故障一般不會造成全行業務的癱瘓；從業務邏輯來看，由於外圍系統一般只涉及特定的業務對其改造只需考慮對應業務即可，而核心系統是所有系統的中樞，對其改造需要梳理所有和其相關的業務；從兼容性來看，外圍系統相對來說新系統居多，沒有太多的歷史包袱，可以從零開始而不需要考慮太多兼容性問題。而核心系統就沒有這麼簡單，例如張家港行核心從集中式平滑過渡到分佈式數據庫過程中需要考慮無數兼容性適配問題。

針對銀行核心系統的數據庫，通常銀行的做法是沿用、並存或者替代，目前大部分銀行的數據庫戰略是沿用、並存，而地方性股份制銀行可能走得更快一點，在沿用、並存的基礎上嘗試國產化替代。對此，張文表示：「核心系統是銀行業務系統的心臟，而核心系統的數據庫就是心臟中的心臟，針對核心系統的數據庫進行改造的難度無異於做一次心臟更換手術。在國有自主可控的大背景下，再結合性能、成本考慮，銀行試水互聯網公司的分佈式數據庫已經成為一個趨勢。全國性股份制銀行，相比於地方性股份制銀行步子邁得可能稍微慢一些，但是也是為了更穩一些，因為大行相對而言歷史包袱更重，遷移工作量和難度更大。當然，我們也看到越來越多的大型銀行機構也在積极參与，積極探索核心系統數據庫的國產化改造。這是一個循序漸進的過程。」

張家港行核心系統數據庫改造案例公開之後，很多行業工作者認為這是個標誌性事件。對於標誌性，張文是這樣理解的：「首先，這個案例證明了在銀行核心系統中，長期被國外所壟斷商用數據庫是可以被替換為國產分佈式數據庫，並且替換後帶來更強勁的性能指標，更低廉的軟硬件成本以及更符合中國人操作的用戶習慣；其次，對於騰訊雲來說，這也是一個具有代表性的案例，未來可能會將該模式複製到其它銀行客戶中。」