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

來源 | 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 時代，購買服務器，安裝各種工具，再在上面開發自己的業務。

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

所以沒必要再去給 Serverless 做什麼定義，他本身已經描述得很清晰。我們拋開概念，看看在各個具體技術領域的產品，相信你會有更直觀的認識。

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，但是其實微服務這個詞已經遠遠超出了純技術框架的範疇，它背後也有核心的支撐思想，包括：

1. 微服務雖然一定程度上增加了技術複雜度，但是在一定規模下它會降低系統複雜度和組織複雜度。
2. 現代業務系統越來越複雜，很多業務系統會基於領域驅動設計（DDD），微服務其實是 DDD 背後的支撐技術。

單體、微服務和複雜度

所以如果到了 Serverless 時代就沒法用微服務，我相信很多開發者會覺得不知所措，或者會“牴觸未來”，因為他們會覺得有人給我描繪了一個未來，但是完全不知道怎麼走過去。

拋開各種具體的技術實現，回到背後的理念，Serverless 代表的是一種無需關注服務器，降低使用雲計算服務的理念，所以它和微服務其實不衝突，完全可以共存。在阿里雲的 SAE 中，集成了微服務的能力（依託於阿里雲產品 MSE），這意味著：

1. 部署在 SAE 這類 Serverless 平臺上的應用，完全可以繼續使用微服務開發，不需要經過任何改造。
2. 在 SAE 上甚至提供了很多微服務能力增強，包括了註冊中心託管、服務治理等等，進一步降低開發者使用微服務的門檻和負擔。

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

函數計算 FC

講完 Serverless Application（應用），我們再來看看 Serverless Function（函數），FC 作為”根正苗紅“的 Serverless 產品，相信大家都對它不陌生，經過這麼些年的發展，它已經在前端 Serverless、多媒體處理、AI、事件類的場景（雲產品事件、數據庫變更事件等等）、物聯網消息等場景得到了很好地應用，甚至也有越來越多的公司將業務完全構建在 FC 之上，比如：世紀聯華的 Serverless 實踐。

另外針對早期的很多技術限制，現在也已經有了解決方案：

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

下面我們就具體介紹部分使用 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）的設計和研發。