6 歲！是時候從新認識下 Serverless 了

背景

Serverless 概念從 2012 年開始提出，真正推出相關雲產品是 2014 年 AWS 推出 Lambda。若是咱們將 Serverless 比做一個嬰兒，那麼它已經 6 歲了。數據庫

雖然業界對 Serverless 尚無一致承認的定義，可是我相信大部分開發者在聽到 Serverless 時，會聯想到 Lambda，而且冒出「函數」、「按需（調用次數）收費」、「事件驅動」等關鍵詞。確實當年剛剛誕生的 Serverless 就像下面可愛的「紫薯人」，紫色充滿神祕感（當年剛推出的時候絕對是黑科技），讓人印象深入。小程序

剛剛出生的 Serverless後端

AWS 的巨大影響力以及自己攜帶的一身黑科技，確實讓人記住了 Serverless，可是也正由於誕生的時候太印象深入，以致於如今提到已經 6 歲的 Serverless，不少人的印象仍是停留在Serverless=Lambda或者Serverless=FC（Function Compute），這不得不說是某種遺憾。服務器

如今的 Serverless架構

今天企業都在全面數字化轉型，整個技術架構體系都渴望依託雲原生來獲取巨大技術紅利，Serverless 從誕生的第一天起就是雲原生的，因此咱們有必要再系統地認識一下 Serverless 的理念以及這些年誕生的相關產品，相信無論你是前端、後端、架構師、SRE、CTO，都會有所收穫，而且在將來能更好地發揮 Serverless 的技術價值助力商業成功。框架

定義

業界一直在嘗試定義 Serverless，好比 CNCF 給出的定義是：NoOps 和 Pay as You Run，還有伯克利說 Serverless = FaaS + BaaS。可是我想說，Serverless 其實無需再去定義，他自己就已經很是清晰明確：「Server + less」，他是一個理念，核心思想就是你再也不須要關注 Server，做爲對比的是 IaaS 時代，購買服務器，安裝各類工具，再在上面開發本身的業務。less

Server 不會消失，而是讓通常的開發者不須要再關注 Server，這意味着【智能彈性】、【快速交付】、【更低成本】，這也是 Serverless 相關產品的典型特性。運維

因此不必再去給 Serverless 作什麼定義，他自己已經描述得很清晰。咱們拋開概念，看看在各個具體技術領域的產品，相信你會有更直觀的認識。dom

PaaS 在 Serverless 時代的重生

PaaS 自己的概念挺大，廣義的說它處於 IaaS 和 SaaS 之間，咱們先從一個具體的產品提及：GAE（Google App Engine）。2006 年 AWS 推出了 IaaS 的雲計算，Google 認爲雲計算不該該是 IaaS 這樣的底層形態，因此在 2008 年推出了本身的雲計算表明產品 GAE（關於這裏的發展原因，能夠參考張磊的這篇文章：容器十年，一部軟件交付編年史）。

初推出的 GAE，也像 Lambda，讓人眼前一亮，可是很快開發者就發現它的限制很是多，用今天的話說就是典型的「我不要你以爲，我要我以爲」，最後的結果就是你們都紛紛回到了 IaaS 的懷抱。

到後來的 PaaS 產品好比 Cloud Foundry，這類 PaaS 產品相對更實際一些，底層 IaaS 仍是雲廠商提供，上層提供一套應用管理生態，背後的思想仍是不但願開發者經過 IaaS 這麼底層的方式去使用雲計算，而是從 PaaS 開始，不過它也不是 Serverless 化的，你仍是要考慮服務器的維護、更新、擴展和容量規劃等等。

SAE（Serverless App Engine）

到了如今，隨着容器技術的成熟，以及 Serverless 理念的進一步發展，PaaS 和 Serverless 理念也開始融合，這樣的產品既有 PaaS 爲表明的【快速交付】，又有 Serverless 的特色【智能彈性】、【更低成本】，典型的產品表明就是阿里雲在 2019 年推出的產品：SAE（Serverless App Engine）。

**首先，它是一個 PaaS，再具體一點說，是一個應用 PaaS。**這意味着大部分開發者使用起來都會很是天然，由於裏面的概念你會很是熟悉，好比應用發佈、重啓、灰度、環境變量、配置管理等等。

**同時，它也是 Serverless 化的。**這意味着你沒必要再關心服務器，不用再申請機器，維護服務器，裝一堆工具，而是按需使用，按分鐘計費，結合強大的彈性能力（定時彈性、指標彈性）實現極致成本。

最後，得益於 Docker 爲表明的容器技術的發展，SAE 解決了經典 PaaS 的突出問題（各類限制和強綁定），依託於容器鏡像，在上面能夠跑任意的語言的應用。

看到這裏，我相信大部分開發者對於 PaaS 和 Serverless 結合的產品已經有了一個輪廓，在中國雲原生用戶調研報告中（2020 年），這種形態的 Serverless 產品開始被愈來愈多的開發者採用。

在這個基礎上，還有另一個話題值得再討論一下，那就是微服務和 Serverless。

微服務和 Serverless

如今業界關於微服務和 Serverless，會有部分這樣的認知：認爲當前雲計算典型表明技術是微服務，下一代的表明技術是 Serverless，這會讓你以爲 Serverless 比微服務要先進，甚至會以爲將來有了 Serverless 就沒有微服務了，相似下面這張圖：

我的認爲產生這一認知仍是由於將 Serverless 的理念具象化到函數計算（FaaS）這樣的產品。如今咱們聊到微服務，會想到背後的技術框架，好比 Spring Cloud、Dubbo，可是其實微服務這個詞已經遠遠超出了純技術框架的範疇，它背後也有核心的支撐思想，包括：

微服務雖然必定程度上增長了技術複雜度，可是在必定規模下它會下降系統複雜度和組織複雜度。
現代業務系統愈來愈複雜，不少業務系統會基於領域驅動設計（DDD），微服務實際上是 DDD 背後的支撐技術。

單體、微服務和複雜度

因此若是到了 Serverless 時代就無法用微服務，我相信不少開發者會以爲不知所措，或者會「抵觸將來」，由於他們會以爲有人給我描繪了一個將來，可是徹底不知道怎麼走過去。

拋開各類具體的技術實現，回到背後的理念，Serverless 表明的是一種無需關注服務器，下降使用雲計算服務的理念，因此它和微服務其實不衝突，徹底能夠共存。在阿里雲的 SAE 中，集成了微服務的能力（依託於阿里雲產品 MSE），這意味着：

部署在 SAE 這類 Serverless 平臺上的應用，徹底能夠繼續使用微服務開發，不須要通過任何改造。
在 SAE 上甚至提供了不少微服務能力加強，包括了註冊中心託管、服務治理等等，進一步下降開發者使用微服務的門檻和負擔。

因此在 Serverless 類的 PaaS 產品上，Serverless 和微服務再也不是對立的，開發者徹底能夠繼續使用微服務技術開發，同時也能夠享受 Serverless 理念所帶來的【智能彈性】、【更低成本】等。

函數計算 FC

講完 Serverless Application（應用），咱們再來看看 Serverless Function（函數），FC 做爲」根正苗紅「的 Serverless 產品，相信你們都對它不陌生，通過這麼些年的發展，它已經在前端 Serverless、多媒體處理、AI、事件類的場景（雲產品事件、數據庫變動事件等等）、物聯網消息等場景獲得了很好地應用，甚至也有愈來愈多的公司將業務徹底構建在 FC 之上，好比：世紀聯華的 Serverless 實踐。

另外針對早期的不少技術限制，如今也已經有了解決方案：

早期大多數的函數計算產品都對磁盤大小、代碼包大小、運行時長、內存規格等有限制，阿里雲函數計算推出了性能實例基本解決了這些限制。
針對冷啓動問題，可使用預留性能實例解決。

下面咱們就具體介紹部分使用 FC 的典型的場景。

前端 Serverless

前端通過了 Ajax、Nodejs、React 等技術迭代後，已經造成了相對成熟的技術體系，特別是 Nodejs，使前端和服務端產生了聯繫。

前端和後端的分工發揮了各個的優勢，可是在協做的過程當中也一直存在一個問題，後端同窗一般是面向領域和服務提供接口，可是前端是面向用戶具體的數據接口，有時候一個簡單的需求會由於兩邊的定義和聯調搞半天。因此也誕生了 BFF（Backends For Frontends）這樣一層，誰使用誰開發，專門解決領域模型 - UI 模型的轉換。

理想很美好，現實也很骨感，若是前端同窗去作 BFF 這一層，發現要學習後端的 DevOps、高可用、容量規劃等等，這些實際上是前端同窗不想關心的，這種訴求在 Serverless 時代獲得了很好地解決，由 BFF 變爲了 SFF（Serverless For Frontend）,讓前端同窗只要寫幾個 Function，其餘都交給 Serverless 平臺。

相似的還有服務端渲染 SSR（Server Side Rendering），原本先後端分工後，後端只須要寫接口，前端負責渲染，可是在 SEO 友好以及快速首屏渲染等需求背景下，有時候會用到服務端渲染的方案，一樣，使用 Serverless 前端同窗又能夠愉快地玩耍了。

其實如今不少偏前端產品裏面（好比各種小程序以及語雀等產品），前端同窗會全棧完成總體開發，愈來愈多地會用到 Serverless 相關技術。

固然，要用好 Serverless，須要完整的生態，包括相關的框架、運行時、工具鏈、配置規範等等，這方面能夠參考阿里 Midway。

多媒體處理

如今在線教育、直播、短視頻等行業都蓬勃發展，也催生了不少視頻需求，包括視頻的處理，例如視頻剪輯、切分、組合、轉碼、分辨率調整、客戶端適配等等，典型場景的好比：

每週五按期產生幾百個 4G 以上的 1080P 大視頻，可是但願當天幾個小時後所有處理完；
甚至您有更高級的自定義處理需求，好比視頻轉碼完成後，須要記錄轉碼詳情到數據庫，或者在轉碼完成後，自動將熱度很高的視頻預熱到 CDN 上，從而緩解源站壓力。

這些訴求在 Serverfull 的場景下，你可能須要搭建一套複雜的系統來支撐，可是若是使用 FC，那麼你會發現一切都變得那麼簡單。

AI Serverless

AI Model Serving 是函數計算一個比較典型的應用場景。數據科學家訓練好模型之後每每須要找軟件工程師把模型變成系統或者服務，一般把這個過程稱之爲 Model Serving。函數計算無需運維和彈性伸縮的特性，正好符合數據科學家對高可用分佈式系統的訴求。

Serverless 容器 - ASK

Kubernetes 做爲生產級別的容器編排系統，如今已經成爲了容器編排的事實標準，被普遍用於自動部署，擴展和管理容器化應用。它也有相應的 Serverless Kubernetes 產品，好比阿里雲的 ASK、AWS Fargate 等。在這類產品中，你無需購買節點便可直接部署容器應用，無需對集羣進行節點維護和容量規劃，而且根據應用配置的 CPU 和內存資源量進行按需付費。ASK 集羣提供完善的 Kubernetes 兼容能力，同時下降了 Kubernetes 使用門檻，讓您更專一於應用程序，而不是管理底層基礎設施。

若是您是 K8S 的重度用戶，那麼使用 Serverless Kubernetes 是一個不錯的選擇，典型客戶場景包括：

微博：在 30s 以內能夠極速擴容 500 個應用實例，應對跨年活動和熱點事件；
曠視科技：基於 ASK 開發智能、免運維的 AI 應用平臺；
趣頭條：基於 ASK 構建 Serverless 大數據計算平臺。

BaaS

上面提到的都是「計算類」 Serverless 產品，FC、SAE、ASK 等，可是咱們都知道，開發過程當中不可能只有計算邏輯，還有不少其餘依賴，好比存儲、中間件等。**BaaS（Backend-as-a-Service，後端即服務）**類產品，提供基於 API 的服務，這些 API 通常都是按需使用、免運維、自動擴縮容的，因此他們也是 Serverless 的。

典型的好比阿里雲的 OSS，具備與平臺無關的 RESTful API 接口，能夠在任何應用、任什麼時候間、任何地點存儲和訪問任意類型的數據。

值得一提還有開發企業級應用時你們很是熟悉的中間件，以阿里爲例當前也在進行 4.0 技術架構升級，全面 BaaS 化，統一運維、交付、計費、支持模式，開箱即用，產品化程度持續提高。

總結

總結一下，上面提到的一系列 Serverless 的產品，覆蓋了前端、後端、容器、BaaS 各個領域，包括不少上面沒有提到的（好比 CDN）其實也算是 Serverless 的產品，因此我不認同伯克利的 Serverless = BaaS + FaaS 的觀點，可是我很是承認他的另外一個觀點：「Serverless will dominate cloud computing」。

Serverless 首先是一個理念，不是某一種具體的技術，當將來某一天，99% 的雲產品都有 Serverless 化的形態時，雲計算也就 Serverless 化了，這種變化我認爲不是非黑即白的，不是推翻重來這種革命性的，而是全面地下降用戶使用雲的成本，全面地提高開發者的研發效率。

做者簡介：陳濤，10 年軟件開發經驗，4 年創業經歷，曾在淘寶、滴滴任職，關注雲原生、微服務、Serverless 等技術領域，積累了在雲計算、電商、從 0 到 1 創業等方面的研發、管理和業務經驗。目前就任阿里雲，在雲原生應用平臺從事 Serverless 應用引擎（SAE）的設計和研發。