Bifrost（英 [‘bi:fr?st]）原意彩虹橋，北歐神話中是連通天地的一條通道。而在漫威電影《雷神》中，Bifrost是神域——阿斯加德（Asgard）的出入口，神域的人通過(guò)它自由穿梭于“九界”（指九個(gè)平行的宇宙）之間。借用“彩虹橋”的寓意，我們希望Bifrost可以成為前端不同SPA(Single Page Application)系統(tǒng)之間的橋梁，使得不同的單頁(yè)應(yīng)用可以用這種方式實(shí)現(xiàn)功能的自由聚合/拆分。

項(xiàng)目背景

立項(xiàng)之初，閃購(gòu)賦能企管平臺(tái)（以下簡(jiǎn)稱“企管平臺(tái)”）僅僅是面向單個(gè)商家的CRM管理系統(tǒng)，采用常規(guī)的Vue單頁(yè)應(yīng)用方式來(lái)實(shí)現(xiàn)。隨著項(xiàng)目的推進(jìn)，它的定位逐漸發(fā)生了變化，從一個(gè)單一業(yè)務(wù)的載體逐漸變成了面向多種場(chǎng)景的商家管理平臺(tái)。另一方面，由于系統(tǒng)由多個(gè)前端團(tuán)隊(duì)共同開(kāi)發(fā)維護(hù)，越來(lái)越多的問(wèn)題隨之浮現(xiàn)：

• 異地協(xié)作時(shí)，信息同步不及時(shí)引起的代碼沖突以及修改公共組件引入的Bug。
• 不同的商家針對(duì)同一個(gè)頁(yè)面存在定制化的需求。
• 已經(jīng)實(shí)現(xiàn)的一些功能需要集成到企管平臺(tái)中來(lái)。

因此，我們希望構(gòu)建一個(gè)更高維度的解耦方案，使我們能夠在開(kāi)發(fā)階段把互不干涉的模塊拆成一個(gè)個(gè)類似后端微服務(wù)架構(gòu)那樣的子系統(tǒng)，各自迭代，在運(yùn)行時(shí)集成為一個(gè)能夠覆蓋上述各種使用場(chǎng)景的完整系統(tǒng)。

方案選型

首先，我們整理了核心訴求，按優(yōu)先級(jí)排序如下：

• 希望異地開(kāi)發(fā)時(shí)不同的模塊能夠獨(dú)立開(kāi)發(fā)、獨(dú)立部署。
• 對(duì)已在線上運(yùn)行的項(xiàng)目，希望能夠低成本地接入企管平臺(tái)，而不需要對(duì)開(kāi)發(fā)、部署流程做大規(guī)模的改動(dòng)。
• 各個(gè)子系統(tǒng)獨(dú)立運(yùn)行，互不影響，但允許我們?cè)陂_(kāi)發(fā)階段與其他子系統(tǒng)進(jìn)行聯(lián)調(diào)。
• 保持單頁(yè)應(yīng)用的體驗(yàn)。
• 由于現(xiàn)有項(xiàng)目都是基于Vue技術(shù)棧開(kāi)發(fā)，因此，我們的框架并不需要做到技術(shù)棧無(wú)關(guān)，只要滿足Vue的項(xiàng)目即可。

基于以上這些訴求，我們調(diào)研了目前市面上常用的微前端方案，最常見(jiàn)的方案有：

• 基于Nginx的路由分發(fā)。
• 使用Iframe將頁(yè)面嵌入。

除此之外，還有美團(tuán)集團(tuán)內(nèi)部的微前端實(shí)踐——美團(tuán)HR系統(tǒng)（用微前端方式搭建類單頁(yè)應(yīng)用）和業(yè)界比較知名的微前端框架——SingleSPA。

這些方案的優(yōu)劣整理如下：

從用戶體驗(yàn)角度出發(fā)，Nginx和Iframe首先被否決；HR系統(tǒng)的方案需要對(duì)現(xiàn)有的項(xiàng)目進(jìn)行改造，把不同團(tuán)隊(duì)目前開(kāi)發(fā)的項(xiàng)目整合到同一個(gè)單頁(yè)應(yīng)用中，在項(xiàng)目快速迭代的過(guò)程中，成本過(guò)高，所以也被否掉。SingleSPA看起來(lái)完美，但它沒(méi)有照顧到實(shí)際生產(chǎn)環(huán)境中的開(kāi)發(fā)、部署的差異性，并不是Product-Ready。綜合多種因素考慮，我們最終決定采用自研的方式來(lái)實(shí)現(xiàn)微前端化Bifrost。

核心架構(gòu)

Bifrost框架在設(shè)計(jì)的時(shí)候參考了SingleSPA的思路，將系統(tǒng)了分為主系統(tǒng)和子系統(tǒng)。

主系統(tǒng)是用來(lái)控制子系統(tǒng)的調(diào)度中心，職責(zé)包括：

• 維護(hù)子系統(tǒng)的注冊(cè)表。
• 管理各個(gè)子系統(tǒng)的生命周期。
• 傳遞路由信息。
• 加載子項(xiàng)目的入口資源。
• 為子系統(tǒng)的實(shí)例提供掛載點(diǎn)。

子系統(tǒng)只負(fù)責(zé)業(yè)務(wù)邏輯的實(shí)現(xiàn)。如果進(jìn)一步細(xì)分的話，子系統(tǒng)可以分為業(yè)務(wù)子系統(tǒng)、實(shí)現(xiàn)公共菜單子系統(tǒng)、導(dǎo)航布局子系統(tǒng)，其中布局子系統(tǒng)會(huì)先于業(yè)務(wù)子系統(tǒng)加載。

Bifrost采用路由消息分發(fā)的方式來(lái)控制子系統(tǒng)的加載和跳轉(zhuǎn)。主系統(tǒng)維護(hù)了一條路由消息總線，當(dāng)路由發(fā)生變化時(shí)，子系統(tǒng)會(huì)將路由事件推送給路由總線，然后由路由總線決定加載/跳轉(zhuǎn)的目標(biāo)子系統(tǒng)。如果路由不需要切換子系統(tǒng)，則交由當(dāng)前子系統(tǒng)進(jìn)行處理。

如果子系統(tǒng)發(fā)生切換，主系統(tǒng)會(huì)在DOM中添加對(duì)應(yīng)子系統(tǒng)的掛載節(jié)點(diǎn)，并異步加載系統(tǒng)的靜態(tài)資源。由于子系統(tǒng)都是完整的Vue實(shí)例，當(dāng)子系統(tǒng)的代碼加載并執(zhí)行之后，子系統(tǒng)就會(huì)自動(dòng)在其對(duì)應(yīng)的掛載節(jié)點(diǎn)上渲染相應(yīng)的內(nèi)容。

整個(gè)系統(tǒng)的生命周期如下圖所示：

具體實(shí)現(xiàn)

基于Bifrost實(shí)現(xiàn)的項(xiàng)目架構(gòu)如下圖所示：

這里，我們主要關(guān)注主系統(tǒng)、業(yè)務(wù)子系統(tǒng)和布局子系統(tǒng)的實(shí)現(xiàn)。

主系統(tǒng)

主系統(tǒng)的邏輯比較簡(jiǎn)單，主要是實(shí)例化Bifrost中定義的Platform對(duì)象，并注冊(cè)各個(gè)子系統(tǒng)。子系統(tǒng)的注冊(cè)信息包括：

• AppName：子系統(tǒng)名，與系統(tǒng)的路由前綴保持對(duì)應(yīng)，同時(shí)也會(huì)作為子系統(tǒng)在DOM中掛載節(jié)點(diǎn)的ID。
• Domain：非必填，如果出現(xiàn)多個(gè)路由前綴都對(duì)應(yīng)同一個(gè)子系統(tǒng)，可以通過(guò)Domain進(jìn)行映射。
• ConfigPath：對(duì)應(yīng)子系統(tǒng)配置文件的URL。

一個(gè)簡(jiǎn)單的主系統(tǒng)實(shí)現(xiàn)如下：

import { Platform } from '@sfe/bifrost'new Platform({layoutFrame: {render () {// render layout}},appRegister: [{ appName: 'app1', configPath: '/path/to/app1/config.js' }] }).start()

業(yè)務(wù)子系統(tǒng)

在設(shè)計(jì)方案時(shí)，我們始終保持一個(gè)理念，就是保證對(duì)業(yè)務(wù)代碼的零侵入，因此業(yè)務(wù)系統(tǒng)改造的工作量很小。代碼層面，只需要把原本子系統(tǒng)的初始化流程放到AppContainer對(duì)象的Mounted回調(diào)函數(shù)里即可：

import { AppContainer } from '@sfe/bifrost' import Vue from 'vue' import VueRouter from 'vue-router'Vue.use(VueRouter) const router = new VueRouter({}) new AppContainer({appName: 'app1',router,mounted () {return new Vue({router,components: { App },template: '<App/>'}).$mount()} }).start()

另外，還需要修改子系統(tǒng)的構(gòu)建流程，構(gòu)建完成之后生成一個(gè)包含子系統(tǒng)入口資源信息的配置文件。一個(gè)典型的配置文件如下：

((callback) => callback({ scripts: ['/js/chunk-vendors.dee65310.js','/js/home.b822227c.js'],styles: ['/css/chunk-vendors.e7f4dbac.css','/css/home.285dac42.css'] }))(configLoadedCb.crm)

此處我們實(shí)現(xiàn)了@sfe/bifrost-config-plugin插件，在Webpack構(gòu)建腳本中引入該插件就可以自動(dòng)生成項(xiàng)目對(duì)應(yīng)的配置文件。配置文件是一個(gè)立即執(zhí)行函數(shù)，主系統(tǒng)可以通過(guò)JSONP的方式讀取配置文件中的內(nèi)容。

在實(shí)際生產(chǎn)環(huán)境中，我們可以將子系統(tǒng)發(fā)布到任意CDN，只要能夠保證配置文件的URL始終不變，那么無(wú)需依賴任何服務(wù)，主系統(tǒng)就可以感知到子系統(tǒng)的發(fā)布。

布局子系統(tǒng)

布局子系統(tǒng)是用來(lái)實(shí)現(xiàn)菜單和導(dǎo)航欄的Vue工程，本質(zhì)上和一般的業(yè)務(wù)子系統(tǒng)沒(méi)有區(qū)別。只需要注意，布局子系統(tǒng)使用的是LayoutContainer而非AppContainer進(jìn)行包裝。

import { LayoutContainer } from '@sfe/bifrost' import Vue from 'vue'import App from './app'new LayoutContainer({appName: 'layout',router,onInit ({ appSlot, callback }) {Vue.config.productionTip = falseconst app = new Vue({el: '#app',router,store,render: (h) => (<App appSlot={appSlot} />)})callback()} }).start()

布局子系統(tǒng)作為主系統(tǒng)的一部分，既可以放在主系統(tǒng)中去實(shí)現(xiàn)，也可以像其他子系統(tǒng)一樣通過(guò)異步的方式去加載。在我們的項(xiàng)目中，結(jié)合了上面兩種方式（布局子系統(tǒng)既可以為作為常規(guī)的Vue項(xiàng)目構(gòu)建，也可以發(fā)布成NPM包），每次發(fā)布時(shí)，會(huì)同時(shí)發(fā)布布局的靜態(tài)資源和NPM包。主系統(tǒng)通過(guò)NPM包的方式引入布局子系統(tǒng)，將它打包到項(xiàng)目中，避免線上運(yùn)行時(shí)，額外加載布局子系統(tǒng)的資源，減小項(xiàng)目體積，加快渲染速度。

本地開(kāi)發(fā)時(shí)，我們則會(huì)通過(guò)Bifrost定義的MockPlatform異步加載布局子系統(tǒng)的靜態(tài)資源，保證線上/線下運(yùn)行效果的一致性，方便本地聯(lián)調(diào)。

工程實(shí)踐

代碼層面的改動(dòng)雖然不多，但要在實(shí)際的生產(chǎn)環(huán)境中落地，還需要解決一系列老生常談的問(wèn)題，包括：

• 本地開(kāi)發(fā)時(shí)，如何保證與線上實(shí)際運(yùn)行效果的一致性？
• 如何實(shí)現(xiàn)全局狀態(tài)管理和子系統(tǒng)之間的通信？
• 如何對(duì)公共依賴和公共模塊進(jìn)行管理？
• 發(fā)布部署流程需要怎樣調(diào)整？

根據(jù)閃購(gòu)業(yè)務(wù)實(shí)踐，我們總結(jié)了一套適用于Bifrost的解決方案。

本地聯(lián)調(diào)

采用微前端的方式意味著子系統(tǒng)的完全隔離，這給我們的開(kāi)發(fā)帶來(lái)了一系列困擾：

• 本地開(kāi)發(fā)時(shí)，無(wú)法看到當(dāng)前開(kāi)發(fā)的功能在主系統(tǒng)中實(shí)際運(yùn)行的效果。
• 子系統(tǒng)之間有時(shí)會(huì)存在跳轉(zhuǎn)關(guān)系，在開(kāi)發(fā)階段難以驗(yàn)證這種跳轉(zhuǎn)邏輯的正確性。

為了解決這些問(wèn)題，Bifrost定義了MockPlatform。MockPlatform的思路很簡(jiǎn)單：既然主系統(tǒng)可以動(dòng)態(tài)加載線上的子系統(tǒng)，那么我們只需要在開(kāi)發(fā)時(shí)，模擬主系統(tǒng)的運(yùn)行方式，去加載其他子系統(tǒng)的線上資源，之后就可以像調(diào)用后端API一樣同各個(gè)子系統(tǒng)進(jìn)行聯(lián)調(diào)了。這也就解釋了為什么布局子系統(tǒng)在輸出NPM包的同時(shí)還維護(hù)了一份靜態(tài)資源。

MockPlatform的API同Platform對(duì)象的API是一致的，開(kāi)發(fā)時(shí)，我們只需要按照主系統(tǒng)的方式引用布局或業(yè)務(wù)子系統(tǒng)的配置文件URL即可：

// ...others...new AppContainer({// ...others...runDevPlatform: process.env.NODE_ENV === 'development', // 只在開(kāi)發(fā)環(huán)境下啟動(dòng)mock platformdevPlatformConfig: {layoutFrame: {mode: 'remote',configPath: 'path/to/layout/config.js'},appRegister: [{appName: 'app2',mode: 'remote',configPath: 'path/to/app2/config.js'}]},// ...others... }).start()

借助MockPlatform，我們項(xiàng)目在開(kāi)發(fā)階段的感受和開(kāi)發(fā)普通的單頁(yè)應(yīng)用沒(méi)有任何差異，如果某個(gè)我們依賴的子系統(tǒng)更新了功能，只需要讓對(duì)應(yīng)的RD發(fā)布一下，就可以在本地看到它的最新效果。

全局狀態(tài)

除了本地聯(lián)調(diào)，全局通信也是微前端項(xiàng)目中繞不開(kāi)的一個(gè)話題。由于我們所有項(xiàng)目采用的都是Vue技術(shù)棧，所以會(huì)選擇基于Vuex來(lái)實(shí)現(xiàn)全局通信。Bifrost的主系統(tǒng)會(huì)維護(hù)一個(gè)全局的Vuex Store，用于保存全局狀態(tài)。

當(dāng)子系統(tǒng)希望監(jiān)聽(tīng)全局狀態(tài)時(shí)，子系統(tǒng)并不是直接訂閱全局Store（Vue的依賴收集機(jī)制也決定了子系統(tǒng)無(wú)法響應(yīng)全局Store的變化），而是借助Bifrost提供的syncGlobalStore函數(shù)來(lái)訂閱全局Store。調(diào)用該函數(shù)后，任何全局狀態(tài)的變化都會(huì)被同步到本地Store的Global命名空間下。之后，就可以像普通的單頁(yè)應(yīng)用那樣，調(diào)用Vuex的mapState方法實(shí)現(xiàn)和全局狀態(tài)的雙向綁定。

import { AppContainer, syncGlobalStore } from '@sfe/bifrost' import Vue from 'vue' import Vuex from 'vuex' // ...others... Vue.use(Vuex) const store = new Vuex.Store({}) new AppContainer({mounted () {// 同步全局store狀態(tài)syncGlobalStore(store)// ...others...return new Vue({store,router,components: { App },template: '<App/>'}).$mount()} }).start()

如果子系統(tǒng)自身的狀態(tài)需要共享，Bifrost還會(huì)提供installGlobalModule函數(shù)。該函數(shù)會(huì)將當(dāng)前子系統(tǒng)需要共享的狀態(tài)掛載到全局Store下，其他子系統(tǒng)可以通過(guò)前面提到的方式來(lái)同步這些狀態(tài)。雖然Bifrost提供了子系統(tǒng)通信的能力，但在實(shí)際拆分子系統(tǒng)時(shí)，應(yīng)該盡量避免這種情況發(fā)生。如果兩個(gè)子系統(tǒng)之間需要頻繁通信，那就應(yīng)該考慮把他們劃分到同一個(gè)子系統(tǒng)。

公共依賴

由于各個(gè)子系統(tǒng)都需要集成到企管平臺(tái)，為了保證體驗(yàn)的一致性，大家都是基于同樣的組件庫(kù)進(jìn)行開(kāi)發(fā)。幾乎所有項(xiàng)目都會(huì)依賴lodash、Moment等基礎(chǔ)庫(kù)，因此如果不對(duì)公共依賴進(jìn)行管理，項(xiàng)目會(huì)加載大量冗余代碼。

針對(duì)這個(gè)問(wèn)題，我們采用的是Webpack External方式來(lái)解決。構(gòu)建時(shí)，各個(gè)子系統(tǒng)會(huì)將公共依賴排除，主系統(tǒng)會(huì)打包一份包含所有這些公共依賴的DLL文件。子系統(tǒng)在運(yùn)行時(shí)，直接從全局引用對(duì)應(yīng)的依賴。如果子系統(tǒng)希望使用某些庫(kù)的特定版本，也可以選擇不排除這些依賴項(xiàng)。這在子系統(tǒng)希望升級(jí)某些依賴庫(kù)的時(shí)候顯得極為有用：通過(guò)子系統(tǒng)的局部升級(jí)，可以限制依賴庫(kù)升級(jí)的影響范圍，避免造成全局影響。

DLL文件會(huì)包含大部分公共依賴，但有一個(gè)例外——我們不會(huì)將Vue打到DLL文件中。因?yàn)樵趯?shí)際開(kāi)發(fā)中，很多庫(kù)都喜歡向Vue的原型鏈上掛載方法和屬性。如果不同團(tuán)隊(duì)開(kāi)發(fā)時(shí)掛載的內(nèi)容恰好用到同一個(gè)字段，就會(huì)帶來(lái)不可預(yù)知的影響。

模塊復(fù)用

除了底層的依賴，我們還需要考慮對(duì)公共的業(yè)務(wù)模塊和工具函數(shù)進(jìn)行復(fù)用。在企管平臺(tái)，我們?yōu)楣矘I(yè)務(wù)組件庫(kù)和公共函數(shù)庫(kù)創(chuàng)建獨(dú)立的Git工程，然后將所有的子系統(tǒng)和公共模塊通過(guò)Git Submodule的方式引入到主系統(tǒng)的工程中。主系統(tǒng)采用Lerna的方式組織代碼，各個(gè)子系統(tǒng)在開(kāi)發(fā)時(shí)，可以通過(guò)軟鏈直接引用到本地公共模塊的代碼，實(shí)現(xiàn)公共模塊的復(fù)用。當(dāng)公共模塊發(fā)生更新，直接調(diào)用Lerna Publish就可以同時(shí)更新所有子系統(tǒng)package.json中依賴版本。

發(fā)布及部署流程

前面提到，主系統(tǒng)采用的是JSONP方式加載子系統(tǒng)的配置文件，整個(gè)發(fā)布過(guò)程都只需要發(fā)布靜態(tài)資源，因此，Talos（美團(tuán)內(nèi)部自研的持續(xù)集成平臺(tái)）提供的前端靜態(tài)資源發(fā)布的能力就可以滿足我們的需求。每次發(fā)布時(shí)，只需要構(gòu)建有更新的項(xiàng)目，并將打包后的靜態(tài)資源上傳到CDN即可。

版本控制

采用微前端架構(gòu)還有一個(gè)額外的好處：在Nginx和實(shí)際的業(yè)務(wù)層之間，多了一層主系統(tǒng)，我們可以像客戶端一樣，動(dòng)態(tài)決定需要加載的子系統(tǒng)版本。基于此，我們實(shí)現(xiàn)了子系統(tǒng)的版本控制和定向灰度功能。發(fā)布時(shí)，我們通過(guò)參數(shù)確定本次發(fā)布是否是灰度版本。在發(fā)布成功后，會(huì)記錄本次發(fā)布的灰度信息、版本和配置文件URL等信息。

主系統(tǒng)每次啟動(dòng)時(shí)，首先會(huì)調(diào)用接口確定當(dāng)前用戶所處的鏈路（全量/灰度），再根據(jù)鏈路信息加載相應(yīng)的子系統(tǒng)。我們記錄了每次發(fā)布的資源URL，所以也支持子系統(tǒng)的版本切換。只需要在版本服務(wù)中修改各條鏈路上需要激活的子系統(tǒng)版本，就可以輕松實(shí)現(xiàn)子系統(tǒng)版本切換。

埋點(diǎn)及錯(cuò)誤上報(bào)

這里我們主要討論Bifrost框架的埋點(diǎn)方案。在Bifrost項(xiàng)目中，可以借助主系統(tǒng)提供的一系列鉤子函數(shù)實(shí)現(xiàn)針對(duì)子系統(tǒng)的埋點(diǎn)，包括：onAppLoading、onAppLoaded、onAppRouting、onError。每當(dāng)子系統(tǒng)發(fā)生切換都會(huì)調(diào)用onAppRouting函數(shù)，因此我們可以在這里記錄子系統(tǒng)加載的次數(shù)（PV）。onAppLoading和onAppLoaded則會(huì)在子系統(tǒng)初次加載時(shí)調(diào)用，通過(guò)計(jì)算Loading和Loaded成功率的比值，我們可以得到子系統(tǒng)加載的成功率。子系統(tǒng)加載失敗時(shí)，會(huì)調(diào)用onError函數(shù)，幫助排查子系統(tǒng)加載失敗的原因。

收益

今年年初，我們對(duì)企管平臺(tái)進(jìn)行了微前端改造，目前系統(tǒng)已經(jīng)在線上平穩(wěn)運(yùn)行半年時(shí)間，支持上百個(gè)零售商品牌，上千家門店業(yè)務(wù)的運(yùn)轉(zhuǎn)。

采用微前端架構(gòu)，給我們項(xiàng)目帶來(lái)的好處是顯而易見(jiàn)的：

• 實(shí)現(xiàn)了異地合作開(kāi)發(fā)時(shí)的完全解藕。采用微前端架構(gòu)之后，兩地團(tuán)隊(duì)在開(kāi)發(fā)過(guò)程中再也沒(méi)有遇到代碼沖突的問(wèn)題。
• 避免了單頁(yè)應(yīng)用發(fā)展成“巨石”應(yīng)用。目前，企管平臺(tái)總共實(shí)現(xiàn)了上百個(gè)頁(yè)面，采用微前端的方式進(jìn)行劃分后，每個(gè)子系統(tǒng)包含的頁(yè)面都不超過(guò)三十個(gè)，子系統(tǒng)的可維護(hù)性得到大大提高。
• 今年企管平臺(tái)經(jīng)歷了兩次大的組件庫(kù)版本升級(jí)。第一次升級(jí)時(shí)，項(xiàng)目還是單頁(yè)應(yīng)用，我們?cè)跁和I(yè)務(wù)開(kāi)發(fā)的基礎(chǔ)上，耗費(fèi)了大約一周的時(shí)間對(duì)所有的頁(yè)面進(jìn)行回歸驗(yàn)證、完成升級(jí)。第二次升級(jí)時(shí)，我們已經(jīng)完成了項(xiàng)目的微前端改造，可以通過(guò)增量的方式，先升級(jí)不常用的子系統(tǒng)，驗(yàn)證通過(guò)后再升級(jí)其他子系統(tǒng)。這樣既不用中斷正常的業(yè)務(wù)開(kāi)發(fā)，也保證了依賴庫(kù)升級(jí)時(shí)的影響范圍和風(fēng)險(xiǎn)可控。

不是“銀彈”

當(dāng)然，同所有的架構(gòu)方案一樣，微前端這種模式也存在一些折衷和妥協(xié)。在獲得低耦合和靈活性的同時(shí)，也引入了額外的復(fù)雜度。在微前端項(xiàng)目中，我們需要考慮多個(gè)工程的規(guī)范和代碼質(zhì)量的統(tǒng)一，需要引入更多的自動(dòng)化工具來(lái)管理項(xiàng)目的發(fā)布部署流程，還需要處理多個(gè)前端工程運(yùn)行在同一個(gè)域名下引起的Cookie覆蓋等問(wèn)題。

因此，在采用微前端架構(gòu)之前，建議大家要謹(jǐn)慎的評(píng)估自己的項(xiàng)目是否真的適合采用微前端的方式，避免盲目引入微前端導(dǎo)致項(xiàng)目難以維護(hù)，得不償失。

我們認(rèn)為，如果項(xiàng)目中存在以下兩個(gè)場(chǎng)景，比較適合采用微前端架構(gòu)：

• 功能模塊較多，且各個(gè)功能模塊相對(duì)較為獨(dú)立的中后臺(tái)系統(tǒng)。
• 項(xiàng)目存在大量歷史遺留問(wèn)題，希望在保留已有功能的基礎(chǔ)上，開(kāi)發(fā)新的功能模塊。

其他大部分項(xiàng)目都可以通過(guò)調(diào)整代碼結(jié)構(gòu)，構(gòu)建單頁(yè)應(yīng)用，甚至采用最傳統(tǒng)的多頁(yè)應(yīng)用等方式來(lái)進(jìn)行優(yōu)化、調(diào)整，從來(lái)達(dá)到降低耦合的目的。微前端并不是“銀彈”。

期許

從去年12月立項(xiàng)至今，Bifrost經(jīng)歷了近一年的迭代，發(fā)布了2個(gè)大版本和38個(gè)小版本。誕生之初，Bifrost僅僅是針對(duì)企管平臺(tái)這個(gè)特定業(yè)務(wù)場(chǎng)景的微前端方案。如今，已進(jìn)化為面向Vue技術(shù)棧的通用微前端框架。期間，我們圍繞Bifrost，逐步完善了整個(gè)微前端技術(shù)體系的建設(shè)，實(shí)現(xiàn)了Bifrost主/子系統(tǒng)的腳手架工程和命令行工具、子系統(tǒng)的管理平臺(tái)、灰度發(fā)布功能等一系列平臺(tái)和工具，完成了Bifrost微前端生態(tài)的雛形。

當(dāng)然，Bifrost依然還有很多可以提升的地方。未來(lái)，我們將會(huì)從以下幾個(gè)方面進(jìn)一步完善Bifrost：

• 提供更加完善的前端微服務(wù)治理工具。
• 實(shí)現(xiàn)JS和CSS沙盒。
• 支持更多的技術(shù)棧。

結(jié)語(yǔ)

隨著前端工程的日益復(fù)雜，我們對(duì)可擴(kuò)展的前端架構(gòu)的訴求也變得更加強(qiáng)烈。微前端作為一種前端解藕的方案，自然更加頻繁地被大家所提及和應(yīng)用。另一方面，雖然網(wǎng)上已經(jīng)有了很多關(guān)于微前端的討論，但依然缺乏真正落地到生產(chǎn)環(huán)境的案例。因此，我們希望通過(guò)對(duì)閃購(gòu)團(tuán)隊(duì)近半年在微前端方案上的實(shí)踐分享，幫助大家對(duì)微前端從概念到應(yīng)用有一個(gè)更加清晰的認(rèn)識(shí)，也期待與大家一起交流，碰撞出更多的火花。

作者簡(jiǎn)介

雨甫，美團(tuán)閃購(gòu)前端研發(fā)工程師。

招聘

美團(tuán)閃購(gòu)是美團(tuán)點(diǎn)評(píng)旗下的零售到家業(yè)務(wù)，閃購(gòu)專注于為消費(fèi)者提供豐富、便捷的零售品類選擇和及時(shí)配送服務(wù)，為零售商家提供線上、線下的整體解決方案，助力商家提升經(jīng)營(yíng)效率。

用戶通過(guò)手機(jī)下單即可快速買到周邊各類商家提供的豐富商品，涵蓋食材生鮮、超市便利、鮮花綠植、母嬰用品和健康護(hù)理等眾多品類。美團(tuán)閃購(gòu)與美團(tuán)外賣共享配送網(wǎng)絡(luò)，平均30分鐘配送上門，24小時(shí)無(wú)間斷配送，打造全品類一站式零售到家平臺(tái)。

美團(tuán)閃購(gòu)前端團(tuán)隊(duì)誠(chéng)招高級(jí)前端開(kāi)發(fā)、前端開(kāi)發(fā)專家。歡迎各位大佬的加入，共同打造極致的LBS電商體驗(yàn)。感興趣同學(xué)可投遞簡(jiǎn)歷至：tech@meituan.com（郵件標(biāo)題注明：美團(tuán)閃購(gòu)前端團(tuán)隊(duì)）

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來(lái)咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的Bifrost微前端框架及其在美团闪购中的实践的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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