簡介:過去兩年,飛豬前端一直在積極地進行 Serverless 建設和實踐,2019 年 - 2020 年咱們和集團 Node 架構組、研發平臺一塊兒完成了基礎能力的建設和業務試點,成爲集團率先落地 Serverless 實踐的 BU,2020 年 - 2021 年咱們開始大規模地在飛豬推廣使用 Serverless 的能力,從導購全鏈路到核心中後臺,都可以看到 Serverless 的身影,這一年咱們完成了 Serverless 從業務試點到生產力工具的轉變,本文將主要分享飛豬基於 Serverless 的實踐成果以及將來想要作的事情。
做者 | 王恆飛(承蔭)
來源 | 阿里巴巴雲原生公衆號前端
本文整理自飛豬旅行前端技術專家--王恆飛(承蔭)在【阿里雲 Serverless Developer Meetup 上海站】上的分享。點擊查看直播回放:https://developer.aliyun.com/live/246653。
過去兩年,飛豬前端一直在積極地進行 Serverless 建設和實踐,2019 年 - 2020 年咱們和集團 Node 架構組、研發平臺一塊兒完成了基礎能力的建設和業務試點,成爲集團率先落地 Serverless 實踐的 BU,2020 年 - 2021 年咱們開始大規模地在飛豬推廣使用 Serverless 的能力,從導購全鏈路到核心中後臺,都可以看到 Serverless 的身影,這一年咱們完成了 Serverless 從業務試點到生產力工具的轉變,本文將主要分享飛豬基於 Serverless 的實踐成果以及將來想要作的事情。
node
2020 年 - 2021 年飛豬 Serverless 的規模和重要度都有很大的變化,主要表如今三方面:
算法
具體的數據以下:
後端
飛豬爲何這麼迫切地要引入 Serverless?這主要是出於先後端研發模式升級以及前端職能擴展的考慮,下面回顧一下飛豬前端架構的發展和研發模式的演進。
api
飛豬前端架構總結下來就是從最初純粹的前端開發,到解決多端一致性的跨端開發,再到接管視圖服務端邏輯的前臺開發,Serverless 就是前端升級轉變的核心一環。數組
前端人員爲何必定要參與服務側開發?從先後端研發模式的演進來看,主要經歷瞭如下三個大的階段:
第一階段是資源解耦,這個階段前端把靜態資源分離出來部署到 cdn,解決了和後端服務同機部署的耦合。
第二階段是模板解耦,咱們以前提到的先後端解耦大部分指的就是模板的解耦,一種不完全的解法就是渲染解耦,服務端放一個空模板內容部分全靠 CSR,完全的解法就是前端接管模板,能夠獨立部署模板也可使用 node.js 替代。
第三個階段就是試圖解耦,一方面是因爲客戶端體系和前端的離線體系的限制,端側對於視圖的動態性要求極高,沒有服務側能力的前端只能將視圖的動態性放在服務端作,另外一方面因爲端側架構對於數據接口協議的特殊要求,須要服務端來進行協議的轉換,也就是服務端常說的 Do 到 Vo 的處理,這就形成了先後端視圖的耦合,爲了去除這部分耦合,前端經過 Node.js 作 BFF 層來接管視圖層的邏輯,Serverless 則是給了前端作 BFF 開發的最佳選擇。
性能優化
其實在 Serverless 出現以前,前端也嘗試了用 node 應用來作 BFF 層的開發,飛豬也是在 2017 年經過 Midway + React SSR 的架構將飛豬 PC 主鏈路首頁、搜索、商品詳情、訂單詳情 Node 化,可是應用級別的開發在前端存在如下幾個問題:
架構
2017 - 2019 年也是集團 Node 開發停滯的兩年,這個階段因爲上述問題的閒置,Node 開發沒法在移動端鋪開,前端使用 Node 主要在中後臺的開發,這時矛盾主要表如今前端迫切渴望研發模式轉變和涉足服務端開發的高昂成本,直到 Serverless 浪潮的出現讓咱們看到了曙光,下面來看下 Serverless 能給前端帶來什麼樣的變化:
less
Node FaaS 經過將中間件集成到 Runtime 的上下文中,開發經過 Api 的方式調用來實現極低上手和開發成本,只要會寫 js 就能在 0.5 人/日內上手 FaaS 開發,同時 Serverless 容器底層經過機器統一管理、鏡像統1、靈活調度、按需付費等方式向開發者屏蔽容器的運維,二者結合完美地幫咱們解決了以前 Node 應用開發遇到的三大問題,至此先後端研發模式升級的最後一塊拼圖集齊,前端開始雲+端的變革。運維
從飛豬首頁到搜索、頻道,再到大促會場,Serverless FaaS 實現了在飛豬導購全鏈路的覆蓋,成爲飛豬前端的經常使用生產力工具之一。另外中後臺開發已全面使用 FaaS 開發,而且賦能客戶端同窗,下圖右側的包體積平臺就是飛豬客戶端同窗使用 Node FaaS 開發完成。
數據協議處理是 BFF 層最爲常見的場景,包括接口合併、Do 到 Vo 的轉換等,飛豬 80% 以上的 C 端 FaaS 場景都是用做數據協議的處理,經過 FaaS 來作協議轉換可以解放服務端,同時加強前端對視圖層的控制,可謂一箭雙鵰。
一個最新的例子(以下圖所示),這是一個飛豬的內容詳情頁,頁面涉及內容中臺、評價中臺、互動、算法等 5 個以上接口,這些接口都是現成的分散在各個系統,對於前端來講確定是不想在端上調 5 次接口,不論是從性能仍是架構設計上考慮,都是不合理的,這時就須要一個服務端接口的合併,FaaS 就很是適合作這樣的事情,經過原子能力的拼裝,無需服務端介入,極大縮短了需求的交付週期。
SSR 同構渲染並非一個新的概念,最先在 React 支持 SSR 的時候,前端就具有一套代碼在 Server 和 Client 端執行的能力,飛豬這邊早在 2017 年就在 pc 端上線了 Midway + React SSR 的頁面。
移動端因爲流量比 PC 大不少,且在 Server 側執行 Js 是一個極耗機器資源的操做,經過 Node 應用的方式作 SSR 機器和運維成本跟隨着頁面流量指數級上升,ROI 並不高,可是 Serverless FaaS 的自動託管,能幫前端解決機器利用率和運維成本的問題。
再配合客戶端的文檔預加載,咱們能夠作到客戶端預加載直出率(500ms下)100%,端外渲染 2s 達標率 90+%,性能提高 80% 以上。
一體化研發是一種更加符合前端人員習慣的開發模式,常見的分爲中後臺一體化和 Rax+FaaS 一體化,將 FaaS 代碼和 Assets 代碼在一個倉庫下開發,調試和部署可以極大地提升開發效率,目前飛豬用得最多的就是中後臺一體化開發。
在基礎建設方面定義爲兩部分:研發態效率的提高和運行時穩定性的保障。
開發階段主要涉及的操做是新建項目、調試和發佈,飛豬經過已有的 Clam 工程體系集成 FaaS 的腳手架模板,對接 def api 打通建立項目、迭代和發佈的能力,讓前端同窗開發 FaaS 能有和開發頁面同樣的體驗,下降上手和開發成本,同時封裝 Mtop 調用和容災 SDK,封裝經常使用 FaaS Utils 集合的方式提升代碼的複用度。
經過函數監控 Alinode、網關監控 Sunfire 以及全鏈路日誌的排查能力,作到問題的快速發現和定位。
經過 tair 容災和 cdn 容災,保障大部分場景在函數或者網關掛掉的狀況下,仍可以正常展現頁面。
2020 年 - 2021 年咱們完成了 Serverless 向生產力工具的轉變,2021 年 - 2022 年整體來看是完全完成飛豬研發模式轉變的目標,讓 FaaS 成爲先後端都習覺得常的一環,規劃還沒作具體,有如下幾個關鍵的事情要作:
基於 Serverless 的雲+端結合已經基本成型,這將是前端近些年來最大的變革之一,將來 FaaS 將是前端開發不可或缺的一環,咱們須要用它來作研發模式升級,也須要用它幫助前端擴大職能,經過 FaaS 的能力讓前端開發深刻到服務層,更好地貼近業務、理解業務、幫助業務。
王恆飛(承蔭),飛豬旅行前端技術專家,飛豬 Serverless 引進和實踐者,探索和推進雲+端的研發模式。
數字時代,如何更好地利用雲的能力?什麼是新型、便捷的開發模式?如何讓開發者更高效地構建應用?科技賦能社會,技術推進變革,拓展開發者的能量邊界,一切,因雲而不一樣。點擊當即報名活動,2021 阿里雲開發者大會將給你答案。
本文內容由阿里雲實名註冊用戶自發貢獻,版權歸原做者全部,阿里雲開發者社區不擁有其著做權,亦不承擔相應法律責任。具體規則請查看《阿里雲開發者社區用戶服務協議》和《阿里雲開發者社區知識產權保護指引》。若是您發現本社區中有涉嫌抄襲的內容,填寫侵權投訴表單進行舉報,一經查實,本社區將馬上刪除涉嫌侵權內容。