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