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

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

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

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

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

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

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

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

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

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

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

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

我們應(yīng)用架構(gòu)采用微服務(wù)的形態(tài)，對比單體應(yīng)用形態(tài)，微服務(wù)對于數(shù)據(jù)庫的要求會更高。因?yàn)閭鹘y(tǒng)的單體應(yīng)用，事務(wù)的 SQL 數(shù)量比較多，劃分成微服務(wù)的話，無論是應(yīng)用邏輯，還是數(shù)據(jù)庫的處理邏輯，都會比較細(xì)粒度，事務(wù)提交次數(shù)成倍增長，對于 MVCC 的樂觀提交模型有一定的壓力，在我們實(shí)測的過程中，越細(xì)粒度的可能表現(xiàn)的性能越不好。

以上就是我們實(shí)踐過程中出現(xiàn)的一些小插曲。

今天很多來自互聯(lián)網(wǎng)企業(yè)的朋友也分享了自己的經(jīng)驗(yàn)，那在金融行業(yè)做分布式數(shù)據(jù)庫落地和互聯(lián)網(wǎng)行業(yè)有什么不同呢？

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

第二點(diǎn)就是組織架構(gòu)不同。就拿微服務(wù)來說，單體的應(yīng)用發(fā)展這么多年，每一個(gè)應(yīng)用它的技術(shù)負(fù)責(zé)人是誰，對應(yīng)的業(yè)務(wù)負(fù)責(zé)人是誰，是哪個(gè)部門，都很明確。如果做微服務(wù)化，進(jìn)行拆分，很多情況下很難確定權(quán)責(zé)，如果要企業(yè)組織架構(gòu)來適應(yīng)系統(tǒng)架構(gòu)也不太現(xiàn)實(shí)。當(dāng)然歷史資產(chǎn)、業(yè)務(wù)場景和互聯(lián)網(wǎng)企業(yè)也是不一樣的，銀行信息化歷史資產(chǎn)更多、業(yè)務(wù)比互聯(lián)網(wǎng)更加復(fù)雜。

圖 9 是我們系統(tǒng)建設(shè)架構(gòu)圖的一部分，最底下是分布式 NewSQL 數(shù)據(jù)庫的基礎(chǔ)平臺，上邊是應(yīng)用系統(tǒng)，目前是傳統(tǒng)架構(gòu)和新型微服務(wù)架構(gòu)并存。

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

第一，經(jīng)過階段性的實(shí)踐，新的架構(gòu)仍需要進(jìn)行多方位的驗(yàn)證，來確保高可用性、擴(kuò)展性、成本等方面的優(yōu)勢。下一個(gè)階段我們希望擴(kuò)大應(yīng)用范圍，把業(yè)務(wù)發(fā)展快、規(guī)模大、對并發(fā)要求高的系統(tǒng)，逐步的遷移過去。

第二，我們要建立一套應(yīng)用規(guī)范，或者說面向 TiDB 的金融級開發(fā)的規(guī)范指引。目前我們正在做這個(gè)事兒，包括最佳研發(fā)應(yīng)用實(shí)踐以及新老架構(gòu)并行方案。建設(shè)傳統(tǒng)數(shù)據(jù)庫和 TiDB 之間的異構(gòu)數(shù)據(jù)庫傳輸?shù)闹虚g件是我們目前很重要的一項(xiàng)工作，這部分做完之后，相信對我們擴(kuò)大應(yīng)用會比較有好處。

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

最后，我們也希望能夠把北京銀行的經(jīng)驗(yàn)和大家多多分享，讓大家不再遇到我們建設(shè)過程中遇到的問題和麻煩，更加順暢的進(jìn)行架構(gòu)轉(zhuǎn)型工作。

以上就是我今天分享的內(nèi)容，謝謝大家。