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

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

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

魔魚

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

產(chǎn)研平臺

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

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

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

問題分析

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

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

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

頁面管理問題

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

解決方案

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

補充一個魔魚平臺整體能力圖：

研發(fā)模式

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

問題分析

產(chǎn)品和運營結(jié)合

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

搭建的靈活性與體驗性能的平衡

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

解決方案

源碼/搭建融合方案

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

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

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

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

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

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

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

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

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

問題分析

首屏性能差

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

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

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

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

解決方案

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

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

動態(tài)模板渲染

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

補充一個文檔和數(shù)據(jù)消費鏈路圖：

魔魚現(xiàn)狀

將魔魚率先應(yīng)用到標準數(shù)據(jù)模型場景

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

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

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

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

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

• • 首次內(nèi)容繪制(FCP)： 673ms-->1s這個數(shù)據(jù)的延長，主要是網(wǎng)關(guān)處理原來2個接口的依賴和召回邏輯。
• • 跨端首屏(sfsp)： 2502ms-->1918ms這個數(shù)據(jù)的縮短，就是因為省下了端上數(shù)據(jù)依賴和請求處理的時間。

直觀效果對比：

改版前改版后

未來規(guī)劃

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

這個問題還有疑問的話，可以加幕.思.城火星老師免費咨詢，微.信號是為: msc496。

推薦閱讀：

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

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