飛豬基於 Serverless 的雲+端實踐與思考

簡介:過去兩年,飛豬前端一直在積極地進行 Serverless 建設和實踐,2019 年 - 2020 年咱們和集團 Node 架構組、研發平臺一塊兒完成了基礎能力的建設和業務試點,成爲集團率先落地 Serverless 實踐的 BU,2020 年 - 2021 年咱們開始大規模地在飛豬推廣使用 Serverless 的能力,從導購全鏈路到核心中後臺,都可以看到 Serverless 的身影,這一年咱們完成了 Serverless 從業務試點到生產力工具的轉變,本文將主要分享飛豬基於 Serverless 的實踐成果以及將來想要作的事情。

頭圖.png

做者 | 王恆飛(承蔭)
來源 | 阿里巴巴雲原生公衆號前端

本文整理自飛豬旅行前端技術專家--王恆飛(承蔭)在【阿里雲 Serverless Developer Meetup 上海站】上的分享。點擊查看直播回放:https://developer.aliyun.com/live/246653

過去兩年,飛豬前端一直在積極地進行 Serverless 建設和實踐,2019 年 - 2020 年咱們和集團 Node 架構組、研發平臺一塊兒完成了基礎能力的建設和業務試點,成爲集團率先落地 Serverless 實踐的 BU,2020 年 - 2021 年咱們開始大規模地在飛豬推廣使用 Serverless 的能力,從導購全鏈路到核心中後臺,都可以看到 Serverless 的身影,這一年咱們完成了 Serverless 從業務試點到生產力工具的轉變,本文將主要分享飛豬基於 Serverless 的實踐成果以及將來想要作的事情。
node

Serverless 的使用規模


2020 年 - 2021 年飛豬 Serverless 的規模和重要度都有很大的變化,主要表如今三方面:
算法

  • 一是函數組規模增加一倍以上,Qps 峯值增加 650%。
  • 二是使用 FaaS 開發的人員規模增加 560%,其中前端人員 80% 以上參與到 FaaS 的開發中。
  • 三是影響力的表現,目前不只飛豬前端都對 Serverless 很熟悉,客戶端也有不少人蔘與到 FaaS 的開發,更重要的是後端和產品同窗也知道咱們有 Serverless 進行服務開發的能力。

具體的數據以下:

1.png後端

爲何要引入 Serverless


飛豬爲何這麼迫切地要引入 Serverless?這主要是出於先後端研發模式升級以及前端職能擴展的考慮,下面回顧一下飛豬前端架構的發展和研發模式的演進。
api

1. 飛豬前端架構的發展


飛豬前端架構總結下來就是從最初純粹的前端開發,到解決多端一致性的跨端開發,再到接管視圖服務端邏輯的前臺開發,Serverless 就是前端升級轉變的核心一環。數組

2.png

2. 研發模式的演進歷程


前端人員爲何必定要參與服務側開發?從先後端研發模式的演進來看,主要經歷瞭如下三個大的階段:

第一階段是資源解耦,這個階段前端把靜態資源分離出來部署到 cdn,解決了和後端服務同機部署的耦合。

第二階段是模板解耦,咱們以前提到的先後端解耦大部分指的就是模板的解耦,一種不完全的解法就是渲染解耦,服務端放一個空模板內容部分全靠 CSR,完全的解法就是前端接管模板,能夠獨立部署模板也可使用 node.js 替代。

第三個階段就是試圖解耦,一方面是因爲客戶端體系和前端的離線體系的限制,端側對於視圖的動態性要求極高,沒有服務側能力的前端只能將視圖的動態性放在服務端作,另外一方面因爲端側架構對於數據接口協議的特殊要求,須要服務端來進行協議的轉換,也就是服務端常說的 Do 到 Vo 的處理,這就形成了先後端視圖的耦合,爲了去除這部分耦合,前端經過 Node.js 作 BFF 層來接管視圖層的邏輯,Serverless 則是給了前端作 BFF 開發的最佳選擇。

3.png性能優化

3. 爲何必定是 Serverless


其實在 Serverless 出現以前,前端也嘗試了用 node 應用來作 BFF 層的開發,飛豬也是在 2017 年經過 Midway + React SSR 的架構將飛豬 PC 主鏈路首頁、搜索、商品詳情、訂單詳情 Node 化,可是應用級別的開發在前端存在如下幾個問題:
架構

  • 開發成本高:Node 應用級別的開發對於新手前端仍是具有必定的開發成本,以前作過粗略的估計,上手成本至少須要 3 人/日,還不包括後續的性能優化、內存泄漏排查等一系列能力。
  • 運維成本高:Docker、鏡像、機器日誌查看、域名申請、機器替換等一系列運維能力對於前端來講具有很是高的複雜度,也是註定沒法推廣的一個重要緣由。
  • 機器成本高:前端在使用應用開發時過分偏向於前端架構設計帶來的應用離散和機器利用率低的問題,根本緣由是前端在用頁面開發的思惟去作應用開發,致使新建一堆應用佔用大量閒置機器。

2017 - 2019 年也是集團 Node 開發停滯的兩年,這個階段因爲上述問題的閒置,Node 開發沒法在移動端鋪開,前端使用 Node 主要在中後臺的開發,這時矛盾主要表如今前端迫切渴望研發模式轉變和涉足服務端開發的高昂成本,直到 Serverless 浪潮的出現讓咱們看到了曙光,下面來看下 Serverless 能給前端帶來什麼樣的變化:

4.pngless

Node FaaS 經過將中間件集成到 Runtime 的上下文中,開發經過 Api 的方式調用來實現極低上手和開發成本,只要會寫 js 就能在 0.5 人/日內上手 FaaS 開發,同時 Serverless 容器底層經過機器統一管理、鏡像統1、靈活調度、按需付費等方式向開發者屏蔽容器的運維,二者結合完美地幫咱們解決了以前 Node 應用開發遇到的三大問題,至此先後端研發模式升級的最後一塊拼圖集齊,前端開始雲+端的變革。運維

飛豬雲+端的核心落地場景

1. 落地場景總覽


從飛豬首頁到搜索、頻道,再到大促會場,Serverless FaaS 實現了在飛豬導購全鏈路的覆蓋,成爲飛豬前端的經常使用生產力工具之一。另外中後臺開發已全面使用 FaaS 開發,而且賦能客戶端同窗,下圖右側的包體積平臺就是飛豬客戶端同窗使用 Node FaaS 開發完成。

5.png

2. 雲+端場景 - 數據協議處理


數據協議處理是 BFF 層最爲常見的場景,包括接口合併、Do 到 Vo 的轉換等,飛豬 80% 以上的 C 端 FaaS 場景都是用做數據協議的處理,經過 FaaS 來作協議轉換可以解放服務端,同時加強前端對視圖層的控制,可謂一箭雙鵰。

6.png

一個最新的例子(以下圖所示),這是一個飛豬的內容詳情頁,頁面涉及內容中臺、評價中臺、互動、算法等 5 個以上接口,這些接口都是現成的分散在各個系統,對於前端來講確定是不想在端上調 5 次接口,不論是從性能仍是架構設計上考慮,都是不合理的,這時就須要一個服務端接口的合併,FaaS 就很是適合作這樣的事情,經過原子能力的拼裝,無需服務端介入,極大縮短了需求的交付週期。

7.png

3. 雲+端場景 - SSR 同構渲染


SSR 同構渲染並非一個新的概念,最先在 React 支持 SSR 的時候,前端就具有一套代碼在 Server 和 Client 端執行的能力,飛豬這邊早在 2017 年就在 pc 端上線了 Midway + React SSR 的頁面。

移動端因爲流量比 PC 大不少,且在 Server 側執行 Js 是一個極耗機器資源的操做,經過 Node 應用的方式作 SSR 機器和運維成本跟隨着頁面流量指數級上升,ROI 並不高,可是 Serverless FaaS 的自動託管,能幫前端解決機器利用率和運維成本的問題。

再配合客戶端的文檔預加載,咱們能夠作到客戶端預加載直出率(500ms下)100%,端外渲染 2s 達標率 90+%,性能提高 80% 以上。

8.png

4. 雲+端場景 - 一體化應用


一體化研發是一種更加符合前端人員習慣的開發模式,常見的分爲中後臺一體化和 Rax+FaaS 一體化,將 FaaS 代碼和 Assets 代碼在一個倉庫下開發,調試和部署可以極大地提升開發效率,目前飛豬用得最多的就是中後臺一體化開發。

9.png

Serverless 研發配套建設


在基礎建設方面定義爲兩部分:研發態效率的提高運行時穩定性的保障

1. 研發態效率


開發階段主要涉及的操做是新建項目、調試和發佈,飛豬經過已有的 Clam 工程體系集成 FaaS 的腳手架模板,對接 def api 打通建立項目、迭代和發佈的能力,讓前端同窗開發 FaaS 能有和開發頁面同樣的體驗,下降上手和開發成本,同時封裝 Mtop 調用和容災 SDK,封裝經常使用 FaaS Utils 集合的方式提升代碼的複用度。

2. 運行時穩定性


經過函數監控 Alinode、網關監控 Sunfire 以及全鏈路日誌的排查能力,作到問題的快速發現和定位。

10.png

經過 tair 容災和 cdn 容災,保障大部分場景在函數或者網關掛掉的狀況下,仍可以正常展現頁面。

將來


2020 年 - 2021 年咱們完成了 Serverless 向生產力工具的轉變,2021 年 - 2022 年整體來看是完全完成飛豬研發模式轉變的目標,讓 FaaS 成爲先後端都習覺得常的一環,規劃還沒作具體,有如下幾個關鍵的事情要作:

  • 中後臺和長尾函數 0 - 1 的彈起嘗試:這塊考慮到一些中後臺函數和長尾函數天天可能只有幾十個 Uv 夠不到 Qps 級別,目前預留 1 核機器的方式還是有些浪費,考慮在不影響初次請求的狀況下嘗試 0 到 1 的彈起,作到機器的極致利用率。
  • 飛豬物理網關的替換:目前雖然飛豬 Java 的網關出於維護狀態投入較低,可是一旦流量發生變化,網關的穩定性會成爲瓶頸,但願可以有 Fc 專門的團隊接管流量網關,以前飛豬也是完成了一個線上試點,2021 年 - 2022 年繼續推動。
  • 研發態和運行時問題的可觀測加強:從 FC 底層容器到函數代碼內部再到函數依賴、流量網關,不論是部署出現的問題仍是線上的問題,都比較難定位,一般須要拉着 FC、研發平臺、Runtime 的同窗一塊排查,後續但願能推進可觀測性的加強,讓業務開發可以快速發現問題。

寫在最後


基於 Serverless 的雲+端結合已經基本成型,這將是前端近些年來最大的變革之一,將來 FaaS 將是前端開發不可或缺的一環,咱們須要用它來作研發模式升級,也須要用它幫助前端擴大職能,經過 FaaS 的能力讓前端開發深刻到服務層,更好地貼近業務、理解業務、幫助業務。

做者簡介


王恆飛(承蔭),飛豬旅行前端技術專家,飛豬 Serverless 引進和實踐者,探索和推進雲+端的研發模式。

2021 阿里雲開發者大會重磅開啓!

數字時代,如何更好地利用雲的能力?什麼是新型、便捷的開發模式?如何讓開發者更高效地構建應用?科技賦能社會,技術推進變革,拓展開發者的能量邊界,一切,因雲而不一樣。點擊當即報名活動2021 阿里雲開發者大會將給你答案。

本文內容由阿里雲實名註冊用戶自發貢獻,版權歸原做者全部,阿里雲開發者社區不擁有其著做權,亦不承擔相應法律責任。具體規則請查看《阿里雲開發者社區用戶服務協議》和《阿里雲開發者社區知識產權保護指引》。若是您發現本社區中有涉嫌抄襲的內容,填寫侵權投訴表單進行舉報,一經查實,本社區將馬上刪除涉嫌侵權內容。
相關文章
相關標籤/搜索