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

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

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

魔魚

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

產(chǎn)研平臺

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

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

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

問題分析

腳手架及應用配置問題

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

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

頁面管理問題

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

解決方案

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

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

研發(fā)模式

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

問題分析

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

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

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

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

解決方案

源碼/搭建融合方案

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

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

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

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

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

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

網(wǎng)關建設

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

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

問題分析

首屏性能差

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

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

組件模塊復用率低

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

解決方案

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

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

動態(tài)模板渲染

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

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

魔魚現(xiàn)狀

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

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

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

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

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

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

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

直觀效果對比：

改版前改版后

未來規(guī)劃

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

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

推薦閱讀：

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

更多資訊請關注幕 思 城。