Serverless——前端的3.0時代

時間 2019-11-29

標籤 serverless 前端 3.0時简体版

原文原文鏈接

《信息簡史》中說「進化自己是生物體與環境之間持續不斷的信息交換的具體表現」，前端技術的進化也是如此。浩瀚的前端宇宙中，又出現過哪些耀眼的星辰呢？指引前端將來的「北極星「又在何方？騰訊雲高級工程師與你暢談前端的變革史與新時代的希冀。前端

在正文以前我想簡單介紹一下本身的從業背景。初次接觸前端是讀書期間的第一份實習工做，在 SAP 上海研究院 TIP BI 部門開發基於 SVG 的Charts 庫，99%的代碼邏輯是將數據用 SVG 轉化爲可視化的 UI。值得一提的是當時用的構建工具是 YUI Compressor 搭配 Ant 調度。

畢業後成爲了一名傳統的 web 前端開發者，期間還折騰過富本文編輯器。後來有近一年的時間研究效率工程，也就是大衆口中的前端工程化。而後在加入騰訊以前的工做是地圖，技術核心是 WebGL。web

能夠說除了音視頻之外，5 年多的經歷基本涵蓋了前端領域絕大部分的技術方向。不管是大衆的 web 仍是小衆的 SVG，不管是宏觀到 web 總體的工程化仍是微觀到像素的圖形學。表面看上去彷佛每一份新工做跟以前的工做都關聯甚微，好比在使用 WebGL 期間積累的矩陣、向量、三角剖分等數學和圖形學知識基本上在現階段工做中得不到體現。但其實從畢業到加入騰訊以前始終處於一種迷惘的狀態中，一直試圖在不一樣的工做類型中尋找真正可以體現前端工程師核心價值的方向，以及輔助這個方向的關鍵技術。數據庫

我想如今我找到了，以全棧爲進化方向的前端，以及輔助其落地的 Serverless。編程

若是要探討一項技術或者一種理念是否具備革命性，必然須要一些參照物，歷史是最佳的參考。因此在討論 Serverless 對前端的革新以前，有必要先「飛快「地回憶一下前端的變革史。windows

前端變革史

前端0.0：WWW

若是以世界上第一個 web 瀏覽器 WorldWideWeb 的誕生做爲起點，那麼 90 年代初即是前端的 0.0 時代。彼時沒有前端工程師的稱謂，前端的工做也很簡單，主要是靜態 UI 和表單驗證，要麼後端工程師兼顧爲之，要麼由獨立的 UI Developer 全權負責。

其實時至今日不少外企仍然沿襲着 UI Developer 崗位，與目前大衆認知的前端工程師不一樣的是，UI Developer 的能力棧除了 HTML/JS/CSS 之外，還要具有必定的 UI 和交互設計能力。後端

前端 1.0：AJAX

起源於 Microsoft Outlook 的 AJAX 是引發前端第一次革命的關鍵技術，這是一個重要的轉折點，以此爲契機網站具有了動態性，前端工程師的能力模型逐漸從 UI 偏向邏輯和數據。前端工程化

前端 2.0：Node.js

而後是廣爲人知的 Node.js 成就了前端 2.0。Node.js 破除了先後端編程語言的壁壘，令前端開發者可以以相對較小的成本跨界服務端，可是編程語言僅僅是服務端開發最表層也是最易突破的，背後更困難的部分是單純靠 Node.js 沒法解決的，細節稍後再表。除了服務端之外，Node.js 對前端最大的貢獻是提供了工程化的土壤。瀏覽器

在此各位不妨思考一個問題：一個構建工具最基本最底層的能力是什麼？答案是文件 IO。安全

在 Node.js 以前，HTML/JS/CSS 的構建只有兩個途徑。第一是藉助其餘編程語言的工具，好比 YUI Compressor；第二是用 IE 瀏覽器。這不是笑話，IE 瀏覽器可以在早期佔據霸主地位可不徹底是由於 windows 系統的背書，它自身的功能性也很是強大。衆所周知早期的 IE 瀏覽器是 windows 系統的一個組件，以它爲入口能夠調用一些系統級的底層功能，文件 IO 便在此列，實現的方式是藉助 ActiveX 控件的 FileSystemObject 對象。細節就不講了，感興趣的同窗能夠自行參閱相關資料。服務器

前端 2.5：React

有一些聲音認爲 React 可以配得上"革命性"一詞，由於它必定程度上改變了前端的編程模型，React 以前的前端是圍繞 DOM，React 以後是面向數據。誠然如此，但跟 AJAX 和Node.js 相比，React 引發的變革仍顯輕微。而 React 對前端組件化生態的影響也是在原有基礎上的加強也並不能稱爲革命性。因此稱 React 爲前端 3.0 缺少足夠的說服力，不過前端 2.5 仍是充分的。說到底，React 只是改變了前端領域自身，而 AJAX 和 Node.js 無一不是對先後端都有顯著影響的技術。

Serverless-從前端到全棧

在討論哪項技術或理念會成就前端 3.0 以前，必需要確認前端下一步的發展方向。

目前有兩種聲音：一是先後端包攬的「大前端」，也就是全棧，關鍵性技術是 Node.js；二是以 React-Native 和 Flutter 爲突破點的「泛前端」，即全端。

以目前的時間節點來看，React-Native 也好，Flutter 也罷，都還未可以稱得上成熟，泛前端之路任重道遠。相對來講，前端下一步發展爲全棧的可能性更高一些。基於這個前提，Serverless 即是成就此道的革命性技術理念。

「全棧」這個詞其實一直存在歧義，狹義上的全棧來源於前端技術圈，指的是一我的包攬前端和 web 服務端；而廣義上的全棧應該是在先後端之外還包括數據庫而且可以精通圍繞三者展開的架構和技術細節，這是幾乎不可能的任務，若是真的有人可以達到這種境界，估計就是接近艾倫·圖靈通常的計算機之神了吧。在狹義與廣義之間，Serverless 面向的是廣義的全棧。Serverless 的理念是將服務器管理、數據庫優化等「粗活」交給雲平臺，從而前端開發者可以將交互邏輯、業務邏輯、數據所有掌控在本身手中，這纔是真正意義上的全棧。

爲了可以更清晰地理解 Serverless，有一種架構模式能夠做爲對比，即 BFF（Backends for Frontend，爲前端服務的後端）。

BFF-從平臺無關性到平臺差別化

BFF 簡單來講就是在原有的一體化服務端基礎上，針對不一樣的業務平臺分別開發一層獨有的、很薄的服務，見下圖。

BFF承擔了一部分的業務邏輯，這部分邏輯一般是平臺獨有的。舉一個現實中的例子：在線視頻提供商有多種平臺，好比網站、app。因爲版權限制有些影片只能在特定的平臺播放。具化到技術層面，實現此類邏輯包含分平臺鑑權、數據查詢策略等等，這些即是典型的平臺差別化業務邏輯。獨立於核心業務邏輯以外的BFF層可以實現差別化邏輯的鬆耦合，進而令迭代和維護更高效和安全。

BFF未解決的問題

目前業內對BFF廣泛實踐模式是將BFF分發到負責各平臺技術開發的團隊，好比App團隊負責Mobile BFF、前端團隊負責PC web和H5 BFF等等。那麼對於前端工程師來講，這種模式是否意味着前端兼顧BFF層？理想的場景是這樣的，但現實工做中並不是如此。

BFF 本質上仍然是服務層，除了編程語言以外，一名合格的服務端開發者還須要具有一些獨有的領域知識以及服務管理、數據管理理念。因此目前大多數BFF仍然由傳統前端以外的專人負責，即使是 Node.js BFF。

也就是說，BFF 並未解決前端成爲全棧的關鍵性問題，而這些問題即是 Serverless 的針對點。

騰訊雲雲開發對Serverless的落地實踐

目前業內對於 Serverless 的廣泛認知是 FaaS（Function as a service，函數即服務）和BaaS（Backend as a service，後端即服務）的綜合體。以此爲前提，騰訊雲的相關團隊將 Serverless 的具體實現爲下圖所示的模型。

以此爲支撐，落地到具體應用場景中的雲開發模式以下圖：

各平臺應用的前端集成對應的 SDK，涵蓋雲函數、雲數據庫和雲存儲的功能調用 API。前端的請求直接送達雲平臺的接入層，目前是以 Node.js 做爲接入層技術棧；而後通過必要的處理（好比用戶鑑權）轉至雲函數、雲數據庫以及雲存儲平臺。

以雲開發體系提供的功能和服務爲基礎支撐，前端開發者的關注點除了 UI 和交互邏輯之外，可以以很小的成本介入以雲函數爲承載的業務邏輯層和以雲數據庫、雲存儲爲支撐的數據存儲層。簡而言之，前端的關注點爲：交互邏輯+業務邏輯（雲函數）+數據（雲數據庫/雲存儲）。

從上文的描述中可能有部分同窗意識到一個問題： 雲存儲跟CDN有什麼區別？

雲存儲提供文件託管服務，本質上與 CDN 相同。其優點體如今開發者無需申請域名、無需管理服務器，文件被自動託管，而且能夠經過鑑權機制保證文件的私密性和安全性。其實針對 CDN的話題能夠延伸到 Serverless，大多數前端開發者在工做中都無需關係CDN服務器的狀態，只須要部署文件便可（甚至這一步也能夠由CI系統完成），那麼CDN對於前端開發者來講就能夠被認爲是 Serverless 的。

完整的 Serverless 體系不只僅包括 CDN，還能夠把數據庫和服務端也實現 Serverless。在這套體系支撐下的工程模型中，一個完整的迭代週期僅僅須要兩種職能角色：前端和測試。前端負責全部與業務相關的工做，包括交互層、業務層和數據層；測試負責質量保證；而部署、發佈、服務器管理、線上監控等等繁瑣的工做交由雲開發平臺去完成。

開發生態

在以上雲開發模式基礎上，具體到現實上手開發，開發者們須要瞭解三種角色：端、雲和 控制檯。

端的表現形式是對應各平臺的 SDK，是與前端開發者關係最緊密的一個角色；
雲指的是支撐 Serverless 體系的後臺系統，這部分對於開發者來講是無感知的，與其對接的工做由端SDK承擔。細化到子角色能夠分爲接入層和基礎服務，接入層負責代理轉發和用戶鑑權等工做；基礎服務提供基本的能力支撐，包括雲函數、雲數據庫和雲存儲；
控制檯的功能分爲兩大類：一是管理功能，好比雲函數的部署、數據和文件的管理等等；二是運營，控制檯提供產品線上監控以及數據的統計和可視化，以輔助運營。