作者 | 黃子毅（紫益） 阿里前端技術(shù)專家

導(dǎo)讀：前端開發(fā)者是最早享受到 “Serverless” 好處的群體，因?yàn)闉g覽器就是一個(gè)開箱即用、甚至無(wú)需為計(jì)算付費(fèi)的環(huán)境！Serverless 把前端開發(fā)體驗(yàn)帶入了后端，利用 FaaS 與 BaaS 打造一套開箱即用的后端開發(fā)環(huán)境。本文作者將從前端角度出發(fā)，為你講述 Serverless 帶來(lái)的收益及挑戰(zhàn)。

引言

Serverless 是一種 “無(wú)服務(wù)器架構(gòu)”，讓用戶無(wú)需關(guān)心程序運(yùn)行環(huán)境、資源及數(shù)量，只要將精力 Focus 到業(yè)務(wù)邏輯上的技術(shù)。

現(xiàn)在公司已經(jīng)實(shí)現(xiàn) DevOps 化，正在向 Serverless 邁進(jìn)，而為什么前端要關(guān)注 Serverless？

對(duì)業(yè)務(wù)前端同學(xué)：

會(huì)改變前后端接口定義規(guī)范；

一定會(huì)改變前后端聯(lián)調(diào)方式，讓前端參與服務(wù)器邏輯開發(fā)，甚至 Node Java 混部；

大大降低 Nodejs 服務(wù)器維護(hù)門檻，只要會(huì)寫 JS 代碼就可以維護(hù) Node 服務(wù)，無(wú)需學(xué)習(xí) DevOps 相關(guān)知識(shí)。

對(duì)一個(gè)自由開發(fā)者：

未來(lái)服務(wù)器部署更彈性，更省錢；

部署速度更快，更不易出錯(cuò)。

前端框架總是帶入后端思維，而 Serverless 則是把前端思維帶入了后端運(yùn)維。
**
前端開發(fā)者其實(shí)是最早享受到 “Serverless” 好處的群體。他們不需要擁有自己的服務(wù)，甚至不需要自己的瀏覽器，就可以讓自己的 JS 代碼均勻、負(fù)載均衡的運(yùn)行在每一個(gè)用戶的電腦中。

而每個(gè)用戶的瀏覽器，就像現(xiàn)在最時(shí)髦、最成熟的 Serverless 集群，從遠(yuǎn)程加載 JS 代碼開始冷啟動(dòng)，甚至在冷啟動(dòng)上也是卓越領(lǐng)先的：利用 JIT 加速讓代碼實(shí)現(xiàn)毫秒級(jí)別的冷啟動(dòng)。不僅如此，瀏覽器還實(shí)現(xiàn)了 BaaS 服務(wù)的完美環(huán)境，我們可以調(diào)用任何函數(shù)獲取用戶的 Cookie、環(huán)境信息、本地?cái)?shù)據(jù)庫(kù)服務(wù)，而無(wú)需關(guān)心用戶用的是什么電腦，連接了怎樣的網(wǎng)絡(luò)，甚至硬盤的大小。

這就是 Serverless 理念。通過(guò) FaaS（函數(shù)即服務(wù)）與 BaaS（后臺(tái)即服務(wù)）企圖在服務(wù)端制造前端開發(fā)者習(xí)以為常的開發(fā)環(huán)境，所以前端開發(fā)者應(yīng)該更能理解 Serverless 帶來(lái)的好處。

精讀

FaaS（函數(shù)即服務(wù)） BaaS（后臺(tái)即服務(wù)） 可以稱為一個(gè)完整的 Serverless 的實(shí)現(xiàn)。除此之外，還有 PaaS（平臺(tái)即服務(wù)）的概念。而通常平臺(tái)環(huán)境都通過(guò)容器技術(shù)實(shí)現(xiàn)，最終都為了達(dá)到 NoOps（無(wú)人運(yùn)維），或者至少 DevOps（開發(fā)&運(yùn)維）。

簡(jiǎn)單介紹一下這幾個(gè)名詞，防止大家被繞暈：

• FaaS - Function as a service

函數(shù)即服務(wù)，每一個(gè)函數(shù)都是一個(gè)服務(wù)，函數(shù)可以由任何語(yǔ)言編寫，除此之外不需要關(guān)心任何運(yùn)維細(xì)節(jié)，比如：計(jì)算資源、彈性擴(kuò)容，而且可以按量計(jì)費(fèi)，且支持事件驅(qū)動(dòng)。業(yè)界大云廠商都支持 FaaS，各自都有一套工作臺(tái)、或者可視化工作流來(lái)管理這些函數(shù)。

• BaaS - Backend as a service

后端及服務(wù)，就是集成了許多中間件技術(shù)，可以無(wú)視環(huán)境調(diào)用服務(wù)，比如數(shù)據(jù)即服務(wù)（數(shù)據(jù)庫(kù)服務(wù)），緩存服務(wù)等。雖然下面還有很多 XAAS，但組成 Serverless 概念的只有 FaaS BaaS。

• PaaS - Platform as a service

平臺(tái)即服務(wù)，用戶只要上傳源代碼就可以自動(dòng)持續(xù)集成并享受高可用服務(wù)，如果速度足夠快，可以認(rèn)為是類似 Serverless。但隨著以 Docker 為代表的容器技術(shù)興起，以容器為粒度的 PaaS 部署逐漸成為主流，是最常用的應(yīng)用部署方式。比如中間件、數(shù)據(jù)庫(kù)、操作系統(tǒng)等。

• DaaS - Data as a service

數(shù)據(jù)即服務(wù)，將數(shù)據(jù)采集、治理、聚合、服務(wù)打包起來(lái)提供出去。DaaS 服務(wù)可以應(yīng)用 Serverless 的架構(gòu)。

• IaaS - Infrastructure as a Service

基礎(chǔ)設(shè)施即服務(wù)，比如計(jì)算機(jī)存儲(chǔ)、網(wǎng)絡(luò)、服務(wù)器等基建設(shè)施以服務(wù)的方式提供。

• SaaS - Software as a Service

軟件即服務(wù)，比如 ERP、CRM、郵箱服務(wù)等，以軟件為粒度提供服務(wù)。

• 容器

容器就是隔離了物理環(huán)境的虛擬程序執(zhí)行環(huán)境，而且環(huán)境可被描述、遷移，比較熱門的容器技術(shù)是 Docker。
隨著容器數(shù)量增多，就出現(xiàn)了管理容器集群的技術(shù)，比較有名的容器編排平臺(tái)是 Kubernetes。容器技術(shù)是 Serverless 架構(gòu)實(shí)現(xiàn)的一種選擇，也是實(shí)現(xiàn)的基礎(chǔ)。

• NoOps

就是無(wú)人運(yùn)維，比較理想主義，也許要借助 AI 的能力才能實(shí)現(xiàn)完全無(wú)人運(yùn)維。

無(wú)人運(yùn)維不代表 Serverless，Serverless 可能也需要人運(yùn)維（至少現(xiàn)在），只是開發(fā)者不再需要關(guān)心環(huán)境。

• DevOps

筆者覺得可以理解為 “開發(fā)即運(yùn)維”，畢竟出了事情，開發(fā)要被問(wèn)責(zé)，而一個(gè)成熟的 DevOps 體系可以讓更多的開發(fā)者承擔(dān) OP 的職責(zé)，或者與 OP 更密切的合作。

---

回到 Serverless，未來(lái)后端開發(fā)的體驗(yàn)可能與前端相似：不需要關(guān)心代碼運(yùn)行在哪臺(tái)服務(wù)器（瀏覽器）、無(wú)需關(guān)心服務(wù)器環(huán)境（瀏覽器版本）、不用擔(dān)心負(fù)載均衡（前端從未擔(dān)心過(guò)）、中間件服務(wù)隨時(shí)調(diào)用（LocalStorage、Service Worker）。

前端同學(xué)對(duì) Serverless 應(yīng)該尤為激動(dòng)。就拿筆者親身經(jīng)歷舉例吧。

從做一款游戲說(shuō)起

筆者非常迷戀養(yǎng)成類游戲，養(yǎng)成游戲最常見的就是資源建造、收集，或者掛機(jī)時(shí)計(jì)算資源的讀秒規(guī)則。筆者在開發(fā)游戲的時(shí)候，最初是將客戶端代碼與服務(wù)端代碼完全分成兩套實(shí)現(xiàn)的：

// ... UI 部分，畫出一個(gè)倒計(jì)時(shí)伐木場(chǎng)建造進(jìn)度條 const currentTime = await requestBuildingProcess(); const leftTime = new Date().getTime() - currentTime; // ... 繼續(xù)倒計(jì)時(shí)讀條 // 讀條完畢后，每小時(shí)木頭產(chǎn)量 100，更新到客戶端計(jì)時(shí)器 store.woodIncrement = 100;

為了游戲體驗(yàn)，用戶可以在不刷新瀏覽器的情況下，看到伐木場(chǎng)建造進(jìn)度的讀條，以及“嘭”一下建造完畢，并且發(fā)現(xiàn)每秒鐘多獲得了 100 點(diǎn)木材！但是當(dāng)伐木場(chǎng)建造完成前、完成時(shí)、完成后的任意時(shí)間點(diǎn)刷新瀏覽器，都要保持邏輯的統(tǒng)一，而且數(shù)據(jù)需要在后端離線計(jì)算。 此時(shí)就要寫后端代碼了：

// 每次登陸時(shí)，校驗(yàn)當(dāng)前登陸 const currentTime = new Date().getTime() // 獲取伐木場(chǎng)當(dāng)前狀態(tài) if ( /* 建造中 */) {// 返回給客戶端當(dāng)前時(shí)間const leftTime = building.startTime - currentTimeres.body = leftTime } else {// 建造完畢store.woodIncrement = 100 }

很快，建筑的種類多了起來(lái)，不同的狀態(tài)、等級(jí)產(chǎn)量都不同，前后端分開維護(hù)成本會(huì)越來(lái)越大，我們需要做配置同步。

配置同步

為了做前后端配置同步，可以將配置單獨(dú)托管起來(lái)前后端共用，比如新建一個(gè)配置文件，專門存儲(chǔ)游戲信息：

export const buildings = {wood: {name: "..",maxLevel: 100,increamentPerLevel: 50,initIncreament: 100}/* .. and so on .. */ };

這雖然復(fù)用了配置，但前后端都有一些共同的邏輯可以復(fù)用，比如根據(jù)建筑建造時(shí)間判斷建筑狀態(tài)，判斷 N 秒后建筑的產(chǎn)量等等。 而 Serverless 帶來(lái)了進(jìn)一步優(yōu)化的空間。

在 Serverless 環(huán)境下做游戲

試想一下，可以在服務(wù)器以函數(shù)粒度執(zhí)行代碼，我們可以這樣抽象游戲邏輯：

// 根據(jù)建筑建造時(shí)間判斷建筑狀態(tài) export const getBuildingStatusByTime = (instanceId: number, time: number) => {/**/ }; // 判斷建筑生產(chǎn)量 export const getBuildingProduction = (instanceId: number, lastTime: number) => {const status = getBuildingStatusByTime(instanceId, new Date().getTime());switch (status) {case "building":return 0;case "finished":// 根據(jù) （當(dāng)前時(shí)間 - 上次打開時(shí)間）* 每秒產(chǎn)量得到總產(chǎn)量return; /**/} }; // 前端 UI 層，每隔一秒調(diào)用一次 getBuildingProduction 函數(shù)，及時(shí)更新生產(chǎn)數(shù)據(jù) // 前端入口函數(shù) export const frontendMain = () => {/**/ }; // 后端 根據(jù)每次打開時(shí)間，調(diào)用一次 getBuildingProduction 函數(shù)并入庫(kù) // 后端入口函數(shù) export const backendMain = () => {/**/ };

利用 PaaS 服務(wù)，將前后端邏輯寫在一起，將 getBuildingProduction 函數(shù)片段上傳至 FaaS 服務(wù)，這樣就可以同時(shí)共享前后端邏輯了！

在文件夾視圖下，可以做如下結(jié)構(gòu)規(guī)劃：

. ├── client # 前端入口 ├── server # 后端入口 ├── common # 共享工具函數(shù)，可以包含 80% 的通用游戲邏輯

也許有人會(huì)問(wèn)：前后端共享代碼不止有 Serverless 才能做到。

的確如此，如果代碼抽象足夠好，有成熟的工程方案支持，是可以將一份代碼分別導(dǎo)出到瀏覽器與服務(wù)器的。但 Serverless 基于函數(shù)粒度功能更契合前后端復(fù)用代碼的理念，它的出現(xiàn)可能會(huì)推動(dòng)更廣泛的前后端代碼復(fù)用，這雖然不是新發(fā)明，但足夠稱為一個(gè)偉大的改變。

前后端的視角

• 對(duì)于前端開發(fā)者而言，會(huì)發(fā)現(xiàn)后臺(tái)服務(wù)變簡(jiǎn)單了；
• 對(duì)于后端開發(fā)者而言，發(fā)現(xiàn)服務(wù)做厚了，面臨的挑戰(zhàn)更多了。

更簡(jiǎn)單的后臺(tái)服務(wù)

傳統(tǒng) ECS 服務(wù)器在租賃時(shí)，CentOS 與 AliyunOS 的環(huán)境選擇就足夠讓人煩惱。對(duì)個(gè)人開發(fā)者而言，我們要搭建一個(gè)完整的持續(xù)集成服務(wù)是很困難的，而且面臨的選擇很多，讓人眼花繚亂：

• 可以在服務(wù)器安裝數(shù)據(jù)庫(kù)等服務(wù)，本地直聯(lián)服務(wù)器的數(shù)據(jù)庫(kù)進(jìn)行開發(fā)；
• 可以本地安裝 Docker 連接本地?cái)?shù)據(jù)庫(kù)服務(wù)，將環(huán)境打包成鏡像整體部署到服務(wù)器；
• 將前后端代碼分離，前端代碼在本地開發(fā)，服務(wù)端代碼在服務(wù)器開發(fā)。

甚至服務(wù)器的穩(wěn)定性，需要 PM2 等工具進(jìn)行管理。當(dāng)服務(wù)器面臨攻擊、重啟、磁盤故障時(shí)，打開復(fù)雜的工作臺(tái)或登陸 Shell 后一通操作才能恢復(fù)。這怎么讓人專心把精力放在要做的事情上呢？

Serverless 解決了這個(gè)問(wèn)題，因?yàn)槲覀円蟼鞯闹皇且粋€(gè)代碼片段，不再需要面對(duì)服務(wù)器、系統(tǒng)環(huán)境、資源等環(huán)境問(wèn)題，外部服務(wù)也有封裝好的 BaaS 體系支持。

實(shí)際上在 Serverless 出來(lái)之前，就有許多后端團(tuán)隊(duì)利用 FaaS 理念簡(jiǎn)化開發(fā)流程。

為了減少寫后端業(yè)務(wù)邏輯時(shí)，環(huán)境、部署問(wèn)題的干擾，許多團(tuán)隊(duì)會(huì)將業(yè)務(wù)邏輯抽象成一個(gè)個(gè)區(qū)塊（Block），對(duì)應(yīng)到代碼片段或 Blockly，這些區(qū)塊可以獨(dú)立維護(hù)、發(fā)布，最后將這些代碼片段注入到主程序中，或動(dòng)態(tài)加載。如果習(xí)慣了這種開發(fā)方式，那也更容易接受 Serverless。

更厚的后臺(tái)服務(wù)

站在后臺(tái)角度，事情就變得比較復(fù)雜了。相對(duì)于提供簡(jiǎn)單的服務(wù)器和容器，現(xiàn)在要對(duì)用戶屏蔽執(zhí)行環(huán)境，將服務(wù)做得更厚。

筆者通過(guò)一些文章了解到，Serverless 的推行還面臨著如下一些挑戰(zhàn)：

• Serverless 各廠商實(shí)現(xiàn)種類很多，想讓業(yè)務(wù)做到多云部署，需要抹平差異；
• 成熟的 PaaS 服務(wù)其實(shí)是偽 Serverless，后續(xù)該如何標(biāo)準(zhǔn)化；
• FaaS 冷啟動(dòng)需要重新加載代碼、動(dòng)態(tài)分配資源，導(dǎo)致冷啟動(dòng)速度很慢，除了預(yù)熱，還需要經(jīng)濟(jì)的優(yōu)化方式；
• 對(duì)于高并發(fā)（比如雙 11 秒殺）場(chǎng)景的應(yīng)用，無(wú)需容量評(píng)估是很危險(xiǎn)的事情，但如果真能做到完全彈性化，就省去了煩惱的容量評(píng)估；
• 存量應(yīng)用如何遷移。業(yè)界的 Serverless 服務(wù)廠商大部分都沒(méi)有解決存量應(yīng)用遷移的問(wèn)題；
• Serverless 的特性導(dǎo)致了無(wú)狀態(tài)，而復(fù)雜的互聯(lián)網(wǎng)應(yīng)用都是有狀態(tài)的，因此挑戰(zhàn)在不改變開發(fā)習(xí)慣的情況下支持狀態(tài)。

所幸的是，這些問(wèn)題都已經(jīng)在積極處理中，而且不少有了已經(jīng)落地的解決方案。

Serverless 給后臺(tái)帶來(lái)的好處遠(yuǎn)比面臨的挑戰(zhàn)多：

• 推進(jìn)前后端一體化。進(jìn)一步降低 Node 寫服務(wù)端代碼的門檻，免除應(yīng)用運(yùn)營(yíng)的學(xué)習(xí)成本。筆者曾經(jīng)遇到過(guò)自己申請(qǐng)的數(shù)據(jù)庫(kù)服務(wù)被遷移到其他機(jī)房而導(dǎo)致的應(yīng)用服務(wù)中斷，以后再也不需要擔(dān)心了，因?yàn)閿?shù)據(jù)庫(kù)作為 BaaS 服務(wù)，是不需要關(guān)心在哪部署，是否跨機(jī)房，以及如何做遷移的；
• 提高資源利用效率。杜絕應(yīng)用獨(dú)占資源，換成按需加載必然能減少不必要的資源消耗，而且將服務(wù)均攤到集群的每一臺(tái)機(jī)器，拉平集群的 CPU 水位；
• 降低云平臺(tái)使用門檻。無(wú)需運(yùn)維，靈活拓展，按價(jià)值服務(wù)，高可用，這些能力在吸引更多客戶的同時(shí)，完全按需計(jì)費(fèi)的特性也減少了用戶開銷，達(dá)到雙贏。

利用 Serverless 嘗試服務(wù)開放

筆者在公司負(fù)責(zé)一個(gè)大型 BI 分析平臺(tái)建設(shè)，BI 分析平臺(tái)的底層能力之一就是可視化搭建。

那么可視化搭建能力該如何開放呢？現(xiàn)在比較容易做到的是組件開放，畢竟前端可以與后端設(shè)計(jì)相對(duì)解耦，利用 AMD 加載體系也比較成熟。

現(xiàn)在遇到的一個(gè)挑戰(zhàn)就是后端能力開放，因?yàn)楫?dāng)對(duì)取數(shù)能力有定制要求時(shí)，可能需要定制后端數(shù)據(jù)處理的邏輯。目前能做到的是利用 maven3、jdk7 搭建本地開發(fā)環(huán)境測(cè)試，如果想上線，還需要后端同學(xué)的協(xié)助。

如果后端搭建一個(gè)特有的 Serverless BaaS 服務(wù)，那么就可以像前端組件一樣進(jìn)行線上 Coding、調(diào)試，甚至灰度發(fā)布進(jìn)行預(yù)發(fā)測(cè)試。現(xiàn)在前端云端開發(fā)已經(jīng)有了不少成熟的探索，Serverless 可以統(tǒng)一前后端代碼在云端開發(fā)的體驗(yàn)，而不需要關(guān)心環(huán)境。

Serverless 應(yīng)用架構(gòu)設(shè)計(jì)

看了一些 Serverless 應(yīng)用架構(gòu)圖，發(fā)現(xiàn)大部分業(yè)務(wù)都可以套用這樣一張架構(gòu)圖：

• 將業(yè)務(wù)函數(shù)抽象成一個(gè)個(gè) FaaS 函數(shù)，將數(shù)據(jù)庫(kù)、緩存、加速等服務(wù)抽象成 BaaS 服務(wù)；
• 上層提供 Restful 或事件觸發(fā)機(jī)制調(diào)用，對(duì)應(yīng)到不同的端（PC、移動(dòng)端）；
• 想要拓展平臺(tái)能力，只要在端上做開放（組件接入）與 FaaS 服務(wù)做開放（后端接入）即可。

收益與挑戰(zhàn)

Serverless 帶來(lái)的收益與挑戰(zhàn)并存，本文站在前端角度聊一聊。

收益一：前端更 Focus 在前端體驗(yàn)技術(shù)，而不需要具備太多應(yīng)用管理知識(shí)。

最近看了很多前端前輩寫的總結(jié)文，最大的體會(huì)就是回憶 “前端在這幾年到底起到了什么作用”。我們往往會(huì)夸大自己的存在感，其實(shí)前端存在的意義就是解決人機(jī)交互問(wèn)題，大部分場(chǎng)景下，都是一種錦上添花的作用，而不是必須。

回憶你最自豪的工作經(jīng)歷，可能是掌握了 Node 應(yīng)用的運(yùn)維知識(shí)、前端工程體系建設(shè)、研發(fā)效能優(yōu)化、標(biāo)準(zhǔn)規(guī)范制定等，但真正對(duì)業(yè)務(wù)起效的部分，恰恰是你覺得寫得最不值得一提的業(yè)務(wù)代碼。前端花了太多的時(shí)間在周邊技術(shù)上，而減少了很多對(duì)業(yè)務(wù)、交互的思考。

即便是大公司，也難以招到既熟練使用 Nodejs，又具備豐富運(yùn)維知識(shí)的人，同時(shí)還要求他前端技術(shù)精湛，對(duì)業(yè)務(wù)理解深刻，魚和熊掌幾乎不可兼得。

Serverless 可以有效解決這個(gè)問(wèn)題，前端同學(xué)只需要會(huì)寫 JS 代碼而無(wú)需掌握任何運(yùn)維知識(shí)，就可以快速實(shí)現(xiàn)自己的整套想法。

誠(chéng)然，了解服務(wù)端知識(shí)是有必要的，但站在合理分工的角度，前端就應(yīng)該 focus 在前端技術(shù)上。前端的核心競(jìng)爭(zhēng)力或者帶來(lái)的業(yè)務(wù)價(jià)值，并不會(huì)隨著了解多一些運(yùn)維知識(shí)而得到補(bǔ)充，相反，這會(huì)吞噬掉我們本可以帶來(lái)更多業(yè)務(wù)價(jià)值的時(shí)間。

語(yǔ)言的進(jìn)化、瀏覽器的進(jìn)化、服務(wù)器的進(jìn)化，都是從復(fù)雜到簡(jiǎn)單，底層到封裝的過(guò)程，而 Serverless 是后端 運(yùn)維作為一個(gè)整體的進(jìn)一步封裝的過(guò)程。

收益二：邏輯編排帶來(lái)的代碼高度復(fù)用、可維護(hù)，拓展 云 端 的能力。

云 端 是前端開發(fā)的下個(gè)形態(tài)，提供強(qiáng)大的云編碼能力，或者通過(guò)插件將端打造為類似云的開發(fā)環(huán)境。其最大好處就是屏蔽前端開發(fā)環(huán)境細(xì)節(jié)，理念與 Serverless 類似。

之前有不少團(tuán)隊(duì)嘗試過(guò)利用 GraphQL 讓接口 “更有彈性”，而 Serverless 則是更徹底的方案。

我自己的團(tuán)隊(duì)就嘗試過(guò) GraphQL 方案，但由于業(yè)務(wù)非常復(fù)雜，難以用標(biāo)準(zhǔn)的模型描述所有場(chǎng)景的需求，因此不適合使用 GraphQL。恰恰是一套基于 Blockly 的可視化后端開發(fā)平臺(tái)堅(jiān)持了下來(lái)，而且取得了驚人的開發(fā)提效。這套 Blockly 通用化抽象后幾乎可以由 Serverless 來(lái)代替。所以 Serverless 可以解決復(fù)雜場(chǎng)景下后端研發(fā)提效的問(wèn)題。

Serverless 在融合了云端開發(fā)后，就可以通過(guò)邏輯編排進(jìn)一步可視化調(diào)整函數(shù)執(zhí)行順序、依賴關(guān)系。

筆者之前在百度廣告數(shù)據(jù)處理團(tuán)隊(duì)使用過(guò)這種平臺(tái)計(jì)算離線日志，每個(gè) MapReduce 計(jì)算節(jié)點(diǎn)經(jīng)過(guò)可視化后，就可以輕松看出故障時(shí)哪個(gè)節(jié)點(diǎn)在阻塞，還可以看到最長(zhǎng)執(zhí)行鏈路，并為每個(gè)節(jié)點(diǎn)重新分配執(zhí)行權(quán)重。即便邏輯編排不能解決開發(fā)的所有痛點(diǎn)，但在某個(gè)具體業(yè)務(wù)場(chǎng)景下一定可以大有作為。

挑戰(zhàn)一：Serverless 可以完全取消前端轉(zhuǎn)后端的門檻？

前端同學(xué)寫 Node 代碼最容易犯的毛病就是內(nèi)存溢出。

瀏覽器 Tab 天然是一個(gè)用完即關(guān)的場(chǎng)景，UI 組件與邏輯創(chuàng)建與銷毀也非常頻繁，因此前端同學(xué)很少，也不太需要關(guān)心 GC 問(wèn)題。而 GC 在后端開發(fā)場(chǎng)景中是一個(gè)早已養(yǎng)成的習(xí)慣，因此 Nodejs 程序緩存溢出是大家最關(guān)注的問(wèn)題。

Serverless 應(yīng)用是動(dòng)態(tài)加載，長(zhǎng)時(shí)間不用就會(huì)釋放的，因此一般來(lái)說(shuō)不需要太擔(dān)心 GC 的問(wèn)題，就算內(nèi)存溢出，在內(nèi)存被占滿前可能已經(jīng)進(jìn)程被釋放，或者被監(jiān)測(cè)到異常強(qiáng)制 Kill 掉。

但畢竟 FaaS 函數(shù)的加載與釋放完全是由云端控制的，一個(gè)常用的函數(shù)長(zhǎng)時(shí)間不卸載也是有可能的，因此 FaaS 函數(shù)還是要注意控制副作用。

所以 Serverless 雖然抹平了運(yùn)維環(huán)境，但服務(wù)端基本知識(shí)還需要了解，必須意識(shí)到代碼跑在前端還是后端。

挑戰(zhàn)二：性能問(wèn)題

Serverless 的冷啟動(dòng)會(huì)導(dǎo)致性能問(wèn)題，而讓業(yè)務(wù)方主動(dòng)關(guān)心程序的執(zhí)行頻率或者性能要求，再開啟預(yù)熱服務(wù)又重新將研發(fā)拖入了運(yùn)維的深淵中。

即便是業(yè)界最成熟的亞馬遜 Serverless 云服務(wù)，也無(wú)法做到業(yè)務(wù)完全不關(guān)心調(diào)用頻率，就可以輕松應(yīng)付秒殺場(chǎng)景。

因此目前 Serverless 可能更適合結(jié)合合適的場(chǎng)景使用，而不是任何應(yīng)用都強(qiáng)行套用 Serverless。

雖然可以通過(guò)定期運(yùn)行 FaaS 服務(wù)來(lái)保證程序一直 Online，但筆者認(rèn)為這還是違背了 Serverless 的理念。

挑戰(zhàn)三：如何保證代碼可遷移性

有一張很經(jīng)典的 Serverless 定位描述圖：

網(wǎng)絡(luò)、存儲(chǔ)、服務(wù)、虛擬家、操作系統(tǒng)、中間件、運(yùn)行時(shí)、數(shù)據(jù)都不需要關(guān)心了，甚至連應(yīng)用層都只需要關(guān)心其中函數(shù)部分，而不需要關(guān)心其他比如啟動(dòng)、銷毀部分。

前面總拿這點(diǎn)當(dāng)優(yōu)勢(shì)，但也可以反過(guò)來(lái)認(rèn)為是個(gè)劣勢(shì)。 當(dāng)你的代碼完全依賴某個(gè)公有云環(huán)境后，你就失去了整體環(huán)境的掌控力，甚至代碼都只能在特定的云平臺(tái)才能運(yùn)行。

不同云平臺(tái)提供的 BaaS 服務(wù)規(guī)范可能不同，FaaS 的入口、執(zhí)行方式也可能不同，想要采用多云部署就必須克服這個(gè)問(wèn)題。

現(xiàn)在許多 Serverless 平臺(tái)都在考慮做標(biāo)準(zhǔn)化，但同時(shí)也有一些自下而上的工具庫(kù)抹平一些差異，比如 Serverless Framework 等。

而我們寫 FaaS 函數(shù)時(shí)，也盡量將與平臺(tái)綁定的入口函數(shù)寫得輕一些，將真正的入口放在通用的比如 main 函數(shù)中。

總結(jié)

Serverless 的價(jià)值遠(yuǎn)大于挑戰(zhàn)，其理念可以切實(shí)解決許多研發(fā)效能問(wèn)題。

但目前 Serverless 發(fā)展階段仍處于早期，國(guó)內(nèi)的 Serverless 也處于嘗試階段，而且執(zhí)行環(huán)境存在諸多限制，也就是并沒(méi)有完全實(shí)現(xiàn) Serverless 的美好理念，因此如果什么都往上套一定會(huì)踩坑。

可能在 3-5 年后，這些坑會(huì)被填平，那么你是選擇加入填坑大軍，還是選一個(gè)合適的場(chǎng)景使用 Serverless 呢？

“ 阿里巴巴云原生微信公眾號(hào)（ID：Alicloudnative）關(guān)注微服務(wù)、Serverless、容器、Service Mesh等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢(shì)、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開發(fā)者的技術(shù)公眾號(hào)。”

《新程序員》：云原生和全面數(shù)字化實(shí)踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結(jié)

以上是生活随笔為你收集整理的收益 or 挑战？Serverless 究竟给前端带来了什么的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。