本文根據蘇強老師在〖2020 DAMS中國數據智能管理峰會〗現場演講內容整理而成。
講師介紹
蘇強，騰訊雲資料庫資深經理，擁有多年ToB產品策劃、產品運維經驗。曾在多個知名企業任職產品經理，主導或參與多款業內知名的B端產品從0到1過程，部分主導產品已實現同類產品佔有率第一。接手騰訊分布式資料庫以來，主要負責騰訊雲分布式資料庫功能策劃、市場能力建設、服務支撐能力建設和團隊建設等。
大家好，我是來自騰訊雲的蘇強。從騰訊雲分布式資料庫商用那天起，我就在分布式資料庫團隊裡，所以可以很自豪地說，我是最了解騰訊雲分布式資料庫的人之一。今天我將和大家分享近兩年來分布式資料庫在金融行業裡真實應用的細節與核心。
一、金融行業現狀
目前國內大中型銀行主要以國外廠商提供的大型主機和資料庫解決方案來進行系統構建。由於近年來金融業務量的不斷增長，以及銀行數位化轉型成為必然趨勢。目前以國外大型主機和資料庫為核心的架構已無法滿足大規模交易和數據處理的需求。
一方面：性能無法滿足業務不斷激增的處理需求，存在系統過載風險；另一方面：本身價格比較昂貴，維護成本居高不下。
以手機銀行、網上理財、網際網路保險等為代表的金融業務創新快速發展，推動新技術正以前所未有的速度與力度發生深層次變革。
這些技術發展，對金融服務模式帶來重大影響，使得金融行業向數位化、分布式轉型成為必然趨勢，金融業務創新與科技創新正在相互促進，重塑金融行業系統能力。
1、分布式資料庫領域的百家爭鳴
多種架構長期共存：分布式資料庫經過這麼多年的發展，實際上並不是一種新興的技術了，從最早基於中間件的模型開始到現在基於分布式存儲的架構，這些架構一直在並存著往前發展，談不上哪個更優秀，因為都各有各的應用場景。
多種技術棧卡位競爭：分布式技術目前發展的方向是，技術棧有兼容MySQL的，也有兼容Oracle的，也有兼容PG的，各技術棧現在互相卡位，在國內的廠商之間，幾乎每個廠商都跟著一條線。
廠商互相PK：目前投入的廠家，特別是在這兩年國家對這塊的支持力度和資本介入之下，做分布式資料庫的廠家越來越多，形成了互相競爭的關係。
2、金融客戶應該如何選擇分布式資料庫
拋開所謂的金融產品的可靠性、可用性等技術點以外，選擇一個金融分布式資料庫最核心的要點我認為是以下四方面：
質量可靠：產品應該成熟可靠，經過大規模業務持續驗證，擁有較多的客戶案例和ISV集成經歷；
團隊建設：建立能用、會用、用好國產資料庫的人才隊伍；形成一支具備高水平維護能力的隊伍；
持續演進：背靠優質平臺或生態，產品可以持續演進發展；廠商擁有一流的研發團隊和長期投入；
服務能力：在國內主要地市建立健全分銷體系、培訓能力、服務團隊。不僅包括資料庫，更能覆蓋金融全技術棧的服務能力。
3、騰訊雲分布式資料庫解決方案
騰訊雲分布式資料庫最早源自於騰訊的增值業務，從充值Q幣開始到財富通、微信支付、微眾銀行，騰訊的分布式資料庫一直是基於開源的自主研發。最近幾年我們開始逐漸面向產研結合和產用結合，在產研結合方面我們和國內頂級高校建立了聯合實驗室，也在國際上發表了多篇頂級論文；在產用結合方面我們和很多銀行建立了聯合實驗室，共同促進產品發展，目前主要應用的是我們TDSQL和TBase兩條產品線。
二、金融應用實踐
接下來將分享一個關於某金融客戶主機下移過程的真實案例，希望能真正給到大家一些啟發。
拋開細枝末節，只聚焦在資料庫上，我們怎麼樣把資料庫的核心往下切？當時我們總結出了以下七個問題：
如何選擇分布式技術棧；
如何設計信息技術創新節奏；
如何使用分布式資料庫；
新老系統的切換；
分布式的擴展容災方案；
如何對國產資料庫進行運維；
其他典型場景分布式資料庫如何適配。
1、分布式技術棧的選擇：對主流方向都有布局和應用
對於分布式技術棧的選擇，目前有兩個主流方向，一個是兼容MySQL，一個是兼容Oracle。
兼容MySQL的優勢是其分布式技術棧比較成熟，易於團隊建設。基於MySQL的分布式協議最早來自於國外的一些網際網路廠家，後逐漸引入到國內的網際網路廠家，包括國內的微信支付、螞蟻金服等幾個巨頭的支付廠家，其底座都是以兼容MySQL協議為主，再加上這麼多年國內開發者對MySQL的研究，所以在此背景之下，金融機構的相關團隊建設是比較容易成型的。
兼容Oracle的優勢是對整個金融系統的改造、遷移、使用成本相對較低，有可復用的部分並且方案相對簡單。
所以說這兩個技術棧方向都各有優勢，騰訊雲因為金融業務足夠大所以覆蓋了這兩個方向的產品，都有自己的產品線，我們現在都把它叫做分布式資料庫產品線，分別是MySQL技術棧的以及Postgre技術棧的產品。
2、技術創新節奏
1）某大型銀行客戶的主機下移「五年計劃」
了解過技術棧的選擇，接下來就是考慮自身團隊適合哪款產品、選擇這款產品後怎麼設計核心系統等。以下是某大型銀行真實計劃的縮影，他們給整個過程設定了五年計劃原則：
技術團隊：建立一支熟悉分布式資料庫技術棧的技術團隊；
分批改造：根據業務重要性，分批分階段改造業務系統；
業務磨合：技術方案應在不影響宏觀穩定，確保業務與資料庫磨合；
技術復用：該技術應該是可以復用或容易建立的；
全量切換：應該是在完全磨合好以後，再全量切換。
並且分成四種節奏開展落地：
2018~2019年，團隊招聘與培養：確定基於Oracle+MySQL實現雙技術棧團隊建設，並選擇網際網路銀行業務選擇開源MySQL方案打磨團隊；
2020年，（試點）核心系統改造：團隊對MySQL熟悉後，實現核心業務系統基於騰訊雲TDSQL上線並開始運營；
2021年，新老系統並行，剩餘系統改造：老業務系統不下線，數據保證實施同步回老業務系統，如果新業務系統一旦故障確保老系統可用；
2022年，最終核心交易全量切換：在運行一段時間後，確保新系統完全穩定後，再封存老系統。
2）某銀行客戶傳統核心業務系統改造過程
以上是另一個銀行客戶的案例，他們的客戶規模相對於上面的銀行小一些，所以進程較快。他們在2018年4月選擇了某一個技術棧方向，並且開始POC測試，聯合著長亮科技在2018年底到2019年初就在業務系統改造生產完成，並且在2019年上半年通過了相關專家機構的評審，正式上線。在2019年年中投產，逐步投產後運行非常穩定，而且性能較之前有較大的提升，所以2019年底整個核心系統全部下移投產。整個過程經歷了差不多兩年的時間，過程中整個項目團隊的工作是非常緊張的，而且也藉助了大量的成熟經驗和長亮科技能力。
3、數據層下移的拆分策略
1）水平拆分&垂直拆分
在執行了相應的規劃以後，就要考慮資料庫改造中數據層下移的拆分策略。說到水平拆分就不得不提及垂直拆分，垂直拆分一般是在SOA時代，基於業務垂直拆分。
分布式改造最主要的還是對其中一些業務核心戶進行水平拆分，使其能夠適應新時代新的科技金融業務的發展。但也並不是所有的系統都需要分布式改造，有些規模比較小的系統就沒必要。騰訊的產品是集中式和分布式組合在一起的，便於客戶只買一個產品，能滿足幾乎所有資料庫的需求。
2）水平拆分的主要方案
從實踐來講，數據層下移的拆分方案主要分為三種：
第一種是按客戶維度拆分：如上圖所示，主要面向客戶規模比較大、無明顯分布性、交易金額小、筆數多等這種對私類業務，一般的拆分策略是一致性哈希。
第二種是按分公司（法人）維度拆分：如上圖所示，主要面向集團，其業務是基於分公司維度展開的，主要有幾個特點——業務按分公司維度展開；交易/清算等以該維度展開；不同分公司交易規模區分明顯；總部搭建業務系統和數據收口；分公司總數少但交易數量多。所以騰訊提供了一種叫虛擬組的能力，可以在分公司分布的基礎上再進行拆分，幫助用戶去提升。比如一個發展比較快的東南亞分公司，可能原來只需要一個小的分片，兩年後爆發式增長就可以基於這種架構進行快速無縫的擴展。
第三種是按時間維度拆分：如上圖所示，通常是訂單類的系統，而且按時間維度會涉及到大促時期呈峰值增長的問題。這種場景下，騰訊的產品可以提供一種二級分區的能力，可以按照時間分區，這就意味著無論歸到歷史庫也好還是這一時間階段交易規模比較大也好，都可以均衡地負載性能。
4、新老系統的切換：DTS-DBBridge
接下來就會涉及到研發，一旦涉及到研發就要考慮整個業務系統遷移的流程。這個流程從最開始的業務溝通，騰訊就可以開始介入，騰訊的技術人員可以通過我們成熟的遷移工具DBBridge輸出對業務系統遷移的評估報告，同時配合開發人員進行業務系統改造、實施、新老系統的並行上線以及到最後的切換，整個服務體系都可以形成一個閉環。
5、國產資料庫的運維：DBBrain&分布式資料庫管理系統
遷移完成後就涉及到如何管理資料庫，這裡涉及到我們另一個方案DBBrain，它能夠幫助用戶從全局角度分析分布式資料庫運行的情況，其中積累了騰訊海量的運維經驗。
6、分布式多活多SET化擴展容災方案
運維起來以後，隨著運行一年到兩年，某些核心就要開始考慮是否要符合監管的要求，是否要做兩地三中心和容災，甚至隨著金融業務呈爆發式發展，原有的機房已經不能滿足需求，需要換多機房方案。
傳統的兩地三中心容災方案，從金融科技發展角度會呈現出一些小問題，比如容災需要人工幹預，當真的面臨事故時，是否敢做切換的決策？實際上很多金融IT從業者都不敢打包票。另外就是備機房常態下無流量，利用率較低，所以現在發展出多活的容災方案，簡單來說就是把業務系統通過一層網關進行一個按SET的劃分，每一個SET下面都對應一套資料庫，這個資料庫既可以是集中式也可以是分布式。騰訊主流金融方案，都是使用多SET的模型。
SET的主從之間是採用資料庫的強同步，SET與SET之間同類業務採用數據同步模型，因為上層的SET做了業務拆分，所以兩個SET組之間的數據是不衝突的，可以互相進行同步。這類架構目前也在國內的某頭部保險公司，同樣是騰訊雲的客戶，已經試驗了兩地四中心的架構，到目前為止已經穩定運行超過9個月，單個SET能承載的理論容量是10TB，TPS是5000以上，而且性能可以基於SET化的分布式擴展往上加，所以SET化可以擴展的能力是很強的。
7、典型場景
騰訊的產品還有哪些場景真正面向金融行業？下面給大家列舉幾個典型場景。
1）異常場景的恢復&全局一致性數據分析
第一種是異常場景的恢復和全局一致性數據分析，這個場景的功能和模型是差不多的，只是應用場景不一樣。舉個簡單的例子，到年終結算的時候我需要2020年凌晨零點整的全年全部數據的一致性快照，可以有兩種方式，第一種是生成一個新的實例，第二種是生成一個新的快照。這裡會存在一個問題，因為分布式情況下伺服器的系統時鐘不一定一致，所以如圖中上者需要進行分布式的補查，下者需要一個GTS絕對時間戳來保證數據的準確。
2）分布式事務實時強一致
第二種是分布式事務實時強一致的能力，舉個例子，假設我有五張銀行卡，因為我要還房貸所以錢從這些卡之間轉來轉去。這時我媳婦正好在我轉帳時來查帳，就會有兩種結果：第一，我媳婦過十分鐘後來查帳，她查詢到的就是我轉帳後的餘額情況，這種叫最終一致性；第二，我媳婦在我轉帳過程中就來查帳，這時就叫實時一致性。實時一致性就是要保證在交易過程中，即時隨時查帳都能得到最準確的結果，這也是我們資料庫當前能夠支持的一種能力。
3）渠道類業務冷熱數據不均
第三種是渠道類業務冷熱數據不均，針對金融行業因為有大量的渠道業務，會出現嚴重的冷熱不均衡。以微信支付為例，京東是我們最大的渠道之一，它一家的體量頂得上街邊小的收銀渠道幾千家的體量，這就會遇到一個問題，我的大商戶和小商戶怎麼分布才能使得整個資源利用率是最佳的，所以我們提出了冷熱數據均衡的能力。我可以把一堆小商戶放到專門小商戶group裡面，大商戶放在大商戶的group裡面。
4）複雜SQL處理（跑批等）
第四種是複雜SQL處理（跑批等），在金融行業裡有時使用開源的分布式資料庫一遇到跑批就死掉，這是很正常的現象，因為數據量大了以後計算節點無法承載。所以我們提出了基於CPU的策略優化方案，簡單來說類似於並行計算，把計算層的節點、計算層要做的事情往下推，推到數據層來做，原本需要在計算層幾百個G的數據，下推後需要計算層處理的數據可能就只有幾個G。因為通過計算層和計算層之間，數據可以做到打通和交流，這樣就極大的提高了批處理的效率。
5）分布式彈性
第五種是分布式彈性，也是金融行業會遇到的比較典型的場景。上圖是美國今年熔斷，富途證券的峰值達到50億次。所以分布式的擴展性能幫助我們在面對這種比較極端的、無法預料的情況下，整套性能能夠很快速的擴展到所需要的目標。
三、總結
>>>>
Q & A
Q1：我了解現在國內做分布式改造無外乎是三種方式，一種是騰訊這種直接改造傳統的結構化資料庫，騰訊這兩個產品都應該是這種模式吧？還有一種是增加一層分布式中間件，國內也有廠商做；第三種是基於谷歌Spanner論文做的產品。請問您怎麼看這三種方案的優缺點？
A：您說的這種方式就是剛才我提到的現在多種業務架構並存，騰訊的方式準確來說也不是基於中間件簡單改的，它實際上是把三種技術能力進行了融合。針對您所說的三種方式，現在確實各有優缺點。
首先基於谷歌Spanner的方式，它的優點是想像空間比較大，所以很容易實現行列混合存儲能力。缺點是它的計算層層比較重，所以它的最大可擴展性和最大的理論性能是有限制的；另外因為該技術是新發展技術，所以大規模應用於稱金融行業可能還需要一些時間。
然後基於中間件的方式，優點是性能特別好，缺點就是業務系統要配合，而且對於語法的兼容性相對來說比較差，不太適合金融行業。
騰訊是屬於偏兩者中間模型，既吸收了NewSQL的能力，又支持像分布式中間件的可靠性能。它的特點是性能、語法兼容性相對來說比較高、底層存儲當前雖然是結構化存儲，因為我們把計算層往上提了，提了以後下面存儲到底是用MySQL、用PG，還是用NewSQL的KV存儲？對我們來說設計就比較靈活，所以我們內部三種形態都有使用。目前因為是面向金融行業，主要還是商用的最成熟，所以主要還是推我們自己最成熟的TDSQL和TBase那一套方案。未來我們內部也有新的方案也在打磨，我們也會發布新的產品能力出來。
Q2：企業裡使用TDSQL的話，您是建議部署在物理機上還是騰訊私有雲平臺上？
A：因為資料庫本身是一個軟體，理論上來說是可以部署在物理機和虛擬機上的。但因為生產環境目前虛擬機對資料庫所需要的高IO，當前虛擬機對此類高IO優化做得效果不太明顯，所以我們目前的建議是部署在物理機上。如果是一些測試環境或非核心環境也是可以部署在虛擬機上的。
為了幫助大家部署在物理機上，方便管理以及進行資源的有效分配，我們所有資料庫部署在物理機上都會有一套自己的虛擬化模型，也就是說您可以在物理機上抽象出類似雲的多租戶的實例模型出來，可以給多個業務單位或者個人使用。