<object id="3iwlw"><noframes id="3iwlw"></noframes></object>

      <th id="3iwlw"></th>

    1. <rp id="3iwlw"></rp>
      <rp id="3iwlw"></rp>

    2. <button id="3iwlw"></button>
      云計算·大數據 頻道

      為什么說數據庫是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領域取得更多的成績,趕超國際一流水平。

      0
      相關文章
        漂亮的苏酥全文阅读