大咖介紹 蘇強，騰訊云資料庫資深產品經理，擁有多年ToB產品策劃、產品運維經驗，曾在多個知名企業任職產品經理，主導或參與多款業內知名的B端產品從0到1程序，部分主導產品已實作同類產品占有率第一，接手騰訊分布式資料庫以來，主要負責騰訊云分布式資料庫功能策劃、市場能力建設、服務支撐能力建設和團隊建設等，
大家好，我是來自騰訊云的蘇強，從騰訊云分布式資料庫商用那天起，我就在分布式資料庫團隊里，所以可以很自豪地說，我是最了解騰訊云分布式資料庫的人之一，今天我將和大家分享近兩年來分布式資料庫在金融行業里真實應用的細節與核心，
一、金融行業現狀
目前國內大中型銀行主要以國外廠商提供的大型主機和資料庫解決方案來進行系統構建，由于近年來金融業務量的不斷增長，以及銀行數字化轉型成為必然趨勢，目前以國外大型主機和資料庫為核心的架構已無法滿足大規模交易和資料處理的需求，
一方面：性能無法滿足業務不斷激增的處理需求，存在系統過載風險；另一方面：本身價格比較昂貴，維護成本居高不下，
以手機銀行、網上理財、互聯網保險等為代表的金融業務創新快速發展，推動新技術正以前所未有的速度與力度發生深層次變革，
這些技術發展，對金融服務模式帶來重大影響，使得金融行業向數字化、分布式轉型成為必然趨勢，金融業務創新與科技創新正在相互促進，重塑金融行業系統能力，
1、分布式資料庫領域的百家爭鳴
| 多種架構長期共存： 分布式資料庫經過這么多年的發展，實際上并不是一種新興的技術了，從最早基于中間件的模型開始到現在基于分布式存盤的架構，這些架構一直在并存著往前發展，談不上哪個更優秀，因為都各有各的應用場景，
| 多種技術堆疊卡位競爭： 分布式技術目前發展的方向是，技術堆疊有兼容MySQL的，也有兼容Oracle的，也有兼容PG的，各技術堆疊現在互相卡位，在國內的廠商之間，幾乎每個廠商都跟著一條線，
l 廠商互相PK： 目前投入的廠家，特別是在這兩年國家對這塊的支持力度和資本介入之下，做分布式資料庫的廠家越來越多，形成了互相競爭的關系，
2、金融客戶應該如何選擇分布式資料庫
拋開所謂的金融產品的可靠性、可用性等技術點以外，選擇一個金融分布式資料庫最核心的要點我認為是以下四方面：
l 質量可靠： 產品應該成熟可靠，經過大規模業務持續驗證，擁有較多的客戶案例和ISV集成經歷，
l 團隊建設： 建立能用、會用、用好國產資料庫的人才隊伍；形成一支具備高水平維護能力的隊伍，
l 持續演進： 背靠優質平臺或生態，產品可以持續演進發展；廠商擁有一流的研發團隊和長期投入，
l 服務能力： 在國內主要地市建立健全分銷體系、培訓能力、服務團隊，不僅包括資料庫，更能覆寫金融全技術堆疊的服務能力，
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測驗，聯合著XXX（英文）在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是5K以上，而且性能可以基于SET化的分布式擴展往上加，所以SET化可以擴展的能力是很強的，
7、典型場景
騰訊的產品還有哪些場景真正面向金融行業？下面給大家列舉幾個典型場景，
1）例外場景的恢復&全域一致性資料分析
第一種是例外場景的恢復和全域一致性資料分析，這個場景的功能和模型是差不多的，只是應用場景不一樣，舉個簡單的例子，到年終結算的時候我需要2020年凌晨零點整的全年全部資料的一致性快照，可以有兩種方式，第一種是生成一個新的實體，第二種是生成一個新的快照，這里會存在一個問題，因為分布式情況下服務器的系統時鐘不一定一致，所以如圖中上者需要進行分布式的補查，下者需要一個GTS絕對時間戳來保證資料的準確，
2）分布式事務實時強一致
第二種是分布式事務實時強一致的能力，舉個例子，假設我有五張銀行卡，因為我要還房貸所以錢從這些卡之間轉來轉去，這時我媳婦正好在我轉賬時來查賬，就會有兩種結果：第一，我媳婦過十分鐘后來查賬，她查詢到的就是我轉賬后的余額情況，這種叫最終一致性；第二，我媳婦在我轉賬程序中就來查賬，這時就叫實時一致性，實時一致性就是要保證在交易程序中，即時隨時查賬都能得到最準確的結果，這也是我們資料庫當前能夠支持的一種能力，
3）渠道類業務冷熱資料不均
第三種是渠道類業務冷熱資料不均，針對金融行業因為有大量的渠道業務，會出現嚴重的冷熱不均衡，以微信支付為例，京東是我們最大的渠道之一，它一家的體量頂得上街邊小的收銀渠道幾千家的體量，這就會遇到一個問題，我的大商戶和小商戶怎么分布才能使得整個資源利用率是最佳的，所以我們提出了冷熱資料均衡的能力，我可以把一堆小商戶放到專門小商戶group里面，大商戶放在大商戶的group里面，
4）復雜SQL處理（跑批等）
第四種是復雜SQL處理（跑批等），在金融行業里有時使用開源的分布式資料庫一遇到跑批就死掉，這是很正常的現象，因為資料量大了以后計算節點無法承載，所以我們提出了基于CPU的策略優化方案，簡單來說類似于并行計算，把計算層的節點、計算層要做的事情往下推，推到資料層來做，原本需要在計算層幾百個G的資料，下推后需要計算層處理的資料可能就只有幾個G，因為通過計算層和計算層之間，資料可以做到打通和交流，這樣就極大的提高了批處理的效率，
5）分布式彈性
第五種是分布式彈性，也是金融行業會遇到的比較典型的場景，上圖是美國今年熔斷，富途證券的峰值達到50億次，所以分布式的擴展性能幫助我們在面對這種比較極端的、無法預料的情況下，整套性能能夠很快速的擴展到所需要的目標，
三、總結
四、Q & A
Q1：我了解現在國內做分布式改造無外乎是三種方式，一種是騰訊這種直接改造傳統的結構化資料庫，騰訊這兩個產品都應該是這種模式吧？還有一種是增加一層分布式中間件，國內也有廠商做；第三種是基于谷歌Spanner論文做的產品，請問您怎么看這三種方案的優缺點？
蘇強：您說的這種方式就是剛才我提到的現在多種業務架構并存，騰訊的方式準確來說也不是基于中間件簡單改的，它實際上是把三種技術能力進行了融合，針對您所說的三種方式，現在確實各有優缺點，
首先基于谷歌Spanner的方式，它的優點是想象空間比較大，所以很容易實作行列混合存盤能力，缺點是它的計算層層比較重，所以它的最大可擴展性和最大的理論性能是有限制的；另外因為該技術是新發展技術，所以大規模應用于稱金融行業可能還需要一些時間，
然后基于中間件的方式，優點是性能特別好，缺點就是業務系統要配合，而且對于語法的兼容性相對來說比較差，不太適合金融行業，
騰訊是屬于偏兩者中間模型，既吸收了NewSQL的能力，又支持像分布式中間件的可靠性能，它的特點是性能、語法兼容性相對來說比較高、底層存盤當前雖然是結構化存盤，因為我們把計算層往上提了，提了以后下面存盤到底是用MySQL、用PG，還是用NewSQL的KV存盤？對我們來說設計就比較靈活，所以我們內部三種形態都有使用，目前因為是面向金融行業，主要還是商用的最成熟，所以主要還是推我們自己最成熟的TDSQL和TBase那一套方案，未來我們內部也有新的方案也在打磨，我們也會發布新的產品能力出來，
Q2：企業里使用TDSQL的話，您是建議部署在物理機上還是騰訊私有云平臺上？
蘇強：因為資料庫本身是一個軟體，理論上來說是可以部署在物理機和虛擬機上的，但因為生產環境目前虛擬機對資料庫所需要的高IO，下面IO優化做得效果不太明顯，所以我們目前的建議是部署在物理機上，如果是一些測驗環境或非核心環境也是可以部署在虛擬機上的，
為了幫助大家部署在物理機上，方便管理以及進行資源的有效分配，我們所有資料庫部署在物理機上都會有一套自己的虛擬化模型，也就是說您可以在物理機上抽象出類似云的多租戶的實體模型出來，可以給多個業務單位或者個人使用，
本文由博客一文多發平臺 OpenWrite 發布！
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/225589.html
標籤：其他