摘要：前端框架總是帶入后端思維，而則是把前端思維帶入了后端運(yùn)維。前端同學(xué)對(duì)應(yīng)該尤為激動(dòng)。而帶來了進(jìn)一步優(yōu)化的空間。當(dāng)服務(wù)器面臨攻擊重啟磁盤故障時(shí)，打開復(fù)雜的工作臺(tái)或登陸后一通操作才能恢復(fù)。

Serverless 是一種 “無服務(wù)器架構(gòu)”，讓用戶無需關(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ù)，而無需學(xué)習(xí) DevOps 相關(guān)知識(shí)。

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

未來服務(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ù)庫服務(wù)，而無需關(guān)心用戶用的是什么電腦，連接了怎樣的網(wǎng)絡(luò)，甚至硬盤的大小。

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

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

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

FAAS - Function as a service

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

BAAS - Backend as a service

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

PAAS - Platform as a service

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

DAAS - Data as a service

數(shù)據(jù)即服務(wù)，將數(shù)據(jù)采集、治理、聚合、服務(wù)打包起來提供出去。DASS 服務(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

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

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

DevOps

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

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

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

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

// ... UI 部分，畫出一個(gè)倒計(jì)時(shí)伐木場建造進(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)，用戶可以在不刷新瀏覽器的情況下，看到伐木場建造進(jìn)度的讀條，以及 嘭 一下建造完畢，并且發(fā)現(xiàn)每秒鐘多獲得了 100 點(diǎn)木材！但是當(dāng)伐木場 建造完成前、完成時(shí)、完成后的任意時(shí)間點(diǎn)刷新瀏覽器，都要保持邏輯的統(tǒng)一，而且數(shù)據(jù)需要在后端離線計(jì)算。 此時(shí)就要寫后端代碼了：

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

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

為了做前后端配置同步，可以將配置多帶帶托管起來前后端共用，比如新建一個(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 帶來了進(jìn)一步優(yōu)化的空間。

試想一下，可以在服務(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ù)并入庫
// 后端入口函數(shù)
export const backendMain = () => {
  /**/
};

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

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

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

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

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

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

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

可以在服務(wù)器安裝數(shù)據(jù)庫等服務(wù)，本地直聯(lián)服務(wù)器的數(shù)據(jù)庫進(jìn)行開發(fā)。

可以本地安裝 Docker 連接本地?cái)?shù)據(jù)庫服務(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è)問題，因?yàn)槲覀円蟼鞯闹皇且粋€(gè)代碼片段，不再需要面對(duì)服務(wù)器、系統(tǒng)環(huán)境、資源等環(huán)境問題，外部服務(wù)也有封裝好的 BAAS 體系支持。

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

為了減少寫后端業(yè)務(wù)邏輯時(shí)，環(huá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)角度，事情就變得比較復(fù)雜了。相對(duì)于提供簡單的服務(wù)器和容器，現(xiàn)在要對(duì)用戶屏蔽執(zhí)行環(huán)境，將服務(wù)做得更厚。

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

Serverless 各廠商實(shí)現(xiàn)種類很多，想讓業(yè)務(wù)做到多云部署，需要抹平差異。

成熟的 PASS 服務(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 秒殺）場景的應(yīng)用，無需容量評(píng)估是很危險(xiǎn)的事情，但如果真能做到完全彈性化，就省去了煩惱的容量評(píng)估。

存量應(yīng)用如何遷移。業(yè)界的 Serverless 服務(wù)廠商大部分都沒有解決存量應(yīng)用遷移的問題。

Serverless 的特性導(dǎo)致了無狀態(tài)，而復(fù)雜的互聯(lián)網(wǎng)應(yīng)用都是有狀態(tài)的，因此挑戰(zhàn)在不改變開發(fā)習(xí)慣的情況下支持狀態(tài)。

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

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

推進(jìn)前后端一體化。進(jìn)一步降低 Node 寫服務(wù)端代碼的門檻，免除應(yīng)用運(yùn)營的學(xué)習(xí)成本。筆者曾經(jīng)遇到過自己申請(qǐng)的數(shù)據(jù)庫服務(wù)被遷移到其他機(jī)房而導(dǎo)致的應(yīng)用服務(wù)中斷，以后再也不需要擔(dān)心了，因?yàn)閿?shù)據(jù)庫作為 BAAS 服務(wù)，是不需要關(guān)心在哪部署，是否跨機(jī)房，以及如何做遷移的。

提高資源利用效率。杜絕應(yīng)用獨(dú)占資源，換成按需加載必然能減少不必要的資源消耗，而且將服務(wù)均攤到集群的每一臺(tái)機(jī)器，拉平集群的 CPU 水位。

降低云平臺(tái)使用門檻。無需運(yùn)維，靈活拓展，按價(jià)值服務(wù)，高可用，這些能力在吸引更多客戶的同時(shí)，完全按需計(jì)費(fèi)的特性也減少了用戶開銷，達(dá)到雙贏。

筆者在公司負(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)境測試，如果想上線，還需要后端同學(xué)的協(xié)助。

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

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

將業(yè)務(wù)函數(shù)抽象成一個(gè)個(gè) FAAS 函數(shù)，將數(shù)據(jù)庫、緩存、加速等服務(wù)抽象成 BAAS 服務(wù)。

上層提供 Restful 或事件觸發(fā)機(jī)制調(diào)用，對(duì)應(yīng)到不同的端（PC、移動(dòng)端）。

想要拓展平臺(tái)能力，只要在端上做開放（組件接入）與 FAAS 服務(wù)做開放（后端接入）即可。

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

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

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

回憶你最自豪的工作經(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è)問題，前端同學(xué)只需要會(huì)寫 JS 代碼而無需掌握任何運(yùn)維知識(shí)，就可以快速實(shí)現(xiàn)自己的整套想法。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

雖然可以通過定期運(yùn)行 FAAS 服務(wù)來保證程序一直 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ì)，但也可以反過來認(rèn)為是個(gè)劣勢(shì)。 當(dāng)你的代碼完全依賴某個(gè)公有云環(huán)境后，你就失去了整體環(huán)境的掌控力，甚至代碼都只能在特定的云平臺(tái)才能運(yùn)行。

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

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

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

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

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

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

討論地址是：精讀《Serverless 給前端帶來了什么》 · Issue #135 · dt-fe/weekly

如果你想?yún)⑴c討論，請(qǐng)點(diǎn)擊這里，每周都有新的主題，周末或周一發(fā)布。前端精讀 - 幫你篩選靠譜的內(nèi)容。