本文將分享我們在FaaS化過程中的經(jīng)驗，嘗試回答關于FaaS的Why、What、How三個問題，給對FaaS有興趣的同學提供一些實踐經(jīng)驗。

背景介紹

從2019年開始，作為集團FaaS的實踐先鋒隊，大淘寶技術行業(yè)團隊在FaaS領域摸爬滾打了三年，并在iFashion、天貓運動等多個業(yè)務場景落地。這篇文章是想分享一下我們在FaaS化過程中的經(jīng)驗，嘗試回答關于FaaS的Why、What、How三個問題，給對FaaS有興趣的同學提供一些實踐經(jīng)驗。

業(yè)務背景

?行業(yè)業(yè)務特點

大家可以在手機淘寶搜索“淘寶吃貨”、“iFashion”等關鍵詞，會進入一個輕應用，這些輕應用都是行業(yè)運營的陣地。

上圖展示了輕應用的典型數(shù)據(jù)邏輯。這些輕應用的主要邏輯都在BFF層，大量的需求都是進行接口和數(shù)據(jù)的拼裝，比較適合FaaS接入。以運動頻道的Feeds模塊為例，其流程如上圖所示。其中藍色部分是運營小二的離線配置，紅色部分為在線鏈路，這個流程對大部分的頻道模塊都是適用的。

行業(yè)數(shù)據(jù)邏輯的特點是大部分的數(shù)據(jù)能力都是已有的中臺能力，我們只是在BFF層做數(shù)據(jù)的拼裝?！?重流程編排，輕數(shù)據(jù)資產(chǎn) ”的特性，決定了行業(yè)頻道的Java部分大部分時候都是在做一些接口的聚合調(diào)用，把數(shù)據(jù)組織成前端模塊需要的結構占開發(fā)工作很大的比重。這種場景比較適合前端用FaaS來全部承接，去掉前后端對接的過程，即可以減少總體人力投入，又可以使前端能夠深入業(yè)務底層邏輯。

?生產(chǎn)關系的轉變

如上圖所示，在FaaS化之前，傳統(tǒng)的前后端分離的生產(chǎn)關系存在天然的缺陷。由于數(shù)據(jù)拼裝本身和UI邏輯是強耦合的，分成兩個人去做，會導致存在天然的邊界不清、聯(lián)調(diào)成本高等問題，導致整個需求的開發(fā)周期變長。我們希望把邏輯拼裝交給前端來做，而后端下沉到數(shù)據(jù)中臺，專心做對他們來講價值更好的中臺服務。這樣可以實現(xiàn)三方共贏。改變之后的生產(chǎn)關系如下圖所示：

?FaaS化進展和收益

大淘寶行業(yè)除了個別業(yè)務外，前后有超過10個輕應用完成了FaaS化，大部分需求由前端獨立承接。前端在業(yè)務中從一個寫頁面的工具人，變成了深入業(yè)務邏輯，有業(yè)務話語權，并能推動業(yè)務發(fā)展的合伙人。

FaaS化對前端來說， 本質上是進行了生產(chǎn)關系的轉變 ，而這個生產(chǎn)關系的轉變，不僅僅是我們搶了后端的活。任何團隊在思考FaaS的時候，第一個想到的肯定不是怎么做，而是為什么這么做？帶來的價值是什么？

我想從3個層次來說明FaaS化打來的價值，而這三個維度正如上圖所示，其實是一個遞進的關系：

1. 賦能前端：從前端自己的角度來講，通過FaaS擴大職責邊界，可以更加深入業(yè)務，從一個業(yè)務資源變成業(yè)務的主人，才有可能真正為業(yè)務的目標起到自己的作用（而不是簡單的接需求）。
2. 提升總體研發(fā)效率：傳統(tǒng)前后端分離的研發(fā)方式，每個需求都需要至少2個技術同學參加，且有大量時間在進行溝通和聯(lián)調(diào)。現(xiàn)在需求只需要一個前端同學參與，且自己定義前后端接口和邏輯，更加靈活方便。
3. 成為業(yè)務合伙人：對于產(chǎn)品運營來說，他們不是很關注研發(fā)效率，如何幫助促成業(yè)務目標，比如提升總成交額，是他們比較關心的。生產(chǎn)關系的轉變，最終需要回歸業(yè)務，需要思考如何為業(yè)務創(chuàng)造價值。這方面我們還在探索中，有一個方向是通過數(shù)據(jù)分析驅動精細化運營。

大淘寶FaaS解決方案

從19年的哇哦視頻FaaS化開始（傳送門 哇哦視頻FaaS ），F(xiàn)aaS解決方案經(jīng)過3年的不斷探索發(fā)展，已經(jīng)有比較成熟解決方案，這是一個簡化版的FaaS架構：

1. Serverless研發(fā)平臺提供了完善的FaaS研發(fā)鏈路，包括從創(chuàng)建、發(fā)布到運維的完整能力，并提供了多個個性化解決方案和租戶自定義能力
2. 基礎設施層提供了FaaS Serverless 解決方案，包括：FaaS編程平面、豐富的中間件、運行時容器、高可用性保障等。
3. 底層服務包括通用的算法、數(shù)據(jù)存儲能力，行業(yè)團隊自定義的服務以及二方三方的通用能力，這些能力都可以通過中間件進行調(diào)用

行業(yè)的實踐經(jīng)驗

? 怎么判斷我的業(yè)務場景是否合適

雖然每個業(yè)務場景都有自己的特色，要不要用FaaS取決于兩個方面：成本和收益。我們分別說說這兩個方面應該如何考量。

正如前文所說行業(yè)團隊目前是選擇在“重邏輯編排、輕數(shù)據(jù)資產(chǎn)”的行業(yè)頻道中進行FaaS實踐，實際上除了做BFF編排之外，根據(jù)業(yè)務需要我們也做了離線任務、數(shù)據(jù)存儲等大前端之外的工作。大家可以從上面的幾個維度，來衡量RIO，再決定是否使用FaaS。

? 如何從零開始在業(yè)務中落地FaaS

如果是新業(yè)務，評估過成本和收益的合理性后，用FaaS承接一般不存在問題。這里主要針對老業(yè)務，一般情況下我們都是對已有的業(yè)務進行FaaS化改造，有兩種方案推進的方案：

1. 一次性全部遷移

1. 在天貓V榜、iFashion等業(yè)務中，我們采取的是全盤重構的方案，專門抽出一個月左右的時間把所有的Java代碼翻譯成等價的FaaS代碼。
2. 這個方案的好處是可以一次性解決歷史遺留問題，以后可以專心做FaaS。難點是復雜的業(yè)務可能遷移時間很長，如果同時進行業(yè)務需求就會很被動，并且進行這么大的改動有較大風險。

2. 新需求逐步遷移

1. 運動、吃貨等頻道采取的是這個方案，在接新需求的同時，把已有的Java代碼遷移成FaaS，一些改動很大的需求直接重寫。對于沒有需求的老模塊，保持原狀直到有新需求。
2. 這樣做的好處是循序漸進漸進，工作量和風險都可控；不足之處是持續(xù)時間比較長，且每次業(yè)務需求都會花額外時間進行代碼遷移導致需求交付周期變長。

方案1都是早期進行時采取的，可以比較快拿到結果，但風險也較高。目前我們都是采用方案2，在業(yè)務中逐步進行FaaS化改造，也推薦大家采用方案2。

FaaS的研發(fā)鏈路相比于傳統(tǒng)的前端研發(fā)，也多出了很多環(huán)節(jié)。如上圖所示，其中灰色的環(huán)節(jié)大家比較熟悉，橙色的環(huán)節(jié)對部分前端同學來說可能比較陌生。FaaS和前端最大的區(qū)別在于，我們需要關注2個新的方面：

1. 數(shù)據(jù)邏輯 ：我們需要知道數(shù)據(jù)從哪里來，怎么接入，如何組織數(shù)據(jù)。
2. 大流量場景 ：需要評估流量有多大，大流量下對整個系統(tǒng)的承載能力要有一定的要求。需要通過壓測來保障大流量場景的穩(wěn)定性
3. 運維 ：即使Serverless少了很多運維工作，對數(shù)據(jù)的監(jiān)控以及應急處理線上故障的工作還是必不可少的。

? 穩(wěn)定性保障

首次上線FaaS函數(shù)后，最擔心的情況就是線上時不時會出現(xiàn)一些錯誤率、RT等告警，讓人寢食難安。前端同學對傳統(tǒng)后端的穩(wěn)定性保障缺少經(jīng)驗，我總結了下，大家可以從如下幾個方面保障業(yè)務的穩(wěn)定性：

這里重點說一下流量評估和兜底方案。

1. 流量評估 ：流量評估有兩個目的，一是為了計算出對下游依賴服務的流量，二是為了計算出需要的容器數(shù)。

1. 如何評估峰值流量QPS？對于大促場景，我們一般會結合去年同期的大促流量加上今年的預期做一個評估；對于一些日常流量比較穩(wěn)定且均勻的業(yè)務，一般會可以用這個經(jīng)驗公式計算平均QPS： 平均QPS = 日均PV/5萬 ，用平均QPS乘以一個安全的系數(shù)作為峰值QPS
2. 單容器并發(fā)能力？單容器的并發(fā)能力可以通過小流量的壓測來確定，不過大部分時候不用特別精確，因為很可能業(yè)務需求的變更就會導致容器并發(fā)能力的變化，對于流量比較小的業(yè)務，很多時候就用默認值即可

2. 兜底方案 ：線上接口無法做到100%的成功率，一方面因為任何Serverless容器都無法保障100%的穩(wěn)定性，以阿里云為例，承諾SLA為99.975%（云服務器ECS服務等級協(xié)議）；另一方面是接口依賴的下游服務也存在一些不穩(wěn)定性。對于這種系統(tǒng)層面的風險，我們通過兜底方案來解決。兜底服務的原理，是每隔固定一段時間，就會把接口的成功數(shù)據(jù)寫到服務器緩存和CDN中，如果接口出現(xiàn)問題，就會從緩存或者CDN中去讀上一次寫入的兜底數(shù)據(jù)。降級后的數(shù)據(jù)存在的一個問題就是無法做到千人千面，因為千人千面去存數(shù)據(jù)的話量太大。

云服務器ECS服務等級協(xié)議 地址：https://terms.aliyun.com/legal-agreement/terms/suit_bu1_ali_cloud/suit_bu1_ali_cloud201909241949_62160.html?spm=a1zaa.8161610.0.0.291545367B6t5A

? 其他一些經(jīng)驗

1. 性能優(yōu)化 ：FaaS函數(shù)理論上應該能達到和Java函數(shù)同等的性能指標，比如典型的招排補邏輯， RT 一般是在 250ms 左右。性能優(yōu)化體現(xiàn)在兩個方面：編碼和架構。編碼層面上應該盡量避免串行請求，減少不必要的字段解析和傳輸，靈活應用緩存。架構層面可以結合SSR、邊緣計算等方式提升首屏性能。
2. 人員能力 ： 一些前端同學對于后端架構了解不深 ，在剛開始做FaaS的時候面對大量的后端名詞時候，往往會一頭霧水，甚至無法正常評審業(yè)務需求。如果每次碰到不同的地方再去學習，很容易陷入到碎片知識總中，缺少對整個體系的整體認知。我們在很久以前對團隊做過一個專題培訓，并沉淀了一個系列文檔，從大的框架上闡述了整個數(shù)據(jù)架構。
3. 資產(chǎn)沉淀 ：FaaS實踐中，約一半的工作都在進行各種字段的補全，我們把這些補全都根據(jù)實體的不同，沉淀到實體數(shù)據(jù)模型中。另外還有有一些通用的faas函數(shù)可以做成服務給其他的業(yè)務調(diào)用。這些都是比較有價值的FaaS資產(chǎn)。

低代碼探索經(jīng)驗

在源碼研發(fā)的過程中發(fā)現(xiàn)，行業(yè)業(yè)務大部分都具有一樣的邏輯模式：召回->補全->排序。我們嘗試通過一種低代碼的方式，能減少這種重復的編碼工作，用可視化的界面編排出這種數(shù)據(jù)邏輯。經(jīng)過大半年的探索，我們創(chuàng)建了織郎平臺，并在三個BU中生產(chǎn)了1000+接口，服務100+用戶。

織郎平臺提供了如下一些能力：

1. 可視化編排 ：通過可視化操作編排出FaaS接口。
2. 完整研發(fā)鏈路 ：創(chuàng)建、編輯、發(fā)布、監(jiān)控等完整的研發(fā)流程，并且能大幅縮短構建發(fā)布時間。
3. 運行時環(huán)境隔離： 在相同容器中，運行時對租戶和函數(shù)的隔離，可以極大提升容器的利用率。
4. 開放協(xié)議 ：織郎定義了一套JSON協(xié)議和配套的SDK，業(yè)務方可以在這套能力上構建出符合自己需求的上層產(chǎn)品

總結

Node FaaS 對于前端工程師的意義在于它可以拓展我們的能力邊界，讓我們有能力用自己熟悉的知識去做更多的事情。而一旦我們用Node FaaS去做一些事情，那就不僅僅是我們自己的工作變了，而是整個研發(fā)的生產(chǎn)關系發(fā)生了變化。怎么從這個變化的生產(chǎn)關系中找到實際的價值，是我們需要深入思考和探索的。如果大家有做FaaS的打算，不要盲目開始，除了文中說的價值判斷原則外，可以先問自己一個靈魂問 題：

你們搞Node FaaS不就是搶了Java的活么？

作者:李宏訓（任行）

來源:微信公眾號:大淘寶技術

出處:https://mp.weixin.qq.com/s?__biz=MzAxNDEwNjk5OQ==&mid=2650472255&idx=1&sn=44c6d7462eb58b09d42373db80b99101