@(技術分享) 前端圈從來不缺少新的技術、點子和話題，有些留下來了而有些則轉瞬即逝。在決定一種新技術是否能夠長久的所有因素裡，最核心的必然是自身實力過硬能夠經受住實踐檢驗。而除此之外，這項技術所解決問題的廣泛程度、受眾群體規模等“非技術因素”也至關重要。

比如一經問世便話題性十足的React時至今日不論是自身還是其優秀的效仿者們都仍舊高歌猛進，高效能的vdom和高效率的資料驅動開發模式固然是其立足的基本，但React能夠高度普及的另一個關鍵因素也不容忽略，那就是它解決了前端開發最表面也是最廣泛的問題：UI程式設計。這可以說是從前端這一崗位自誕生以來最核心的關注點，而且不論什麼型別的web應用都無法脫離它。

但是很少人知道React的資料驅動UI的模式早在2011年的D3.js中就有很成熟的應用，一個重要的原因是面向SVG程式設計的D3.js受眾群體太小，只有從事SVG資料視覺化程式設計的人才會使用它，所以沒有很高的傳播度。

之所以講React和D3，是因為今天我們要討論的是一種不論從普及的速度上還是話題性上都非常驚人的技術理念-Serverless。

Serverless解放了後端和運維，前端呢？

業內對於Serverless的正式得名來自何處並沒有絕對統一的看法，但一種相對普遍的認知是始於亞馬遜AWS Lambda。自2014年始，在AWS Lambda之後，Google、IBM、Microsoft、騰訊等國內外雲廠商們相繼推出類似的雲函式計算平臺，稱為FaaS。時至今日Serverless=FaaS的誤解仍未完全消除，不過Serverless=FaaS+BaaS的理論模型已經趨於標準。各類社群、論壇和技術大會對此的講解有很多，本文便不再贅述。

提一個有趣的東西，早年間折騰過“梯子”的小夥伴肯定熟悉一個很好用的工具：Google App Engine，簡稱GAE。雖然Google將GAE定位為一種SaaS產品，但GAE本身可以被拆解為很多細分的功能，在這些能力之上開發可以開發自己的SaaS產品。在這個角度上GAE很符合目前技術圈對於Serverless的解讀。

Serverless最直觀的優勢是解放了傳統後端和一部分運維工程師的生產力。原本由web server承載的業務邏輯轉交給FaaS平臺的一個個函式，沒有了伺服器硬體的束縛，也捨棄了MVC之類的架構模式，只剩下業務邏輯本身。服務部署在雲端能夠節省很多運維成本，什麼交換機、路由器、刀鋒伺服器等等全都與開發者無關。

Serverless可以稱得上是一種轉變軟體開發正規化的理論。軟體開發技術經歷幾十年的發展歷程到今天，開發者在Serverless的加持之下，從原始的聚焦於系統架構和軟體架構兩者，轉變為只關注軟體架構本身。

Serverless無疑是一個偉大的理論，但不論是系統架構還是軟體架構，交付給使用者的形式終究要依託應用端。而Serverless本身並沒有關注於解決對端問題上。這像極了通訊技術領域的“最後一公里”問題：通訊服務商們克服了重重困難將電纜跨過了陸地和海洋，最終卻在抵達使用者計算機的最後一公里之前遇到了瓶頸。

在對端的最後一公里，Serverless還缺少什麼？

這個問題其實已經超越了狹隘Serverless的範疇，更準確地表達是：在Serverless的基礎上，如何設計合理的對端解決方案？

解決問題的關鍵在於FaaS層。

目前市場上提供FaaS服務的雲端計算廠商中，包括AWS Lambda、Azure Functions、阿里雲的Function Compute以及騰訊雲的SCF，在應用端呼叫函式的方式大都以http API的形式為主。這跟傳統的web server介面在呼叫方式上並無本質區別。

http api本身沒有任何問題，問題在於呼叫請求直接送達FaaS函式有很多不便和隱患。FaaS函式很接近函式語言程式設計思想裡的純函式。函式本身是無狀態的，但是業務邏輯是有狀態的，最典型的場景是使用者鑑權。這並不是很複雜的業務邏輯，但是如果一個FaaS函式來承擔的話，那麼這個函式便跟業務有了強耦合性，變得不再“純”，成為了一個“高階函式”。

對於這類FaaS平臺，比較普遍的做法是在FaaS之上另行搭建一層API Gateway，用來做鑑權、session維護等與業務相關的工作，同時充當FaaS層代理的角色。

部分廠商提供了API Gateway能力。

這是一種比較合理的接入方式，但需要開發者付出一定的成本，不論是自行搭建API Gateway還是使用雲廠商提供的能力。沒有做到“開箱即用”的便捷性，這也是最能夠體現雲開發優勢的一點。

雲開發：Serverless最後一塊拼圖

雲開發並不是Serverless，準確地說，它不是Serverless的全部。在目前技術圈對Serverless的認知基礎之上，雲開發以“最後一塊拼圖”的形態彌補了Serverless對端能力的不足。

雲接入層不僅僅是一層傳統的API Gateway，同時會對應用端的每一次請求進行許可權驗證，包括雲函式、儲存以及資料庫在內的所有能力都有細分的許可權管理策略。

端與雲接入層的通訊流程隱藏在端SDK中，開發者使用比http API更便捷、更具語義化的函式語法進行呼叫。

關於函式語法與http API的優劣對比後續文章會詳細講解，敬請關注。

在雲開發體系下，開發者省去了搭建API Gateway的人力和經濟成本，真正做到了“開箱即用”。在端SDK的加持之下，開發者能夠以更便捷友好的編碼方式進行開發。

這些已經超出了Serverless的狹隘範疇，所以將本節開始那句話補充完整即為：雲開發不是Serverless的全部，同時Serverless也不是雲開發的全部。雲開發的目標是在Serverless的基礎上進一步弱化開發者對後臺的感知，聚焦於應用開發本身上。

總結

“含著金湯匙出生”的Serverless僅用不到5年的時間便經歷了從誕生到普及的歷程，在當前的時間節點業內對於Serverless雖有公知但仍未絕對統一，大家都是踩著石頭過河。雲開發自2018年9月在小程式落地之後，從一開始的質疑大過認可到成為小程式開發的標配僅用了不到一年的時間，未來也將以成為標準的Serverless對端解決方案為目標。