來源 |
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，但是其實微服務這個詞已經遠遠超出了純技術架構的範疇，它背後也有核心的支撐思想，包括：
- 微服務雖然一定程度上增加了技術複雜度，但是在一定規模下它會降低系統複雜度群組織複雜度。
- 現代業務系統越來越複雜，很多業務系統會基于領域驅動設計（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）的設計和研發。