2019 年，Gartner 在一份報告中将 Serverless 選為最有潛力的雲計算技術發展方向，稱其為雲原生時代的 必然發展趨勢之一。Serverless 從底層開始變革計算資源的形态，為軟體架構設計與應用服務部署帶來了新 的設計思路。 在各類 Serverless 應用中，資料庫的 Serverless 化被認為是頗具挑戰性的一大類别。曾幾何時，業内 隻有亞馬遜 AWS 釋出了較為成功的 Serverless 資料庫産品。2020 年 4 月，騰訊雲釋出了國内第一款 Serverless 資料庫，填補了國内這一領域的市場空白，在資料庫市場獲得了大量關注與期待。為了讓更多 IT 從業者更深入了解騰訊雲 Serverless 資料庫。在 2021 年 QCon 全球軟體開發大會【上海站】中，騰訊 雲資料庫進階工程師巫旭東發表了《雲原生 Serverless 資料庫的設計與實踐》的主題演講，分享了騰訊雲 Serverless 資料庫的誕生背景、設計理念與落地實踐。
傳統資料庫常見問題與解決方案 在 IT 行業，新概念的誕生與崛起往往是為了解決現有方案長期存在的問題和挑戰，Serverless 資料庫亦是如此。随着行業快速向雲原生架構轉型，傳統資料庫的一系列缺陷變得愈加突出，逐漸成為系統架構中不可 忽視的瓶頸環節：
1. 業務系統轉向微服務架構後，由于每個微服務需要單獨搭配資料庫，當微服務比較多時，輕量化資料庫的 數量也随之增加，開發環境預釋出與線上微服務的相乘結果将呈爆發式增長，其成本很容易陷入失控狀态；
2. 很多新服務上線時，很難準确預估其計算資源需求，傳統的雲端預付費模式容易導緻資源購買過量和浪費； 部分資料庫呈現平時低頻，短時高頻的通路特征，傳統模式不僅會造成浪費，還很難及時完成資源擴容， 帶來業務損失；
3. 傳統資料庫的存儲與計算在同一台伺服器上完成，當使用者存儲與計算需求不比對時，傳統購買模式會大幅 增加擴容成本；
4. 服務資料庫容量可能超過單機上限。當業務早期沒有準備好分布式能力，或需要開發分布式事務時，傳統 資料庫的這一瓶頸會對業務産生較大沖擊。
之是以傳統資料庫會遇到上述問題，最主要原因在于其計算層與存儲層耦合于同一台伺服器上，很難靈活分 配資源。傳統資料庫缺乏自治能力，使用者尚不清楚資料庫服務負載時就要先購買固定的計算與存儲能力；當 伺服器負載升高時，資料庫無法自行感覺資源不足情況并進行應對。與此同時，資料庫主機的計算與存儲資 源比例固定，售賣時隻能遵循這一固定比例，多餘成本需要使用者買單。另外，傳統資料庫的擴容依賴人工響應，跨機遷移速度非常緩慢。最後，單機存儲上限大大限制了傳統資料庫的水準擴充能力。 針對上述問題，行業提出了一些針對性的設計理念。例如成本問題可以通過按量計費模式解決，資源預估問 題和低頻服務需求可以通過自治能力、自動擴縮容來處理。存儲池化概念能夠突破單機存儲能力瓶頸，實作 動态擴縮容。
綜合來看，新一代資料庫需要做到：第一，計算與存儲分離，不再受限于某一台伺服器的計算與存儲資源； 第二，實作服務自治，能夠自動計算伺服器負載，實作資源動态擴縮容。
Serverless 資料庫架構與設計理念
騰訊雲 Serverless 資料庫就是基于上述理念打造而成的新一代雲原生資料庫。這款資料庫的架構基石就是“存算分離”，所有計算節點共享同一份存儲層資料。對于使用者來說，不管在叢集裡購買多少計算節點，都隻需 要一份存儲資源。 計算與存儲分離在不同機器上，就需要網絡 IO 來交換資料。若使用傳統的網絡 IO 技術，資料庫的計算與 存儲節點互動的日志會非常龐大，且延遲很明顯。是以騰訊雲自研了 Txstore 分布式存儲核心，将所有日志 統一到了 redolog 的功能上。TXstore 會接收發送過來的 redolog ，這樣既能把計算與存儲剝離開，又可以達到最高性能。
在 Serverless 資料庫的自動駕駛架構中，分為五個層次——使用者、管控、資料流、計算和存儲。使用者層就 是控制台的一些子產品。管控子產品分為兩個部分，其一負責管控計算子產品的配置設定、回收、暫停操作。其二是副 駕駛決策子產品，負責實時采集計算子產品的目前負載，根據實時負載及之前配置設定的計算節點資源來做評估；如 果目前配置設定的資源不足以處理目前的負載，該子產品會向管控子產品發起擴容請求；如果計算節點負載較低，分 配的資源有備援，決策子產品會發起收容請求。
極端情況下某些計算節點可能完全沒有負載。例如共享充電寶一般放在商場裡面，商場晚上 10 點後就關門 了，這時充電寶不會發來請求。如果資料庫還在運作，資源就會浪費一整夜。此時系統發現資料庫超過十分 鐘沒有任何新連接配接，就會回收計算資源。但存儲資源是有狀态的，不會回收。到早上 10 點商場開門了，用 戶進來掃充電寶，其用戶端就會向叢集的 proxy 發出連接配接請求。此時 proxy 發現計算節點不在，就會向管控子產品發起請求，請它喚醒計算節點。管控子產品會重新拉起計算節點，并通過路由表來關聯存儲節點。之後 proxy 發現計算節點已經拉起，會把連接配接重新打給計算節點。這就是資料庫具備的，從啟動到暫停再到啟動 的完整自動駕駛能力。
架構對比
騰訊雲 Serverless 資料庫的存儲池化架構是核心要素之一。傳統架構使用的是母機概念。上圖中的三個母機， 藍色部分是計算資源，綠色加紅色是存儲子產品，其中紅色是已經使用的子產品。母機是格式化配置設定，必須要對 計算與存儲做相應比例的配置設定。綠色的子產品沒有使用，但使用者也要付費；沒有使用的空間都是預付費的能力， 必須提前付費。且傳統架構中增加計算資源時，使用者必須要重新購買完整的計算與存儲母機，就可能為多餘 的存儲成本買單。
在存算分離架構中 Master 跟 Slave 共享同一份存儲，存儲是按照 shard 分片這一最小單元做配置設定，每個分 片固定為 2G。如果資料庫隻用到 10G 的資料就隻需要為 10G 付費，用到 11G 就隻需為 12G 空間買單。并 且因為存儲是分布式，容量不受單機存儲限制，最大可達 128T。
存儲池化涉及路由表的概念。存儲池的實際實體存儲單元 page 為 16K，每個 page 有自己的編号。一 批 page 的集合就是 shard ，其位址都會存在 DBMaster 子產品裡。讀寫請求需要找到 page 時，系統找到 page 後計算得到分片号，基于分片号通過路由表找到實體位置；再計算 page 在 shard 上的偏移量，有了 實體位址和偏移量可以做 page 尋址，完成一次讀寫請求的資料查找。
下面是關于計算自治部分，首先是擴縮容場景。
資料庫啟動時，首先需要使用者主動填寫期望的資料庫最小與最大規格。因為有些使用者對成本比較敏感，不希 望資料庫無限擴容，希望到一定的階段就停止；還有使用者希望資料庫啟動時最小規格保持在較高水準。為此 騰訊雲提供了一些規格清單供選擇。
擴縮容時，CPU 容量不限于資料庫目前使用的數量，資料庫啟動時可以使用的 CPU 上限是規格最大的上限。 因為如果系統限制使用者的 CPU 數量，那麼超過限制值時性能就會下降；但擴容本身有一定延遲，在 30 秒左 右，也就是說決策子產品發現業務使用的 CPU 數量超過目前的規格限制 30 秒之後才會擴容。是以騰訊雲決 定 CPU 數量不受目前使用數量限制，并承擔 30 秒以内的多餘成本，是以使用者側是無感覺的。
與 CPU 相比，記憶體是有參數限制的。資料庫的記憶體使用上漲後不會自動縮容，必須有參數動态限制資料庫 的記憶體。另一方面，當使用者實際使用的 CPU 超過了目前計費值 30 秒後，系統就會向下一個規格擴容，例 如從 0.25 擴容到 0.5、1 核，進而實作服務靈活自治，實際性能不受計費規格限制，且超出部分由廠商買單。 但這樣一來單台伺服器可能擴容到超過主機資源上限，出現母機資源超載問題。
解決母機超載問題就需要跨機遷移。這裡的算法假設母機的所有計算資源總量是 S，目前母機上所有執行個體規 格總規格是 M，擴容後規格計做 N。當 M 加 N 大于等于 S，意味着一台母機的計算資源不夠用了。這時存 儲是足夠的，隻需遷移計算節點，需要新找一台機器拉起計算節點，初始化表結構。此過程可以在兩秒内完成， 相比傳統架構的遷移耗時（可達數十小時）有巨大飛躍。
關于計算節點的暫停與冷啟動方面，當某個執行個體連續十分鐘沒有連接配接時，系統算法會将其回收，進入“暫停中”狀态。用戶端再發起連接配接請求時不會直接打到執行個體上，而是會打到 proxy 上。後者發現資料庫暫停，就會發 起喚醒請求到管控子產品，管控子產品拉起 Serverless 的計算節點。從 proxy 發起喚醒到計算節點被拉起的時 間就是冷啟動時間。
傳統資料庫的冷啟動必須要加載所有存儲資料，時間非常漫長。但 Serverless 資料庫隻需要處理計算節 點，隻需加載路由表，是以啟動速度非常快，可以優化到 1.6 秒到 2 秒。冷啟動完成後，proxy 會正常向 Serverless 資料庫發起連接配接請求，成功連接配接用戶端并進行正常的讀寫操作。
CCU計算單元
上圖是 Serverless 資料庫按量計費方案，其計算計費機關是 CCU 。系統每秒鐘在母機上采集 CPU 目前值 和五秒前的值，做減法除以 5 就得到每一秒平均 CPU ；記憶體與存儲的使用量每秒上報。這樣 Serverless 的 名額可以做到秒級采集。最終計費的單元是 CCU 和存儲，這兩個名額按小時上報扣費系統，給使用者看到按照小時計費的帳單。
Serverless 資料庫落地場景
騰訊雲 Serverless 資料庫已上線 10 月左右，使用者量累計較多。其中較典型的應用場景是同騰訊雲開發的深度合作。
很多小程式開發者的雲服務托管在騰訊雲開發上，後者與 Serverless 資料庫做了深入耦合。一些雲開發使用者對成本和業務性能非常敏感，過去他們會報告資料庫成本非常高，現在得到了明顯的成本下降效果。騰訊雲函數也是 Serverless 資料庫比較早的實踐者。雲函數将代碼托管到容器裡，當使用者使用時拉起容器，不 使用的時候把容器關掉，以提供無服務化的産品。過去計算節點在不提供服務時也會收費，而 Serverless 資料庫就填補了這塊拼圖。
上圖是實際使用中的效果展示。可以看到左上角的 CPU 使用核數與右上角的 CCU 呈現比較完整的耦合狀态， CPU 用量增加，CCU 也跟着漲了上來；10 點 16 分 CPU 降下來的時候，CCU 也會按照預期一半一半往下縮。
監控管理方面，騰訊雲 Serverless 資料庫與智能管家做了一些深度合作的監控管理，可以從不同的次元監 控資料庫。其中包括一些 SQL 預防操作，系統感覺風險後會給使用者提供操作建議。性能分析子產品發現資料 庫的 CPU 或者記憶體出現瓶頸，會建議把最大規格再調大一點。資料庫的告警機制也比較完善，可以支援 70 多個監控名額的告警。此外還有問題快速定位，可以給使用者提出一些比較好的處理建議、分析複盤和優化建議。
總結
回顧曆史，可以看到資料庫技術經曆了四個時代。最早是自建時代，開發者在購買伺服器自建資料庫。這個 時代的資料庫和硬體生命周期完全綁定，且運維方式比較原始。第二個是 paas 租用資料庫的時代，出現了 一些運維層面的改進，且節省了硬體購買成本，但因為存算一體化是以資源彈性比較差。接下來是雲原生數 據庫時代，做到了存算分離，是以資源彈性有大幅改善，可以高效擴縮容。但這一代資料庫沒有自治能力， 是以騰訊雲在雲原生資料庫的基礎上進一步設計了第四代 Serverless 資料庫，完美利用了存算分離特性。 第四代資料庫可以進一步提升資源彈性，可以做到純粹按量計費，且服務更加自治，有了秒級擴縮容，服務 更加穩定。
摘錄自：infoq: 騰訊雲技術實踐精選集2021