本文將分享我們?cè)贔aaS化過(guò)程中的經(jīng)驗(yàn)，嘗試回答關(guān)于FaaS的Why、What、How三個(gè)問(wèn)題，給對(duì)FaaS有興趣的同學(xué)提供一些實(shí)踐經(jīng)驗(yàn)。

背景介紹

從2019年開(kāi)始，作為集團(tuán)FaaS的實(shí)踐先鋒隊(duì)，大淘寶技術(shù)行業(yè)團(tuán)隊(duì)在FaaS領(lǐng)域摸爬滾打了三年，并在iFashion、天貓運(yùn)動(dòng)等多個(gè)業(yè)務(wù)場(chǎng)景落地。這篇文章是想分享一下我們?cè)贔aaS化過(guò)程中的經(jīng)驗(yàn)，嘗試回答關(guān)于FaaS的Why、What、How三個(gè)問(wèn)題，給對(duì)FaaS有興趣的同學(xué)提供一些實(shí)踐經(jīng)驗(yàn)。

業(yè)務(wù)背景

?行業(yè)業(yè)務(wù)特點(diǎn)

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

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

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

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

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

?FaaS化進(jìn)展和收益

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

FaaS化對(duì)前端來(lái)說(shuō)， 本質(zhì)上是進(jìn)行了生產(chǎn)關(guān)系的轉(zhuǎn)變 ，而這個(gè)生產(chǎn)關(guān)系的轉(zhuǎn)變，不僅僅是我們搶了后端的活。任何團(tuán)隊(duì)在思考FaaS的時(shí)候，第一個(gè)想到的肯定不是怎么做，而是為什么這么做？帶來(lái)的價(jià)值是什么？

我想從3個(gè)層次來(lái)說(shuō)明FaaS化打來(lái)的價(jià)值，而這三個(gè)維度正如上圖所示，其實(shí)是一個(gè)遞進(jìn)的關(guān)系：

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

大淘寶FaaS解決方案

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

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

行業(yè)的實(shí)踐經(jīng)驗(yàn)

? 怎么判斷我的業(yè)務(wù)場(chǎng)景是否合適

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

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

? 如何從零開(kāi)始在業(yè)務(wù)中落地FaaS

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

1. 一次性全部遷移

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

2. 新需求逐步遷移

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

方案1都是早期進(jìn)行時(shí)采取的，可以比較快拿到結(jié)果，但風(fēng)險(xiǎn)也較高。目前我們都是采用方案2，在業(yè)務(wù)中逐步進(jìn)行FaaS化改造，也推薦大家采用方案2。

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

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

? 穩(wěn)定性保障

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

這里重點(diǎn)說(shuō)一下流量評(píng)估和兜底方案。

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

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

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

云服務(wù)器ECS服務(wù)等級(jí)協(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)驗(yàn)

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

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

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

織郎平臺(tái)提供了如下一些能力：

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

總結(jié)

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

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

作者:李宏訓(xùn)（任行）

來(lái)源:微信公眾號(hào):大淘寶技術(shù)

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