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

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

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

對業(yè)務(wù)前端同學：

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

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

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

對一個自由開發(fā)者：

未來服務(wù)器部署更彈性，更省錢。

部署速度更快，更不易出錯。

前端框架總是帶入后端思維，而 Serverless 則是把前端思維帶入了后端運維。

前端開發(fā)者其實是最早享受到 “Serverless” 好處的群體。他們不需要擁有自己的服務(wù)，甚至不需要自己的瀏覽器，就可以讓自己的 JS 代碼均勻、負載均衡的運行在每一個用戶的電腦中。

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

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

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

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

FAAS - Function as a service

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

平臺即服務(wù)，用戶只要上傳源代碼就可以自動持續(xù)集成并享受高可用服務(wù)，如果速度足夠快，可以認為是類似 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ù)，比如計算機存儲、網(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ù)，比較有名的容器編排平臺是 Kubernetes。容器技術(shù)是 Serverless 架構(gòu)實現(xiàn)的一種選擇，也是實現(xiàn)的基礎(chǔ)。

NoOps

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

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

DevOps

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

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

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

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

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

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

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

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

為了做前后端配置同步，可以將配置多帶帶托管起來前后端共用，比如新建一個配置文件，專門存儲游戲信息：

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

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

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

// 根據(jù)建筑建造時間判斷建筑狀態(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ù) （當前時間 - 上次打開時間）* 每秒產(chǎn)量得到總產(chǎn)量
      return; /**/
  }
};

// 前端 UI 層，每隔一秒調(diào)用一次 getBuildingProduction 函數(shù)，及時更新生產(chǎn)數(shù)據(jù)
// 前端入口函數(shù)
export const frontendMain = () => {
  /**/
};

// 后端 根據(jù)每次打開時間，調(diào)用一次 getBuildingProduction 函數(shù)并入庫
// 后端入口函數(shù)
export const backendMain = () => {
  /**/
};

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

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

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

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

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

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

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

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

可以本地安裝 Docker 連接本地數(shù)據(jù)庫服務(wù)，將環(huán)境打包成鏡像整體部署到服務(wù)器。

將前后端代碼分離，前端代碼在本地開發(fā)，服務(wù)端代碼在服務(wù)器開發(fā)。

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

Serverless 解決了這個問題，因為我們要上傳的只是一個代碼片段，不再需要面對服務(wù)器、系統(tǒng)環(huán)境、資源等環(huán)境問題，外部服務(wù)也有封裝好的 BAAS 體系支持。

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

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

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

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

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

成熟的 PASS 服務(wù)其實是偽 Serverless，后續(xù)該如何標準化。

FAAS 冷啟動需要重新加載代碼、動態(tài)分配資源，導致冷啟動速度很慢，除了預熱，還需要經(jīng)濟的優(yōu)化方式。

對于高并發(fā)（比如雙 11 秒殺）場景的應(yīng)用，無需容量評估是很危險的事情，但如果真能做到完全彈性化，就省去了煩惱的容量評估。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

雖然可以通過定期運行 FAAS 服務(wù)來保證程序一直 Online，但筆者認為這還是違背了 Serverless 的理念。

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

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

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

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

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

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

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

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

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

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

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

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