計算服務的演進也是類似，從前自建機房，需要維護機房設備；后來可以在云上直接購買虛擬機，部署業務，負責服務的擴縮容；現在的函數計算，從CI/CD到服務部署，擴縮容，全部自動完成，客戶可以更專注于業務代碼。

狹義的serverless分為FaaS和BaaS，基本特點是無需運維、以API方式提供服務、按實際使用計費、無使用無費用等。

舉個例子，用戶瀏覽網頁，可能涉及CDN資源。如果是靜態內容，從對象存儲下載照片、視頻；如果是動態內容，則觸發一個函數計算，云函數將從云數據庫獲取相應的資源，生成用戶所需的動態內容。其中，云函數為FaaS，對象存儲和云數據庫則為BaaS。

傳統的云數據庫會提供多種內存/CPU規格給用戶購買。即使無法時刻用滿負載，用戶也需要為選中的規格付費。如果要將數據庫serverless化，需要滿足以下三大特性：

圖左側是目前的主流架構—單體冗余架構（一主多從），是現在大部分客戶使用的架構。這類架構存在擴展性問題，實例的升降級和讀擴展，都通過數據搬遷實現，隨著數據量的增長，遷移耗時越來越長。

為了解決這個問題，業界趨勢是采用存算分離架構，衍生出兩類，一類是ShareNothing架構，計算和存儲均支持水平擴展，擴展能力非常強。不過，也存在一些缺點，其中最大的問題是SQL兼容性，解決之道在于持續構建和完善自己的生態，讓用戶更好的接受提供的用法；

另一類則是ShareStorage架構，共享存儲架構并沒有改變查詢引擎和ACI這些基礎特性，可以做到100%的兼容性。當然它也有缺點，目前計算節點沒有提供寫擴展能力，這個也是未來演進的方向。

隨后，李志陽又關注到了Serverless數據庫的用戶群，主要面向中長尾用戶，他們對擴展性的訴求并不強，更多關注使用的便利性，兼容性是最重要一點。

因此，騰訊云優先選擇了基于共享存儲架構的數據庫產品TDSQL-C提供Serverless服務。

在計算層使用了騰訊維護的MySQL內核分支-TXSQL，復用它的bugfix和新特性；存儲側則選擇了在騰訊內部有十幾年歷史的云硬盤CBS，把CBS的核心存儲和硬盤邏輯進行剖離，打造了統一存儲平臺-HiSTOR。

作為存儲底座，已適配了云硬盤CBS、云分布式文件系統CFS和數據庫TDSQL-C等多款產品，提供副本同步、故障自動遷移、數據校驗等一系列完善的數據安全保障能力，這正是TDSQL-C產品能夠穩定運行數年的重要基石。

另外，它還提供豐富的特性：備份/回檔速度，支持以MB為粒度并發，速度達到GB/s；除了高性能的SSD，還有混存和EC版本，應對歸檔類的業務，提供更低成本的存儲。

除了上述兩個關鍵組件，我們還在計算側實現了物理復制，將innodb的redo日志準實時同步到備機，主從延時非常低（小于1毫秒）；相比傳統數據庫先寫日志后異步刷臟，TDSQL-C只寫日志到存儲，存儲側通過dbstore模塊將日志轉化數據。日志下沉的優點很多，這里不做贅述。

由于騰訊云是國內首家提供Serverless數據庫的廠家，李志陽主要對比了國外AWS的同類產品Aurora Serverless，并分析如何實現serverless數據庫的三大特性。

一、自動擴縮容

上圖右側有一個共享的虛擬機池，規格不盡相同。Aurora Serverless的擴容策略是從1核2G到4核8G逐步遞增規格。例如需要從1核2G擴大到2核4G，則從池子里面找到2核4G的虛擬機，將對應的數據盤掛載到虛擬機，并將訪問切到該虛擬機，即可完成自動擴容。

有2個問題：1、假設用戶訪問本身需要4核8G，Aurora Serverless仍需要從1核2G開始逐步增加到4核8G，擴容耗時偏長；2、由于選擇新的虛擬機擴容，會導致BP失效，訪問將經歷一次冷啟動過程。

二、按使用量計費

實現比較簡單，秒級粒度統計正在使用的規格，按照該規格計費。

三、不使用不計費

如果實例超過一段時間沒有訪問，則關閉計算節點。由于有數據庫代理節點作為接入層，如果用戶再有訪問請求，會先到達數據庫代理節點。

此時，代理節點按照上面提到的方法，從共享池里面找到對應的虛擬機提供服務。對用戶而言，原有連接不受到影響，只是感覺到一次卡頓。缺點是引入了代理節點，用戶需要為此付費；另外，恢復時長需要30秒，耗時也比較長。

擴容時BP失效導致的問題

上圖為總體架構，核心模塊為中控節點（svls scheduler）。

中控節點接收計算層采集的內存/CPU/訪問情況等監控數據，根據策略決定是否擴縮容，啟停實例，以及按照計費規則上報云控制臺計費。

相對Aurora Serverless的區別在于暫停的應對，TDSQL-C Serverless有faker模塊，暫停計算節點時會把四層的vip:vport綁定到faker端口，用戶請求過來后，識別為有效的MySQL協議，則通知中控模塊將實例重新拉起。其優點在于用戶不需要為代理節點付費。

隨后，李志陽詳細解釋了TDSQL-C Serverless如何滿足serverless數據庫的三大特性。

一、?自動擴縮容：

目標是做到秒級的擴縮容，并且期間對用戶是平滑的，無感知的。

以上圖為例子，用戶在購買時選擇最小規格為1核2G，最大規格為2核4G。左邊為Aurora Serverless，矩形的縱坐標是CPU，橫坐標為內存。

初始為1核2G，當業務訪問過來，把CPU用滿了，持續一段時間才擴容到2核4G；而右側的TDSQL-C Serverless，初始就給用戶提供最大CPU規格，內存則從最小規格開始。假設用戶使用的CPU超過1核，并持續一段時間，將把內存從2G擴到4G。

可以看出，TDSQL-C Serverless的CPU資源不會受限，可以在設置的最大規格內任意使用。優點是用戶性能不受限，引入的缺點是可能整機出現滿負載。

由于TDSQL-C采用存算分離架構，一旦監控到整機資源超過閾值，就進行快速遷移。遷移其實就是在另外一臺相對空閑的機器重新拉起實例，秒級完成。在資源負載上可以精準控制。

另外，現在云數據庫整機利用率偏低。基于這兩點，TDSQL-C Serverless可以很好應對。

二、?按使用量計費：

我們定義了一個算力單元CCU（TDSQL-C Compute Unit）=max{CPU,MEM/2,最小規格}。其中，MEM/2的含義是，由于我們定義的規格CPU/內存比都是1/2，內存除以2相當于把內存換算成CPU。

整體還是以CPU決定整個算力。我們通過計算每個小時CCU平均值給用戶計費。

舉例說，假設用戶選擇最小最大規格為0.25核-4核，從圖中可以看到，業務高峰過來，一開始就能用到3核，右側CCU也會按照3核計費，能夠很好的應對業務負載。

三、?不使用無計費：

自動啟停的邏輯比較簡單，只要10分鐘（用戶可配）內監測到沒有訪問就回收掉計算節點，訪問回來就把節點重新拉起。

最核心的點是怎么做到快速恢復，之前提過TDSQL-C是日志下沉的，存儲側接收到日志之后會源源不斷的回放，數據庫計算節點在啟動的過程中，不需要像傳統數據庫那樣加載到日志然后重放，所以啟動相對比較簡單和快速。

具體來說，VDL表示已經持久化的日志點。在運行階段會不斷異步持久化VDL（last-vdl）。Recovery階段，首先獲取last-vdl（checkpoint點），然后廣播所有相關的小表獲取大于等于last-vdl的所有日志段，最后通過敗者樹找到最后連續的日志點作為VDL。整個過程都是并行化的，而且沒有數據重放，耗時小于100毫秒。

另外，我們還對MySQL啟動過程做了多處并行化處理，目前可以2秒內恢復實例。

同時，為了進一步降低用戶的存儲成本，如果很長時間沒有訪問，將數據轉存到對象存儲COS，屆時用戶只需要付COS的費用即可。最后，歡迎大家多多使用TDSQL-C Serverless！