今年春天突如其來的新冠病毒疫情，在一定程度上改變了人們的生活、工作習慣，給各行各業帶來了巨大影響。銀行也難逃“池魚之殃”：傳統商業銀行的盈利能力、資產和信貸規模都受到了一定程度的影響。疫情期間，人們對線上銀行服務的需求激增，原本深受詬病傳統銀行的技術架構，又一次被推上了風口浪尖。有”危“就有“機”，疫情期間，北銀金科雲計算應用部副總經理 & 金融業務及解決方案專家于振華老師做客 TiDB 直播間，分享了 TiDB 在金融場景的應用，以下為直播文字回顧。
本文以銀行業數據庫架構演進為契機，結合商業銀行的核心業務，探討未來商業銀行的技術發展趨勢和機遇。
第一部分：背景介紹
我發現隨著時間的推進，金融科技工作者感覺越來越累，因為技術變化是一直存在的，金融科技發展有一個非常快的加速度，並且我覺得未來應該也會延續這種趨勢。下面這張圖，如果是你能夠站上這條曲線，能夠追上科技的發展，那就能夠利用科技的力量來賦能業務，這就是為什麼我們現在這麼累，為什麼大家感覺科技工作者的節奏越來越快的理解。
具體談到在業務層面，第一是互聯網的業務爆發增長，對系統提出了更高的要求，以往沒有互聯網的時候，業務可能是恆定的量，有了互聯網，有了線上化的模式，需要系統架構有一定的可擴展能力。第二是我們現在做互聯網金融產品，就是要快速上線，快速適應市場的行情，具備快速交付能力。第三就是要做到自主可控，做到金融安全可以把控，我們強調做一套生態，從底層做起，做數據庫，做雲，也是綜合了這幾個因素對我們提出的挑戰，要快速來應變。
談到技術層面，在商業銀行裡面，單體應用還是有的，包括單體數據庫和常規的瀑布式的開發模式，傳統的架構模式很長一段時間支撐了銀行的業務發展，但是在向互聯網化、向線上化、向快速交付能力的方向上，它確實也存在一些問題。所以我們在積極推進整個架構升級，在架構升級的工作中，因為涉及到業務，涉及到技術，涉及系統之間的關聯等等，要詳細講起來的話可能是千頭萬緒。所以根據以往的經驗，從頂層架構設計來講，總結了三個我覺得比較好的原則：
- 第一，務實 ，無論技術怎麼發展，一定是為業務服務的，我們在選取一項技術是一定要對業務有真實的促進作用。
- 第二，速贏，其實在整個架構升級過程中，這一點我覺得最為重要，做到速贏，讓組織很快的能看到它的價值，對於未來業務開展非常有利。
- 第三，全棧，我們需要具備一個全棧性的價值，我們要選取的場景是數據庫，是雲，就是因為我們覺得在全棧上都有價值輸出的話，是比較有意義的。
談到技術架構，不得不說數據庫架構，因為它是重中之重，它承載了上層應用和業務，在數據庫架構選擇上，我們也有三點考量：
- 第一，通過動態增加或者減少機器來實現分佈式數據庫系統的靈活架構，滿足業務使用需求，應用層可以不用關心容量和吞吐量等問題。
- 第二，支持完整的 ACID 事務 ，提供金融級別的可靠性保證。
- 第三，提供跨數據中心的數據安全保證，任意一個數據副本或數據中心宕機，均可快速自動的進行副本內接管，無需人工接入，確保數據服務的持續性，以及準確性。
第二部分：TiDB 應用實踐
我們和 TiDB 的接觸是比較早的，主要覺得 TiDB 是國產數據庫裡面技術比較強的一個，在 2016 年就進行了接觸。之前，我們採用的是一體化的數據庫的方法。那為什麼要做分佈式數據庫，其實當時也是希望能夠從這個數據庫的層面能夠具備一定的線性擴展的能力，能夠打破以往只能在硬件上做縱向升級的情況。北京銀行 也是在國內首發了針對面向分佈式數據庫的評測標準的體系和評測軟件。在這裡我想強調的是：TiDB 首先是一個 100% OLTP 數據庫，我們的選型和測試和最終的上線業務也是基於 OLTP 的場景。
評測體系
上面這張圖，其實是面向數據庫功能的測試，包括高可用性、SQL 兼容、橫向擴展、擴容等等這些能力。像我們這個評測的過程中，比如高可用性，其實也是做了很多努力，包括拔網線、殺進程、殺操作系統這個都做了，就是在驗證分佈式數據庫，在這種場景下能不能做到高可靠性的服務，TiDB 都通過這些苟刻的測試流程。另外像 TPC-C、Sysbench 等等這些工具，都是面向非金融場景，為了考察 TiDB 在金融場景下的服務能力，我們和中國信通院進行了合作，開發了一個工具，主要包括：數據初始化功能，業務性能測試，把我們實際需要的業務場景，遷移到分佈式數據庫上，來驗證 TiDB 的性能。該工具包括兩個部分：
第一部分是數據初始化的功能，比如銀行的基礎的信息表，包括網點，科目，帳戶表，客戶表等等這些。在數據規模上，1000 萬 和 1 億的客戶數據都順利完成該項測試。
第二個部分是業務性能測試。我們選取的場景其實也是銀行最典型的業務場景，包括轉帳，代發工資，帳戶查詢，存款，取款，以及資產盤點等等。雖然我們做這個工具是面向性能測試的，但是我們覺得這個性能測試也離不開準確性。在整個數據庫的性能測試過程中，都會實時檢測 TiDB 的 ACID 特性。這就是我們為了做分佈式數據庫構建的評測體系。
部署架構
在部署架構上我們目前是採用兩地三中心五副本的模式進行建設。在北京，有兩個 IDC，在西安有一個 IDC。為了保障安全，在異地同時建設了 TiDB 的從集群，允許非實時性的查詢交易，能夠放在從集群上，來分擔主集群的壓力。上圖就是我們整個 TiDB 集群部署架構圖，為什麼要採用兩地三中心五副本呢？因為北京到西安的距離非常遠，大概 1000 多公里，延時也是比較高的，應該是有 10 幾毫秒左右。對於這種高併發的線上業務，如果一筆交易 10 幾毫秒，然後 SQL 的數量又比較多，那一個交易整個延時就會非常高，
我們利用了TiDB 的 Multi-Raft 機制，將 Raft Leader 都固定在北京兩個 IDC 。這樣的話，其實他們每一筆業務的請求，對於數據庫的請求，不會強行經過西安的網絡，才給業務方返回請求結果，避免了網絡的延時。滿足業務高性能的服務，也具備了低延時的特性。業務選型
目前也很多的典型的業務系統，包括大家每天都會用到微信支付，網聯清算的功能。如果你有北京銀行的卡，那麼每天你做掃碼支付，包括銀聯無卡支付等等，都會用到 TiDB 的數據庫。目前都和 TiDB 的數據庫進行了對接。從 2018 年的 5 月份到現在，目前生產比較穩定，每天的交易量大概在數百萬筆。
上圖是 TiDB 對接行內的主要場景，只列到了 2019 年 5 月份，從 2016 年的 9 月進行預研 ，我們花了很大的力量，因為之前沒有人做過，我們也是做了第一次嘗試。比較可喜的是什麼？我們確實利用 TiDB 可擴展的架構解決了一些問題。上圖右下角是 2019 年雙十一的截圖，大家可以特別看到，在這個零點的時候，交易激增了 10 幾倍。我們也是利用這種可擴展的架構來克服掉了零點那一刻的交易激增，這個也體現出可擴展的分佈式數據庫的一個魅力。在我們在做 IT 系統規劃的時候，我們按零點之前的這個性能壓力來做規劃，不可取，那如果我們按照零點這一刻來做規劃的話，也不可取。所以可擴展的數據庫的意義，在此刻就體現的比較全面。
另外目前網貸業務系統成功上線投產，已經實現授信客戶數近千萬，發放貸款突破千億規模，日均渠道數據處理超百萬筆，賬務交易日處理量數十萬筆，日批處理量達百萬筆，通過對基礎資源的彈性擴所容滿足業務增長需求，現有資源完全滿足其未來五到十年線上網貸業務發展需求。
產品未來
上圖是關於「如果我是 PingCAP 的產品經理，我會想，產品未來要從哪些方向做突破？」這個問題，我的一些想法。
第一點就是持續保持的 ACID 事務的支持；
第二點，因為銀行的業務是不可以被間斷的，所以我希望可用性上能夠做到更加的穩定。另外要談到成本，比如 N 臺物理機，組成了一個集群，平日能夠提供 1000 TPS 的服務，遇到業務高峰在不擴展集群規模的情況下，是否能夠提供 2000 TPS 的服務，能夠讓我們硬件投入的更少，更加具有性價比；
第三點就是生態，包括我們也希望 TiDB 能夠融入進來，能夠適配金融的 IT 的現狀。之前，應該是在很早之前，我就提過一個建議，我建議加入悲觀鎖的功能，TiDB 官方後來也採納了這個建議，在後續的版本中 加入這個功能。因為整個生態歷史資產，都是以悲觀鎖的模型來做的。TiDB 這個產品，也要適當的做一些改變，來納入整個生態圈；
第四，簡單運維，減少人力，運維無壓力；
第五是 HTAP，現在整個 HTAP 這塊是蠻熱的，業務的需求也特別的大，都希望不單是能做交易性的系統，也可以在做交易系統業務的同時，能夠提供準實時的分析能力；
最後一塊雲上產品，這個是之前我沒想到的，但是這次由於這次疫情的影響，讓大家辦公起來，都不太方便，這塊我也是希望未來 TiDB 能夠在雲上。
第三部分：北銀科技產品方向
我現在到北銀科技了，下面我就介紹一下北銀科技的產品的方向。
這張圖是列的現在比較熱的大家都在做的一些技術，包括分佈式技術平臺，包括人工智能平臺，還有一個在底層的數據架構，底層的基礎設施上，我們是在與 TiDB 合作，也是一個數據庫國產化和平臺化的嘗試，還包括下邊我要講到的北銀科技的一個主力產品。
其實在做整個系統生態建設中，我們覺得不應該制訂一個特別大，特別宏偉的目標，反而應該立足於做整個垂直能力的建設，所以我們採用的是先縱後橫的建設方案。現在這個基礎設施層，比如我們自主建設的 PaaS 容器雲平臺，包括相關的數據庫，中間件的支撐，再到上圖箭頭上所指的具體的業務場景。我們也是先做垂直能力上的建設，然後把這個關打通之後，再在橫向上鋪開我們對外服務的業務能力。
目前我們這個容器雲平臺已經發布了 1.0 版本，也歡迎大家來合作。我們也是第一時間把我們的容器雲產品和 TiDB 產品進行了集成，目前我們在環境上已經是跑的 TiDB 的集群版本。
北銀科技產品的方向首先是容器雲，因為我們覺得它對應用的業務的價值更大，更靠近應用。我們也和行業內的主流的應用廠商，比如 Spring Cloud/Dubbo 這些微服務的架構廠商進行了對接，來驗證我們的這個容器雲的穩定性，服務能力。目前這部分工作，已經接近尾聲，應該很快就會完成。
剛才已經講到了為什麼要做整個雲化的數據中心，從傳統數據中心轉到這個虛擬化的數據中心，而目前我看到的大多數金融機構，應該是停留在第二個階段：就是大家都有針對物理資源的虛擬化的一個管理能力。在做應用部署的時候，都在虛擬主機上來進行部署。現在隨著容器技術的發展，先逐步的來走到第三個階段：雲化的數據中心，實現軟件定義的這種 IT 架構。
第四部分:展望未來
未來的方向，我們是比較務實的，第一個，剛才我介紹了，我們已經發布了容器雲的產品，在容器雲產品現在也已經進行到了尾聲，未來一段時間，我們要更加的面向整個銀行的 IT 生態，來推廣我們的產品，通過和業務方的對接和業務系統的對接，來產出一些更有價值的功能，預計到今年年底，是要完成整個雲生態的初步的一個建設工作。依託與這個容器雲產品，我們也要做很多能力上的建設，很多業務方向的建設，包括微服務標準框架、人工智能、智能客服、知識圖譜、RPA、機器人等等。
