閑魚前端 Faas 框架與通信方案|前端搞 Serverless

前端早早聊大會，前端成長的新起點，與掘金聯合舉辦。本文是前端早早聊的第 45 位講師，也是第六屆 - Serverless 專場，來自閑魚前端團隊的丹俠的分享 - 講稿簡要整理版（完整版含演示請看錄播視頻和 PPT）：概述今天給大家分享一下閑魚如何在現有產品中落地 FaaS，希望我們的實踐 ...

前端早早聊大會，前端成長的新起點，與掘金聯合舉辦。

本文 是前端早早聊的第 45 位講師 ，也是第六屆 - Serverless 專場，來自閑魚前端團隊的丹俠的分享 - 講稿簡要整理版（完整版含演示請看錄播視頻和 PPT）：

概述

今天給大家分享一下閑魚如何在現有產品中落地 FaaS，希望我們的實踐可以給大家帶來借鑒和靈感。今天跟我一同分享的，還有我的同事，海瀦。他是我們團隊的架構師，FaaS 層的通信架構就是由他設計並實現。在後續的 PPT 中，有關通信相關的技術點，會由他來帶給大家。

之前 5 場，大家已經聽到了像 Severless、雲計算、雲平臺等跟 FaaS 關係比較緊密的概念。接下來我和海瀦講的內容里，不會涉及太多的基礎概念，我們的方案不限定具體某個技術棧或者是工具，也沒有要求使用特定的平臺及環境。我們會更傾向於解決具體業務問題。主要給大家分享一套設計思路和方法論。講的是在富交互場景的產品鏈路里，如何利用 FaaS，給現有的研發模式提供一些便利和想象空間。當然，FaaS 目前在前端領域，產生很多新的研發創新思路的同時，也是有一些不可忽視的問題存在，也是需要大家一起不斷思考和實踐，並逐漸完善。

閑魚的端技術和 FaaS 研發體系

首先讓大家瞭解下閑魚目前的端技術組成。閑魚給業內印象比較深的，可能是 Flutter 的研發體系。但是閑魚也有很多基於 Web 的應用場景，這些場景，還是基於前端比較熟悉的技術棧來實現的，比如 React，Vue，小程式。除了端內有不少 Web 的場景，在端外的投放，基本也都是基於前端 H5 技術來實現的。

大家知道，Flutter 官方提供的編程語言是 Dart。所以閑魚在 FaaS 體系構建之初，是把 Dart 作為 FaaS 層的編程語言，這樣客戶端就可以實現一體化的研發體驗。這跟前端使用 TS 結合 Node 是一樣的道理。在 FaaS 的實踐過程中，前端又是跟客戶端共用一套 FaaS 技術框架，所以為了讓前端同學也可以實現一體化的編程體驗，前端在工程上做了一層語法轉化，實現了用 TS 編程，構建時轉化成 Dart 的工程能力，這樣也就間接實現了一體化的研發體驗。

所以目前閑魚 FaaS 研發的技術環境就是：客戶端和前端共用同一套 FaaS 框架。我們的 FaaS 函數，是部署在一個叫蓋亞的研發部署平臺，這個平臺是阿裡內部面向函數的研發運維平臺，這個對各位同學來說並不是唯一選擇，大家可以使用自家公司的，或者自己熟悉的平臺來部署 FaaS 函數。

傳統的 MVVM 的研發模式

先回顧一下傳統的前端研發模式，大部分同學，對 MVVM 應該比較熟悉。像 React、Vue 都是擅長使用這套模式管理前端代碼的。

重端側的研發過程中，會有三個概念：Model、View、ViewModel，這三個都是在端側定義並管理的。統一管理的好處是一個工程維護一套業務，研發效率比較高；缺點就是代碼管理成本比較高，複雜業務需要藉助一些端側代碼框架，比如 Redux，或者像螞蟻先後推出開發框架 Dvajs、Umijs，都是幫助大家去管理端側代碼。但即使有這些框架的協助，有時對 UI 狀態和業務狀態的管理也會比較混亂。這跟業務的多變性、開發人員的綜合素質以及開發團隊對代碼管理的嚴格程度都有關係。

重端側的研發模式，有個問題就是技術棧的適配和遷移成本較高，比如從 Vue 遷移到 React 或者是小程式。不光要適配 UI 層，還需要依賴於之前的邏輯層抽象的比較好，否則這個過程肯定是比較痛苦的。這也是近幾年小程式比較火的一個原因之一，各家 App 都支持了小程式，可以做到一次開發，多端投放的效果。但是並不是所有的場景都是適合用小程式來實現的。

重端側研發還有一個問題是前端對介面的控制能力不足。服務端會針對業務提供定製的介面，復用度較差。數據格式轉化到 Model 的過程中，還需要端側做一些適配、轉化及容錯處理。

當然前端也可以通過 BFF 層，Backend For Frontend，顧名思義，服務前端的後端。但這是一層是非常輕量級的服務層，主要做的是數據的重組，欄位補全、格式校驗、標準化等能力。最終的數據能力還是沒有大的改變。只是把原來服務端不擅長的那部分數據處理工作給攬過來了。

基於 FaaS 的研發模式

基於 FaaS 的研發模式，它給前端的研發模式提供了新的思路。還是熟悉的 MVVM 研發模式，只是端側只剩下了View、把 Model 和 ViewModel 都遷移到了 FaaS 側。大部分更新UI的工作通過事件通信來實現。

可以看到這種模式下，介面的服務能力也有一定的變化，也就是 FaaS 函數跟 Severless 的配合，服務端會提供領域級別的服務，這些領域服務一般設計成可復用，不跟具體的業務邏輯耦合。對業務的邏輯處理和數據的編排和重組，都是放在 FaaS 層。這樣前端的邏輯也放在了 FaaS，FaaS 的能力和職責是被放大了。前端可做的事情和想象空間也變得更大。

當然 FaaS 本身是一種無狀態的服務，在邏輯處理過程中如果需要使用一些狀態存儲的能力，就要藉助於 BaaS 才能完成一些狀態保存的能力。

而且業務邏輯和數據編排的能力放在一起，可以讓整個業務邏輯不再割裂，可以更好地進行抽象設計，甚至編排。

FaaS 在淘系的應用之一（導購）

這裡舉例一個淘系最早應用 FaaS 的場景：導購。導購的端側場景特點是以展示為主，一般用戶的行為主要是滾動屏幕瀏覽、點擊商品跳轉。所以它主要關註的技術點是：

商品個性化推薦演算法
商品屬性透出（數據補全）
排序規則
數據的分頁獲取
數據或者權益的投放排期

所以基於這樣的業務場景，FaaS 側要做的主要工作是對服務的編排。

欄位映射：FaaS 側的數據模型跟端側的 View 模塊之間的欄位映射。
模板管理：對某個業務模塊的實例管理
連接器：連接器是一些 if else 邏輯或者是一些具體的行為（比如數據請求）

模板管理和連接器是可視化編排的重要素材

而數據編排，是下游的服務能力，是給 FaaS 層提供數據的數據中台能力，不包含在 FaaS 應用層。所以我們之前進行調研的時候，也是考慮導購的 FaaS 業務模型，是否可以套用到我們閑魚產品的 FaaS 模型中呢？

接下來我拿閑魚的回收、寄賣業務來進行例舉分析一下。

閑魚的具體業務分析

以閑魚的回收寄賣業務為例：這是兩條相似的產品鏈路，他們共用類目選擇、問卷估價等業務場景，但回收會多出信用評估和代扣簽約這兩個業務場景。

同時，回收寄賣涉及的類目也比較多，包括手機數位、大家電、圖書、舊衣等。最後又有不同的服務商對接，也會影響流程頁中的渲染和交互方式。而且不同的類目，對應不同的業務方和運營同學，他們的產品策略也會有些差異。所以看似差不多的鏈路里，包含了很多的差異性因數。如果把這些因數做統一的數據處理和服務編排，可想而知，前端的邏輯會變得非常複雜，並且難以維護。所以現有的 FaaS 框架不足以管理複雜的產品鏈路。

綜合分析下來，是缺少兩個關鍵的組成：

缺少富交互場景的通信方案。因為複雜交互，用戶的行為響應，端側只剩下 View，無法進行直接處理，是需要頻繁跟 FaaS 進行通信才能實現狀態的變更。
缺少一套 FaaS 側的業務框架來抽象和管理整個業務。

產品交互與 FaaS 的通信模式

所以基於之前的分析和事後的思考，我們設計出一個模型。這個模型里，最關鍵的兩個概念是：業務框架 FaaS Story 和數據處理框架 Nexus，這兩個概念都在 FaaS 側進行抽象和實現，然後通過一個我們命名為 Logic Engine 的模塊，跟端側進行通信。

可以看到圖中的整個數據鏈路：端側的 page state，管理了組件的屬性和事件配置，這裡的 Action 並不是一個 Function，而是對事件函數的一個配置，端側的 Logic Engine 會統一解析這個配置，並調用統一的事件函數，組裝成統一的數據包，向 FaaS 發起請求。

數據到了 FaaS 側，還是由 FaaS 側的 Logic Engine 進行數據包解析，路由匹配到對應的函數進行處理，函數基於 FaaS Story 這套業務框架進行設計，最終把處理後的信息再次通過 FaaS 側的 Logic Engine 打包返回給端側，端側的 Logic Engine 進行解析處理，最終響應具體的 Action（比如更新頁面狀態，或者是發起另一次數據通信，又或者是調用某個容器的 API 等）。

業務模型 FaaS-Stroy

基於這樣的模型，我們把之前回收寄賣業務映射過來。整個業務，我們我們就定義為一個故事（Story），這個故事有多個 Scene 組成。

這裡 Scene 的概念並不是一個單頁的概念，而是根據業務來進行定義的，一個頁面可能會承載多個 Scene，後面也會例舉多 Scene 的業務場景。

一個 Scene，主要由數據模型 Model、編排邏輯函數 Convertor 以及渲染邏輯函數 Render 組成。Model 映射原始的介面數據（也就是服務端的領域模型），一個場景函數中，可能會獲取多個 Model；Converter 處理業務邏輯並輸出跟端側 page state 一致的結構，它的作用也就是 MVVM 結構中的 ViewModel；Render 運行在端側，最終渲染頁面並掛載事件。我們的 Nexus 框架實現了統一的端側事件模型，UI 組件的事件函數同樣可以使用這個事件模型，也就是之前提到的 Action 配置，這樣組件從初始化到交互都可以由 FaaS 控制。

Story 的函數管理方式類似於端側 APP 的概念，可以全局上對這些 FaaS 函數進行管理和編排，比如提供一套統一的配置，來定義路由，以及處理函數之間的流轉關係。

一個多場景的頁面

之前在介紹閑魚業務的時候也提到了，我們有很多的類目，不同的類目，雖然主鏈路基本一致，每個類目對應的品類屬性差異還是比較大的，這會影響頁面的渲染和交互。同時不同類目對應的業務方也不同，產品策略和營銷策略都會有差異。比如有些類目的下單是需要上門取件，有些類目的評估流程中是需要拍照鑒定，有些類目在某個節日要做個特殊的活動等等。

所以我們從類目的緯度橫向分割了 FaaS 函數，不同類目的個性化邏輯在自己的 FaaS 函數中獨立管理，相互之間互不幹擾。他們的公共部分被抽象到了公共類庫，或者一些工具類庫。

Nexus 框架

Nexus 是一種一體化應用開發協議，用於解決 UI / 邏輯分離下，端 / FaaS 跨系統函數調用的問題。在它上面可以長很多的，基於特定業務場景的框架，比如上面介紹的 Story，還有另外一個同事編寫的基於 fish-redux-view 結合 Logic Engine 的 Nexus Framework。

首先說一下為什麼會有這樣一個協議：大家可以看上圖左邊，在端側長時間的發展過程中，大家都在致力於解決 UI/邏輯如何更好得分離的問題。不管是最早的 MVC，還是 MVP，以及 MVVM，都想要解決這個問題。但是無論端側如何解決，嚴格得執行各種框架，被分離的邏輯都只是那部分存在於端側的業務邏輯。

我們如果把目光放得更大一些，會發現，端側的邏輯是分離出去了，但是網關層的呢？實際上大部分端側請求的介面，不管是下發數據，還是寫入數據，都不是直接面向領域層的調用。而是會經過網關再進行一次邏輯處理。最典型的比如，頁面數據請求，幾乎很少有頁面去直接面向領域層的多個介面直接進行數據請求。那麼為什麼呢？因為領域是面向具體的領域問題進行的設計，而端側需要是面向UI展示進行設計，這兩邊的設計天然是後鴻溝的。簡單一點說，領域層下發的很多數據，端側是不要的。而通常一個領域介面無法滿足一個頁面所需要的所有數據。所以才需要經過網關層進行處理。

所以大家發現沒有，不管端側怎麼做分離，總會有一部分邏輯存在於網關層。那麼如果網關層把所有領域數據都處理成 VO 給到端側好不好？當然好了，但是後端的同學就不樂意了。一來這個 UI 不是我寫的，我還得跟你溝通你需要點啥，每次 UI 改動還得我跟著改。二來寫這些東西我也沒啥成長。所以更多的時候，是端側一部分處理邏輯，網關層再做一部分。

這就帶來了一個完整業務中 UI / 邏輯實際並不分離的問題。同時也會造成前後端在溝通、協作上的諸多問題。基於以上，我們思考的是，那不然就不要後端同學來寫網關層了，用 FaaS 讓前端的同學上去寫，自己要什麼自己最清楚，也少了協同和溝通，提升效率，還能公用一部分的代碼。這就是一體化編程模型的來源。也就是左邊的圖所表達的。

現在我們打算讓 FaaS 來處理所有的業務邏輯。還有兩個問題需要解決：

事實上，業務如何被驅動，都來自於端側的事件。那麼 FaaS 如何感受到來自事件的驅動
FaaS 的處理結果，最終是要在端側產生 Effect 才行，而這些 Effect 基本上只能由端側來執行。

所以我們一定是需要一個通信協議，來讓端能夠調用到 FaaS 上的邏輯函數，也能讓 FaaS 能夠調用端側的函數產生 Effect。

整個協議在數據部分基於 NexusBinderAction 體系，將每一個 Action 映射到一個邏輯 Handler 上。Action 是一種數據信息載體，它內部的信息實際上體現的是調用一個函數所需要的“函數簽名”和“函數入參”兩類關鍵信息，某種意義上來說，它也是一種“跨系統的函數調用”協議。

但是它與傳統的 RPC 協議之間，有什麼區別，或者特點呢？這與端側 UI 編程的特征有關。在端側編程中，我們發現，有三類的函數調用是可以被歸納的： 1、調用一個後端函數(即執行一段業務邏輯) 2、調用端側的公共能力函數 3、修改數據並重新渲染。

這三類函數是端側編程中被大量重覆使用的函數，尤其是第三類。UI = F(state)。這些的背後都隱含著一個操作，就是業務邏輯操作。不管是由某一個動作觸發的狀態改變，還是網路請求，還是諸如 dialog，頁面跳轉，這背後都需要一些邏輯代碼來進行判斷和修改。

基於對端側編程中常用的函數調用的抽象，我們得到了一個 Action 的有限集合。以及支撐這個協議的庫 Logic Engine。這裡的“有限”非常重要，如果開發者在每次開發一個頁面的時候都需要重覆得定義大量的 Action 和 Handler，那麼一來會增加開發者的負擔，二來會出現很多重覆的代碼，也不符合軟體開發中 DRY 的原則。

這樣開發方式實際又回到了原始的 Req -> Do something -> Effect，這條路上。所以整個 Action 體系中包含的種類一定要非常少，但它卻可以支持大部分的端側編程中對邏輯函數調用的需求。也就是現在 Nexus 協議的樣子。

根據上面對 Nexus 協議的抽象，可以很明顯得看到，無論運行在什麼環境中。有兩種 Action 的處理邏輯是大體上不變的：

對於 remote - req 來說，它的邏輯就是解析出 Action 中與請求相關的 apiname、apiversion 以及 params 部分，然後調用一個外部註入進來的網路請求函數把這個調用發送到 FaaS 上去。可以看到，調用一個遠程的 FaaS 函數的過程大體上是不變的，也就是 remote - req，Handler 的邏輯可以內置在 Engine 中的的基礎。
從一個 state change 的 Action 中提取新的 UI state，並提交給 UI 進行更新。

另外兩種內置的通用 handler 並不來自於 nexus 協議的抽象，而是脫胎於日常開發。

state-diff。它的邏輯是把一個 json patch 合併到當前的 state 中，產生一個新的 state 並提交給 UI 去更新。因為整個端調用 FaaS 的過程中，FaaS 作為無狀態服務本身並不存儲狀態，那麼所有計算所需要的狀態信息都會由端發送到 FaaS 上。但是 FaaS 在計算完新的 state 之後，並沒有必要全量得返回狀態數據，本身端側就保存有 state的原始版本。那麼我們考慮，是不是可以通過 diff 的方式讓端側合成一份新的 state，可以有效得減少遠程調用的下行流量。為此，我們根據 RFC6901/6902 中關於 json pointer 和 json patch 的規範，在 dart 上實現了json_patch 庫。我們在閑魚內的“下單頁”做了測試，“修改地址”操作將會涉及“地址信息”、“紅包”、“運費”、“最終價格”數據，使用 diff 後大約可以減少 50% 的下行流量。
在一體化開發中，我們發現，經常會需要在端側順序得執行多個 action。最簡單的一個例子，端側在進行 FaaS調用的時候通常都會 show 一個 progress 來阻塞用戶的後續操作，那麼當 FaaS 執行完業務邏輯並返回準備好的 state 數據之後，會通過 engine 讓頁面進行繪製。但是慢著，大家有沒有發現哪裡不對勁，這個 progress 還 show 在那裡，誰來執行 hide progress 的操作呢？所以這種時候 FaaS 會需要下發一個batch類型的 action，順序得讓端側的 engine 執行 UI update 和 hide progress。

當然開發者可以基於 batch 做更多複雜得 action 編排。所以本質上 batch 類型的 action 提供給開發者一個順序編排執行邏輯的能力。避免了多次來回請求的開銷，也會讓執行邏輯變得更加得清晰。

上一頁我們已經把 nexus 協議想要解決的問題說清楚了，那麼作為具體執行協議的 Engine，它所需要提供的功能就非常明顯了。首先它必須能夠執行一種協議到具體邏輯代碼的映射功能，這裡麵包含了協議的解析、函數的映射、函數的執行。最後我們還需要給它加上執行上下文的管理功能。上圖中的紅色部分，是 Engine 對外提供的功能，包括允許外部進行函數註冊，以及外部可以調用某個 API 來進行函數調用。

綠色的部分為 Engine 內部需要提供的功能，包括協議的解析、目標函數的匹配和執行上下文的管理。函數註冊、執行函數、解析消息、函數匹配這四個功能是比較容易想到的。對於執行上下文管理功能。Engine 實際上除了綁定了 Action 這種協議載體之外，並不綁定任何的框架或者端側環境，也就是說對 Engine 來說，你運行在 android native 還是 flutter 環境，對它都沒有影響，它依然可以完成自己對接 Action 協議的使命。這種設計是為了儘可能得給 engine 解綁，也可以釋放 Engine 的能力以提供業務方進行上層框架的自定義。

最後也是這裡把它單獨領出來的一塊，橘黃色的部分，“內置的通用函數”。也就是上面所說的 remote-req、state-change、state-diff 和 batch。