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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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