Serverless For Frontend 前世今生
轉自：天豬
https://www.yuque.com/egg/nodejs/sff-history
作為一個前端，你可能一直在迷茫，Node.js 的定位是什麼？為什麼我們需要它？
尤其是到了 2019 這個時間點，未來一段時間內，有一個詞 — Serverless 你會聽到想吐。
所有人都在說 Serverless
幾乎沒有人知道如何落地 Serverless
但大家都覺得其他人在大力做 Serverless
所以大家都在宣傳自己在做 Serverless
阿里作為 Node.js 國內的引航者，在該領域深度實踐多年。
在國內第一個引入 BFF 的概念，現在也是第一個提出 SFF（Serverless For Frontend）。
筆者過去幾年有幸參與到該演化進程中，在此分享給大家一些心得，拋磚引玉。
演進史
鑒古知今，以史明鑒。
我們從哪裡來，經過哪裡，要去到哪裡。
遠古時代
天地初開，還沒有出現前後端之分，僅有 設計 和 研發 兩種角色：
設計師根據需求產出高保真的原型圖。
研髮根據需求和原型圖來編寫對應的業務邏輯和頁面。
在 Web 1.0 的時代，大部分的 B/S 系統都採用的是 集中式架構，分為標準的三層（MVC）：
數據訪問層：封裝對資料庫的訪問。
服務層：用於業務邏輯的處理。
Web 層：用戶處理頁面渲染，路由邏輯等等。
比較流行的是 Struts Spring Hibernate 框架，還有 Dreamweaver 等前端三劍客。
此時的業務開發的套路，基本上是：
從資料庫查詢到一段動態數據。
套到模板上，渲染出頁面。
再加上幾個靜態資源（JS/CSS）去實現交互。
此時的主要矛盾在於：如何把那些有像素眼的 『美工』的天馬行空的點子，高還原度的實現出來。
石器時代
然而藝術和代碼之間的 Gap，對於很多缺乏藝術細胞的直男程序猿來說，是一件非常頭疼的事。如何更好的提升用戶交互體驗，如何像素級的還原設計稿，都需要更高專業度的投入。
同時，由於互聯網的迅猛增長，集中式架構已經逐漸無法滿足海量的訪問，從而演進出 分散式架構 ，對研發的能力要求也進一步提升。
因此基於專業度的訴求，逐漸分化出 前端研發 和 後端研發 的角色：
前端此時更偏向設計，很多都是懂點研發的設計師承擔。
後端則更深入到業務建模，系統運維等方面。
此時的業務開發的套路，變為：
前端研發 根據原型圖，切圖，產出 HTML/CSS/JS ，交付給 後端研發。
後端研發 把 CSS/JS 上傳 CDN，然後把 HTML 手動改寫為後端模板。
從資料庫查詢到一段動態數據。
套到模板上，渲染出頁面。
此時的主要矛盾在於前後端耦合 ：
前端同學交付 HTML 頁面，被後端改寫為 TPL 模板。
如果需求變更，從而導致 HTML 修改後，後端再次套模板的時候，merge 起來會比較考眼力。
如果模板渲染有問題，往往是前端跑到後端的電腦上直接修改模板來調試，然後還需要同步回去自己的 HTML。
青銅器時代
隨著 Web 2.0 的到來，以 Google 推出的 Gmail 為號角，前端進入富應用時代，各種框架層出不窮，從 AJAX jQuery，到逐漸形成 Angular、React、Vue 三國鼎立。
此時的業務開發的套路，變為 前後端分離：
後端提供 API 介面，把 領域模型 轉換為 數據傳輸對象，並通過 HTTP 對外服務。
前端通過 AJAX 調用對應的介面，接管模板層，直接在瀏覽器側渲染，也稱之為前端渲染。
前後端分離 一定程度上解決前後端的耦合問題，約定好介面後，前端可以直接 Mock 然後進行開發。
前端第一次翻身，如火如荼的投入到 前端框架 和 前端工程化 的建設中，矛盾在一定程度上弱化了。
蒸汽時代
隨著後端 微服務化 的演進，開始走向深水區，服務下沉，趨向穩定，業務被劃分為很多獨立的微服務。
前端框架 和 前端工程化 趨向穩定，同時前端也進入了移動時代，出現了跨平台、跨終端適配的場景，對用戶體驗提出的更高的要求，對首屏時間等性能指標越來越重視，且發布頻度越來越快。
此時的架構演化為：
後端分為很多微服務。
前端還是通過 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 等降低後端同學的上手成本。
電氣時代
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 化：讓應用能利用雲平台實現資源的按需分配和彈性伸縮，從而減少資源浪費。
自動化運維：DevOps noops，減少研發對基礎措施和運維的關注，交給我們這些專業的框架維護者。
一句話闡述：讓純前端開發者，只需寫幾個 Function 即可使用到後端相關的能力。
此時的研發角色劃分，似乎又兜兜轉轉回到最初，但其實歷史是螺旋上升的，表象一樣，內在已然不同。
目前該演進正在進行中，更多分享敬請期待。
小結
鑒古知今，我們一直在前行，與君共勉。
未來已來，與其耳聽八方，不如眼見為實，一起參與進來把生米煮成熟飯。
※徹底理解cookie、session、token
※Firefox和Chrome拼性能，結果……
TAG:JavaScript |