前言

最近關於 Serverless 的討論越來越多。看似與前端關係不大的 Serverless，其實早已和前端有了頗深淵源，並且將掀起新的前端技術變革。此次分享根據個人理解和總結，從前端開發模式在serverless的演進、Serverless 常見服務商提供的解決方案以及基於Serverless 的前端開發模式等方面，與大家探討 Serverless 中的前端開發模式。

一、前端開發模式的演進

首先回顧一下前端開發模式的演進，我覺得主要有四個階段。。

1、基於模板渲染的動態頁面
2、基於 AJAX 的前後端分離
3、基於 Node.js 的前端工程化
4、基於 Node.js 的全棧開發

基於模板渲染的動態頁面

在早起的互聯網時代，我們的網頁很簡單，就是一些靜態或動態的頁面，主要目的是用來做信息的展示和傳播。這個時候開發一個網頁也很easy，主要就是通過 JSP、PHP 等技術寫一些動態模板，然後通過 Web Server（nginx，apache）將模板解析成一個個 HTML 文件，瀏覽器只負責渲染這些 HTML 文件。這個階段還沒有前後端的分工，通常是後端工程師順便寫了前端頁面。

JSP: Java Server Page: Java服務端頁面，在html頁面中編寫Java代碼的頁面
WebServer：網站服務器或web服務器

基於 AJAX 的前後端分離

2005 年 AJAX 技術的正式提出，翻開了 Web 開發的新篇章。基於 AJAX，我們可以把 Web 分為前端和後端，前端負責界面和交互，後端負責業務邏輯的處理。前後端通過接口進行數據交互。我們也不再需要在各個後端語言裡面寫著難以維護的 HTML。網頁的複雜度也由後端的 Web Server 轉向了瀏覽器端的 JavaScript。也正因如此，開始有了前端這個職位。

基於 Node.js 的前端工程化

2009年 Node.js 的出現，對於前端來說，也是一個歷史性的時刻。隨著 Node.js 一同出現的還有 CommonJS 規範和 npm 包管理機制。隨後也出現了 Grunt、Gulp、Webpack 等一系列基於 Node.js 的前端開發構建工具。

在 2013 年前後，前端三大框架 React.js/Angular/Vue.js 相繼發佈第一個版本。我們可以從以往基於一個個頁面的開發，變為基於一個個組件進行開發。開發完成後使用 webpack 等工具進行打包構建，並通過基於 Node.js 實現的命令行工具將構建結果發佈上線。前端開發開始變得規範化、標準化、工程化。

基於 Node.js 的全棧開發

Node.js 對前端的重要意義還有，以往只能運行在瀏覽器中的 js 也可以運行在服務器上，前端可以用自己最熟悉的語言來寫服務端的代碼。於是前端開始使用 Node.js 做全棧開發，開始由前端向全棧的方向轉變。這是前端主動突破自己的邊界。
另一方面，前端在發展，後端也在發展。也差不多在 Node.js 誕生那個時代，後端普遍開始由巨石應用模式向微服務架構轉變。這也就導致以往的前後端分工出現了分歧。隨著微服務架構的興起，後端的接口漸漸變得原子性，微服務的接口也不再直接面向頁面，前端的調用變得複雜了。於是 BFF（Backend For Frontend）架構出現了，在微服務和前端中間，加了一個 BFF 層，由 BFF 對接口進行聚合、裁剪後，再輸出給前端。而 BFF 這層不是後端本質工作，且和前端的關係最大，所以前端自然而然選擇了 Node.js 來實現。這也是當前 Node.js 在服務端較為廣泛的應用的原因。

巨石應用：大部分web工程是將所有的功能模塊(service side)打包到一起並放在一個web容器中運行，很多企業的Java應用程序打包為war包

微服務架構：微服務架構是一種架構理念，是指將功能分解到離散的各個服務當中，從而降低系統的耦合性，並提供更加靈活的服務支持。把一個大型的單體應用程序和服務拆分為數個或數十個的微小型服務，它可擴展單個組件而不是整個的應用程序堆棧，從而滿足服務等級協議。

下一代前端開發模式

說完了這幾個階段，可以看到，每一次前端開發模式的變化，都因某個變革性的技術而起。先是 AJAX，而後是 Node.js。那麼下一個變革性的技術是什麼？不言而喻，個人覺得就是 Serverless。

什麼是serverless

CNCF，全稱Cloud Native Computing Foundation（雲原生計算基金會），成立於 2015 年7月21日（於美國波特蘭OSCON 2015上宣佈），其最初的口號是堅持和整合開源技術來讓編排容器作為微服務架構的一部分，其作為致力於雲原生應用推廣和普及的一支重要力量，不論您是雲原生應用的開發者、管理者還是研究人員都有必要了解。

目前行業可能更多處在容器 Docker+Kubernetes, 利用
IaaS、PaaS和SaaS 來快速搭建部署應用

基礎架構即服務（Infrastructure as a Service，IaaS）、平臺即服務（Platform as a Service，PaaS）以及軟件即服務（Software as a Service，SaaS）。

Docker是一個平臺，它主要是提供一些服務，任何一臺裝有docker的機器你都可以建立、發佈、運行你的應用程序，使用docker很省錢省時。

簡單的介紹Kubernetes。它就是一套成熟的商用服務編排解決方案。Kubernetes定位在Paas層，重點解決了微服務大規模部署時的服務編排問題。

其實 Serverless 早已和前端產生了聯繫，只是我們可能沒有感知。

1、CDN: 相信大家都使用過 CDN，我們開發完成之後，直接將靜態文件部署到 CDN 上，通過 CDN 進行內容分發、網絡加速，在這個過程中，前端不需要關心 CDN 有多少個節點、如何做負載均衡，也不需要知道 CDN 的 QPS 是多少。所以從這個角度來說，CDN 是一種 serverless 的實現。

2、再比如對象存儲，和 CDN 一樣，我們只需要將文件上傳到對象存儲，就可以直接使用了，不需要關心它如何存取文件、如何進行權限控制，所以對象存儲對前端來說是 Serverless。
3、甚至一些第三方的 API 服務，也是 Serverless，因為我們使用的時候，不需要去關心服務器。

當然，有了體感還不夠，我們還是需要一個更精確的定義。從技術角度來說，Serverless 就是 FaaS 和 BaaS 的結合。

簡單來講，FaaS（Function as a Service）就是一些運行函數的平臺，比如阿里雲的函數計算、AWS 的 Lambda 等。

BaaS（Backend as a Service）則是一些後端雲服務，比如雲數據庫、對象存儲、消息隊列等。利用 BaaS，可以極大簡化我們的應用開發難度。

Serverless 則可以理解為運行在 FaaS 中，使用了 BaaS 的函數。

Serverless 的主要特點有：

1、事件驅動----函數在 FaaS 平臺中，需要通過一系列的事件來驅動函數執行。
2、無狀態----因為每次函數執行，可能使用的都是不同的容器，無法進行內存或數據共享。如果要共享數據，則只能通過第三方服務，比如 ```Redis`` 等。

Redis（全稱：Remote Dictionary Server 遠程字典服務）是一個開源的使用ANSI C語言編寫、支持網絡、可基於內存亦可持久化的日誌型、Key-Value[數據庫]，並提供多種語言的API。從2010年3月15日起，Redis的開發工作由VMware主持。從2013年5月開始，Redis的開發由Pivotal贊助。

3、無運維----使用serverless我們不需要關心服務器，也不需要關心運維，這也是serverles思想的核心；
4、低成本----使用 Serverless 成本很低，因為我們只需要為每次函數的運行付費。函數不運行，則不花錢，也不會浪費服務器資源過度

？？？？哪些公司平臺提供這些功能???現有的服務商雲平臺亞馬

二 Serverless 常見服務商提供的解決方案

1、上圖是當前主要的一些 Serverless 服務，以及對應的服務解決方案。
2、從下往上，分別是基礎設施、開發工具和應用場景。
亞馬遜-微軟-谷歌
3、基礎設施主要是一些雲計算廠商提供，包括雲計算平臺和各種 BaaS 服務，以及運行函數的 FaaS 平臺。
前端主要是 Serverless 的使用者，所以對前端來說，最重要的開發工具這一層，我們需要依賴開發工具進行 Serverless 開發、調試和部署。
4、框架（Framework）
如今還沒有一個統一的 Serverless 標準，不同雲計算平臺提供的 Serverless 服務很可能是不一樣的，這就導致我們的代碼，無法平滑遷移。Serverless 框架一個主要功能是簡化 Serverless 開發、部署流程，另一主要功能則是屏蔽不同 Serverless 服務中的差異，讓我們的函數能夠在不改動或者只改動很小一部分的情況下，在其他 Serverless 服務中也能運行。常見的 Serverless 框架有 Serverless Framework、ZEIT Now、Apex 等。不過這些基本都是國外公司做的，國內還沒有這樣的平臺。
5、Web IDE
和 Serverless 緊密相關的 Web IDE 主要也是各個雲計算平臺的 Web IDE。利用 Web IDE，我們可以很方便地在雲端開發、調試函數，並且可以直接部署到對應的 FaaS 平臺。這樣的好處是避免了在本地安裝各種開發工具、配置各種環境。常見的 Web IDE 有 AWS 的 Cloud9、阿里雲的函數計算 Web IDE、騰訊雲的 Cloud Studio。

6、當然，目前最主要的開發方式還是在本地進行開發。所以在本地開發 Serverless 的命令行工具也必不可少。
命令行工具主要有兩類，一類是雲計算平臺提供的，如 AWS 的 aws、 Azure 的 az、阿里雲的 fun；還有一類是 Serverless 框架提供的，如 serverless、now。
大部分工具如 serverless、fun 等，都是用 Node.js 語言來實現的。
7、應用場景
在開發工具上面一層，則是 Serverless 的一些垂直應用場景。除了使用傳統的服務端開發，目前使用 Serverless 技術的還有小程序開發，未來可能還會涉及到物聯網領域（IoT）。

不同 Serverless 服務的對比

上圖從支持語言、觸發器、價格等多個方面對不同 Serverless 服務進行了對比，可以發現有差異，也有共性。

1、比如幾乎所有 Serverless 服務都支持 Node.js/Python/Java 等語言。

2、從支持的觸發器來看，幾乎所有服務也都支持 HTTP、對象存儲、定時任務、消息隊列等觸發器。當然，這些觸發器也與平臺自己的後端服務相關，比如阿里雲的對象存儲觸發器，是基於阿里雲的 OSS 產品的存取等事件觸發的；而 AWS 的對象存儲觸發器，則是基於 AWS 的 S3 的事件觸發的，兩個平臺並不通用。這也是當前 Serverless 面臨的一個問題，就是標準不統一。

S3:Amazon Simple Storage Service (Amazon S3) 是一種對象存儲服務，提供行業領先的可擴展性、數據可用性、安全性和性能

從計費的角度來看，各個平臺的費用基本一致。在前面也提到，Serverless 的計費是按調用次數計費，執行時長。

三基於 Serverless 的前端開發模式

serverless 開發流程

1、在開始具體的案例之前，先看一下傳統開發流程。
在傳統開發流程中，我們需要前端寫頁面，後端工程師寫接口。後端寫完接口之後，把接口部署了，再進行前後端聯調。聯調完畢後再測試、上線。上線之後，還需要運維工程師對系統進行維護。整個過程涉及多個不同角色，鏈路較長，溝通協調也是一個問題。

2、而基於 Serverless，後端變得非常簡單了，以往的後端應用被拆分為一個個函數，只需要寫完函數並部署到 Serverless 服務即可，後續也不用關心任何服務器的運維操作。後端開發的門檻大幅度降低了。因此，只需要一個前端就可以完成所有的開發工作。

當然，前端基於 Serverless 去寫後端，最好也需要具備一定的後端知識。涉及複雜的後端系統或者 Serverless 不適用的場景，還是需要後端開發。

serverless帶來的價值

1．降低運營複雜度

Serverless架構使軟件應用和服務器實現瞭解耦，服務器不再是用戶開發和運營應用的焦點。在應用上線前，用戶無須再提前規劃服務器的數量和規格。在運維過程中，用戶無須再持續監控和維護具體服務器的狀態，只需要關心應用的整體狀態。應用運營的整體複雜度下降，用戶的關注點可以更多地放在軟件應用的體驗和改進以及其他能帶來更高業務價值的地方。
2．降低運營成本
服務器不再是用戶關注的一個受管資源，運營的複雜度下降，應用運營所需要投入的時間和人力將大大降低。在最好的情況下，可以做到少數幾個應用管理員即可管理一個處理海量請求的應用系統。

3、縮短產品的上市時間
在Serverless架構下，應用的功能被解構成若干個細顆粒度的無狀態函數，功能與功能之間的邊界變得更加清晰，功能模塊之間的耦合度大大減小。這使得軟件應用的開發效率更高，應用開發的迭代週期更短。

serverless實踐

基於 Serverless 的 BFF (Backend For Frontend)

傳統 BFF (Backend For Frontend) 架構

1、一方面，對不同的設備需要使用不同的 API，另一方面，由於微服務導致前端接口調用的複雜，所以前端開始使用 BFF 的方式，對接口進行聚合裁剪，以得到適用於前端的接口。

2、最底層的就是各種後端微服務，最上層就是各種前端應用。在微服務和應用之前，就是通常由前端開發的 BFF。
-手機端-web端-嵌入式-
這樣的架構解決了接口協調的問題，但也帶來了一些新的問題。

傳統 BFF (Backend For Frontend) 的痛點

比如針對每個設備開發一個 BFF 應用，也會面臨一些重複開發的問題。而且以往前端只需要開發頁面，關注於瀏覽器端的渲染即可，現在卻需要維護各種 BFF 應用。以往前端也不需要關心併發，現在併發壓力卻集中到了 BFF 上。總的來說運維成本非常高，通常前端並不擅長運維。

Serverless 則可以幫我們很好的解決這些問題。用Serverless，我們可以用一個個函數來實各個接口的聚合裁剪。前端向 BFF 發起的請求，就相當於是 FaaS 的一個 HTTP 觸發器，觸發一個函數的執行，這個函數中來實現針對該請求的業務邏輯，比如調用多個微服務獲取數據，然後再將處理結果返回給前端。這樣運維的壓力，就由以往的 BFF Server 轉向了 FaaS 服務，前端再也不用關心服務器了。

基於 Serverless 的 BFF 架構

上圖則是基於 Serverless 的 BFF 架構。為了更好的管理各種 API，我們還可以添加網關層，通過網關來管理所有 API（比如阿里雲的網關），比如對 API 進行分組、分環境。基於 API 網關，前端就不直接通過 HTTP 觸發器來執行函數，而是將請求發送至網關，再由網關去觸發具體的函數來執行。
API Gateway
在沒有API網關作為統一出口的情況下，需要調用方自己組合各種服務，而且容易讓調用方感知後端各種服務的存在，各個需要各個做很多相同的工作。
加入API Gateway之後的作用
一般也會把路由，安全，限流，緩存，日誌，監控，重試，熔斷等都放到 API 網關來做，然後服務層就完全脫離這些東西，純粹的做業務，也能夠很好的保證業務代碼的乾淨，不用關心安全，壓力等方面的問題。

基於 Serverless 的服務端渲染

傳統服務端渲染

基於當下最流行的三大前端框架（React.js/Anguler/Vue.js），現在的渲染方式大部分都是客戶端渲染。頁面初始化的時候，只加載一個簡單 HTML 以及對應的 JS 文件，再由 JS 來渲染出一個個頁面。這種方式最主要的問題就是白屏時間和 SEO 搜索引擎優化

為了解決這個問題，前端又開始嘗試服務端渲染。本質思想其實和最早的模板渲染是一樣的。都是前端發起一個請求，後端 Server 解析出一個 HTML 文檔，然後再返回給瀏覽器。只不過以往是 JSP、PHP 等服務端語言的模板，現在是基於 React、Vue 等實現的同構應用，這也是如今的服務端渲染方案的優勢。

但服務端渲染又為前端帶來了一些額外的問題：運維成本，前端需要維護用於渲染的服務器。

基於serverless的服務端渲染

Serverless 最大的優點就是可以幫我們減少運維，那 Serverless 能不能用於服務端渲染呢？當然也是可以的。

傳統的服務端渲染，每個請求的 path 都對應著服務端的每個路由，由該路由實現對應 path 的 HTML 文檔渲染。用於渲染的服務端程序，就是這些集成了這些路由的應用。
使用 Serverless 來做服務端渲染，就是將以往的每個路由，都拆分為一個個函數，再在 FaaS 上部署對應的函數。這樣用戶請求的 path，對應的就是每個單獨的函數。通過這種方式，就將運維操作轉移到了 FaaS 平臺，前端做服務端渲染，就不用再關心服務端程序的運維部署了。

基於 Serverless 的小程序開發

1、目前國內使用 Serverless 較多的場景可能就是小程開發了。具體的實現就是小程序雲開發，支付寶小程序和微信小程序都提供了雲開發功能。
2、在傳統的小程序開發中，我們需要前端進行小程序端的開發；後端進行服務端的開發。小程序的後端開發和其他的後端應用開發，本質是是一樣的，需要關心應用的負載均衡、備份冗災、監控報警等一些列部署運維操作。如果開發團隊人很少，可能還需要前端去實現服務端。
但基於雲開發，就只需要讓開發者關注於業務的實現，由一個前端就能夠完成整個應用的前後端開發。因為雲開發將後端封裝為了 BaaS 服務，並提供了對應的 SDK 給開發者，開發者可以像調用函數一樣使用各種後端服務。應用的運維也轉移到了提供雲開發的服務商。
下面分別是使用支付寶雲開發的一些例子，函數就是定義在 FaaS 服務中的函數。

負載均衡（Load Balance）其意思就是分攤到多個操作單元上進行執行，例如Web服務器、FTP服務器、企業關鍵應用服務器和其它關鍵任務服務器等，從而共同完成工作任務

備份冗災：就是為了防止出現自然或者社會滅害帶來的對存儲設備的損害而造成對數據丟失,而採取的備份.

通用 Serverless 架構

基於上述幾個 Serverless 開發的例子，就可以總結出一個通用的 Serverless 架構。