前言

作為一個前端，你可能一直在迷茫，Node.js 的定位是什麼？為什麼我們需要它？

尤其是到了 2019 這個時間點，未來一段時間內，有一個詞 —— Serverless 你會聽到想吐。

“所有人都在說 Serverless ”

“幾乎沒有人知道如何落地 Serverless 但大家都覺得其他人在大力做 Serverless ，所以大家都在宣傳自己在做 Serverless “

阿里作為 Node.js 國內的引航者，在該領域深度實踐多年。

在國內第一個引入 BFF 的概念，現在也是第一個提出 SFF（Serverless For Frontend）。

筆者過去幾年有幸參與到該演化程式中，在此分享給大家一些心得，拋磚引玉。

演進史

鑑古知今，以史明鑑。我們從哪裡來，經過哪裡，要去到哪裡。

1.遠古時代
天地初開，還沒有出現前後端之分，僅有 設計 和 研發 兩種角色：

• 設計師根據需求產出高保真的原型圖。
• 研發根據需求和原型圖來編寫對應的業務邏輯和頁面。

在 Web 1.0 的時代，大部分的 B/S 系統都採用的是 集中式架構，分為標準的三層（MVC）：

• 資料訪問層：封裝對資料庫的訪問。
• 服務層：用於業務邏輯的處理。
• Web 層：使用者處理頁面渲染，路由邏輯等等。

比較流行的是 Struts + Spring + Hibernate 框架，還有 Dreamweaver 等前端三劍客。

此時的業務開發的套路，基本上是：

1.從資料庫查詢到一段動態資料。
2.套到模板上，渲染出頁面。
3.再加上幾個靜態資源（JS/CSS）去實現互動。

此時的主要矛盾在於：如何把那些有畫素眼的 『美工』的天馬行空的點子，高還原度的實現出來。

2.石器時代
然而藝術和程式碼之間的 Gap，對於很多缺乏藝術細胞的直男程式猿來說，是一件非常頭疼的事。如何更好的提升使用者互動體驗，如何畫素級的還原設計稿，都需要更高專業度的投入。

同時，由於網際網路的迅猛增長，集中式架構已經逐漸無法滿足海量的訪問，從而演進出 分散式架構 ，對研發的能力要求也進一步提升。

因此基於專業度的訴求，逐漸分化出 前端研發 和 後端研發 的角色：

• 前端此時更偏向設計，很多都是懂點研發的設計師承擔。
• 後端則更深入到業務建模，系統運維等方面。

此時的業務開發的套路，變為：

1.前端研發 根據原型圖，切圖，產出 HTML/CSS/JS ，交付給 後端研發。
2.後端研發 把 CSS/JS 上傳 CDN，然後把 HTML 手動改寫為後端模板。
3.從資料庫查詢到一段動態資料。
4.套到模板上，渲染出頁面。

此時的主要矛盾在於 前後端耦合 ：

• 前端同學交付 HTML 頁面，被後端改寫為 TPL 模板。
• 如果需求變更，從而導致 HTML 修改後，後端再次套模板的時候，merge 起來會比較考眼力。
• 如果模板渲染有問題，往往是前端跑到後端的電腦上直接修改模板來除錯，然後還需要同步回去自己的 HTML。

3.青銅器時代
隨著 Web 2.0 的到來，以 Google 推出的 Gmail 為號角，前端進入富應用時代，各種框架層出不窮，從 AJAX + jQuery，到逐漸形成 Angular、React、Vue 三國鼎立。

此時的業務開發的套路，變為 前後端分離：

• 後端提供 API 介面，把 領域模型 轉換為 資料傳輸物件，並通過 HTTP 對外服務。
• 前端通過 AJAX 呼叫對應的介面，接管模板層，直接在瀏覽器側渲染，也稱之為前端渲染。

前後端分離 一定程度上解決前後端的耦合問題，約定好介面後，前端可以直接 Mock 然後進行開發。

前端第一次翻身，如火如荼的投入到 前端框架 和 前端工程化 的建設中，矛盾在一定程度上弱化了。

4.蒸汽時代
隨著後端 微服務化 的演進，開始走向深水區，服務下沉，趨向穩定，業務被劃分為很多獨立的微服務。

前端框架 和 前端工程化 趨向穩定，同時前端也進入了移動時代，出現了跨平臺、跨終端適配的場景，對使用者體驗提出的更高的要求，對首屏時間等效能指標越來越重視，且釋出頻度越來越快。

此時的架構演化為：

• 後端分為很多微服務。
• 前端還是通過 HTTP 訪問後端，但介面變多了，效能變低，且帶來安全問題。
• 後端會提供一層 API 粘合層來緩解。

隨之而來的新的矛盾：服務下沉與使用者體驗靈活性的矛盾。

• 服務趨向穩定，傾向下沉。
• 使用者體驗趨向不穩定，訴求服務的高度靈活與定製。
• 不同裝置對 API 有不同的訴求，需要裁剪。
• 服務端介面，究竟是面向 UI 還是通用服務？

此時 Sam Newman 提出了 Backends For Frontends ：

• 簡稱之為 BFF，最重要的是：服務自治 ，誰使用誰開發，帶來了靈活與高效。
• BFF 根據團隊的技術棧來選型，在我們的業務場景中，相對較優，生態最活躍，最能被前端接受的 Node.js。
• BFF 層一直都存在，因為 領域模型 - UI 模型 的轉換是必然會存在的，區別只是在於維護者是誰。
• GraphQL 之類的閘道器可以視為通用型的 BFF。

此時，研發角色又轉變為：

• 後端研發，專注於業務建模，維護中介軟體服務和業務微服務。
• 全棧研發，專注於處理 Web 層，比模板層更進一步，接管 BFF 層。

其中全棧研發又有兩種來源：

• 從前端進化過來的，一般會選擇 Node.js 作為技術棧，使用諸如 Egg 等框架來降低前端同學的上手成本。
• 前端資源嚴重不足，於是賦能後端，助其轉變為全棧，使用 Ant Design、Umi 等降低後端同學的上手成本。

5.電氣時代
BFF 的實踐，在社群的分化嚴重，在大公司和創業公司比較受歡迎，但在話語權不強的中型公司，則舉步維艱。

• 小創業公司 - 追求快狠準，先活下來再說，效率優先，幹就是了。
• 大公司 - 具備良好的基建和研發流程支撐，對效能有更高的追求，如荼如火。
• 中型公司 - 前端話語權不強，百廢待興，現有基建對前端不友好，推行舉步維艱。

作為國內前端的引航者，過去幾年，我們螞蟻體驗技術部工程產品的同學，產出了很多效能產品，包括：

• Basement 前端工作臺 - 打造更適合前端場景的工作流，管控研發流程和質量。
• 雲鳳蝶 - 視覺化建站，提升非前端專業同學在站點搭建方面的效能。
• DockerLab - 輕運維，支援快速創新，讓 idea 閃現到服務更加便捷。
• Egg - 企業級的 Node.js 框架，掃清後端框架、中介軟體生態接入方面的障礙。
• Ant Design - 企業級的中後臺前端框架，讓中後臺產品 default to good.

但這些大部分還侷限在 Pro Code 領域，離我們願景中的終局還有很長的路要走。

此時的主要矛盾在於：

• 專業人才儲備
遠遠低估了前端的缺人程度，一將難求，無人可招。
全棧人才的培養成本不低，包括前端需要學習後端 DevOps，後端需要學習前端的使用者互動。

• 基建牆，各種流程太重
不同的基建服務需要去不同的後臺走申請流程，N 多個工單需等待審批。
像 DRM 的配置、Mobilegw 的配置，需要在每種環境中單獨配置一遍。

• 資源浪費
在 BFF 場景下，伺服器水位較低（10% ~ 30%），基於微服務的高可用訴求導致了伺服器資源的浪費。
譬如在螞蟻容災要求下，至少需要 11 臺 4C8G 的容器。據此估算，支撐內部上千箇中臺應用，則就至少需要約 2000 臺 32 核物理機！！！

幸而阿里開始吹響了 雲通未來 的號角，各集團軍協同作戰，讓我們能借助兄弟團隊的協作，向未來邁進一大步，參與到『雲通未來』的子戰場。。

就如前言提到的，每個人對 Serverless 的定義和落地的理解都不一樣。

我們依舊聚焦於一直以來的目標 — 提升前端的研發效能，以一當百。

其中 BFF 這個細分領域，我們將依託 Serverless 繼續探索，簡稱為 SFF。

我們的思路如下：專業的人做專業的事，讓業務開發者專注於業務本身的研發。

• 場景化：根據不同業務場景做垂直領域定製，減少不必要的干擾，專注於業務邏輯的開發。
• 輕流程化：打破基建牆，一站式的接入三方服務，減少各種不必要的流程和工單，以程式碼為中心，宣告即接入。
• Serverless 化：讓應用能利用雲平臺實現資源的按需分配和彈性伸縮，從而減少資源浪費。
• 自動化運維：DevOps → noops，減少研發對基礎措施和運維的關注，交給我們這些專業的框架維護者。

一句話闡述：讓純前端開發者，只需寫幾個 Function 即可使用到後端相關的能力。

此時的研發角色劃分，似乎又兜兜轉轉回到最初，但其實歷史是螺旋上升的，表象一樣，內在已然不同。

目前該演進正在進行中，更多分享敬請期待。

小結

鑑古知今，我們一直在前行，與君共勉。

未來已來，與其耳聽八方，不如眼見為實，一起參與進來把生米煮成熟飯。

螞蟻金服 Serverless 應用服務（https://tech.antfin.com/produ...）於近期開始正式內測，進入產品主頁，及時瞭解最新動態。