頭圖 | CSDN 下載自東方 IC
本文為企業投稿
省卻成本，縮短產品上市時間，減少運維與開發團隊之間的摩擦是 Serverless 最核心的所在，從 AWS 發佈「Lambda」讓「Serverless」越來越多地為開發者所知到今天，已經過去了 6 年的時光，Serverless 也正當時地引起了非常多的企業及開發團隊的青睞與跟進。
不久前，騰訊雲發佈了國內第一款 Serverless 數據庫 —— PostgreSQL for Serverless（ServerlessDB），在業界受到眾多數據庫開發者的廣泛關注，它基於 PostgreSQL 數據庫實現按需分配資源，能夠做到安全隔離、彈性擴容、按需付費、原生 SQL 支持。在本文中，騰訊雲 ServerlessDB 產品負責人從租戶隔離技術、快速擴縮容能力、連接池管理等方面，詳細解密這款數據庫背後的設計細節，希望能夠為所有開發者帶來啟發。
如何實現真正的自動擴縮容？
相比較於傳統數據庫，雲數據庫的彈性擴縮容和按量計費能夠幫助用戶按需使用雲資源，避免資源浪費的同時大幅節省了成本。在系統實現原理上，目前雲數據庫提供的這類“彈性方案”本質上是一種策略上的彈性，即開發者需要先行預估自己的產品負載量，例如一款遊戲什麼階段玩家特別多，什麼時候人潮回落，在設定好數據庫需求的方案後，對應進行手動的容量調整。
預估得越精細，這種“彈性”就越接近“按需分配”。要想通過彈性擴縮容最大限度降低成本，就需要做到精細化的預估和自動分配，這對絕大多數開發者提出了挑戰。
精細化預估理論上要求用戶的擴縮容對內存資源、CPU 資源、IO 資源、網絡資源等各種資源做全位一體的判斷。當用戶訪問請求上漲時，數據庫針對用戶請求的特點使用不同的系統資源，而這些資源需要動態的響應，且不會受到服務器限制。不同資源的擴縮容粒度需要小到一個數據塊——CPU 核心。當前普通的雲數據庫實例擴縮容相對粗放，若要提升 CPU 性能，順帶還必須擴展內存大小。
手動調控也是一個挑戰，一旦用戶請求上漲，則需要擴容，但是對於不可預估的業務場景來說，上漲和降低是隨機的，越是精細的預判越會導致頻繁的擴縮容，而如能實現細粒度的自動調控，會大大提升整體效率。
騰訊雲 ServerlessDB 的推出就完全克服了目前的挑戰，其最大優勢就是在技術層面上可以實現天然、精確、不需要人為干預的彈性擴縮容。
Serverless DB 架構圖
上圖是這款數據庫的技術架構，在騰訊雲 ServerlessDB 架構中，客戶端訪問數據庫是通過 Proxy 層進行轉發至數據庫中的，且數據庫可以縮容，也可以進行擴容。騰訊雲 ServerlessDB 採用租戶隔離擴縮容以及連接池管理技術，從而實現了技術層面上真正的彈性擴縮容。
租戶隔離技術
瞭解數據庫的應該知道，PostgreSQL 可以創建多個數據庫 Database，多個數據庫之間的數據是可以互相訪問的。而 PostgreSQL 的 Serverless 化破除了數據庫之間可以互相訪問的能力，將單個數據庫摘出來獨立成為一個實例對外提供服務，這與 Oracle 12C 裡面的 PDB 類似，但是騰訊雲 ServerlessDB 在技術層面的優化遠不止於此。
不同用戶共享一組數據庫實例時要保證用戶訪問不會出現越界的情況，所以需要對用戶進行隔離這就涉及到對 PostgreSQL 內核進行改造。騰訊雲 ServerlessDB 在 PostgreSQL 內核中加入了租戶的概念，一個租戶除了只能管理一個數據庫外，其他的和正常數據庫使用沒有區別，一樣可以擁有多個用戶。相當於一個用戶擁有自己的一套命名空間，每一個租戶維護自己的元數據信息。為了避免互相影響，系統表也進行了隔離，每個租戶的信息進行單獨存放。
Serverless DB 邏輯架構
這就是騰訊雲 ServerlessDB 的租戶隔離，可以通過上圖看到，將實例作為一個容器，其中將數據庫獨立成一個個單獨的租戶，每個租戶之間都是隔離狀態。數據庫實例負責公共操作，比如日誌讀寫、配置文件讀取、控制文件刷新等，租戶維護數據文件以及臨時文件，其中包括本租戶的元數據信息、租戶類型等操作，同實例可以擴展多個租戶數據庫。
這就相當於傳統 PostgreSQL 實例以前是一棟大別墅，裡面有多個房間（database）供一家人使用。那麼 Serverless 化後，改建為一座佔地 100 畝的大公寓，裡面有很多房間供用戶使用。
快速擴縮容能力
在租戶隔離技術避免了不同租戶之間的訪問越界問題後，在擴縮容方面，ServerlessDB 是如何保證對用戶進行細粒度控制的呢？
首先 ServerlessDB 將服務器計算資源分為 3 個區域，分別是系統全局區、數據庫全局區和資源池，每個區域都是互相隔離的。
ServerlessDB 擴縮容原理
其中系統全局區的計算資源用於處理操作系統本身的任務；數據庫全局區負責處理數據庫共享的任務，如 autovacuum，刷日誌，歸檔日誌等；租戶資源區負責剩餘的租戶類的操作，如工作進程都按照租戶打包，一個租戶只佔用一個資源區。
若租戶沒有任何連接訪問數據庫，對於該租戶就沒有任何資源響應，也就不會佔用資源池的計算資源。當租戶建立了數據庫連接後，管控就會自動給該租戶分配一個最小資源區單元。一旦該用戶對計算資源訪問達到了此資源區單元的 80%，後端管控將自動調整資源區的可使用的計算資源上限，以提高擴容的閾值，此時的擴容是完全無感知的，資源響應也是實時的。當用戶對資源利用率低於 20%的時候，租戶資源區將自動降低其可以使用的計算資源上限，空餘出來的計算資源將重新流通到資源池當中，供其他租戶調用。這就是計算資源實現 CPU 和內存的快速伸縮。
連接池管理
當前這種實現形式帶來了另外一個問題：一個連接會新增一個進程，而多租戶模式會導致服務器新建大量進程來消耗掉租戶的資源，多個租戶的連接數提升時很快會把服務器資源打爆，怎麼辦呢？
ServerlessDB 引入了連接池概念，當一個租戶的多個連接訪問到連接池後，將同一租戶的連接通過一個連接捆在一起建立起數據庫的連接，這樣就保證了一個租戶到數據庫側只有一個連接，相當於 N：1。在數據庫側建立的連接均通過租戶間的資源隔離技術將其分離，避免不同租戶產生影響，這樣就解決了連接池管理的問題。
因為其是無狀態的，即使連接池性能達到了瓶頸之後，用戶也可以橫向擴容，將請求進行負載均衡，這樣可以避免因為連接池性能瓶頸導致整體的服務不可用。
回到剛剛舉的例子，傳統 PostgreSQL 數據庫是一座別墅時，每來一個客人都需要單獨提供一個車庫（會話進程）給他們，訪客增多時會出現車位不夠用的問題。改建成公寓後專門修建了一個地下停車場（連接池），每一個租戶有一個獨門獨戶的電梯，所有訪問同一個租戶的訪客，都可以通過這一座電梯直達房間。如果訪問同一個租戶的訪客數量激增到一個電梯不夠用，就會為其專修一座電梯來避免單租戶的訪問量太大而無法負載的問題。
應用場景與實踐
其實，Serverless 概念的核心價值在於快速部署和降低使用成本。從這兩點來看，ServerlessDB 最主要應用場景就是小程序，對於一些簡單應用，甚至連後臺都無需開發。
疫情期間，各大平臺紛紛推出了自己的疫情監控功能，基於 Serverless 架構可以快速實現疫情監控。PostgreSQL 數據庫提供豐富的插件擴展，比如招牌特色的 PostGIS 插件，支持豐富的空間地理類型據，可以根據人群定位，自動避開風險區域。
Serverless 只是產品形態與使用上的改變，數據庫本身的功能沒有發生變化。用戶在使用這款數據庫的過程中，把數據庫的底層能力當作了一個 Serverless 化的服務來進行使用，無需關心數據庫底層的運維等操作。
今日福利
遇見大咖
由 CSDN 全新專為技術人打造的高端對話欄目《大咖來了》來啦！
CSDN 創始人&董事長、極客幫創投創始合夥人蔣濤攜手京東集團技術副總裁、IEEE Fellow、京東人工智能研究院常務副院長、深度學習及語音和語言實驗室負責人何曉冬，來也科技 CTO 胡一川，共話中國 AI 應用元年來了，開發者及企業的路徑及發展方向！
