閑魚前端技術(shù)體系的背后——魔魚（良心推薦，從思路到實(shí)踐）

閑魚經(jīng)過(guò)近八年的發(fā)展，前端技術(shù)在整個(gè)研發(fā)體系中有著舉足輕重的地位，前端有迭代速度快，動(dòng)態(tài)化能力強(qiáng)，跨端適配成本低等顯著優(yōu)勢(shì)。閑魚前端一直使用淘系提供的基礎(chǔ)技術(shù)和平臺(tái)工具，但隨著業(yè)務(wù)的不斷發(fā)展，逐漸無(wú)法滿足復(fù)雜、個(gè)性化的業(yè)務(wù)和技術(shù)環(huán)境。

工欲善其事，必先利其器，擁有自己的上層研發(fā)體系勢(shì)在必行，于是從去年下半年開始，前端開始著手代號(hào)為「魔魚」的技術(shù)體系建設(shè)。

魔魚

目前魔魚包含產(chǎn)研平臺(tái)、研發(fā)模式和網(wǎng)關(guān)建設(shè)三大部分。

產(chǎn)研平臺(tái)

閑魚原有的研發(fā)流程是在集團(tuán)提供的工程研發(fā)平臺(tái)上進(jìn)行的。大致流程如下：

1. 1. 在研發(fā)平臺(tái)創(chuàng)建應(yīng)用，同步創(chuàng)建Git倉(cāng)庫(kù)；
2. 2. 在研發(fā)平臺(tái)創(chuàng)建迭代，同步創(chuàng)建Git分支；
3. 3. 獲取分支代碼進(jìn)行本地研發(fā)；
4. 4. 提交分支代碼，研發(fā)平臺(tái)進(jìn)行日常/預(yù)發(fā)構(gòu)建部署，H5應(yīng)用構(gòu)建產(chǎn)物為CSS/JS/HTML，把HTML文檔部署到Web服務(wù)器，生成Url進(jìn)行測(cè)試；
5. 5. 完成測(cè)試，研發(fā)平臺(tái)進(jìn)行正式發(fā)布，給出最終投放Url，并且結(jié)束迭代；

可以看到原有的研發(fā)流程主要依賴于集團(tuán)研發(fā)平臺(tái)提供的基本能力，由于平臺(tái)定位問題，功能相對(duì)單一，很多問題還是需要團(tuán)隊(duì)自己想辦法解決：

問題分析

腳手架及應(yīng)用配置問題

研發(fā)平臺(tái)提供應(yīng)用創(chuàng)建引導(dǎo)，幫助初始化應(yīng)用工程Git倉(cāng)庫(kù)和腳手架代碼。但是這樣創(chuàng)建項(xiàng)目的缺點(diǎn)也非常明顯：

1. 1. 只能用于初次創(chuàng)建應(yīng)用，后續(xù)腳手架升級(jí)需要配合另外的升級(jí)命令或文檔。如果在研發(fā)過(guò)程中對(duì)腳手架改動(dòng)較大，也會(huì)對(duì)后續(xù)的升級(jí)造成一定的困難；
2. 2. 大部分情況下，初始化工程并不能直接投入使用，還需要經(jīng)過(guò)一系列手動(dòng)配置，配置過(guò)程對(duì)腳手架并不熟悉的新同學(xué)來(lái)說(shuō)也是相當(dāng)痛苦，配置錯(cuò)誤會(huì)導(dǎo)致項(xiàng)目無(wú)法運(yùn)行，甚至對(duì)產(chǎn)品質(zhì)量和性能造成影響。

頁(yè)面管理問題

研發(fā)平臺(tái)只關(guān)注研發(fā)流程，而對(duì)應(yīng)用產(chǎn)物（頁(yè)面）的管理并不是它的強(qiáng)項(xiàng)。對(duì)于閑魚業(yè)務(wù)來(lái)說(shuō)，研發(fā)構(gòu)建發(fā)布僅僅是開發(fā)同學(xué)要關(guān)心的，業(yè)務(wù)同學(xué)更關(guān)心頁(yè)面的管理及使用，所以衍生出了其他數(shù)據(jù)投放和管理配置平臺(tái)，這樣的問題是：頁(yè)面發(fā)布和數(shù)據(jù)配置發(fā)布割裂，經(jīng)常因?yàn)閮蛇叞l(fā)布沒有同步，導(dǎo)致線上頁(yè)面和配置不一致造成故障。

解決方案

• • 統(tǒng)一模板管理：魔魚平臺(tái)集成應(yīng)用創(chuàng)建及升級(jí)功能，預(yù)定義工程模板、提供可變配置項(xiàng)，支持創(chuàng)建差異化的工程模板，并且模板和配置后期可以在魔魚平臺(tái)進(jìn)行配置調(diào)整及版本升級(jí)，徹底告別本地代碼維護(hù)應(yīng)用框架的做法。
• • 集成配置管理：魔魚平臺(tái)提供運(yùn)營(yíng)數(shù)據(jù)配置投放能力，從流程上管控?cái)?shù)據(jù)配置投放和頁(yè)面發(fā)布，保證線上數(shù)據(jù)的一致性，實(shí)現(xiàn)一站式研發(fā)、配置能力。
• • 場(chǎng)景管理模式：魔魚平臺(tái)提供了業(yè)務(wù)維度的管理模式，可以把不同應(yīng)用構(gòu)建的頁(yè)面進(jìn)行圈選，統(tǒng)一管理這些頁(yè)面的權(quán)限、配置及發(fā)布，大型活動(dòng)和部分產(chǎn)品鏈路都比較適合用這種模式管理多個(gè)頁(yè)面集合。
• • 接管發(fā)布流程：最終的文檔發(fā)布和配置數(shù)據(jù)發(fā)布都在魔魚平臺(tái)進(jìn)行，保證了發(fā)布流程的一致性，也對(duì)定制化研發(fā)實(shí)現(xiàn)了流程閉環(huán)。

補(bǔ)充一個(gè)魔魚平臺(tái)整體能力圖：

研發(fā)模式

之前閑魚的H5業(yè)務(wù)只有兩種研發(fā)模式可選：源碼開發(fā)和模塊搭建。復(fù)雜邏輯業(yè)務(wù)和產(chǎn)品鏈路以源碼開發(fā)為主；活動(dòng)和一些二級(jí)導(dǎo)購(gòu)頁(yè)面以模塊搭建為主。隨著業(yè)務(wù)復(fù)雜度提高、對(duì)性能體驗(yàn)要求的提升，需要擴(kuò)展研發(fā)模式，升級(jí)技術(shù)方案。

問題分析

產(chǎn)品和運(yùn)營(yíng)結(jié)合

源碼開發(fā)的頁(yè)面一般以產(chǎn)品屬性為主，運(yùn)營(yíng)很少能介入這類頁(yè)面的配置和搭建。這類頁(yè)面如果要配合某些大促活動(dòng)增加一些運(yùn)營(yíng)屬性，需要額外的開發(fā)工作，并且當(dāng)活動(dòng)結(jié)束后，還要把這部分代碼刪除，否則容易產(chǎn)生冗余業(yè)務(wù)邏輯。

搭建的靈活性與體驗(yàn)性能的平衡

閑魚一直在使用集團(tuán)提供的通用搭建平臺(tái)，它基于一套標(biāo)準(zhǔn)的模塊研發(fā)管理模式，并且提供整頁(yè)搭建的能力，但是這個(gè)平臺(tái)并不是為閑魚量身定制的，很多功能對(duì)于閑魚來(lái)說(shuō)過(guò)渡設(shè)計(jì)，并且由于閑魚自建商品招選體系，導(dǎo)致在數(shù)據(jù)投放層面無(wú)法跟搭建平臺(tái)很好地融合，每個(gè)模塊需要內(nèi)置數(shù)據(jù)的獲取和處理邏輯，當(dāng)頁(yè)面模塊數(shù)量一多，頁(yè)面的體驗(yàn)性能會(huì)受到較大影響，而且內(nèi)置業(yè)務(wù)數(shù)據(jù)邏輯的模塊也很難復(fù)用。

解決方案

源碼/搭建融合方案

這套方案彌補(bǔ)原有技術(shù)能力不足的問題，融合純?cè)创a、源碼搭建和純搭建，開發(fā)同學(xué)也不再需要做二選一的選擇題。

技術(shù)方案底層邏輯還是依賴集團(tuán)的模塊體系，這樣可以最大限度地利用已有組件物料，同時(shí)在模塊配置上，引入插槽（Slot）的自定義類型，結(jié)合編輯器，實(shí)現(xiàn)模塊靈活搭建，并且可以嵌套，讓模塊組合更加靈活。

基于模板的研發(fā)模式

以前應(yīng)用構(gòu)建的最終產(chǎn)物是 HTML/JS/CSS，現(xiàn)在產(chǎn)研平臺(tái)接管了應(yīng)用創(chuàng)建和配置管理等工作，文檔具有動(dòng)態(tài)化能力，最終產(chǎn)物是 XTPL/JS/CSS/Schema：

• • 其中XTPL是動(dòng)態(tài)文檔模板，線上頁(yè)面基于它實(shí)例化之后可以被CDN緩存；
• • Schema是對(duì)投放配置數(shù)據(jù)格式的描述，在平臺(tái)編輯器解析這份描述文件，渲染出配置表單。

這種研發(fā)模式，除了上文提到了平臺(tái)可以接管頁(yè)面框架配置以外，還可以基于頁(yè)面模板創(chuàng)建多個(gè)頁(yè)面實(shí)例，實(shí)現(xiàn)一碼多頁(yè)，并且每個(gè)頁(yè)面又具有獨(dú)立的搭投能力，應(yīng)用的靈活性有了大幅提升。

網(wǎng)關(guān)建設(shè)

在導(dǎo)購(gòu)和營(yíng)銷活動(dòng)、大促場(chǎng)景下，頁(yè)面數(shù)據(jù)基于運(yùn)營(yíng)配置，數(shù)據(jù)模型之間又有相互依賴關(guān)系，比如運(yùn)營(yíng)配置了一組選品id，需要發(fā)起二次請(qǐng)求來(lái)獲取這組選品id下對(duì)應(yīng)的商品數(shù)據(jù)。

在搭建場(chǎng)景下，模塊相對(duì)獨(dú)立，有完整的數(shù)據(jù)獲取及消費(fèi)邏輯，當(dāng)多個(gè)模塊搭建成一個(gè)頁(yè)面之后，每個(gè)模塊獨(dú)立處理數(shù)據(jù)獲取和渲染邏輯，導(dǎo)致模塊渲染時(shí)機(jī)不可預(yù)期，大量并行的請(qǐng)求也會(huì)導(dǎo)致請(qǐng)求阻塞。

問題分析

首屏性能差

由于存在串行數(shù)據(jù)獲取的邏輯，頁(yè)面渲染時(shí)機(jī)延后，導(dǎo)致首屏渲染時(shí)間較長(zhǎng)。解決這類方案一般有以下幾種：

1. 1. 服務(wù)端膠水層：由服務(wù)端把頁(yè)面依賴的數(shù)據(jù)合并成一個(gè)接口返回，這種僅適合相對(duì)穩(wěn)定的產(chǎn)品業(yè)務(wù)，對(duì)于搭建場(chǎng)景就不可用，而且這類接口沒有復(fù)用性，由服務(wù)端維護(hù)膠水層也并不是一個(gè)明智的選擇；
2. 2. 前端使用SSR直出文檔：這種方式相當(dāng)于由前端接管膠水邏輯，一方面需要基建支持，另一方面無(wú)法做頁(yè)面緩存，對(duì)于訪問量大的頁(yè)面，對(duì)SSR服務(wù)的壓力考驗(yàn)也比較大，比較費(fèi)資源。一些對(duì)體驗(yàn)要求高的核心產(chǎn)品頁(yè)面，SSR確實(shí)是一種提升體驗(yàn)性能的王炸，但它還不能作為一個(gè)通用技術(shù)方案覆蓋所有業(yè)務(wù)場(chǎng)景。
3. 3. 實(shí)現(xiàn)一個(gè)輕量的網(wǎng)關(guān)：處理數(shù)據(jù)依賴分析、召回、補(bǔ)全、裁切等輕邏輯，這個(gè)方案適用于處理通用數(shù)據(jù)模型，比如商品、內(nèi)容、用戶等，不適用于單一產(chǎn)品數(shù)據(jù)模型。

組件模塊復(fù)用率低

由于模塊需要負(fù)責(zé)數(shù)據(jù)獲取邏輯，數(shù)據(jù)跟業(yè)務(wù)的耦合度較高，導(dǎo)致開發(fā)了很多UI相同，數(shù)據(jù)依賴不同的模塊。這對(duì)UI組件復(fù)用和維護(hù)都不友好。

解決方案

前端數(shù)據(jù)網(wǎng)關(guān)

為了解決首屏數(shù)據(jù)加載性能問題，針對(duì)導(dǎo)購(gòu)、營(yíng)銷場(chǎng)景，我們采用上面提到的實(shí)現(xiàn)一個(gè)輕量的網(wǎng)關(guān)的方案，順便聯(lián)合服務(wù)端，對(duì)現(xiàn)有閑魚通用數(shù)據(jù)模型進(jìn)行梳理及標(biāo)準(zhǔn)化制定。

動(dòng)態(tài)模板渲染

針對(duì)上文提到的動(dòng)態(tài)模板搭建的研發(fā)模式，我們接入集團(tuán)提供的動(dòng)態(tài)模板渲染引擎，當(dāng)運(yùn)營(yíng)在魔魚平臺(tái)編輯器完成頁(yè)面搭建、配置和發(fā)布之后，不需要前端介入開發(fā)就可以實(shí)現(xiàn)模塊JS/CSS資源的動(dòng)態(tài)注入，實(shí)現(xiàn)文檔的動(dòng)態(tài)配置渲染。

補(bǔ)充一個(gè)文檔和數(shù)據(jù)消費(fèi)鏈路圖：

魔魚現(xiàn)狀

將魔魚率先應(yīng)用到標(biāo)準(zhǔn)數(shù)據(jù)模型場(chǎng)景

• • 閑魚業(yè)務(wù)畢竟是電商App，前端支持的業(yè)務(wù)中，導(dǎo)購(gòu)和營(yíng)銷場(chǎng)景比較多，比如「閑魚優(yōu)品」、「手機(jī)數(shù)碼」；
• • 閑魚也在不斷探索內(nèi)容場(chǎng)景，比如「會(huì)玩」、「圈子」；

無(wú)論商品和內(nèi)容都是相對(duì)容易標(biāo)準(zhǔn)化的數(shù)據(jù)模型，通過(guò)數(shù)據(jù)網(wǎng)關(guān)接入后可以快速得到數(shù)據(jù)性能優(yōu)化的收益；同時(shí)這類業(yè)務(wù)也是運(yùn)營(yíng)參與比較多，利用魔魚的研發(fā)、搭投一體化的體驗(yàn)，提高研發(fā)效率和運(yùn)營(yíng)配置效率及體驗(yàn)。

業(yè)務(wù)遷移性能對(duì)比

以手機(jī)數(shù)碼頻道為例。這個(gè)頻道在遷移之前，首頁(yè)主要數(shù)據(jù)接口有2個(gè)，并且是串行依賴關(guān)系；遷移到魔魚之后使用平臺(tái)數(shù)據(jù)配置投放，利用網(wǎng)關(guān)的數(shù)據(jù)召回能力，把數(shù)據(jù)接口合并成1個(gè)。

上線后數(shù)據(jù)：

• • 首次內(nèi)容繪制(FCP)： 673ms-->1s這個(gè)數(shù)據(jù)的延長(zhǎng)，主要是網(wǎng)關(guān)處理原來(lái)2個(gè)接口的依賴和召回邏輯。
• • 跨端首屏(sfsp)： 2502ms-->1918ms這個(gè)數(shù)據(jù)的縮短，就是因?yàn)槭∠铝硕松蠑?shù)據(jù)依賴和請(qǐng)求處理的時(shí)間。

直觀效果對(duì)比：

改版前改版后

未來(lái)規(guī)劃

1. 1. 魔魚作為前端統(tǒng)一研發(fā)體系，不光可以支持H5的研發(fā)，后面還可以支持端外小程序、高性能容器的業(yè)務(wù)開發(fā)，提供豐富的研發(fā)模板類型，配合組件物料實(shí)現(xiàn)頁(yè)面快速創(chuàng)建；
2. 2. 前端跟服務(wù)端緊密結(jié)合，除了進(jìn)行標(biāo)準(zhǔn)化數(shù)據(jù)模型定義之外，還會(huì)接入更豐富的投放配置能力，比如人群定投、AB實(shí)驗(yàn)等動(dòng)態(tài)投放策略；
3. 3. 跟招商、權(quán)益、測(cè)試、埋點(diǎn)/監(jiān)控等平臺(tái)進(jìn)行數(shù)據(jù)互通和工作流關(guān)聯(lián)，降低多平臺(tái)之間的流程操作成本。
4. 4. 基于Schema的描述模型和配置編輯器可以作為衍生產(chǎn)品，給閑魚其他的中后臺(tái)系統(tǒng)使用，統(tǒng)一閑魚的數(shù)據(jù)投放方案。

這個(gè)問題還有疑問的話，可以加幕.思.城火星老師免費(fèi)咨詢，微.信號(hào)是為: msc496。

推薦閱讀：

[淺規(guī)則Vol.1] 聽說(shuō)濫發(fā)信息的規(guī)則要變了

更多資訊請(qǐng)關(guān)注幕 思 城。