作者 | 蒲松洋（秦粵）

作者說

在開始本篇內(nèi)容前我想與各位開發(fā)者達成幾個共識。

第一個共識，軟件工程沒有銀彈， Serverless 也不是銀彈，它并不是解決所有問題的萬能公式。

第二個共識，Serverless 能夠解決的是運維域的問題，它是解決特定領(lǐng)域問題的一個技術(shù)，并不是無限延伸的，與低代碼沒有關(guān)系。

第三個共識是復(fù)雜度守恒定律-泰斯勒定律（Tesler’s law）。典型例子就是蘋果，蘋果的產(chǎn)品很容易上手操作。但本質(zhì)上它整體復(fù)雜度是守恒的，它其實是把復(fù)雜的事情留給了系統(tǒng)開發(fā)工程師和軟件開發(fā)的工程師，讓用戶可以順滑體驗。同理 Serverless 也是如此，把部署 or 運維應(yīng)用、網(wǎng)站的煩復(fù)轉(zhuǎn)交給了云服務(wù)商，但整體的復(fù)雜度是不變的。

第四個共識是鄧寧-克魯格效應(yīng)（The Dunning-Kruger Effect），大家在認(rèn)知學(xué)習(xí)過程中，都會出現(xiàn)這樣的發(fā)展曲線：從剛開始一無所知，到對新知識的幻想，再到失望的低谷，緩慢爬坡。我們學(xué)習(xí)任何一個新事物都會經(jīng)歷這樣一個曲線過程。Gartner 采用鄧寧-克魯格曲線，來解釋新技術(shù)的發(fā)展周期。

個人認(rèn)知曲線

Gartern 技術(shù)發(fā)展曲線

作為開發(fā)工程師經(jīng)常會有這種體感，新的技術(shù)層出不窮學(xué)的很累。Serverless 剛推出來時也一樣，大家對這個技術(shù)充滿了無限的想象，當(dāng)想象到了一個巔峰以后，會慢慢認(rèn)識到想象與現(xiàn)實的差距，切身去體會在產(chǎn)品中使用時就會掉到技術(shù)的低谷，然后再緩慢的爬坡。

Serverless 正當(dāng)時

本文將會通過三個部分，為各位介紹 Serverless：

第一個部分是 “復(fù)雜化 for 云開發(fā)商”

第二個部分是 “簡化 for 開發(fā)者”

第三個部分，會介紹一些我自己和我們團隊使用 Serverless 的最佳場景。

復(fù)雜化 for 云開發(fā)商

(1) Serverless 架構(gòu)

Serverless 是一個集大成者，它的整發(fā)展歷史是站在巨人的肩膀上的?，F(xiàn)在很多云服務(wù)商去跑一個函數(shù)，底層都是這樣架構(gòu)。首先 Serverless 的運行底層會有一個 CaaS 層。它是一個 Serverless 化的容器服務(wù)，大部分的應(yīng)用服務(wù)都會跑在這一層上面，容器調(diào)度現(xiàn)在開源的比較好的解決方案就是 K8s，用 K8s 來調(diào)度容器，底層 laaS 就是虛擬機，最底層則是物理機。

CaaS 的實現(xiàn)的方式有很多，Serverless 應(yīng)用底層必須有 CaaS 服務(wù)的支撐。除了Docker 以外，vm 也可以是 CaaS ；例如 Node.js 的 vm 也可以做 CaaS ，webassembly 也可以做 CaaS 等等。另外在做整體架構(gòu)設(shè)計的時候，還需要一個 Component 層去解決網(wǎng)絡(luò)東西流量和南北流量的問題，例如 service Mesh 和 ingress 的方案，總體來說 Serverless 背后的架構(gòu)設(shè)計基本都是如此。

(2) 云開發(fā)商：不可變基礎(chǔ)設(shè)施

CNCF 的架構(gòu)整套框架是根據(jù)配置文件去遷移的，可以部署在阿里云、也可以騰訊云、亞馬遜的云上，甚至自己搭建的私有云。當(dāng)所有云服務(wù)作為不可變基礎(chǔ)建設(shè)，復(fù)雜度下沉到 K8s 層，架構(gòu)會變得通用。

另外對云服務(wù)商來說，他們以前積累的傳統(tǒng)的優(yōu)勢(虛擬機 laas 層的運維優(yōu)勢和 PaaS 層的平臺級的優(yōu)勢）就會漸漸失去。所以如果是 vendor-unlock 云服務(wù)商之間就會白熱化地打價格戰(zhàn)，看誰能提供更優(yōu)質(zhì)便宜的服務(wù)。

廣義的 Serverless 是整個云服務(wù)商運維體系的 Serverless 化。如傳統(tǒng)提供一個MySQL 或 Redis，必須讓開發(fā)者意識到這是跑在服務(wù)器上的，需要提供出來個 ip ，但 Serverless 化（BaaS 化）后，開發(fā)者不需要再去關(guān)心這個服務(wù)到底是運行在哪里，只需要申明需要一個 DB，應(yīng)用就可以自動去鏈接并消費 DB。

狹義的 Serverless 不僅僅是 Severless Computing，還指一個 FaaS 的應(yīng)用，是由 trigger（也可以歸并為BaaS） + FaaS + BaaS 的架構(gòu)組成的?，F(xiàn)在云開發(fā)商在 Serverless FaaS 的這一層的核心競爭力是不斷推出新的 BaaS （Backend as a Service） 能力，而 BaaS 主要是跟 FaaS 配套去使用的。

上面講到的云服務(wù)商的不可變基礎(chǔ)建設(shè)，如下圖所示，開發(fā)者在最上面這層去部署應(yīng)用，根本不用關(guān)心底層的這些基礎(chǔ)建設(shè)?，F(xiàn)在云服務(wù)商提供的 BaaS SDK 實際上已經(jīng)包含在你的這個 FaaS 的 runtime 里面，開發(fā)者只需要把它當(dāng)成一個函數(shù)接口去直接調(diào)用，不用關(guān)心數(shù)據(jù)庫部署在什么地方、要不要保持長鏈接等等。

簡化 for 開發(fā)者

此圖是 Gartner 在 2017 年推出的新興技術(shù)發(fā)展?fàn)顟B(tài)，當(dāng)時 Gartner 覺得 Serverless 還是一個比較新的概念，大家對它的認(rèn)知還處于爬坡階段；但實際上到今天，Serverless 已經(jīng)進入了平緩爬升期了，大家對 Serverless 可以解決運維域的問題，有哪些邊界的限制等等這些問題已經(jīng)有了清晰的認(rèn)知。

為什么最近這幾年沒有什么特別新的東西推出了？原因在于 Serverless 這層沒有特別新的概念誕生，大家更多是在做 FaaS 應(yīng)用基礎(chǔ)建設(shè)。現(xiàn)有的各種 Web 應(yīng)用場景場景是否可以 Serverless 化，比如近期已經(jīng)支持了的，數(shù)據(jù)庫 BaaS 化， websocket 支持 FaaS，另外還有很多 Web 應(yīng)用場景都是通過諸位的努力慢慢爬坡實現(xiàn)，使其能夠接近理想中的 Serverless 。

2021 年 Gartner 技術(shù)采納建議圖

圖中畫框的位置就是 Serverless，綠色代表已經(jīng)成熟，可以看出，現(xiàn)在的 Serverless 已經(jīng)是一個比較成熟的技術(shù)了，支持大部分 Web 應(yīng)用的場景了，所以各位開發(fā)者大家可以放心大膽地去嘗試 Serverless。

(1) 運維領(lǐng)域的 Serverless

國內(nèi)很多人把 Serverless 翻譯成無服務(wù)器或者叫無服務(wù)，這都不太準(zhǔn)確，Severless的反義詞是 Serverful，Serverful 的意思是需要特別關(guān)注服務(wù)器，Serverless 的本質(zhì)是為了降低心智負(fù)擔(dān)，不需要十分關(guān)心服務(wù)器，只專注部署函數(shù)就行，至于它怎么運行、底層有多少容器、底層有多少服務(wù)器來支撐它，開發(fā)者都不需要關(guān)心。

傳統(tǒng)的模式的前后端開發(fā)模式是由：后端提供數(shù)據(jù)服務(wù)，以前叫 SOA 是面向服務(wù)的編程，現(xiàn)在比較流行的是領(lǐng)域驅(qū)動微服務(wù)，前端消費組裝數(shù)據(jù)。后端數(shù)據(jù)接口傳統(tǒng)的方式是提供 HTTP API，到現(xiàn)在的流行的 BFF (Backend For Frontend) 膠水層函數(shù)編排。配合微服務(wù)提供全量數(shù)據(jù)，是目前業(yè)界比較流行的做法。那么未來的趨勢將會全部 BaaS 化，理想的狀態(tài)是前后端一體化模型驅(qū)動，不再需要再寫接口。

(2）結(jié)合 Serverless 做技術(shù)變革

當(dāng)下 Serverless 所處的階段的優(yōu)勢是跟其他領(lǐng)域的技術(shù)結(jié)合， Serverless 結(jié)合其他領(lǐng)域來引爆許多技術(shù)變革。例如，傳統(tǒng)的微服務(wù) + Serverless 結(jié)合起來后，可以做成 BaaS 化微服務(wù)。以前提供一個微服務(wù)，是需要開發(fā)者去關(guān)心這個微服務(wù)部署在哪里，但是加上 Serverless 后，便不用管部署在哪里，只需要關(guān)心怎么去調(diào)用即可。LowCode 加上 Serverless 可以讓搭建出來的頁面快速部署并上線；之前的接口函數(shù)編排如傳統(tǒng)的 BFF，在未來都可以 Serverless 化，變成 SFF（Serverless for frontend），很適合做前后端一體化方案。

(3）開發(fā)角色的轉(zhuǎn)變：前后端一體化

Serverless 出現(xiàn)后，未來還會出現(xiàn)前后端一體化的局面。現(xiàn)在已經(jīng)出現(xiàn)邏輯編排可視化的工具，例如狼叔的 iMove ，目前已經(jīng)可以做到后端接口的可視化編排，前端工程師去做一個后端的接口編排變得非常簡單。由此可以預(yù)見，前端工程師未來的職責(zé)可以往后端去延伸。

而原來的后端工程師會從傳統(tǒng)的應(yīng)用部署逐漸轉(zhuǎn)化去做 BaaS 化服務(wù)級別的開發(fā)，而未來運維工程師也會更偏向于向云端遷移。這個就是 Serverless 對研發(fā)生產(chǎn)鏈路帶來的一系列變革。

Serverless 的最佳場景實踐

對于 Serverless 使用最近場景的判定，最便捷的方式就是去看云開發(fā)商支持哪些 Trigger 事件觸發(fā)。

所以目前這個階段，各個云開發(fā)商都在不停的增加新的 Trigger。如圖所示，開發(fā)人員在寫 FaaS 時，是將 HTTP request 包裝成了 Trigger，可以把 FaaS 函數(shù)想象成在封閉的一個包裹里面，要如何喚醒這個包裹，怎么打開這個包裹呢？其實就是通過 Trigger 來喚醒。

另外 Serverless 的現(xiàn)階段，開發(fā)語言的重要性沒那么高了，語言只是去實現(xiàn)功能所需要的工具。CNCF 推出來以后 FaaS 就已經(jīng)是與語言無關(guān)的了，那么其實到底是 Node.js，PHP，Python 亦或是其他主流語言的代碼 FaaS 都可以，你甚至可以自建一個鏡像自定義語言和執(zhí)行環(huán)境。因此在 Serverless 后，多語言的優(yōu)勢我們都可以借用，比如用 Python 去處理 AI 數(shù)據(jù)，Node.js 去處理高并發(fā)網(wǎng)絡(luò) I/O 等等。

1）SFF 數(shù)據(jù)編排

最佳實踐就是 BFF + Serverless，這在阿里集團內(nèi)部是十分常見的。由于阿里內(nèi)部的大多場景后端都是 Java 工程師，前端團隊需要跟工程師去對接，而后端工程師提供的就是 HSF 微服務(wù)，可以把它理解為一堆 RPC 接口。以前就是部署一個 Node.js 應(yīng)用去調(diào)接口，拿到數(shù)據(jù)后對這些數(shù)據(jù)進行是清洗、處理，放到前端頁面去渲染。但是采用 Serverless 部署 BFF 的 Node.js 應(yīng)用后，基本不需要考慮跟進流量擴縮容、節(jié)省成本等問題。

(2）GitOps 模型

GitOps 對于小企業(yè)來說，是非常適用的場景，相當(dāng)于可以自建一套自動發(fā)布上線的管道，不再需要像以前一樣，修改一個版本便要測試一遍，目前整個方案已經(jīng)十分成熟了。Git 本身支持大量的 hook 函數(shù)，所以打造這樣一個流程也是非常容易的。需要關(guān)注的是要結(jié)合云開發(fā)商的能力，比如阿里云發(fā)布流程便十分自動化，在云下平臺發(fā)布上線后可以支持線上的流量錄制、回放。

(3）小而美的技術(shù)團隊

最后一點是打造小而美的團隊。在我的認(rèn)知中，技術(shù)架構(gòu)有個強大制約就是：組織架構(gòu)會決定我們的技術(shù)架構(gòu)。

就像前后端分離，大多是因為組織架構(gòu)定義了：前端有前端的領(lǐng)導(dǎo)，后端有后端的領(lǐng)導(dǎo)，所以就會產(chǎn)生前端由前端的開發(fā)，后端由后端的開發(fā)，需要中間去聯(lián)調(diào)基于 API溝通。那我們?nèi)绻氪蛟煲粋€小而美的團隊怎樣打破這個隔閡呢？

Serverless 一個比較適合的場景就是，通過前端的服務(wù)編排 SFF 將解決掉中間 API溝通的問題，后端去提供全量的服務(wù)即可。這種變革會迫使后端去做微服務(wù)化，甚至后端研發(fā)采用 Serverless 去做 BaaS 化，這是反向的導(dǎo)推過程。如果我們的前端團隊掌握了 Serverless， 有三個優(yōu)勢：前端的數(shù)據(jù)編排便不再需要再找后端工程師了；GitOps 解決部署運維，可以降低前端心智負(fù)擔(dān)；前端同學(xué)能夠?qū)Ｐ某橄髽I(yè)務(wù)模型。