云開發如何解決serverless對端的最后一公里問題

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

比如一經問世便話題性十足的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對端解決方案為目標。

posted @ 2019-10-31 18:06  寒月十八  閱讀(...)  評論(... 編輯 收藏
11选5走势图