<mark id="oztn4"></mark>
0
近年來，金融行業數據泄漏事故頻發，遠高于其他行業。
通過永安在線數據資產泄露風險監測平臺統計，金融行業是數據資產泄露的主要來源，占到了42%，而數據資產泄露高發的互聯網行業也只排名第二，占27%。出現這種情況是因為金融行業涉及到的人群大多是高凈值人群，數據轉化率高，變現能力強。
騰訊云數據庫TDSQL首席架構師張文認為：“雖然企業數據安全不只依靠數據庫，但數據庫一定要做這種最后一根救命稻草的保障?！?/p>
張文還介紹到，“數據的誤刪、誤操作，對于一些銀行客戶而言，可能一年或者幾個月都不會發生一次，但是，我們面對著云上的客戶，每天都有客戶誤刪、誤操作，在這方面TDSQL積累、總結了大量的經驗、教訓。對此，我們也有很多的解決方案包括SQL防火墻、透明加密、自動備份等——如何更快速的幫助用戶找回數據、恢復其可用性，經過這么多年的打磨，我認為我們是非常專業的?！?/p>
恰逢新年，雷鋒網《AI金融評論》邀請到張文參加「銀行業AI生態云峰會」，他分享了騰訊云是如何在「銀行數據庫」這一領域深耕發展；如何在國外商用數據庫的“壓力”下，突破求生，拿下多個銀行核心系統大單。
目前「銀行業AI生態云峰會」已成功舉辦4場，微眾銀行區塊鏈安全科學家嚴強、達觀數據聯合創始人紀傳俊、騰訊云數據庫TDSQL首席架構師張文、阿里云金融科技AI產品負責人王巍給觀眾帶來了十分精彩的演講，后續還將有360數科首席科學家張家興、融慧金科董事長兼CEO王勁、華為云FusionInsight首席架構師徐禮峰、摸象科技董事長高鵬等眾多大咖前來分享最新、最有貨的科技觀點。
以下為張文的演講內容，雷鋒網AI金融評論作了不改變原意的編輯：
大家晚上好，很高興能在雷鋒網這個平臺帶來關于分布式數據庫的分享，今天主要的議題是《騰訊云分布式數據庫在銀行核心系統的改造實踐》。
眾所周知，2020年12月24日，騰訊云數據庫官宣TDSQL品牌整合升級計劃，集中發力數據庫技術創新突破。騰訊云原有的TDSQL、TBase、CynosDB三大產品線統一升級為“騰訊云企業級分布式數據庫TDSQL”。全新升級后的騰訊云TDSQL將涵蓋金融級分布式、分析型、云原生等多引擎融合的完整數據庫產品體系。本次分享將主要以金融級分布式版TDSQL的實踐進行介紹，下述以“TDSQL”為簡稱。
銀行的“核心系統”，對于數據庫廠商而言是一個比較大的挑戰。
銀行，我們都知道有核心系統和外圍系統，核心系統是銀行心臟中的心臟。
銀行的核心系統改造，對于數據庫廠商而言是一個很大的考驗。數據庫廠商需要面對包括數據的一致性、高可用，以及SQL的兼容性等等一系列復雜問題。
過去我們的核心系統，包括銀行核心，還有一些政務核心系統，對外國廠商的依賴度超過了90%，包括軟、硬件，硬件主要是依賴于國外的大型機，小型機。
軟件方面，像操作系統和數據庫軟件，整個一套技術架構都采用的是國外的產品。直到現在，在技術自主創新大趨勢浪潮下，從硬件到軟件，我們逐步在進行國產化的探索。
硬件上，我們開始嘗試用基于X86或者是ARM的國產化硬件，以構成底層的硬件平臺；軟件上，從操作系統到數據庫，包括一些中間件，在國產化方面近幾年涌現出了很多基礎類軟件。
所以，現在整體的技術導向是：從軟件到硬件整個基礎平臺開始向國產化的態勢發展，而不僅僅局限于數據庫。
對于分布式數據庫而言，如何迎合這樣的契機和挑戰？
為什么早期國外的商用數據庫和商用的基礎軟件，在國內的銀行、政務系統占據了大量份額？大部分企業選擇這些基礎軟件，主要訴求是其穩定性。以穩定性為口碑，經過多年打磨，因而國外廠商的這些軟件占據了壟斷性的地位。
這種壟斷性地位在短時間內是不容易被打破的，因為它有個長時間的市場效應，對于使用國外軟件的這些廠商而言，一旦涉及到替換或者升級，就容易產生一些兼容性問題，還有一些遷移成本和改造難度等問題。
對于國產的分布式數據庫，如果想要切入政務及銀行系統，首先需要打破長期被國外商用數據庫建立起來的一系列壁壘，這些壁壘對于國產物數據庫是一系列的挑戰點。
強一致性高可用
作為金融級數據庫，可用性和數據強一致性是至關重要的，因為在金融場景下，一條數據的價值是無法估量的，沒法評估它到底是錯了一分錢還是一個億，或者更多，所以金融級高可用是國產分布式數據庫首要面對的一個挑戰。
性能成本
在國產化方面主要基于廉價存儲，因為在分布式的架構下，可以實現線性水平擴展。但是數量對于分布式數據庫而言，并不是一昧的堆機器、堆存儲、堆計算，那樣實際上是很浪費資源的。分布式數據庫組成一個較大的集群，假如有上千臺機器，那么如果在性能方面提高20%，就能節省上百臺的機器，甚至能節省出來一個機房。
所以，性能成本也是分布數據庫一直在探索的以較低的成本獲取較高的性能，這也是我們追求的一個性價比。
水平伸縮
對于分布式數據庫，水平伸縮能力是必須要具備的，因為分布式數據庫在互聯網場景算是需要比較常態化的水平伸縮。
例如應對如雙11購物節、春晚紅包的突增流量，需要有一個迅速的彈性擴展能力以承載這些流量。而業務有峰值就有谷值，活動結束后，需要再將這些資源進行回收。這種水平伸縮能力，是分布式數據庫應當具備的基本點，任何分布式數據庫都需要具備這種可伸縮、可拓展的能力。
產品化程度
產品化程度是用戶能否快速上手的關鍵。
比如從一個傳統的集中式數據庫轉換到分布式數據庫，尤其是對于一些政企類、金融客戶而言，他們能否從傳統觀念或者傳統數據庫的環境下，過渡到分布式數據庫的環境和條件，這類客戶其網絡往往跟外網是隔離的，也就是在用戶出了問題之后，我們沒法第一時間登錄他的環境，幫助其進行調試，就需要他自助的完成。
如果沒有比較成熟且產品化的一套解決方案，用戶出了問題只能7x24小時找到廠商解決，非常低效。所以，產品化程度也是至關重要的。
早期那些國外的商務數據庫也是歷經多年打磨，才慢慢的讓這些傳統廠商的數據庫團隊、科技團隊接受的。
關鍵案例
前面幾點做得再好、再花哨，如果是沒有關鍵案例的驗證，一切都是竹籃打水一場空，“實踐是檢驗真理的唯一標準”，做得再好都需要有案例加以證明其可行性，對于分布式數據庫的挑戰，最重要的一點也是最為關鍵的一點，就是實實在在的案例。
如果沒有人用，大家都處于觀望狀態。關鍵案例是分布式數據庫面臨的最大挑戰，目前來看，國內的傳統廠商、銀行、政企，還是外企的份額居多，國內的分布式數據庫也是在近幾年才殺出一條血路。
所以，關鍵案例方面，除了需要TDSQL，也需要所有的友商共同探索，將關鍵案例不斷的迭代、鋪開，有了更多案例的證明，國產分布式數據庫的影響力也好，口碑也罷，包括大家的接受程度，才能慢慢地得到提高。
這里的非技術層次的挑戰更偏向于產品側，主要分為以下4個挑戰：
質量可靠
對于一款分布式數據庫，需要經過大量業務的驗證，產品在成熟或者說正式用于外部之前，一定需要經過內部的打磨和錘煉，像TDSQL數據庫，我們往往都是在內部打磨得非常成熟后才將其推向外部。
因為我們的內部場景非常多，騰訊也有很多業務線，例如在類金融場景、社交場景、醫療健康、互動娛樂，以及各種各樣的公有云的場景加以打磨。
我們秉承著對自己產品認真、負責的態度，先經過內部的打磨才推送到外部客戶。因為將產品推送到外部客戶時，實際上已經是一個黑盒的環境，要求我們一定要在內部盡可能的提前發現一些比較關鍵和顯而易見的問題，比如用戶的體驗性和一些使用方面的問題。
持續投入
數據庫的更新迭代非?？欤瑥腡B級PB級再到更高數量級的提升。
因為迭代更新比較快，所以要求廠商要有一個穩定的數據庫團隊持續地跟進演進。
對于TDSQL而言，作為騰訊內部唯一的自研數據庫品牌，我們團隊也要緊跟技術的演進和變化，除了服務外部客戶還要服務內部，因為無論是內部還是外部都是我們的關鍵的客戶，都是我們非常重視的使用場景。
像騰訊這種體量的互聯網公司，需要一支比較穩定，并且可以不斷緊跟著技術的演進和發展不斷迭代的數據庫團隊。
團隊建設
需要我們的數據庫有自己的生態，包括用戶從集中式轉換到分布式的配套工具，周邊文檔資料，人員的招聘，還有一些過渡保障措施。
TDSQL是兼容MySQL、PostgreSQL生態的，而這些生態是一個非常龐大的數據庫圈子，其文檔和資料，以及全世界的活躍社區都給我們提供了很多的學習參考的途經，我們一些技術水平比較高的銀行合作伙伴往往在出了問題之后，對于一些比較基本的問題，都是自己通過查閱相關資料加以解決。
對于我們的客戶而言，選用了一款分布式數據庫，它也要考慮自己團隊對新型分布式數據庫的維護能力。
服務能力
服務能力要求分布式數據庫的具有完善的服務機制與生態體系。比如用戶出了問題之后，能夠第一時間真的需要到現場，能夠第一時間去就近服務，包括一個完善的區域的合作伙伴的服務機制。
在服務能力方面，TDSQL也在全國培養了很多的技術支持團隊幫助，引導客戶解決問題。比如一些重大的節日保障，或者是涉及到一些重大變更，需要我們的合作伙伴立刻到達現場，做業務的割接、切換或者是大規模的災備演練。比如對一個機房進行斷電的容災演練，我們也有專門的團隊去支持，DBA團隊也有服務合作伙伴，共同為客戶保駕護航。
目前，我們在華東、華南、華北都有專門的服務團隊。
作為一款成熟的分布式數據庫產品，除了要在技術側加以打磨，還需要有足夠的案例輸出，同時在服務體系、整合能力還有持續演進能力方面，都要有與之相匹配的能力。否則，它就沒有辦法成為一個成熟完善的商業化產品。
為什么在騰訊的土壤下能誕生出像TDSQL這樣的數據庫？
首先，騰訊是一個依托百億級賬戶數量的互聯網公司，其數據規模、場景相對而言比較有挑戰性。
例如，幾年前微信春節紅包的峰值超過了每秒20萬筆，對于任何數據庫而言都是一個比較大的考驗，如果不按照分布式進行拆分，那么，沒有任何一個大機或者小機能承載這樣的業務壓力。
眾所周知，互聯網業務營銷活動比較多，在活動前、活動后，其請求還有峰值都是指數級的數量，對數據庫的容量、伸縮能力是一個很大的考驗。
TDSQL，依托騰訊云這個載體，服務于政務、金融、電商、社交，還有智慧城市等等各種場景的打磨。另外，TDSQL在公有云上服務于各行各業和各種場景的用戶，這些都是對TDSQL各種場景的打磨。
最后就是持續的投入。
伴隨著TDSQL迭代的這10年，騰訊加以持續的投入，不斷的打磨產品。因為數據庫對于這種體量的互聯網公司而言至關重要。騰訊有著百億的賬戶，豐富的內部產品線和業務線，任何一個這種互聯網業務產品都會對數據庫有著強依賴。在數據庫方面，TDSQL不僅是作為外部的一個產品，在內部也是承擔了一個比較重要的作用。
在這里，詳細的介紹一下到底什么是TDSQL，其應對的主要場景有哪些？
按照官方最新解讀，TDSQL是騰訊推出的一款多引擎融合分布式數據庫品牌。
所以TDSQL覆蓋三類數據庫場景，分別是：分布式數據庫，云原生數據庫以及分析型數據庫。所以，TDSQL分為三個產品序列，分別是金融級分布式TDSQL、云原生共享存儲的TDSQL-C以及分析型數據庫的 TDSQL-A。
這樣的多引擎超融合體系針對數據庫場景的幾個關鍵領域，都提供了特定場景的解決方案，比如云原生數據庫，在存儲層基于共享存儲做分布式的就是TDSQL-C。
在面對金融場景或者政務系統的聯機交易和離線跑批場景，分別是分布式TDSQL和分析型TDSQL-A的兩個產品。實際上，TDSQL是騰訊整個一套分布式數據庫的解決方案，無論是在線聯機型的，還是離線分析型的，或者是基于共享存儲的分布式型場景，它都可以輕松應對。
金融級分布式版TDSQL的核心特性包括以下幾點：
首先，數據強一致，因為在金融場景下，數據不丟不錯是至關重要的。
第二，金融級高可用，在金融場景至少要保證99.999%的可用性，因為金融除了其本身的行業因素外，更重要的是它還受到監管的約束。無論是對內還是對外服務，TDSQL是按照99.9999%的可用性要求的。高性能低成本，作為分布式數據庫，盡可能要讓所有的X86、ARM的廉價存儲方式榨干機器的資源，帶給整個分布式數據庫高吞吐量的增益效果。
再者，企業級安全，雖然需要實現企業級安全的不只是數據庫，但數據庫一定要做這種最后一根救命稻草的保障。比如數據的誤刪、誤操作，對于一些銀行客戶而言，可能一年或者幾個月都不會發生一次，但是，我們面對著云上的客戶，每天都有客戶誤刪、誤操作，在這方面TDSQL積累、總結了大量的經驗、教訓。對此，我們也有很多的解決方案包括SQL防火墻、透明加密、自動備份等——如何更快速的幫助用戶找回數據、恢復其可用性，經過這么多年的打磨，我認為我們是非常專業的。
線性水平擴展能力：分布式數據庫一定要具備伸縮、可擴展能力。
最后，便捷的運維——這套分布式數據庫交付到客戶手里，用戶要能夠自行掌控、操作。而不是出了問題后，只能7×24小時的給廠商打電話，這也不是我們的初衷和訴求。
最底層的是資源池。
TDSQL既可以基于物理機部署，也可以基于虛擬機，我們可以將這個資源池簡單理解成一個iaas 服務層的概念，在資源池上方提供了兩種形態的存儲節點，一種是Noshard數據庫，另外一種是分布式數據庫，分別代表了單機版和分布式兩種形態。
作為分布式TDSQL，為什么還要有一種形態是單機版的？
對于一個廠商、一個銀行或者一個金融客戶而言，并非所有業務都會用到分布式數據庫，或者不一定所有的都是業務大表，它可能是多個業務之間有交叉，真正涉及到分布式的可能是一部分表，還有一部分可能是非分布式的。
在這種產品形態下，同時兼容分布式和非分布式，因為分布式下有一些使用限制，比如語法的限制、分布式事務的性能損耗，以及跨數據節點的join.
在分布式下，因為兩個數據節點是一定分布在兩個不同的物理節點上的，如果在這兩個物理節點之間的數據做join，很容易造成拉表，相當于是把兩個物理節點上的數據要統一匯總到一個節點上進行join，這樣的效率不是很高。
而單機版的則沒有這個問題，因為數據的拖拽都是在單臺物理節點的內存中，所以，Noshard的形態可以自由做表與表之間的join，但是在分布式上會有性能方面的消耗，這也說明了分布式和非分布式兩者各有優缺點。
所以，我們在存儲節點保留了兩種形態，用戶可以根據需要自行選擇，比如業務實例要求必須得做到分布式，需要將數據分散，包括將來考慮到業務的拆分，我們就要用分布式的；如果沒有強烈的訴求，我們提供單機版的就能滿足需求。此外，從單機模式轉換成分布式模式，TDSQL自帶的同步遷移工具也是支持的。
再往上是計算節點。
首先，OLTP型引擎主要包括了讀寫分離、SQL改寫、分布式事務以及關聯查詢。
除此之外，對于計算節點，需要處理一些比較復雜的SQL，需要對其進行拆分，包括將執行計劃下推等等，就屬于OLAP型的計算邏輯。
所以，計算節點在分布式下的工作相對還是比較復雜的，在內部，計算節點又被稱為SQL引擎，作為所有SQL的入口，它會對SQL進行分發，對一些復雜SQL拆解成對應的SQL，再發到對應的存儲節點，當存儲節點取完數據之后再回吐到計算節點，計算節點對其進行分類匯總，最后回吐到客戶端。
如果把計算節點、存儲節點、資源池比作一個黑盒，那么赤兔運營管理平臺就是一個用戶接口，所有的DBA操作都是通過赤兔管理平臺來操縱存儲節點、計算節點、資源池。
以往，DBA要做數據庫的變更，比如主備切換或者重啟，需要登錄到后臺，比如計算節點，存儲節點執行SQL命令，現在只要通過赤兔管理平臺頁面按鈕可以完成90%以上的操作，極大地減少了DBA的誤操作風險。
雖然有用戶界面，但是如果DBA確實是要登錄到后臺了解更詳細的信息也沒有問題，一樣允許登錄到對應節點的后臺進行查看。
赤兔運營管理平臺主要是為DBA提供用戶接口，它還對計算節點、存儲節點，包括機器IO、CPU網絡等各種信息的上百項指標進行統計匯總，并且當監控告警系統的指標出現異常時，可以在第一時間發出告警。
那么，“扁鵲”智能DBA平臺有什么作用？
打個比方，某天晚上發生了機房斷電，數據庫也發生了切換，第二天早上DBA收到一個告警，線上前一天晚上發生了切換（當然這個業務是正常切換過來了，然后對業務的影響也是可控的），DBA需要知道為什么會發生切換，只需要在智能DBA平臺上點一下“故障分析”，智能DBA自動到機器上分析操作系統和數據庫日志，原來是操作系統發生了重啟，這樣 DBA就不需要再手動登錄到機器上查看信息。
再比如上線了一個新業務，上線了新業務之后瞬間卡死不可用。這時就找到DBA投訴，“之前數據庫用得好好的，怎么一上新業務就不行了？”
實際上，可能是新上線的業務產生了一條慢SQL，慢SQL并發量又比較大，然后把數據庫連接耗盡。按照傳統的做法，這時DBA也是先分析日志，找到這條慢SQL，然后再一點點的進行分析。
而通過智能DBA平臺，可以進行一鍵診斷，智能DBA平臺可自動篩選出那條慢SQL，并且告訴DBA需要對這條慢SQL如何進行優化。
有了智能DBA平臺，就可以將我們從一些日常的、重復性的繁雜工作中解放出來，這套平臺也是我們對外口碑最好的一套平臺，尤其對于傳統客戶而言是非常受用的，能極大地提高DBA的工作效率，同時降低處理問題時在時間上的損失。
調度系統，負責整個集群的資源調度和管理，包括計算節點，如何組成一套數據庫實例，跟下方資源池里的資源如何進行重組、搭配，都是調度系統需要做的事情。
備份系統，沒有備份的數據庫屬于一個裸奔狀態，在這方面，TDSQL提供了豐富的備份策略，如全量的、增量的、物理的、邏輯的、日志的等各種各樣的策略。可以完成定點恢復、庫表結構恢復、指定表的恢復等等。
服務模塊，服務模塊屬于比較高級功能，主要應對一些特殊性場景，如：審計、數據訂閱、數據治理，以及SQL防火墻，數據遷移等等。
比如用戶需要從原生的MySQL遷移到TDSQL，或者從其它異構數據庫把TDSQL遷移到其中，都涉及到數據遷移，我們有專門的數據遷移模塊，包括TDSQL的兩種形態之間，包括從分布式到單機版，從單機版到分布式，都依賴于這樣的數據遷移。
數據遷移也彰顯了TDSQL不綁架用戶的一個初衷，這也是TDSQL開放生態的一個特點，基于MySQL生態的數據庫在遷移過來之后一定不用擔心將你綁架——也就是它不讓你遷出去，因為日志、數據結構都是開源的，有很多種工具提供了在線、離線的遷移方式。
如果用戶覺得TDSQL不好用，可以通過我們的遷移工具再將數據遷走，數據進出自由，并非綁死在TDSQL。
運營管理
赤兔監控：這里羅列的幾項指標，是SQL引擎請求量的對比，包括與前一日的對比曲線。
智能告警：如果報警標紅就會閃爍，如果只有監控而沒有告警，其實是起不到任何作用的，一定要將監控與告警關聯，才能起到預警作用。
扁鵲系統：其內部邏輯非常復雜，主要是基于騰訊多年來海量運維的經驗，形成的策略庫、語法庫。通過在這方面經驗的積累，對一些常見的故障進行分析和識別并處理。
一鍵運維：TDSQL赤兔管理臺的首頁，它包含的功能在我們看來如果DBA數據庫管理員有這套東西，基本上是可以做到只在頁面上完成所有的操作，不需要登錄到后臺進行變更、維護。
第一個案例：微眾銀行
微眾銀行是在2014年開始籌建，最終采用了TDSQL，并搭建分布式架構核心系統。微眾銀行對于機房的部署是，在同城有5個機房異地有2個機房，按照傳統意義上的理解，這同城的5個機房如果做成1主4備，其余4個機房都有可能會浪費。因為只有1個機房沒有讀寫請求。
微眾銀行對上述機房的部署肯定沒法充分利用機房的資源。對此，又是怎么解決的呢？
首先，將數據庫規劃成一個個的 DCN，一個DCN模型就是一個小的微眾銀行的分行、網絡分行，一個分行只固定500萬的賬戶數，這500萬的客戶數也是經過了一系列的壓測驗證，至少這500萬放在這個單機版的TDSQL上是安全的，不會有性能的瓶頸。
如果超過500萬，比如客戶數到了600萬，就再加一個DCN，實際數據庫的實例層是由多個DCN組成了一套集群，而多個DCN之間相互沒有聯系，因為用的都是單機版的TDSQL。
那么，微眾銀行是如何利用這種單機版的Noshard模式實現整體的分布式呢？
微眾銀行還引入了一個組件GNS， GNS被稱作全局路由，業務訪問數據庫一定要經過GNS，之后，GNS告訴他所需要的數據在DCN的具體位置，業務再把對應的SQL發到對應的DCN。
所以，GNS解決了路由的問題。
在這種情況下，如果要做分布式事務該怎么辦？傳統的分布式數據庫，對于用戶側而言就是一個begin，然后增刪、改查、commit。
如果增刪、改、查里涉及到的多個DCN對業務是透明的，但是在這種情況下，實際上沒法做到完全的透明。
對此，微眾銀行又引入了一個組件RMB——可靠的消息隊列，是處理分布式事務的，也就是在一筆分布式事務到達后，首先要在RMB這里注冊一個分布式事務的總事務，之后再由RMB完成子事務的分發，最后它會確保所有的分布式事務所涉及到的 DCN在處理完成后，返回給業務端。
微眾的數據庫是怎么部署的呢？利用多個IDC交叉部署，第一個DCN的主放在IDC1，第二個DCN的主放在IDC2，以此類推，其所有DCN的主是交叉部署在這5個機房的。
如果最后是500個DCN，有5個機房，每個機房就放100個DCN，這樣的好處在于每個機房的讀寫流量是均勻的，并不會造成像原來所有的讀寫都壓在1個機房，其余4個機房都是stand by的角色。
所以，微眾銀行這套架構從整體上看，實現了5個機房資源的充分利用。
任何一個機房的故障都只會影響1/5的流量，不會造成系統性的宕機。
像以前這種1主4備的模式，如果主節點壞掉，整個全行所有的服務都會癱瘓，雖然最后也會切換，但是其過程對全行的業務是有影響的。
如果按照分散的方式，就會產生另外一個問題，一個節點壞掉之后，使得1/5的業務受到影響，而原來的1主4備的模式，如果壞掉的是一個備機，那正常業務就不會受到影響。所以，這其中存在著可用性和成本之間的博弈。
第二個案例：張家港銀行
張家港銀行是我們對傳統銀行核心系統進行的一次徹頭徹尾地改造。
首先，它是一家傳統銀行，并非新成立。其次，它的核心系統是針對傳統銀行打造的。從微眾銀行到張家港銀行已經過去大概5年的時間，整個TDSQL在產品迭代方面已經有了很大的變化。
對于張家港銀行而言，首要考慮的問題是性能，其早期的數據庫是Sybase數據庫，大概是10年前的一個架構。在張家港銀行在業務高峰期經常有卡頓、超時的問題，所以其訴求就是要升級成一個能滿足行里現在業務場景的數據庫。
第二，張家港銀行的量級相對較小，其訴求就是成本。
另外，改造的難度，在業務方面，微眾銀行在數據庫方面做了很多的自身的改造。
比如引入了GNS、RMB，這些都是微眾自己進行維護的。并且從一開始，微眾銀行基于自身的定位，更多地還是想參與金融創新，定位自身為一家金融科技公司。而張家港銀行更希望能快速地解決自身的問題并且把東西用起來。
所以，張家港銀行的架構圖就非常清晰和簡單，就是一個標準的分布式兩地三中心的架構，同城總行機房部署一組主節點和一組備機節點，同城的災備機房部署一組備節點，整個分布式實例采用一主三備四分片的架構。
此外，在異地還有一組異步節點。從整體看，沒有任何的復雜組件，張家港銀行采用的這種形態與微眾銀行的截然不同。
TDSQL有兩種形態——Noshard和shard，張家港銀行完全采用了后者的形態，這樣，張家港銀行就不需要引入諸如GNS、RMB等組件,因為我們的SQL引擎會助其自動做路由，以及分布式事務管理。
所以，張家港銀行直接使用分布式shard版的TDSQL，對于業務而言，只需進行細微的調整和改動，例如重新設計庫表。按照這種分片關鍵字，一些大表需要選擇其分片關鍵字。
再者，就是將之前用到的存儲過程、觸發器的一些計算邏輯，盡可能地上提到業務代碼中。因為在分布式數據庫下，數據庫盡可能的只做數據的存取，否則很容易產生性能問題。
按照這種策略和思路，對張家港銀行的改造大概歷時半年完成，改造完之后，整個性能提升非常明顯，查詢交易在100毫秒以內完成，高頻交易在300毫秒內完成，像貸款結息這種跑批業務與原來相比得到成倍的提升，體現出分布式的一個優勢。
性能方面，原來在硬件成本方面需要4~5000萬，現在不足1000萬。同樣的成本，在oracle下是8000的TPS而在TDSQL下是6200的TPS。
在整體性能差異不大的情況下，成本已下降到了不足原來的1/5。同時TDSQL可以通過繼續加機器來提高集群的吞吐能力，所以性能還可以不斷地提升，具備橫向擴展的能力。
第三個案例：平安銀行
平安銀行更具代表性。平安銀行的體量與張家港銀行相比又上升了一個數量級，同時其應用改造的難度相對而言也是一個比較有挑戰性的工作。今年，我們完成了支持平安銀行信用卡核心從傳統集中式架構的大型機下移至分布式平臺。
平安銀行采用了TDSQL Noshard和Groupshard兩種架構。為了配合此次改造，應用引入了微服務架構對應用進行了拆分和解耦。對賬號的分布進行了單元化劃分，以DSU為一個邏輯單元，單個DSU包含200萬個客戶信息，單個DSU同時處理聯機和賬務兩種業務。這樣做的好處：一方面避免跑批時段消耗資源過多對聯機交易的，另外一方面避免由于基礎架構的故障導致全局不可用。。
平安銀行也有統計分析類型的業務，如果按照Noshard架構，對應用開發要求比較高，需要將統計類的SQL拆分成多個子SQL分發給多個noshard實例。
groupshard架構更適合， 從邏輯上來看，Groupshard架構對于應用而言就是多個獨立的邏輯表，應用不需要關心數據是如何組織分布的。由于要對數據進行統計分析，數據訪問量較大。所以，這種場景下，在訪問需要的數據時，應用只需把SQL發給SQL引擎，SQL引擎會對SQL進行拆分、并行下推,再進行結果集的聚合。
同時，TDSQL Noshard和Groupshard兩套集群之間通過TDSQL自帶的同步組件完成實時數據同步。
政務系統
第七次全國人口普查的數據采集處理工作，對于我們的TDSQL而言也是具有重要意義的。
首先，其數據量的規模是10億級別的，峰值QPS是百萬級。
這種情況，無論在我們內部業務還是外部業務都是非常罕見的，對于TDSQL性能的要求，包括跨節點之間的通信、分布式事務的處理都是比較大的挑戰。
因為人口普查涉及到國家政務的敏感信息，我們不便將其詳細的架構圖畫出來。
但可以肯定的是，基于TDSQL多引擎融合技術，第七次全國人口普查穩健完成了數據采集處理工作。
欲了解更多活動詳情，可聯系負責人周舟（微信：18811172358）。
雷峰網原創文章，未經授權禁止轉載。詳情見轉載須知。
