Serverless，將給前端發展帶來大變革的技術？

| 引言本文將從前端的角度來看Serverless究竟是什麼，Serverless的出現會給前端帶來什麼樣的機遇和挑戰，並以一個具體的項目為例說明如何基於Serverless實現項目功能。

前端開發的橫向演進

在剛開始的互聯網時代，網頁很簡單，就是一些靜態或簡單動態的頁面，主要是用來做信息的展示和傳播。開發一個網頁主要就是通過 JSP、PHP 等技術寫一些動態模板。這個階段還沒有前後端的分工，通常是後端工程師順便寫了前端頁面。

在AJAX 技術出現之後，可以把Web 分為前端和後端，前端負責界面和交互，後端負責業務邏輯的處理。前後端通過介面進行數據交互。隨著頁面越來越複雜，移動網路的應用的興起，對載入性能有了更多的要求，通常非同步渲染頁面白屏時間比較長，另一方面對SEO也不夠友好，所以落地頁又回歸到服務端渲染的這個方案。

前端在發展，後端也在發展，在分層和模塊劃分上更加的粒度化，微服務化。微服務的介面不再是面向頁面，前端的介面調用變得複雜了，所以需要在微服務和前端中間，加了一個 BFF 層，全稱（backend for frontend），由這一層對介面進行聚合、裁剪後，再輸出給前端。而這層不是後端本質工作，距離前端比較近，關係更大一些，所以前端工程師很自然選擇了 Node.js 來實現。這也是當前 Node.js 在服務端比較廣泛的應用。

可以看到，每一次前端開發模式的變化，都因為某個變革性技術的出現。先是 AJAX，然後是 Node.js。

那麼下一個變革性的技術是什麼？

不言而喻，就是 Serverless。

前端工程師也能開發後端嗎？

但是，如果完全讓前端工程師來開發一個後端，需要考慮很多內容。

首先要考慮代碼運行的環境和相關資源。

比如前端代碼運行的環境是用戶的瀏覽器。

後端環境需要伺服器，網路，訪問服務的域名、證書，伺服器的操作系統，軟體安裝，WebServer，資料庫等。

除此之外，前端要考慮的是用戶的網路，瀏覽器的兼容性，交互的流暢程度，還有視覺效果。

後端還要考慮負載均衡，流量控制，彈性伸縮，高並發，備份容災，安全防護，監控警告等。

前端並不擅長這些，但有了Serverless之後，這些我們基本上不用考慮，我們的主要精力可以用來實現業務邏輯。

那麼，Serverless為什麼能幫助做這些事情？

如下圖所示，FaaS BaaS可以稱之為一個完整的Serverless，FaaS（Function as a Service） 是函數運行的平台。BaaS（Backend as a Service）則是一些後端雲服務，比如雲資料庫、對象存儲、消息隊列等，通過使用BaaS，可以極大簡化應用開發難度。開發者將代碼上傳到雲函數平台，並配置相關的觸發器。平台根據觸發器事件，完成運行環境的準備、調度、執行和擴容這些工作。

從架構上，可以看到Serverless 的這些特點：

無運維，使用 Serverless 我們不需要關心伺服器，不需要關心運維，這也是 Serverless 思想的核心。

無狀態，因為每次函數執行，可能使用的都是不同的容器，無法進行內存或數據共享。

如果要共享數據，則只能通過Redis 、COS等第三方服務。

事件驅動，函數在 FaaS 平台中，是需要通過事件來觸發函數執行。

低成本，實現按需調用，按需伸縮、按使用收費。

基於Serverless的前端開發模式

01BFF

基於Serverless，前端的一些通用開發模式可以怎麼來做呢？下圖是比較通用的BFF架構。最底層是後端微服務，最上層是前端應用，在微服務和應用之間，是通常由前端工程師開發的 BFF層，對介面進行聚合裁剪，在返回給前端使用 。

這樣的架構解決了介面協調的問題，但也帶來了一些新的問題。以前前端只需要關注瀏覽器端的渲染，現在卻需要維護各種 BFF 應用以及運維，但是通常前端並不擅長運維。Serverless的出現可以很好的解決這些問題。基於 Serverless，可以使用雲函數來實現BFF層，只需要關注業務邏輯，運維的工作交給了Serverless平台。

上圖中的APIGateway代替了我們的Nginx代理伺服器，以前可能是將轉發規則寫在代理伺服器的配置文件中，現在在API網關中有了可視化的管理、可監控、可設置版本等等更多更易用的功能。

02SSR

傳統的服務端渲染，服務端根據路由返回渲染好的HTML頁面。而在Serverless上實現也類似，可以將多個頁面返回放到一個函數中，也可以將每個頁面拆分成一個個雲函數，這樣用戶請求的一個頁面，對應的就是每個單獨的函數。

03小程序

目前國內使用 Serverless 較多的場景可能就是小程序開發了。在傳統的小程序開發中，需要前端工程師進行小程序端的開發；後端工程師進行服務端的開發。小程序的後端開發和其他的後端應用開發，本質是是一樣的，需要關心應用的負載均衡、彈性伸縮，備份冗災、監控報警等等運維操作。

但基於雲開發，開發者只需要關注於業務的實現，由一個前端工程師就能夠完成整個應用的前後端開發。應用的運維轉移到了雲平台上。

04後端思維

前端工程師去基於Serverless去寫後端，最好也要具備一定的後端知識。涉及複雜的後端或者Serverless不適用的場景，還是需要後端去開發，只不過後端變得更加靠後。簡單說說前後端開發異同之處。

（1）共性思維，就是前端後端都通用的。

第一個工程化，分層模式，前端的工程化現在也相當的成熟，視圖和數據分離，組件和頁面的組裝，而後端最基本的一個分層模式就是DAO層，業務模塊層，介面層。

可用性：

監控一切。

這個大家都比較好理解，服務端監控包括：

介面，各種服務，機器的性能等等

高性能：

和前端有各種緩存技術方案一樣，在後端如果要提升性能，一樣需要利用緩存，理論上每個層級都可以緩存，從資料庫到Redis，內存，從元數據到渲染好的頁面，但緩存越多，系統複雜度也越高，需要根據需求成本來平衡方案取捨。

（2）安全意識。

防別人對付用戶 ：

設置 CSRF Token

防用戶對付系統：

參數校驗、許可權檢查、防SQL注入

防系統對付自己：

提交防重/頻率控制

（3）並發意識。服務端和前端主要不同的點是，服務端同時服務所有用戶，需要有並發的意識。

資源多級隔離：

防止一個有問題導致系統雪崩。

共享數據加鎖：

比如有限數量的商品多人同時下單的場景。

任務隊列緩存：

將高並發放到任務隊列中，減緩並發高峰，讓高並發變得更為可控一些。

如何基於Serverless進行項目開發

程序受眾廣易傳播，開發成本低，效果好等特點，非常適合老產品拉新/創新，新產品快速嘗試。這裡以一個背單詞小程序為例。

01項目需求

這個項目的核心需求是學習單詞，記錄學習情況，學習單詞又包含看單詞，聽單詞發音，讀單詞，系統對用戶發音進行評分，還有檢驗。

基於Serverless的技術方案如下，可以看到有登陸模塊，通過雲函數，調用微信的API進行登錄校驗。語音合成和口語評測這兩個功能，騰訊雲就有這兩個服務，可以直接調用，需要做的僅僅是通過雲函數進行鑒權中轉。學習記錄這部分，就結合函數邏輯和雲資料庫來完成。可以看到項目的完整層級架構，是非常清晰簡單的。

一個項目的完整開發流程包括設計/開發、調試、測試、上線、監控/運維，下面展開說一下基於Severless每個階段具體是怎樣做的。

02設計/開發

以下是一個基於Serverless的Web應用通用架構。

主要有三部分：

1.靜態資源存放

靜態資源（JS/CSS/IMG/HTML）放在COS（對象存儲），COS可以自定義域名和開啟CDN加速，通過URL直接訪問。

模板文件和數據文件放在COS，函數通過COS SDK可以很方便的對文件進行讀寫。

2.數據存儲使用

由於Serverless的特點是事件觸發，用完釋放。那麼需要考慮本地存儲和緩存必須依賴於第三方服務如COS（對象存儲）和Redis。不過函數實例本身會有延遲釋放的時間，便於在新請求來的時候可以復用，可以利用本地緩存作為第一級緩存。

DB/Redis的連接訪問和原來一樣，在雲平台申請相關存儲資源，設置和雲函數相同的虛擬子網，雲函數就可以通過內網地址進行資源訪問，保證了數據服務和外網的安全隔離。騰訊雲資料庫提供了全套運維解決方案，大大簡化了運維工作。

3.應用邏輯實現

傳統架構上請求是由Nginx代理轉發到相關NodeServer上去處理，而Serverless是請求到了API網關再轉發到雲函數上處理。原來的轉發內容是HTTP請求，雲函數上接收的是API網關事件。為了應對這種變化，可以在代碼中直接去解析使用API 網關事件。但如果已經很習慣express的開發框架，而且很依賴一些好用的中間件，如果需要重建這部分中間件，這會是不小工作量。

那有沒有方案兼容原來的寫法？可以將API網關事件轉換成HTTP請求，通過本地Socket和函數NodeServer進行通信。

但這樣中間經過了一層的轉發，性能會不會有所損耗呢？在耗時統計來看，有了這一層轉發，雲函數平均耗時也在20ms之內，中間即使有性能損耗也在毫秒級別的了，相對於網路耗時來說，就是小巫見大巫了。

所以非必要的情況下，無論是遷移還是新開發的Web項目其實都可以採用這個方案：

中間轉發代理層已經有一些可用的框架（serverlessplus, scf-framework）。

03調試

接下來看一下怎麼調試雲函數。

第一種，通過命令行可以很方便的將代碼發布到雲函數平台上，支持雲上調試

第二種，對於複雜一點的應用，可以使用SCF命令行工具在本地環境進行調試。

第三種，我們前端可能比較習慣在瀏覽器中直接刷url來調試，如果項目是基於koa或者express之類的框架，可以直接增加一個server的入口，調試的時候就直接本地起一個nodeserver來調試。

但是目前發布到雲函數是要包含node_modules文件夾的，壓縮之後，需要通過網路傳輸上去。如果改一行代碼，就要上傳一次來執行，這樣比較複雜，而且在線的IDE也是只能編輯入口文件的，但是代碼都不是寫在入口文件那的，升級IDE需求也在規劃開發中。

如果在本地調試，需要提前安裝SCF CLI命令行工具、docker，這個運行方式的原理是，載入一個和雲函數環境相同的一個鏡像，然後在docker中去執行。然而還是會遇到一些問題：

比如連接的資料庫需要是外網地址，因為docker的網路環境和本地並不能連通，與雲上的環境也不能連通。

還有，比如我在本地安裝的npm包，也不能正常執行，因為本地開發環境是mac系統，而鏡像是linux系統。

SCF CLI本地命令行工具，可以支持native調試，就是用本地的環境進行調試。這樣就解決了資料庫連通問題，以及調試時操作系統差異問題。（那麼系統差異的問題只能是需要一個專門的編譯機了，一般情況下，如果依賴的npm庫如果不涉及到操作系統差異的話，npm包都是可以通用的。）

如果項目是基於koa或者express之類的框架，可以直接增加一個server的入口，調試的時候就直接本地起一個server，和普通node server一樣的進行調試。

04測試/上線/迭代

前面說到用命令行工具很方便的將代碼發布到雲函數平台上。還需要測試、上線與回滾。雲函數本身有發版本功能。API網關也默認有測試、預發布、發布3個環境，每個環境可以指定雲函數的版本。這樣看起來就可以將測試和線上的環境區分開。

但是，測試和線上連接的資源是不一樣的，比如DB，我們通常是通過讀取環境變數來判斷是測試環境還是線上環境，但是一個雲函數只有一個配置。

騰訊雲函數還提供了命名空間、函數複製這樣的功能。利用這些功能可以：

測試和線上放在兩個不同到命名空間，隔離測試和線上代碼，更加安全；

測試和線上環境通過函數配置不同的環境變數來區分；

上線通過複製函數來完成，選擇不複製配置；

回滾通過API網關切換函數版本來完成。

這樣就可以滿足我們的測試部署、上線部署，回滾的需求了。

05運維/告警/監控

在Serverless下，運維需要做哪些呢？負載均衡，流量控制，擴縮容，高並發，安全防護這些都由雲函數平台做了。另外雲函數接入了雲監控，在雲監控我們可以自定義統計視圖，配置告警閾值和告警方式，還可以上報自定義的監控點。

至此，從開發到調試，從部署到運維，一個項目的完整開發流程都已經完成了。

結 語

最後，談一下對雲函數的展望，現在使用HTTP協議時，需要通過API GATEWAY中轉一層，能不能去掉這一層中轉？如果業務應用比較複雜，需要拆成多個雲函數來承載，對於這樣的現有項目能否0改造遷移？現在部署雲函數的時候，需要將lib庫也打包上傳，未來希望能和代碼倉庫打通，在git push的時候，能夠在線編譯，並且自動部署。

開發者所想，也是服務商所想，這些功能騰訊雲都正在開發中，近期將會發布，敬請期待！

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！