為什麼說資料庫是Serverless最難攻堅的堡壘？

看到如今Serverless在雲端計算行業噴薄欲出的態勢，像極了《星星之火，可以燎原》中的描述：雖然不能預測未來的發展和變化，但對於雲端計算來說這是個相對確定的方向。

從Google Trends的Serverless關鍵字的趨勢可以看到，對於Serverless的搜尋一直居高不下，並且在未來的一段時間內也會保持相當的熱度。從2015年開始，以AWS為代表的國外雲端計算大廠也在不斷地佈局Serverless相關的產品，AWS Lambda、Aliyun FAAS，資料庫領域的Aurora Serverless、RedShift Serverless、Azure SQL Database等。

學術界對Serverless的研究熱度也不亞於工業界對商業化方案的追求，文末列出了一些相關文章作為參考。對於雲端計算往Serverless演進的趨勢，學術界也經歷過一些質疑，2018年“Serverless Computing: One Step Forward, Two Steps Back”[3] 文章曾經對Serverless的發展給現在IT基礎設施帶來的衝擊表示過擔憂，但2019年同一撥人在這個方向上又表現出了支援和樂觀的態度。從Serverless領域被引用次數較多的論文上看到，主流科研機構對Serverless的趨勢和方向研究上趨於一致，研究重點也慢慢從“why”轉變為“how”[6]。

何為Serverless?為什麼Severless是個趨勢?“Cloud Programming Simplified: A Berkeley View on Serverless Computing”[5] 這篇文章為代表做了一個比較全面的分析和預測。同樣是Berkeley在2009年發表的另一篇文章“Above the Clouds: A Berkeley View of Cloud Computing”[7] 預測了雲端計算作為IAAS基礎設施的觀點。該篇文章延續了之前的風格，分析了現狀和難點，預測了雲端計算2.0的形態Serverless作為下一代基礎設施，也定義了Serverless的主要三個特徵。

1、資源的解耦和服務化

弱化了儲存和計算之間的聯絡。服務的儲存和計算被分開部署和收費，儲存不再是服務本身的一部分，而是演變成了獨立的雲服務。這使得計算變得無狀態化，更容易排程和擴縮容，同時也降低了資料丟失的風險。

2、自動彈性伸縮

程式碼的執行不再需要手動分配資源。不需要為服務的執行指定需要的資源(比如使用幾臺機器、多大的頻寬、多大的磁碟等)，只需要提供一份程式碼，剩下的交由Serverless平臺去處理就行了。當前階段的實現平臺分配資源時還需要使用者方提供一些策略，例如單個例項的規格和最大併發數，單例項的最大CPU使用率。理想的情況是透過某些機器學習演算法來進行完全自動的自適應分配。

3、按使用量計費

Serverless按照服務的使用量(呼叫次數、時長等)計費，而不是像傳統的Serverful服務那樣，按照使用的資源(ECS例項、VM的規格等)計費。

值得一提的是[5]這篇文章有眾多雲端計算廠商的背書，包括AWS、Micorsoft、Google、Alibaba等，同時文章也直接以AWS Lambda服務作為樣板去分析Serverless的問題。Serverless本身的技術難度，這篇文章羅列了多項內容，這裡不做贅述，可以具體讀一下文章。

關於Serverless的技術實現[3]給出了一個可行的系統實現方式，當然還是以FAAS為背景。其中提到Serverless關鍵技術路徑包括：

統一的標準執行環境支援多語言的執行時統一管理;

輕量級/蠅量級安全容器(在[4]中額外提到安全和隔離的重要性)

冷熱容器池設計做極致的多租戶複用能力;

高效的函式排程能力。

其中，函式計算的實現方式，卻與資料庫Serverless息息相關。

資料庫的Serverless

資料庫品類繁多，關係型資料庫自1979年E. F. Codd對於關係模型的描述[7]開始，後來者大多隻是模仿，而尚未在使用者接受度和規模上有超越。

資料庫不僅僅是一個“stateful”的應用，而且是一個“state-heavy”的應用。資料庫是Serverless最不友好的應用之一，包括雲原生基礎設施kubernates對於stateful應用的支援，也是等到StatefulSet和operator之後才有一個比較好的解決方案。而在這之前資料庫都是作為Serverless對狀態做解耦和狀態下沉的工具，也是全棧Serverless解決方案中最難攻堅的最後一個堡壘。

對於Serverless的定義，文章給出來一個公式：Serverless = FAAS + BAAS。將FAAS(Functions as a Service)定義為事件、API、訊息驅動的計算層;將BAAS(Backends as a Service )定義為類似資料庫、訊息佇列等後端服務。

“State-heavy applications will remain as BaaS”是目前對於資料庫的一個基本認知，但這與資料庫本身是否具備一定程度的Serveless能力其實是兩回事。前者強調的是在應用向Serverless做架構轉型的過程當中，資料庫的大量狀態儲存做不到FAAS這樣即開即用的能力，只能作為“+”來對接Serverless生態;後者說的是在某種程度上也能夠滿足“資源解耦”、“自動彈性”、“按使用量付費”的特點，某種程度上也可以認為是Serverless。

資料庫Serverless的難點究竟在哪裡?

資料庫做Serverless有若干難點[4]，總結如下：

Serverless沒有內建的持久化儲存，需要依賴遠端儲存，這就會導致在延時上較高;

客戶端是基於連線的方式訪問資料庫，在客戶端往往會維護連線池的方式供應用訪問，而函式計算往往具備飄忽不定的網路地址，與資料庫傳統的IP+User+password鑑權的方式迥異;

很多高效能的資料庫使用共享記憶體技術，而FAAS本身不具備共享記憶體的能力，會使得計算和資料庫之前的資源動態擴充套件能力不一致

其中尤其要注意的是第2點，在應用進FAAS之後，當前的資料庫訪問方式已經不適用於Serverless生態：

伺服器與DB做連線保持，這就意味著訪問狀態是由客戶端和資料庫共同維護，而FAAS無法做到連線持續保持的能力;

伺服器透過driver和連線池的方式訪問資料庫，每次的連線初始化相對較重，FAAS上無法承受如此重的連線初始化工作;

伺服器訪問鑑權透過user/password/ip的方式訪問資料庫，而FAAS多租戶場景所有使用者共享IP地址池，user/password內建到FAAS當中也暴露了極大的安全風險;

資料庫需要一種新的訪問方式，直接影響到資料庫能否作為Serverless生態當中的一部分，直接影響到當前Serverless應用做全棧Serverless改造。其重要程度甚至大於資料庫Serverless(資源解耦、極致彈性、按使用量付費等)本身。

當然資料庫本身要做的事情遠遠不止如此，資料庫本身要實現高效的彈升彈降，涉及到更多的管控和核心緊密的聯動。

他山之石

行業翹楚AWS在Serverless相關的佈局從2015年推出Lambda開始，引領著這個方向的發展。這裡更多的關注在資料庫方面，結合AWS在Aurora Serverless上的取捨，洞察AWS對於資料庫Serverless的理解。

從Aurora Serverless V1發表於2018年，在Serverless的理念上做了大膽的創新，做了幾件事情：

以ACU的方式去統一底層的資源，不再對上層暴露底層具體的機型和代數。1ACU“相當於”2GiB的RAM，統一對底層資源做了標準化和規範化的處理。這與Serverless理念中資源的解耦、以及對底層資源的遮蔽一致;

支援自動啟停，在無負載的情況下支援將計算節點降低至“0”。將Serverless中按資源使用量付費體現到極致，但也帶來了另外的問題。自動啟停在一般場景下首次拉起需要30s左右，犧牲了部分auto scale的能力;

資料庫彈性過程中核心相關buffer pool等引數隨著資源配合的變化而發生變化，這也是資料庫這種特殊的應用場景需要做的一些特殊處理;

2019年推出Data API功能，補全了資料庫作為BAAS接入FAAS的能力，解決了前面提到的生態相容的問題。

2020年釋出的Aurora Serverless V2的介紹影片並提供內測申請，而在前不久V2也正式GA。從Aurora Serverless V2的能力來看，在Serverless能力上做了增強和取捨：

將V1中彈效能力繼續提升至秒級，做極致快速的彈性。將V1中跨機升級的能力最佳化為本地升級的能力，保證業務在彈性過程中不受損。從Aurora Serverless只在3.0.2這一個版本上支援可以看出，核心層針對Serverless場景也做了大量的最佳化;

去除了V1中關於自動啟停的能力，使用者可以手動啟停例項;更加關注例項的auto scale能力，最小資源降低至0.5ACU而非0，犧牲了部分按使用量付費的能力，這也是一種取捨;

將彈性縮容的策略做得更加保守，以保證業務壓力情況下對業務的影響儘可能小。

從V1到V2的變化，對比V2和V1的User Case可以看出，Aurora Serverless V2主要解決的是從“開發測試環境”到有限場景下的生產環境的轉變，至於底層的實現原理，可以從一絲絲蛛絲馬跡中去探究。結合其他雲的做法，Serverless的能力目前還是看重這個理念，各個廠商也在以自己的產品形態去向貼近這個理念，至於說一統行業標準的產品化方案，還為時過早，這一領域大有可為。

未來可期

從2009年開始，雲的能力不斷增強，雲的本質是資源的池化，而這些資源不僅僅包含硬體資源，更包含專業的技術人才，以及核心的技術專利標準等。經過了十來年在規模和成本上的激烈競爭，IAAS資源也在不斷的向Serverless的方向演進，底層能力的增強也意味著上層PAAS層和SAAS服務有了更快地向Serverless演進的路徑。

如果開源託管產品RDS可以看成是雲資料庫服務1.0，自研產品如PolarDB和Aurora可以看成是雲資料庫2.0，那麼Serverless將會是雲資料庫服務的3.0。其中，客戶應用跟資料庫互動方式的改變(例如，從JDBC/ODBC向Restful API轉變)，將會具有重要意義。

從艾瑞2022年初對資料庫雲管平臺的發展趨勢預測[9]、以及結合雲的趨勢和Serverless本身，我們可以對Aurora Severless未來的發展方向做一些大膽的預測：

智慧化加持

從re:Invent2021釋出的Devops Guru產品上看到，AWS正在智慧化場景下進行追趕。內建的智慧化引擎對Serverless的場景可以做出更多的精準預測，讓“響應式”擴容升級為“響應式兜底，智慧化加持”的雙引擎驅動。

資源解耦和極致的彈性

共享記憶體技術、Brust IO能力等會推著Serverless將更多的資源進行解耦，以及進行獨立的升降配。

更多的Serverless手段

擴容是最有效直接應對資料庫流量的方式，但是有了更多智慧化的手段之後，單純的“擴容”已經有更多選擇，自動索引最佳化、智慧調參會是很好的選項。

自動的橫向擴充套件能力

scale out和scale up同樣可以應對業務流量的變化，但scale out的複雜程度要遠遠高於scale out本身，也是個可能的選項。

低成本硬體大規模使用

ACU的單位定義遮蔽了底層資源屬性，ARM、x86還是RISC-V已經不是那麼重要，標準化歸一化的算力能力讓更多型別的硬體無縫無感的接入到Serverless當中。

目前，在國產雲資料庫領域，各大國產廠商也正在加大研發力量。期待未來我們的國產雲資料庫能在Serverless領域取得更多的成績，趕超國際一流水平。