你聽(tīng)過(guò)多少款無(wú)服務(wù)器架構(gòu)（Serverless）數(shù)據(jù)庫(kù)？

什么是Serverless呢？簡(jiǎn)單理解，Serverless 分為  FaaS 和 BaaS 兩個(gè)部分，其中 FaaS 指的是函數(shù)即服務(wù)，BaaS 是后端即服務(wù)。

舉個(gè)例子，用戶瀏覽網(wǎng)頁(yè)，可能涉及CDN資源。如果是靜態(tài)內(nèi)容，從對(duì)象存儲(chǔ)下載照片、視頻；如果是動(dòng)態(tài)內(nèi)容，則觸發(fā)一個(gè)函數(shù)計(jì)算，云函數(shù)將從云數(shù)據(jù)庫(kù)獲取相應(yīng)的資源，生成用戶所需的動(dòng)態(tài)內(nèi)容。其中，云函數(shù)為 FaaS，對(duì)象存儲(chǔ)和云數(shù)據(jù)庫(kù)則為 BaaS。

傳統(tǒng)的云數(shù)據(jù)庫(kù)會(huì)提供多種內(nèi)存/CPU規(guī)格給用戶購(gòu)買(mǎi)。即使無(wú)法時(shí)刻用滿負(fù)載，用戶也需要為選中的規(guī)格付費(fèi)。大多數(shù)客戶在購(gòu)買(mǎi)數(shù)據(jù)庫(kù)服務(wù)時(shí)，只能根據(jù)歷史經(jīng)驗(yàn)來(lái)推測(cè)需求規(guī)格，無(wú)法準(zhǔn)確判斷業(yè)務(wù)未來(lái)的發(fā)展趨勢(shì)。也是，咱們沒(méi)有天眼，誰(shuí)知道什么時(shí)候能被時(shí)代選中呢？

不過(guò)，咱還是要默默的問(wèn)自己一聲。萬(wàn)一爆紅，你的數(shù)據(jù)庫(kù)做好準(zhǔn)備迎接業(yè)務(wù)訪問(wèn)量暴漲、計(jì)算或存儲(chǔ)的需求量激增了嗎？

不打算爆紅的企業(yè)不是好企業(yè)，抱著一顆要爆紅的心，大多數(shù)的企業(yè)會(huì)選擇比真實(shí)需求稍微偏大一些規(guī)格的數(shù)據(jù)庫(kù)服務(wù)。在沒(méi)爆紅前，這就是存儲(chǔ)、計(jì)算資源的浪費(fèi)，也是嘩嘩的銀子在流淌。當(dāng)然也有很多務(wù)實(shí)的企業(yè)，計(jì)算的近乎精準(zhǔn)，可還是避免不了資源的靈活規(guī)劃問(wèn)題，如某一時(shí)刻突然業(yè)務(wù)訪問(wèn)量暴漲，對(duì)計(jì)算或存儲(chǔ)的需求量激增，也容易出現(xiàn)實(shí)例資源不夠、規(guī)格太小，需要緊急擴(kuò)容。

那，用戶當(dāng)然要問(wèn)了，到底我要選擇多大規(guī)格的呢？在 TDSQL-C 這兒，完全不用糾結(jié)。

Serverless 服務(wù)是騰訊云數(shù)據(jù)庫(kù)自研的新一代云原生關(guān)系型數(shù)據(jù)庫(kù) TDSQL-C MySQL版的無(wú)服務(wù)器、全 Serverless 架構(gòu)版。TDSQL-C 推出的 Serverless 服務(wù)基于計(jì)算與存儲(chǔ)分離的理念，滿足了客戶在公有云計(jì)算環(huán)境下根據(jù)業(yè)務(wù)發(fā)展彈性擴(kuò)展集群的剛性需求，讓用戶不再糾結(jié)實(shí)例資源問(wèn)題，讓用戶像使用自來(lái)水一樣使用數(shù)據(jù)庫(kù)?？偨Y(jié)其特性，可分為以下三點(diǎn)：

• 自動(dòng)擴(kuò)縮容：用戶不需要過(guò)度關(guān)注規(guī)格，訪問(wèn)量上來(lái)時(shí)自動(dòng)擴(kuò)容，降低時(shí)自動(dòng)縮容，且實(shí)現(xiàn)擴(kuò)縮容的過(guò)程中做到業(yè)務(wù)無(wú)感知；

• 實(shí)用實(shí)付：按秒計(jì)量，按小時(shí)結(jié)算，按照實(shí)際使用的資源付費(fèi)；

• 不使用不計(jì)費(fèi)：如果沒(méi)有訪問(wèn)，不應(yīng)該收費(fèi)，幫助業(yè)務(wù)極大程度地節(jié)省成本；

要想完美的實(shí)現(xiàn) Serverless 的特性，必然不能放過(guò)任何一個(gè)細(xì)節(jié)。數(shù)據(jù)庫(kù)實(shí)例的啟停過(guò)程帶來(lái)的時(shí)間成本、安全挑戰(zhàn)就是其中重要的一點(diǎn)，接下來(lái)將會(huì)圍繞這個(gè)細(xì)節(jié)為大家闡述騰訊云數(shù)據(jù)庫(kù)TDSQL-C的解法。

在一些極限的測(cè)試場(chǎng)景下，實(shí)例會(huì)頻繁的自動(dòng)啟停，這時(shí)候如何保證實(shí)例停止后快速恢復(fù)呢？如何保證在恢復(fù)實(shí)例時(shí)無(wú)需用戶重復(fù)鏈接，直到恢復(fù)訪問(wèn)？

站在用戶的角度考慮，誰(shuí)都不希望數(shù)據(jù)庫(kù)每次啟停都耗費(fèi)大量的時(shí)間，更不希望在這個(gè)過(guò)程中對(duì)業(yè)務(wù)有任何的影響。因此，極致壓縮冷啟動(dòng)時(shí)間，做到鏈接不斷轉(zhuǎn)發(fā)請(qǐng)求的能力相當(dāng)關(guān)鍵。

為了實(shí)現(xiàn)這一能力，我們做了眾多探索，最后選定了通過(guò)在接入層增加一個(gè)恢復(fù)感知器來(lái)實(shí)現(xiàn)秒級(jí)冷啟動(dòng)這一方案。同比于通過(guò) proxy 來(lái)實(shí)現(xiàn)鏈接的保持和轉(zhuǎn)發(fā)能力的方案，我們采用的方案更加貼合 Serverless 服務(wù)為用戶提供低成本的理念。這是因?yàn)椴捎?proxy 模式需要支付額外的成本，整體設(shè)計(jì)會(huì)更加復(fù)雜，并且還需要設(shè)計(jì)多租戶的能力。

這一方案的核心要點(diǎn)是在 TDSQL-C 的接入層增加了一個(gè)恢復(fù)感知器（下文簡(jiǎn)稱：perceptron），通過(guò)  perceptron 模塊來(lái)實(shí)現(xiàn)請(qǐng)求轉(zhuǎn)發(fā)，perceptron 在和客戶端握手之后，不斷開(kāi)與用戶連接，恢復(fù)實(shí)例后，與 TDSQL-C 握手，后續(xù)轉(zhuǎn)發(fā)四層報(bào)文。以下為 perceptron 與 TDSQL-C 建連的具體過(guò)程：

         

完成 TCP 握手之后，preceptron 會(huì)向客戶端發(fā)送 “隨機(jī)數(shù) A” 進(jìn)行挑戰(zhàn)（P1），MySQL 客戶端用自己的賬號(hào)密碼和 “隨機(jī)數(shù) A” 來(lái)計(jì)算并回復(fù)自己的 “登錄解答 A”（P2）。

由于 preceptron 并沒(méi)有存儲(chǔ)用戶的賬號(hào)密碼，所以無(wú)法校驗(yàn) “登錄解答 A” 是否正確，但 preceptron 能區(qū)分客戶端是 MySQL 客戶端，還是其他類(lèi)型的客戶端（preceptron 在機(jī)器學(xué)習(xí)界是分類(lèi)器，區(qū)分不同類(lèi)型的客戶端，這也是我們以它命名的原因之一）。

校驗(yàn) “登錄解答 A” 將由 TDSQL-C 計(jì)算層（下文簡(jiǎn)稱：TDSQL-C）來(lái)完成，preceptron 通過(guò)管控喚醒 TDSQL-C 后（P3），開(kāi)始下一步的登錄校驗(yàn)流程。

在和 preceptron TCP 握手之后（P4），對(duì)于 TDSQL-C 來(lái)說(shuō)，preceptron 也是一個(gè)普通的 MySQL 客戶端，所以也發(fā)送一個(gè) “隨機(jī)數(shù) B” 挑戰(zhàn)（P5）給 preceptron。

preceptron 的回復(fù)是一個(gè)我們實(shí)現(xiàn)的特殊的 MySQL 報(bào)文（P6），首先它用 “隨機(jī)數(shù) B” 和 preceptron 自身的鑒權(quán)機(jī)制計(jì)算得到 “登錄解答 B” 并放入報(bào)文中，其次它也將 “隨機(jī)數(shù) A” 和 “登錄解答 A” 捎帶在此報(bào)文中。

TDSQL-C 收到特殊的解答報(bào)文后會(huì)做兩次校驗(yàn)，第一次是 “隨機(jī)數(shù) B” 和 “登錄解答 B” 的正確性以及 preceptron 的身份，通過(guò)后再進(jìn)行第二次的 “隨機(jī)數(shù) A” 和 “登錄解答 A” 的正確性，通過(guò)即以用戶身份進(jìn)行登錄，并回復(fù) preceptron 登錄成功（P7）。

preceptron 進(jìn)而回復(fù)用戶登錄成功（P8）。

經(jīng)歷過(guò)這樣的流程后，我們?cè)诳蛻舳税l(fā)起一次登陸請(qǐng)求后，實(shí)例就可以完全無(wú)感地進(jìn)行實(shí)例恢復(fù)，恢復(fù)登錄后，后續(xù)的請(qǐng)求和數(shù)據(jù)包通過(guò) preceptron 進(jìn)行相互的轉(zhuǎn)發(fā)。

比較巧妙的點(diǎn)在于整體流程設(shè)計(jì)采用了兩個(gè)挑戰(zhàn)隨機(jī)數(shù)進(jìn)行鑒權(quán)，這樣做的優(yōu)勢(shì)在于：

• 實(shí)現(xiàn)中繼模塊 preceptron 不存儲(chǔ)用戶名密碼的情況下也可以完成用戶名密碼驗(yàn)證；

• 保證了用戶密碼的安全性，也不會(huì)引入存儲(chǔ)的密碼不一致的問(wèn)題；

由于后續(xù)的 SQL 請(qǐng)求都是通過(guò) preceptron 進(jìn)行轉(zhuǎn)發(fā)，此功能對(duì)于 preceptron 的安全性、穩(wěn)定性、低資源消耗以及低延遲響應(yīng)能力都有要求。所以 TDSQL-C 團(tuán)隊(duì)采用了 Rust 語(yǔ)言進(jìn)行研發(fā)，相比使用垃圾回收機(jī)制管理內(nèi)存的語(yǔ)言，Rust 具有更穩(wěn)定的響應(yīng)時(shí)間。同時(shí)基于 Rust 內(nèi)存管理特點(diǎn)，使得 preceptron 更安全，占用的內(nèi)存資源更少，最大化降低成本。

至此，讀者一定會(huì)疑問(wèn)，基于 serverless 形態(tài)下如果所有請(qǐng)求都通過(guò) preceptron 進(jìn)行轉(zhuǎn)發(fā)，這樣成本和開(kāi)銷(xiāo)無(wú)疑會(huì)變大，有悖于數(shù)據(jù)庫(kù)在 serverless 下的低成本特性吧？

其實(shí)，選擇 serverless 的用戶更在意低成本，而不是讀寫(xiě)分離和鏈接保持能力。因此我們?cè)谠O(shè)計(jì) preceptron 模塊時(shí)，只會(huì)把觸發(fā)恢復(fù)的請(qǐng)求鏈接接路由到 preceptron 上，當(dāng)實(shí)例恢復(fù)后，新增的請(qǐng)求會(huì)直接發(fā)給 TDSQL-C。

這一流程是通過(guò) VIP 權(quán)重來(lái)實(shí)現(xiàn)路由的定向轉(zhuǎn)發(fā)。當(dāng)實(shí)例處于暫停狀態(tài)時(shí)，僅保留 preceptron 的路由；當(dāng)實(shí)例恢復(fù)后時(shí)，同時(shí)保留 preceptron 的路由和 TDSQL-C 的路由，并設(shè)置 preceptron 的路由權(quán)重為 0，以實(shí)現(xiàn)新增連接直連到 TDSQL-C，同時(shí)存量與 preceptron 已經(jīng)建連的鏈接依然能夠通訊。

那么下面我們來(lái)模擬一下用戶恢復(fù)實(shí)例的鏈接不斷機(jī)制。首先我們選好一個(gè)暫停狀態(tài)的 serverlss 實(shí)例，如果其在運(yùn)行中我們也可以通過(guò)手動(dòng)暫停來(lái)停止實(shí)例的運(yùn)行。

通過(guò)監(jiān)控?cái)?shù)據(jù)和控制臺(tái)，我們可以看到上面的實(shí)例已經(jīng)處于完全暫停狀態(tài)了，接下來(lái)我們通過(guò)遠(yuǎn)程連接工具，直接對(duì)數(shù)據(jù)庫(kù)發(fā)起連接請(qǐng)求。

如下圖所示，我們?cè)诎l(fā)起數(shù)據(jù)庫(kù)連接請(qǐng)求時(shí)，可以做到秒級(jí)數(shù)據(jù)庫(kù)恢復(fù)，并且在整個(gè)連接的過(guò)程中用戶側(cè)對(duì)實(shí)例恢復(fù)和重連毫無(wú)感知，極大程度地提高了 Serverlss 產(chǎn)品的易用性。

經(jīng)過(guò)多輪測(cè)試，我們累加內(nèi)核側(cè)、管控側(cè)、perceptron 側(cè)的總體冷啟動(dòng)時(shí)間，整體重連時(shí)間約在 2000ms 左右。淺放一張今天下午測(cè)試的結(jié)果，歡迎大家來(lái)體驗(yàn)秒級(jí)的快樂(lè)！

TDSQL-C Serverless 功能還在持續(xù)優(yōu)化中，今天我們更貼近了云函數(shù)的啟動(dòng)時(shí)間，在保證實(shí)例暫停的狀態(tài)下快速拉起服務(wù)并對(duì)業(yè)務(wù)無(wú)感。未來(lái)，我們還會(huì)繼續(xù)提升冷啟動(dòng)的時(shí)間。

同時(shí)，我們?yōu)榱诉M(jìn)一步降低用戶的存儲(chǔ)成本，我們?cè)诔掷m(xù)探索新型的存儲(chǔ)能力，在實(shí)例暫停狀態(tài)下將數(shù)據(jù)轉(zhuǎn)存到對(duì)象存儲(chǔ)COS，并保證實(shí)例在恢復(fù)時(shí)不影響數(shù)據(jù)的讀取，更大程度幫助用戶降低成本。

如何像用自來(lái)水一樣使用數(shù)據(jù)庫(kù)？

騰訊云TDSQL-C重磅升級(jí)，性能全面領(lǐng)跑云原生數(shù)據(jù)庫(kù)市場(chǎng)

↓↓點(diǎn)擊閱讀原文，深入了解TDSQL-C