前言

首先為大家簡(jiǎn)單介紹一下我們的業(yè)務(wù)場(chǎng)景，1688 隸屬于阿里集團(tuán)的國(guó)內(nèi)貿(mào)易事業(yè)部（CBU），是阿里最早起家的業(yè)務(wù)，已有十幾年的歷史。我們主要負(fù)責(zé) PC 端 1688.com 以及手機(jī)端阿里巴巴 APP，是目前國(guó)內(nèi)最大的 B 類電商交易平臺(tái)，主要面向 B2B 電商業(yè)務(wù)的場(chǎng)景，為中小企業(yè)提供零售、批發(fā)、分銷以及加工定制等電商交易渠道。

我本人是在 1688 團(tuán)隊(duì)的無線服務(wù)端技術(shù)團(tuán)隊(duì)，團(tuán)隊(duì)主要是給 App 端提供業(yè)務(wù)支持，負(fù)責(zé) 1688 手機(jī)端 App 內(nèi)部的各種場(chǎng)景構(gòu)建，比如首頁推薦、商品詳情等等，也是典型的電商業(yè)務(wù)場(chǎng)景。

（電商業(yè)務(wù)場(chǎng)景）

Serverless 落地選型

（FaaS 在 1688 復(fù)雜業(yè)務(wù)場(chǎng)景下的提效實(shí)踐）

1688 對(duì) FaaS (Function as a Serverles) 技術(shù)的探索要追溯到 2015 年左右。當(dāng)時(shí)整個(gè)阿里集團(tuán)最大的業(yè)務(wù)目標(biāo)就是 “ALL IN 無線”，移動(dòng)互聯(lián)網(wǎng)剛剛興起，需要快速地把存在 PC 端的業(yè)務(wù)，無論是淘寶也好；還是 1688，需要能夠迅速地把它移植到移動(dòng)端上面，生成 App 來搶占移動(dòng)端流量。

在這樣一個(gè)大的業(yè)務(wù)背景下，1688 的解決方法是設(shè)立無線服務(wù)端。通過微服務(wù)體系調(diào)用 PC 端存量的業(yè)務(wù)接口，然后面向前臺(tái)的移動(dòng)端業(yè)務(wù)去進(jìn)行一些輕量的業(yè)務(wù)邏輯編排和 UI 層的映射，最后通過移動(dòng)網(wǎng)關(guān)，就可以快速為 APP 端提供擁有同樣業(yè)務(wù)能力的服務(wù)接口。

移動(dòng)互聯(lián)網(wǎng)端的功能迭代非常之快，在這種模式下，我們很快遇到了問題：傳統(tǒng)的微服務(wù)體系構(gòu)建、發(fā)揮、部署和調(diào)試時(shí)間都非常漫長(zhǎng)，而面向前臺(tái)的業(yè)務(wù)改動(dòng)又非常頻繁，速度要求很快。技術(shù)能力和業(yè)務(wù)訴求之間產(chǎn)生的錯(cuò)位，push 著我們?nèi)ふ液吞剿鞲玫慕鉀Q方案。

FaaS 能力落地的兩個(gè)階段

FaaS 在 CBU 內(nèi)部的落地經(jīng)歷了兩個(gè)大階段。第一個(gè)階段是 2015 年，部門內(nèi)部自研了一套基于 JVM 的動(dòng)態(tài)加載系統(tǒng)，來實(shí)現(xiàn)快速發(fā)布、快速上線、熱部署等等，基本實(shí)現(xiàn)了 FaaS 的效果。第二階段則是從去年開始，我們與阿里云 FC 團(tuán)隊(duì)進(jìn)行共建，將整個(gè) FaaS 能力的底座更換為阿里云的函數(shù)計(jì)算，以獲得更好的彈性伸縮、容器隔離等能力。

（1） MBOX：基于 JVM 動(dòng)態(tài)加載能力的 FaaS 系統(tǒng)

前文說到，在整個(gè)無線端業(yè)務(wù)快速迭代的背景下，我們需要一種能夠?qū)崿F(xiàn)快速發(fā)布變更服務(wù)端接口的能力。在 2015 年左右，Java 工程界主流的思路是充分利用 JVM 的動(dòng)態(tài)加載特性：即在不重啟 JVM 的前提下，通過一定的機(jī)制將外部的代碼實(shí)時(shí)編譯成 class 字節(jié)碼，然后動(dòng)態(tài)地載入正在運(yùn)行的 JVM 實(shí)例中，從而實(shí)現(xiàn)熱加載的效果。

于是，基于上述的思路，我們打造了一套基于 JVM 的動(dòng)態(tài)服務(wù)加載系統(tǒng) —— MBOX。在 MBOX 中，我們構(gòu)建了一個(gè)通用的輕量服務(wù)容器，該容器可以接收來自外部的一段代碼（可能是一個(gè) Java 類或者是一個(gè)簡(jiǎn)單的 groovy 腳本），并對(duì)代碼進(jìn)行實(shí)時(shí)的編譯，生成 class 字節(jié)碼。之后容器本身還會(huì)對(duì)生成的字節(jié)碼進(jìn)行一定的安全加固操作（如消除死循環(huán)等），最后通過一個(gè)自定義 class loader 把它加載成線上正在運(yùn)行的 JVM 中的一個(gè) class，生成對(duì)象實(shí)例、注入中間件代理，便可以對(duì)外提供服務(wù)。

基于 MBOX，我們實(shí)現(xiàn)了在線編碼、在線預(yù)覽和秒級(jí)發(fā)布的能力，以現(xiàn)在的視角來看，它就是一個(gè)非常典型的 FaaS 服務(wù)平臺(tái)，并具備以下特點(diǎn)： 一、相比于傳統(tǒng)微服務(wù)，它是在線開發(fā)的模式，隨寫隨用，所見及所得，研發(fā)效率非常高。 二、熱加載更新機(jī)制。它可以做到秒級(jí)的發(fā)布，整個(gè)業(yè)務(wù)上線的迭代效率十分高。 三、對(duì)于使用平臺(tái)的開發(fā)者來講，它帶來了 Serverless 的體驗(yàn)，因?yàn)樗械倪\(yùn)維、機(jī)器部署等等，全部是由 MBOX 平臺(tái)來承擔(dān)，開發(fā)只需要關(guān)心其業(yè)務(wù)邏輯的實(shí)現(xiàn)即可。（在這里，我們扮演了類似現(xiàn)在云服務(wù)廠商的角色）

在長(zhǎng)達(dá)五年的時(shí)間里，MBOX 系統(tǒng)承載了整個(gè) 1688 超過 10 萬 QPS 的業(yè)務(wù)調(diào)用，巔峰時(shí)期有超過 1500 個(gè)線上函數(shù)，節(jié)省了大量人力資源，在整個(gè)無線業(yè)務(wù)擴(kuò)張階段立下了汗馬功勞，也為我們的 Serverless 技術(shù)探索之路打開了一扇大門。

說完了優(yōu)點(diǎn)，我們?cè)僬勔徽勥@套系統(tǒng)的缺點(diǎn)和風(fēng)險(xiǎn)：

首先，第一點(diǎn)是隔離性問題，因?yàn)槭?MBOX 基于 JVM 的，JVM 本身沒有辦法提供有效的資源隔離機(jī)制（如 CPU、內(nèi)存等），所以存在比較大的安全風(fēng)險(xiǎn)：即同一個(gè)業(yè)務(wù)容器中加載的多個(gè)服務(wù)之間會(huì)彼此產(chǎn)生影響。比如今天這個(gè)業(yè)務(wù)集群 A 上面有一個(gè)人寫的代碼發(fā)生了內(nèi)存泄露，結(jié)果可能是整個(gè)集群的性能都被拖慢，上面所有的服務(wù)都會(huì)受到影響，這是一個(gè)非常嚴(yán)重的安全隱患。

第二點(diǎn)是代碼的開發(fā)模式太輕，純腳本式開發(fā)，只能寫個(gè)代碼片段，雖然開發(fā)起來很快很爽，但是沒有工程結(jié)構(gòu)，不能使用框架、不能使用任何的設(shè)計(jì)模式，這樣導(dǎo)致可應(yīng)用場(chǎng)景非常受限，代碼本身的質(zhì)量也很差。

第三點(diǎn)對(duì)于 MBOX 的維護(hù)方來說，資源的管理是一個(gè)非常頭疼的問題，經(jīng)常遇到整個(gè)集群水位飆升，但是又沒有辦法判斷出來到底是哪一個(gè)服務(wù)在里面占用了資源的情況。而系統(tǒng)本身又無法很好的進(jìn)行彈性伸縮，只能依賴人肉手動(dòng)擴(kuò)容，到了平臺(tái)維護(hù)的后期，運(yùn)維成本是非常高的。

到了 2019 年左右，MBOX 的一些問題已經(jīng)比較凸顯了，而這時(shí)業(yè)界在 Kubernetes 的影響之下，掀起了 Serverless 和云原生的技術(shù)浪潮，我們立刻開始了對(duì)應(yīng)的技術(shù)調(diào)研，最終在 2020 年底與阿里云函數(shù)計(jì)算團(tuán)隊(duì)展開共建，希望能夠打造一套真正面向云原生的 FaaS 平臺(tái)。

（2) 阿里云 FC：基于 Serverless + Sidecar 的 FaaS 系統(tǒng)

阿里云函數(shù)計(jì)算（FC）在 Kubernetes 容器自動(dòng)運(yùn)維能力的基礎(chǔ)上，打造出了一套高彈性、強(qiáng)隔離，且易于開放定制的 FaaS 基建，目前已經(jīng)基本成為整個(gè)阿里集團(tuán)內(nèi)部 FaaS 能力的統(tǒng)一解決方案。

除了底層高度成熟和強(qiáng)大的彈性自動(dòng)運(yùn)維能力之外，FC 還提供了開放度非常高的 Runtime 設(shè)計(jì)，任何語言甚至是任何團(tuán)隊(duì)都可以定制自己的運(yùn)行時(shí)框架，從而最大限度滿足業(yè)務(wù)一線開發(fā)人員的訴求。

對(duì)于跨語言的老大難問題 —— 中間件調(diào)用上，FC 團(tuán)隊(duì)和中間件團(tuán)隊(duì)，結(jié)合微軟最新開源的 DAPR 技術(shù)，實(shí)現(xiàn)了一套標(biāo)準(zhǔn)化的 Sidecar 能力，涵蓋了 RPC、緩存、消息隊(duì)列、配置中心等常見中間件，抹平多語言差異的同時(shí)進(jìn)一步精簡(jiǎn)了用戶的運(yùn)行時(shí)容器，讓函數(shù)的冷啟動(dòng)和彈性速度得以進(jìn)一步提升。

最終在 FC 底層強(qiáng)大技術(shù)的支撐下，我們一同共建了面向集團(tuán)內(nèi) Java 研發(fā)者通用的 Runtime 框架及研發(fā)運(yùn)維配套設(shè)施，替換了原有的 JVM MBOX 系統(tǒng)，實(shí)現(xiàn)了 FaaS 能力的技術(shù)換代。

回顧 CBU 的 Serverless 演進(jìn)之路，從最早的微服務(wù)架構(gòu)，到自主研發(fā)的 JVM FaaS 系統(tǒng)，再到現(xiàn)在的 FC 函數(shù)計(jì)算，逐步探索出了最適合業(yè)務(wù)場(chǎng)景的技術(shù)方案，同時(shí)也算是在業(yè)界率先邁出了大規(guī)模落地 FaaS 的一步：作為集團(tuán)第一批大規(guī)模落地 Serverless 理念的部門，我們的 FaaS 系統(tǒng)在部門內(nèi)擁有超過 80% 的業(yè)務(wù)滲透率，使用時(shí)間更是達(dá)到了 5 年以上。

FaaS 落地的靈魂三問

在了解了 FaaS 的能力和實(shí)現(xiàn)之后，我們接下來討論大家最關(guān)心的問題：如何在業(yè)務(wù)系統(tǒng)中落地 FaaS 能力？

以我們過往的實(shí)踐經(jīng)驗(yàn)，在實(shí)際業(yè)務(wù)中落地 FaaS 并非大部分人想象中那么 “絲滑”，勢(shì)必會(huì)遇到一些問題，這里提煉了三個(gè)我們認(rèn)為最核心的 “靈魂拷問”：

一是：存量業(yè)務(wù)的改造。對(duì)于存量的業(yè)務(wù)（尤其是我們這種已經(jīng)持續(xù)運(yùn)行了很多年的業(yè)務(wù)），有大量的歷史包袱不能拋掉。這就面臨一個(gè)問題，線上大量的傳統(tǒng) Serverful App，怎么去轉(zhuǎn)換成 Serverless Function？直接進(jìn)行改造風(fēng)險(xiǎn)是非常大的，是否有辦法在保障現(xiàn)有業(yè)務(wù)穩(wěn)定運(yùn)行的前提下，以最小的成本獲得 FaaS 帶來的優(yōu)勢(shì)？

二是：FaaS 的碎片化問題。傳統(tǒng) Serverful 應(yīng)用的構(gòu)建思路是非常高內(nèi)聚的，某個(gè)業(yè)務(wù)的核心能力基本都聚合在幾個(gè)微服務(wù)應(yīng)用中，數(shù)量相對(duì)較少。但是函數(shù)不同，它輕量化的特點(diǎn)會(huì)導(dǎo)致數(shù)量膨脹非常快，如果不加以設(shè)計(jì)和控制，那么很容易出現(xiàn)一個(gè)業(yè)務(wù)背后對(duì)應(yīng)著幾十個(gè)函數(shù)的碎片化情景出現(xiàn)。

三是：研發(fā)提效的問題。業(yè)界目前普遍認(rèn)為 Serverless 能夠大幅提升研發(fā)效率，但是真正落地之后會(huì)發(fā)現(xiàn)研發(fā)提效這件事情，并沒有那么簡(jiǎn)單，只是將傳統(tǒng)的 Serverful 應(yīng)用換成 Serverless 函數(shù)能夠帶來的研發(fā)提效幅度是非常有限的。

存量的復(fù)雜業(yè)務(wù)如何與 FaaS 結(jié)合？

首先回答第一個(gè)問題，在存量復(fù)雜業(yè)務(wù)和 FaaS 能力結(jié)合這件事上，通過實(shí)踐探索，我們總結(jié)出了兩種比較落地的模式，分別是 BFF 模式和擴(kuò)展點(diǎn)模式。

(1) BFF 模式

BFF 模式是現(xiàn)在 FaaS 落地比較常見的一種主流做法。我們可以把傳統(tǒng) Serverful App 里面的邏輯進(jìn)行一些抽象，一般來說在我們可以根據(jù)變更的頻繁度，將業(yè)務(wù)場(chǎng)景中的邏輯分為兩層：一部分的代碼邏輯比較輕，同時(shí)沒有一些復(fù)雜的依賴，但是產(chǎn)品的需求可能大部分集中在這部分，稱其為變動(dòng)層。

另一部分的代碼可能是業(yè)務(wù)的應(yīng)用框架，中間件二方依賴，以及一些核心的重業(yè)務(wù)邏輯，相對(duì)來說改動(dòng)不會(huì)太多，但是改造風(fēng)險(xiǎn)非常大，改造收益也可能不盡理想，稱其為穩(wěn)定層。

如果你的業(yè)務(wù)應(yīng)用可以按照上述的思路拆分，那就非常適合采用 BFF 模式，把變動(dòng)層抽象出來，放到 Serverless 函數(shù)中去，這樣就實(shí)現(xiàn)了一個(gè)類似 BFF 層的效果，前臺(tái)的消費(fèi)方其實(shí)是直接通過函數(shù)再去消費(fèi) Serverful App 里面穩(wěn)定層的 API。這樣就可以構(gòu)造一個(gè)業(yè)務(wù)的緩沖區(qū)，能夠?qū)崿F(xiàn)更快地發(fā)布 & 交付以及更少的運(yùn)維。雖然有相當(dāng)一部分的老代碼包袱還是丟不掉的，但是可以集中 80% 的精力提效。

這種模式比較適用于前臺(tái)類的業(yè)務(wù)場(chǎng)景，比如說傳統(tǒng)應(yīng)用 M-V-C 架構(gòu)當(dāng)中的 controller 層，就非常適合使用 FaaS 來替換。

(2) 擴(kuò)展點(diǎn)模式

第二種模式是擴(kuò)展點(diǎn)模式，擴(kuò)展點(diǎn)模式比較適合于偏中后臺(tái)的場(chǎng)景，或者說業(yè)務(wù)里面的一些中臺(tái)系統(tǒng)，例如我們的商品中心，就用到了這個(gè)模式。

對(duì)于中后臺(tái)類的應(yīng)用，一般本身就十分復(fù)雜，且業(yè)務(wù)邏輯非常多，加上歷史比較悠久，不適合進(jìn)行大刀闊斧地改造。但是我們可以把復(fù)雜的業(yè)務(wù)邏輯層進(jìn)行一定的抽象，面向未來設(shè)計(jì)一些關(guān)鍵的擴(kuò)展點(diǎn)，同時(shí)提供擴(kuò)展點(diǎn)的 FaaS 適配方案。

這樣對(duì)于一些后續(xù)增量的業(yè)務(wù)邏輯，就可以使用 FaaS 的能力來提供，而對(duì)于存量的業(yè)務(wù)邏輯，則可以基本保持不變，只需要在代碼結(jié)構(gòu)上稍作適配，也可以成為標(biāo)準(zhǔn)的擴(kuò)展點(diǎn)實(shí)現(xiàn)。

擴(kuò)展點(diǎn)模式的另一個(gè)好處是可以讓原來封閉式的架構(gòu)變得更加開放化，采用這種模式后，即便是中臺(tái)性質(zhì)的應(yīng)用，只要制定好擴(kuò)展點(diǎn)的對(duì)接規(guī)范，任何的業(yè)務(wù)方都可以通過提供自定義的 FaaS 函數(shù)來實(shí)現(xiàn)自己想要的擴(kuò)展能力。在 1688 的商品中臺(tái)系統(tǒng)中，就通過這種擴(kuò)展點(diǎn)模式實(shí)現(xiàn)了商品價(jià)格計(jì)算邏輯的業(yè)務(wù)開放化定制能力。

避免 FaaS 的碎片化問題

(1) 編程界面的權(quán)衡

早期我們?cè)?MBOX 系統(tǒng)中定義函數(shù)的編程界面時(shí)，采用的是腳本式編程，用戶的編程粒度就是一段代碼，一個(gè) Java 類。這種方式雖然寫起來非常輕量，但是會(huì)導(dǎo)致函數(shù)數(shù)量非常多 （為了實(shí)現(xiàn)一個(gè)稍復(fù)雜的業(yè)務(wù)，可能需要寫很多個(gè)腳本，同時(shí)由于沒有工程結(jié)構(gòu)，代碼質(zhì)量非常低下，也無法使用一些設(shè)計(jì)模式）。

因此在基于 FC 制定函數(shù)的編程界面時(shí)，我們基于上述經(jīng)驗(yàn)設(shè)定了一個(gè)規(guī)則，那就是用戶函數(shù)的運(yùn)行粒度應(yīng)該是一個(gè) “Micro App”，而不是 “Single Function”；編程界面的粒度應(yīng)該是一個(gè) “Code Project”，而不是 “Single Script”。

基于這樣的原則，對(duì)于開發(fā)者來說，一個(gè)函數(shù)實(shí)例更接近于一個(gè)微應(yīng)用，整體保留了最精簡(jiǎn)的工程結(jié)構(gòu)，即可以以較低的成本進(jìn)行單一功能點(diǎn)的實(shí)現(xiàn)，同時(shí)也可以進(jìn)行復(fù)雜邏輯的開發(fā)，引入各種二、三方庫，不至于產(chǎn)生非常嚴(yán)重的函數(shù)數(shù)量膨脹和碎片化問題。

(2) 建設(shè)內(nèi)部服務(wù)市場(chǎng)

采用了 Micro App 式的函數(shù)粒度定義，在業(yè)務(wù)中使用到的函數(shù)數(shù)量仍然會(huì)比傳統(tǒng)微服務(wù)應(yīng)用多出好幾個(gè)量級(jí)，為了解決這個(gè)問題，我們?cè)O(shè)計(jì)了【業(yè)務(wù)域 】-【函數(shù)組】- 【函數(shù)】- 【接口】四層緯度的函數(shù)分類定義，并在函數(shù)的工程模板里埋入了插件，在函數(shù)完成構(gòu)建發(fā)布的時(shí)候自動(dòng)采集上報(bào)這些分組分類信息，最終建設(shè)出面向內(nèi)部研發(fā)人員的函數(shù)服務(wù)市場(chǎng)，讓大家能夠直觀的看到當(dāng)前所存在的函數(shù)分類，以及各個(gè)接口 API 的歸屬信息。

研發(fā)效率的瓶頸在哪里？

讓開發(fā)者能夠 “Only focus on business”，這是 Serverless 從誕生之初就標(biāo)榜的核心理念，但是如果只是簡(jiǎn)單將運(yùn)維等底層基礎(chǔ)設(shè)置切換到 Serverless 的基建之上，引入 FaaS 等相關(guān)技術(shù)能力，其實(shí)對(duì)研發(fā)人員而言離真正意義上的 “Only focus on business” 還差很遠(yuǎn)。

在我們初期落地 Serverless 時(shí)，確實(shí)發(fā)現(xiàn)研發(fā)同學(xué)編寫代碼的效率好像高了很多，但是從整體的業(yè)務(wù)團(tuán)隊(duì)的業(yè)務(wù)需求交付角度來講，研發(fā)效能沒有發(fā)生質(zhì)變的提升：大部分的需求研發(fā)流程仍然比較冗長(zhǎng)，需求推進(jìn)過程中的溝通成本、協(xié)作成本依然巨高不下。仔細(xì)審視我們會(huì)發(fā)現(xiàn)，研發(fā)效能的關(guān)鍵瓶頸很多時(shí)候可能并不在于 “研發(fā)” 本身，而在于代碼之外。

那么 Serverless 能夠?yàn)檠邪l(fā)提效是否是一個(gè)偽命題呢？當(dāng)然也不是，首先，Serverless 和 FaaS 確實(shí)可以大幅度降低運(yùn)維和編碼的成本，提升效率；其次，Serverless 技術(shù)的出現(xiàn)讓服務(wù)端的技術(shù)門檻降低，使得一些非服務(wù)端專業(yè)的研發(fā)人員也能夠有能力開發(fā)一些簡(jiǎn)單的業(yè)務(wù)邏輯，這使得需求的全棧式開發(fā)成為可能。

從整體需求交付的效率來考量，假設(shè)研發(fā)人員能夠獨(dú)立完成整個(gè)需求的所有開發(fā)工作，無需和他人進(jìn)行聯(lián)調(diào)溝通，那么效率勢(shì)必是最大化的 — Serverless 為這種全新研發(fā)模式的落地和普及帶來了可能性，或許才是 “Only Focus on Business” 真正的意義所在。

總之，Serverless 也并不是提效的銀彈，事實(shí)上，沒有任何一門技術(shù)是銀彈，當(dāng)我們期望研發(fā)效能提升的時(shí)候，更多的還要從全局的視角來進(jìn)行審視，而不是將思路僅僅聚焦在“研發(fā)”階段。

復(fù)雜業(yè)務(wù)場(chǎng)景的提效實(shí)踐

最后我們以一個(gè)實(shí)際的業(yè)務(wù)場(chǎng)景為例子，給大家介紹一下 1688 在存量復(fù)雜業(yè)務(wù)場(chǎng)景下，是如何結(jié)合 FaaS 能力進(jìn)行研發(fā)提效的。

這里先簡(jiǎn)單介紹一下 1688 的商品詳情業(yè)務(wù)場(chǎng)景：商品詳情就是商品面向買家的最終展示頁面，承載了大量的商品信息。1688 的商品詳情頁和其他普通 C 類電商不一樣的地方在于：面向 B 類的交易會(huì)存在多種交易渠道，例如現(xiàn)貨批發(fā) 、分銷鋪貨、加工定制等等，其中每個(gè)渠道的交易方式、價(jià)格、庫存邏輯都不一樣；除此之外 B 類電商對(duì)于消費(fèi)品、工業(yè)品等不同行業(yè)的商品，在表達(dá)上也會(huì)存在巨大差異；不同渠道和行業(yè)定制，再疊加各類電商營(yíng)銷活動(dòng)玩法，使得 1688 的商品詳情頁面業(yè)務(wù)復(fù)雜度非常之高。

原本的技術(shù)架構(gòu)中涉及到了多個(gè)團(tuán)隊(duì)： ? 其中包括底層的商品基礎(chǔ)團(tuán)隊(duì) ：對(duì)接集團(tuán)中臺(tái)商品的能力，沉淀領(lǐng)域模型的服務(wù)和一些核心的商品邏輯； ? 無線服務(wù)端團(tuán)隊(duì) ：將底層商品基礎(chǔ)服務(wù)，面向客戶端和前端封裝成 — 專用的商品詳情接口； ? 搭建投放團(tuán)隊(duì) ：負(fù)責(zé)為頁面提供一定的搭建、投放橫向能力支持，以及最終展現(xiàn)側(cè)的 ios、安卓、前端三端。 ? 除此之外，在面對(duì)一些業(yè)務(wù)定制類的需求 （如分銷等） 時(shí)，還需要對(duì)應(yīng)的業(yè)務(wù)團(tuán)隊(duì)參與。

這種模式下，一個(gè)需求最多會(huì)有 5、6 個(gè)團(tuán)隊(duì)在同時(shí)協(xié)作，溝通成本非常高；再加上服務(wù)端側(cè)采用了比較重的微服務(wù)應(yīng)用模式，研發(fā)和運(yùn)維效率都比較低下。

前臺(tái)業(yè)務(wù)邏輯收攏：BFF 模式

我們首先是在業(yè)務(wù)核心變化最多最快的前臺(tái)業(yè)務(wù)邏輯層，以 BFF 模式引入了 FaaS 能力，并且將所有的 UI 相關(guān)邏輯都上行收攏到了 FaaS 函數(shù)中。這樣做一方面提升了服務(wù)端對(duì)應(yīng)邏輯的研發(fā)和部署效率，另一方面使得前端和客戶端的組件只需處理最簡(jiǎn)單的展示邏輯，從而盡可能抹平多端技術(shù)差異，讓一些跨端能力得以實(shí)現(xiàn)。

商品后端：擴(kuò)展點(diǎn)模式支持定義

商品后端側(cè)面對(duì)的主要問題是各種定制業(yè)務(wù)邏輯的接入成本過高，因此我們采用了 FaaS 擴(kuò)展點(diǎn)模式來進(jìn)行優(yōu)化：將商品信息的核心邏輯 （如價(jià)格、庫存） 抽象成一個(gè)個(gè)標(biāo)準(zhǔn)的擴(kuò)展點(diǎn)，并對(duì)接函數(shù)網(wǎng)關(guān)，允許任意的業(yè)務(wù)方按照模板編寫一個(gè)函數(shù)來定制其業(yè)務(wù)邏輯，從而實(shí)現(xiàn)封閉架構(gòu)的開放化。

經(jīng)過上述的技術(shù)架構(gòu)改造后，我們可以看到整個(gè)需求研發(fā)的模式和鏈路發(fā)生了非常大的改變。在之前老的模式下，如果要定制一個(gè)業(yè)務(wù)的商品詳情，需要從業(yè)務(wù)后端到客戶端多個(gè)團(tuán)隊(duì)全部參與，非常多的鏈路都需要進(jìn)行改動(dòng)，成本是非常高的。

而在新的模式下，從核心業(yè)務(wù)邏輯的定制，到前臺(tái)展現(xiàn)側(cè)的業(yè)務(wù)邏輯實(shí)現(xiàn)，都可以通過編寫簡(jiǎn)單的 FaaS 函數(shù)來實(shí)現(xiàn)，甚至完全可以僅由一位同學(xué)完成所有后臺(tái)業(yè)務(wù)邏輯的變更。（如果前端和客戶端的組件能夠?qū)崿F(xiàn)低代碼 + 跨端開發(fā)，那么完全可以實(shí)現(xiàn)業(yè)務(wù)需求的全棧開發(fā)！）

最后我們來看一下整體業(yè)務(wù)場(chǎng)景完成改造后所帶來的成效，在結(jié)合了 FaaS 的研發(fā)模式下，商品詳情相關(guān)的需求發(fā)待時(shí)長(zhǎng)降低了 80%、發(fā)布頻次提升 300% +，需求的吞吐量也有提升；最關(guān)鍵的是，研發(fā)人員的投入減少了 50%，整個(gè)后端側(cè)由原來的 2 個(gè)正式員工人力投入降低為:僅需半個(gè)正式員工 + 1 個(gè)外包員工支持，參與需求開發(fā)的相關(guān)團(tuán)隊(duì)和人員減少了許多，整個(gè)研發(fā)交付鏈路變得十分簡(jiǎn)潔明了。

總結(jié)與展望

最后還是站在當(dāng)下的時(shí)間節(jié)點(diǎn)，以業(yè)務(wù)團(tuán)隊(duì)的視角，簡(jiǎn)單的對(duì) Serverless 技術(shù)做一個(gè)總結(jié)和展望。

以我們過往業(yè)務(wù)場(chǎng)景落地的經(jīng)驗(yàn)總結(jié)幾個(gè)關(guān)鍵結(jié)論：

Serverless 無疑是一輪新的技術(shù)革命，FaaS 等核心技術(shù)所帶來的生產(chǎn)力提升已經(jīng)在很多場(chǎng)景得到有力的證明。 Serverless 的落地要結(jié)合實(shí)際的業(yè)務(wù)場(chǎng)景有的放矢，而不是說一桿捅到底。 任何技術(shù)都不是提效 “銀彈”，研發(fā)效能的提升更多還要是站在團(tuán)隊(duì)的組織架構(gòu)和人的角度去思考來做業(yè)務(wù)和技術(shù)的結(jié)合。 而對(duì)于 Serverless 和 FaaS 后續(xù)的發(fā)展，我也在此作出一些比較個(gè)人的看法，歡迎大家理性討論：

FaaS 將會(huì)持續(xù)進(jìn)化：雖然目前 Serverless 的 FaaS 能力已經(jīng)比較成熟，但是仍有很大進(jìn)步空間。可以擁有更好的彈性能力以及冷啟動(dòng)速度。我們可以看到業(yè)界正在 WASM、eBPF 等新的方向上不斷的探索，有理由相信接下來我們將在這個(gè)領(lǐng)域看到持續(xù)的突破。 FaaS 不會(huì)完全替代傳統(tǒng)微服務(wù)：傳統(tǒng)微服務(wù) （包括運(yùn)行在 Kubernetes 上的）與 FaaS 這兩種形態(tài)，至少在未來很長(zhǎng)一段時(shí)間里仍然會(huì)共存，業(yè)務(wù)團(tuán)隊(duì)?wèi)?yīng)該做好這種準(zhǔn)備，因地制宜地在業(yè)務(wù)場(chǎng)景中結(jié)合兩種技術(shù)，發(fā)揮它們的優(yōu)勢(shì)。 全棧和低代碼 （或者說，低門檻）研發(fā)將會(huì)成為一種趨勢(shì)：我們看到，Serverless 的興起給研發(fā)提效帶來了一種全新的思路，全棧式的業(yè)務(wù)需求開發(fā)能夠大幅降低項(xiàng)目中的溝通和協(xié)作成本、提升需求的吞吐量。隨著 Serverless 技術(shù)的進(jìn)一步成熟和推廣，這將可能改寫現(xiàn)在研發(fā)團(tuán)隊(duì)的形態(tài)。

發(fā)布云原生技術(shù)最新資訊、匯集云原生技術(shù)最全內(nèi)容，定期舉辦云原生活動(dòng)、直播，阿里產(chǎn)品及用戶最佳實(shí)踐發(fā)布。與你并肩探索云原生技術(shù)點(diǎn)滴，分享你需要的云原生內(nèi)容。

關(guān)注【阿里巴巴云原生】公眾號(hào)，獲取更多云原生實(shí)時(shí)資訊！

總結(jié)

以上是生活随笔為你收集整理的1688 复杂业务场景下的 Serverless 提效实践的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。