作者介紹：
于振華，北京銀行軟件開發部資深架構師，長期從事銀行核心系統研發、規劃，參與過多個核心信息系統建設工作，包括一、二代支付系統、第四代銀行核心系統建設、分佈式核心系統建設等企業級項目工作。當前主要研發方向集中在構建先進、高效、面向 OLTP 的銀行交易系統，提升銀行信息系統服務能力。
本文整理自於振華老師在 TiDB DevCon 2019 上的演講實錄，演講主題爲《TiDB 在銀行核心金融領域的研究與實踐》。
今天參加 TiDB DevCon 2019 能夠和這麼多各行各業的朋友一起來交流 TiDB 的實踐情況，這個機會非常難得，因爲平時都是我們技術團隊和 TiDB 團隊單向的交流，橫向的這種客戶之間交流的機會很少，像剛纔幾位老師講的，我覺得都很有意思，也希望通過咱們這次大會，大家能擦出不一樣的火花。
北京銀行和 PingCAP 團隊進行了深度的合作，目前有幾套重要的實時交易類系統已經對接，包括比較重要網聯繫統、銀聯無卡支付、金融互聯服務平臺等。現在怎麼來評價一款產品到底穩不穩，很大程度上要看這款產品在金融，尤其是核心金融的場景有沒有應用，能不能支持金融場景的要求。我們是在 2018 年 3 月份、5 月份、6 月份進行了投產。經過半年多的時間，我們看到 TiDB 也能夠支持金融場景了。從側面來講，分佈式數據庫技術，確實已經到達了一定的成熟度。
一、背景介紹
我相信這幾年，尤其是這三四年，大家應該都有感觸。無論是工作方式，還是生活方式，都發生了很大的變化，各種信息、科技產品鋪面而來，有人說是這種變化叫工業科技革命 4.0。不知道這種提法準確不準確，但這種變化確實對我們銀行的系統產生了比較大的挑戰。
<center>圖 1</center>
在圖 1 中 ，我列出了幾項，比如高併發的要求，要求你具備很快的擴展能力。再比如產品發佈，要求你具備快速的發佈能力，在座的應該有很多做產品、做實施的團隊，大家應該很有感觸，比如可能前一天還無人問津的產品，第二天可能就會賣的很火爆，來的每個項目都是緊急項目，都要求你在最快的時間發佈出去。當然還包括一些老生常談的問題，像傳統架構成本難以控制，還有自主可控亟待攻關，其實在傳統閉源的生態裏面，我們很難達到自主可控的要求。
二、系統分析
<center>圖 2</center>
在這種背景下，我們從全局的角度出發，對銀行以往的技術形態做了系統性的分析，圖 2 中列舉了一些典型的架構形態，有一些在現在的銀行架構裏邊還是存在的，比如單體的應用，再比如傳統的數據庫，現在用的最多的 DB2 和 Oracle，還有傳統的單機或者集羣部署模式，以及瀑布開發模型，當然還有面向傳統架構的運維模式。
今天我們來談分佈式數據庫，它是一個新技術，但不能說把以往技術架構就否定掉。以往的技術形態好不好？坦白講，我認爲很好，不好的話不可能支撐了這麼多年的金融業務發展，但站在今天這樣的時間點來說問題也是存在的。像剛纔講到的，高併發的要求、擴展能力、成本、以及產品交付能力都存在一些不盡如人意的地方。
在這種情況下，我們啓動了北京銀行新一輪的架構轉型的工作，分佈式數據庫也納入到我們的工作範圍裏。我們和 PingCAP 很早就接觸了，在一年多的工作過程中，要談的技術細節、技術方案、工作流程等等這些內容會很多，如果真的來總結一下這項工作是怎麼做的話，我總結出以下三條。大家一看可能會覺得很虛，但是你如果真的來實踐這件事，也許會有同樣的感觸。
第一個就是「務實」。架構轉型不是一個爲了技術而技術，爲了新產品而新產品的工作，而是確實要對你的業務發展、開發、運維的效率有所提升。
第二個，我覺得可能是最重要的，就是要做到「速贏」。無論是你在什麼樣的企業來做技術升級，技術轉型，或多或少的都會遇到一些阻力，尤其是在傳統企業。那做到速贏，迅速的釋放價值，讓你周圍的人、讓你的團隊、讓你的組織，迅速看到它的價值，會讓你未來的工作開展更加平滑。
第三個是「全棧」。因爲是整體的架構轉型工作，我們希望建設一套平臺，它能夠釋放整體的價值，而不是在乎一城一池的得失。今天本來我想介紹北京銀行的應用架構和分佈式數據庫架構，因爲時間關係今天只說一下分佈式數據庫建設的情況。
三、進展情況
<center>圖 3</center>
在介紹具體內容之前，先跟大家同步一下，我們現在的工作進展。2018 年 3 月，我們投產了行業內首個面向核心金融業務的分佈式數據庫，採用的是兩地三中心五副本的架構模式。以分佈式數據庫爲基礎，5 月份我們投產了網聯支付清算平臺，這也是很重要的一個帶資金業務的實時交易系統，6 月份投產了銀聯無卡支付平臺。這張圖（圖 3）可能稍微有點老，現在我們投產的還包括金融互聯服務平臺，IFRS9 減值系統。我們未來要做的事其實和剛纔劉奇講的比較一致，包括 HTAP，包括容器雲的這些方案等等，這也是我們目前最迫切的需求。
3.1 專項評測
現在回想起來，北京銀行開展分佈式數據庫建設的工作，其實是在行業裏面算很早的，也是因爲我們開展這件工作的時間比較早，所以在整個過程中遇到了很多的困難困惑。行裏的技術力量集中在 DB2、Oracle 上可能比較多，對於分佈式數據庫的掌握來講，需要有一個週期。我們做的第一步，爲了保證產品可用，建設了面向金融業務的評測體系。
<center>圖 4</center>
圖 4 左上角是面向這個功能的測試，比如數據庫有沒有高可用性，能不能做線性擴展，有沒有在線升級能力，這些都是我們的測試點。圖 4 左下角這塊，是面向性能的測試，我們並沒有採用市面上已經有的工具，比如 TPCC、Sysbench 等等。因爲我們實際分析下來覺得市面已經有的這些工具和我們的金融場景有一些距離，用它們來測試可能不會有很好的參考意義，所以我們自研了這套面向分佈式數據庫的金融性能評測體系，能夠讓我們明確出分佈式數據庫可以應用在金融場景，並且對於功能和性能，讓大家能有一個可度量的工具。
在這個過程中，要感謝支付清算協會、信通院等上級單位和組織給予我們的幫助，另外，我們也和硬件廠商英特爾進行了比較深的合作，比如今年（2018 年）新的硬件平臺，我們也做了專項的分佈式數據庫測試，爲未來我們硬件的架構選型提供了有效的參考。
3.2 部署模式
<center>圖 5</center>
對於分佈式數據庫的技術層面來講，剛纔幾位講師介紹的比較多了，我就來講一些北京銀行比較不一樣的、走在前面的一些地方。 大家看到圖 5 這套架構是北京銀行的數據存儲層的架構。北京銀行的架構採用兩地三中心五副本的模式部署。
跨城長距離的分佈式數據庫建設具有很大的挑戰。比如北京和西安大概一千多公里，兩地距離比較遠，延時比較高，我們實測的延時大概是十七毫秒左右。這十七毫秒，如果放在一條 SQL 來講，一來一回三十幾毫秒，這樣的延時我們肯定是接受不了。所以在這種情況下，我們用了一個五副本的模式：北京兩個 IDC，各放置兩副本，西安一個 IDC 放置一個副本，採用 2:2:1 的模式。這樣做的好處就是當前端應用請求過來之後，不需要用到北京到西安的這個網絡，北京的四個副本中成功三個，就可以給前端實時返回，而且北京的部分實例允許失效。這樣做 SQL 平均延時，大概在 1.2 毫秒左右，.95 延時大概 5 毫秒左右，這是比較不錯的一個成績（網聯、銀聯的業務其實要比互聯網業務複雜很多）。
這裏給大家分享一個我們實際在生產過程中遇到的一個小故事。在某個週六的中午我接到我們運維值班人員的電話，他說 TiKV 存儲服務器壞了一臺，當日我第一時間問的是：壞了一臺有沒有影響服務。他說沒有影響服務，服務還是正常的。我說那就趕緊找硬件廠商給修一下機器。當時還覺得挺高興的，不經意間在生產系統驗證了一把。到了第二天週日的中午，他又給我打了一個電話，說又壞了一臺服務器。當時有一些擔心，是不是我們這批採購的硬件服務器有什麼問題，想到這點就立馬做排查，當然第一時間問的還是有沒有影響服務，他說沒有影響服務。這樣連着兩天壞了兩臺存儲服務器都沒有影響服務，也證明了多副本方案的有效性。
3.3 兩地三中心
<center>圖 6</center>
圖 6 展示的是整個包括應用、F5 到 TiDB、PD、TiKV 等整個部署的模式。目前我們接着有網聯、銀聯這兩個比較大的系統，這兩個系統業務量相對來講比較大，每天有一兩百萬筆的業務。在西安，我們還部署了一個從集羣，那這個從集羣是做什麼呢？這個從集羣就是爲了對接一些 OLAP 或者說比較大的報表的情況，從而避免它對主集羣的負載產生過大的影響。
四、應用實踐
4.1 出現過的問題
<center>圖 7</center>
有人說“當你有了錘子，好像什麼問題都看上去像釘子”。我們期待從傳統數據庫過渡到分佈式數據庫，什麼問題都可以解決。但事實上，肯定是沒有一個萬能的技術方案。圖 7 右下角，我列了一些從我們項目開展之初到現在，產生一些問題或者說一些小插曲。
比如我們剛纔介紹了行裏的 DB2、Oracle 應用的比較多。DB2、Oracle 以前用的是 READ COMMITTED 的隔離級別，那現在到了 TiDB 的 Repeatable Read 的這種形式可能還需要適應。我們建設初期也出現過這種問題：這邊 Insert 的數據，那邊卻查不到，就因爲 TiDB 是這種快照的隔離級別。
還有執行計劃的索引沒有選中的問題，這個在我們實際的生產過程中也遇到過，明明有索引，卻沒有精確選中那一個索引。造成 SQL 運行的特別慢，內存吃的也比較多。這個問題，我覺得是可以解決好的，臨時解決方案就是手動強制加 Hint，未來我相信 TiDB 在版本升級上也會考慮這一點，讓執行計劃更加準確。
還有熱點數據的問題，熱點數據指望數據庫來解決，現階段來看是不可能了。無論是傳統數據庫，還是分佈式數據庫，要引入另外的應用緩存的組件纔可以解決，在傳統方案裏邊，我們做的技術方案也有很多，像比較傳統的散列方式，把熱點數據散列出去來解決，現在有了緩存，可以引入緩存解決這件事。
我們應用架構採用微服務的形態，對比單體應用形態，微服務對於數據庫的要求會更高。因爲傳統的單體應用，事務的 SQL 數量比較多，劃分成微服務的話，無論是應用邏輯，還是數據庫的處理邏輯，都會比較細粒度，事務提交次數成倍增長，對於 MVCC 的樂觀提交模型有一定的壓力，在我們實測的過程中，越細粒度的可能表現的性能越不好。
以上就是我們實踐過程中出現的一些小插曲。
4.2 與互聯網行業在應用實踐上的區別
<center>圖 8</center>
今天很多來自互聯網企業的朋友也分享了自己的經驗，那在金融行業做分佈式數據庫落地和互聯網行業有什麼不同呢？
首先來講，銀行的發展時期和很多互聯網新興科技公司是不同的，銀行有很成熟的硬件體系、部署模式、軟件的設計模式、開發模式、運維模式，站在這種平臺上來做新型技術落地會更加的困難。爲什麼會得到這個結論？因爲現在也有很多的軟件廠商，很多做產品的人，大家都希望做新建系統的事情。但對於龐大的歷史系統做遷移的話，肯定不會是一刀切的方案，因爲代價太大了。所以需要並行運行，對於這種新舊架構並行，很多時候就沒有了方案，做不了。其實現在我們也在做這項工作，做一個新舊系統優雅的並行方案，包括業務邏輯的並行，還有業務數據的並行，如果大家有興趣的話，也可以和我們私下交流這部分內容，我覺得這是很重要的一個事情。
第二點就是組織架構不同。就拿微服務來說，單體的應用發展這麼多年，每一個應用它的技術負責人是誰，對應的業務負責人是誰，是哪個部門，都很明確。如果做微服務化，進行拆分，很多情況下很難確定權責，如果要企業組織架構來適應系統架構也不太現實。當然歷史資產、業務場景和互聯網企業也是不一樣的，銀行信息化歷史資產更多、業務比互聯網更加複雜。
4.3 新型架構
<center>圖 9</center>
圖 9 是我們系統建設架構圖的一部分，最底下是分佈式 NewSQL 數據庫的基礎平臺，上邊是應用系統，目前是傳統架構和新型微服務架構並存。
五、未來展望
<center>圖 10</center>
最後再介紹一下未來我們的建設方向。
第一，經過階段性的實踐，新的架構仍需要進行多方位的驗證，來確保高可用性、擴展性、成本等方面的優勢。下一個階段我們希望擴大應用範圍，把業務發展快、規模大、對併發要求高的系統，逐步的遷移過去。
第二，我們要建立一套應用規範，或者說面向 TiDB 的金融級開發的規範指引。目前我們正在做這個事兒，包括最佳研發應用實踐以及新老架構並行方案。建設傳統數據庫和 TiDB 之間的異構數據庫傳輸的中間件是我們目前很重要的一項工作，這部分做完之後，相信對我們擴大應用會比較有好處。
第三，我們還要做 HTAP，這點和剛纔劉奇談到的可能會比較契合。之前我看過 TiFlash 的設計理念和設計方式，我覺得是比較新穎的一種方式，比現在有些還需要 T+1 的數據分析方案會好很多，技術架構更加一體化、業務過程更加流暢。另外，我們一直在做性能提升、網絡依賴消減等工作。
最後，我們也希望能夠把北京銀行的經驗和大家多多分享，讓大家不再遇到我們建設過程中遇到的問題和麻煩，更加順暢的進行架構轉型工作。
以上就是我今天分享的內容，謝謝大家。
