在介紹具體內容之前，先跟大家同步一下，我們現在的工作進展。2018 年 3 月，我們投產了行業內首個面向核心金融業務的分布式數據庫，采用的是兩地三中心五副本的架構模式。以分布式數據庫為基礎，5 月份我們投產了網聯支付清算平臺，這也是很重要的一個帶資金業務的實時交易系統，6 月份投產了銀聯無卡支付平臺。這張圖（圖 3）可能稍微有點老，現在我們投產的還包括金融互聯服務平臺，IFRS9 減值系統。我們未來要做的事其實和剛才劉奇講的比較一致，包括 HTAP，包括容器云的這些方案等等，這也是我們目前最迫切的需求。

現在回想起來，北京銀行開展分布式數據庫建設的工作，其實是在行業里面算很早的，也是因為我們開展這件工作的時間比較早，所以在整個過程中遇到了很多的困難困惑。行里的技術力量集中在 DB2、Oracle 上可能比較多，對于分布式數據庫的掌握來講，需要有一個周期。我們做的第一步，為了保證產品可用，建設了面向金融業務的評測體系。

圖 4 左上角是面向這個功能的測試，比如數據庫有沒有高可用性，能不能做線性擴展，有沒有在線升級能力，這些都是我們的測試點。圖 4 左下角這塊，是面向性能的測試，我們并沒有采用市面上已經有的工具，比如 TPCC、Sysbench 等等。因為我們實際分析下來覺得市面已經有的這些工具和我們的金融場景有一些距離，用它們來測試可能不會有很好的參考意義，所以我們自研了這套面向分布式數據庫的金融性能評測體系，能夠讓我們明確出分布式數據庫可以應用在金融場景，并且對于功能和性能，讓大家能有一個可度量的工具。

在這個過程中，要感謝支付清算協會、信通院等上級單位和組織給予我們的幫助，另外，我們也和硬件廠商英特爾進行了比較深的合作，比如今年（2018 年）新的硬件平臺，我們也做了專項的分布式數據庫測試，為未來我們硬件的架構選型提供了有效的參考。

對于分布式數據庫的技術層面來講，剛才幾位講師介紹的比較多了，我就來講一些北京銀行比較不一樣的、走在前面的一些地方。 大家看到圖 5 這套架構是北京銀行的數據存儲層的架構。北京銀行的架構采用兩地三中心五副本的模式部署。

跨城長距離的分布式數據庫建設具有很大的挑戰。比如北京和西安大概一千多公里，兩地距離比較遠，延時比較高，我們實測的延時大概是十七毫秒左右。這十七毫秒，如果放在一條 SQL 來講，一來一回三十幾毫秒，這樣的延時我們肯定是接受不了。所以在這種情況下，我們用了一個五副本的模式：北京兩個 IDC，各放置兩副本，西安一個 IDC 放置一個副本，采用 2:2:1 的模式。這樣做的好處就是當前端應用請求過來之后，不需要用到北京到西安的這個網絡，北京的四個副本中成功三個，就可以給前端實時返回，而且北京的部分實例允許失效。這樣做 SQL 平均延時，大概在 1.2 毫秒左右，.95 延時大概 5 毫秒左右，這是比較不錯的一個成績（網聯、銀聯的業務其實要比互聯網業務復雜很多）。

這里給大家分享一個我們實際在生產過程中遇到的一個小故事。在某個周六的中午我接到我們運維值班人員的電話，他說 TiKV 存儲服務器壞了一臺，當日我第一時間問的是：壞了一臺有沒有影響服務。他說沒有影響服務，服務還是正常的。我說那就趕緊找硬件廠商給修一下機器。當時還覺得挺高興的，不經意間在生產系統驗證了一把。到了第二天周日的中午，他又給我打了一個電話，說又壞了一臺服務器。當時有一些擔心，是不是我們這批采購的硬件服務器有什么問題，想到這點就立馬做排查，當然第一時間問的還是有沒有影響服務，他說沒有影響服務。這樣連著兩天壞了兩臺存儲服務器都沒有影響服務，也證明了多副本方案的有效性。

圖 6 展示的是整個包括應用、F5 到 TiDB、PD、TiKV 等整個部署的模式。目前我們接著有網聯、銀聯這兩個比較大的系統，這兩個系統業務量相對來講比較大，每天有一兩百萬筆的業務。在西安，我們還部署了一個從集群，那這個從集群是做什么呢？這個從集群就是為了對接一些 OLAP 或者說比較大的報表的情況，從而避免它對主集群的負載產生過大的影響。

有人說“當你有了錘子，好像什么問題都看上去像釘子”。我們期待從傳統數據庫過渡到分布式數據庫，什么問題都可以解決。但事實上，肯定是沒有一個萬能的技術方案。圖 7 右下角，我列了一些從我們項目開展之初到現在，產生一些問題或者說一些小插曲。

比如我們剛才介紹了行里的 DB2、Oracle 應用的比較多。DB2、Oracle 以前用的是 READ COMMITTED 的隔離級別，那現在到了 TiDB 的 Repeatable Read 的這種形式可能還需要適應。我們建設初期也出現過這種問題：這邊 Insert 的數據，那邊卻查不到，就因為 TiDB 是這種快照的隔離級別。

還有執行計劃的索引沒有選中的問題，這個在我們實際的生產過程中也遇到過，明明有索引，卻沒有精確選中那一個索引。造成 SQL 運行的特別慢，內存吃的也比較多。這個問題，我覺得是可以解決好的，臨時解決方案就是手動強制加 Hint，未來我相信 TiDB 在版本升級上也會考慮這一點，讓執行計劃更加準確。

還有熱點數據的問題，熱點數據指望數據庫來解決，現階段來看是不可能了。無論是傳統數據庫，還是分布式數據庫，要引入另外的應用緩存的組件才可以解決，在傳統方案里邊，我們做的技術方案也有很多，像比較傳統的散列方式，把熱點數據散列出去來解決，現在有了緩存，可以引入緩存解決這件事。

我們應用架構采用微服務的形態，對比單體應用形態，微服務對于數據庫的要求會更高。因為傳統的單體應用，事務的 SQL 數量比較多，劃分成微服務的話，無論是應用邏輯，還是數據庫的處理邏輯，都會比較細粒度，事務提交次數成倍增長，對于 MVCC 的樂觀提交模型有一定的壓力，在我們實測的過程中，越細粒度的可能表現的性能越不好。

以上就是我們實踐過程中出現的一些小插曲。

今天很多來自互聯網企業的朋友也分享了自己的經驗，那在金融行業做分布式數據庫落地和互聯網行業有什么不同呢？

首先來講，銀行的發展時期和很多互聯網新興科技公司是不同的，銀行有很成熟的硬件體系、部署模式、軟件的設計模式、開發模式、運維模式，站在這種平臺上來做新型技術落地會更加的困難。為什么會得到這個結論？因為現在也有很多的軟件廠商，很多做產品的人，大家都希望做新建系統的事情。但對于龐大的歷史系統做遷移的話，肯定不會是一刀切的方案，因為代價太大了。所以需要并行運行，對于這種新舊架構并行，很多時候就沒有了方案，做不了。其實現在我們也在做這項工作，做一個新舊系統優雅的并行方案，包括業務邏輯的并行，還有業務數據的并行，如果大家有興趣的話，也可以和我們私下交流這部分內容，我覺得這是很重要的一個事情。

第二點就是組織架構不同。就拿微服務來說，單體的應用發展這么多年，每一個應用它的技術負責人是誰，對應的業務負責人是誰，是哪個部門，都很明確。如果做微服務化，進行拆分，很多情況下很難確定權責，如果要企業組織架構來適應系統架構也不太現實。當然歷史資產、業務場景和互聯網企業也是不一樣的，銀行信息化歷史資產更多、業務比互聯網更加復雜。

圖 9 是我們系統建設架構圖的一部分，最底下是分布式 NewSQL 數據庫的基礎平臺，上邊是應用系統，目前是傳統架構和新型微服務架構并存。

最后再介紹一下未來我們的建設方向。

第一，經過階段性的實踐，新的架構仍需要進行多方位的驗證，來確保高可用性、擴展性、成本等方面的優勢。下一個階段我們希望擴大應用范圍，把業務發展快、規模大、對并發要求高的系統，逐步的遷移過去。

第二，我們要建立一套應用規范，或者說面向 TiDB 的金融級開發的規范指引。目前我們正在做這個事兒，包括最佳研發應用實踐以及新老架構并行方案。建設傳統數據庫和 TiDB 之間的異構數據庫傳輸的中間件是我們目前很重要的一項工作，這部分做完之后，相信對我們擴大應用會比較有好處。

第三，我們還要做?HTAP，這點和剛才劉奇談到的可能會比較契合。之前我看過 TiFlash 的設計理念和設計方式，我覺得是比較新穎的一種方式，比現在有些還需要 T+1 的數據分析方案會好很多，技術架構更加一體化、業務過程更加流暢。另外，我們一直在做性能提升、網絡依賴消減等工作。

最后，我們也希望能夠把北京銀行的經驗和大家多多分享，讓大家不再遇到我們建設過程中遇到的問題和麻煩，更加順暢的進行架構轉型工作。

以上就是我今天分享的內容，謝謝大家。