深入淺出FaaS應用場景：資料編排

通過上一篇深入淺出FaaS的兩種程式模型瞭解到FaaS 的程式模型有兩種：常駐程式型和用完即毀型。常駐程式型是為了適應傳統 MVC 架構設計的，它看起來並不自然；如果你從現在開始玩 FaaS 的話，我當然首選推薦用完即毀型，它可以最大限度發揮 FaaS 的優勢！

接下來，我們就繼續把焦點放到用完即毀型上，來具體看看它可以用在哪些更加自然的場景裡。

資料編排

我們做開發的多多少少都知道，目前最成功最廣泛的設計模式就是 MVC 模式。但隨著前端 MVVM 框架越來越火，前端 View 層逐漸前置，發展成 SPA 單頁應用；後端 Control 和 Model 層逐漸下沉，發展成面向服務程式設計的後端應用。

這種情況下，前後端更加徹底地解耦了，前端開發可以依賴 Mock 資料介面完全脫離後端限制，而後端的同學則可以面向資料介面開發，但這也產生了高網路 I/O 的資料閘道器層。

Node.js 的非同步非阻塞和 JavaScript 天然親近前端工程師的特性，自然地接過資料閘道器層。因此也誕生了 Node.js 的 BFF 層 (Backend For Frontend)，將後端資料和後端介面編排，適配成前端需要的資料結構，提供給前端使用。

我們的程式設計師好朋友小程也跟進了這個潮流，將“待辦任務”Web 服務重構成了第二個版本。他將原先的應用拆解成了 2 個專案：前端專案採用 React+AntDesignPro+Umi.js的單頁應用，後端專案還是採用 Express。我的示例也採用這個技術架構一步一步教你在雲上部署 SPA+FaaS 混合框架演進。

如上圖所示，BFF 層充當了中間膠水層的角色，粘合前後端。未經加工的資料，我們稱為後設資料 Raw Data，對於普通使用者來說後設資料幾乎不可讀。所以我們需要將有用的資料組合起來，並且加工資料，讓資料具備價值。對於資料的組合和加工，我們稱之為資料編排。

BFF 層通常是由善於處理高網路 I/O 的 Node.js 應用負責。傳統的服務端運維 Node.js 應用還是比較重的，需要我們購買虛擬機器，或者使用應用託管 PaaS 平臺。

因為 BFF 層只是做無狀態的資料編排，所以我們完全可以用 FaaS 用完即毀型模型替換掉 BFF 層的 Node.js 應用，也就是最近圈子裡老說的那個新名詞 SFF（Serverless For Frontend）

好，到這兒，我們已經理解了 BFF 到 SFF 的演進過程，現在我們再串下新的請求鏈路邏輯。前端的一個資料請求過來，函式觸發器觸發我們的函式服務；我們的函式啟動後，呼叫後端提供的後設資料介面，並將返回的後設資料加工成前端需要的資料格式；我們的 FaaS 函式完全就可以休息了。具體如下圖所示。

另外，除了我們自己的後端應用資料介面，網際網路上還有大量的資料供我們使用。比如疫情期間，你要爬取下各個地區的疫情資料、天氣資料，這些工作，也都可以放到 FaaS 上輕鬆搞定，並且基本還能免費，因為目前各大雲服務商都提供了免費的額度，這個我剛給你講過了。

編排後端介面，編排網際網路上的資料，這倆場景我想你也很容易想到。不過，我覺得，編排雲服務商的各種服務才能讓你真正體會到那種觸電的感覺！

基礎篇：FaaS的拆解和編排

• 阿里舉集團之力趟坑Serverless,到底它能解決什麼問題？
• 通過一個Serverless案例，理解FaaS的執行邏輯
• 深入淺出FaaS的兩種程式模型