在 toB 的前端開發工作中，我們往往就會遇到如下困境：

1. 工程越來越大，打包越來越慢
2. 團隊人員多，產品功能復雜，代碼沖突頻繁、影響面大
3. 內心想做 SaaS 產品，但客戶總是要做定制化

不同的團隊可能有不同的方法去解決這些問題。在前端開發日新月異、前端工程化蓬勃發展的今天，我想給大家介紹下另一種嘗試——微前端。

微前端是什么？

那什么是微前端？微前端主要是借鑒后端微服務的概念。簡單地說，就是將一個巨無霸(Monolith)的前端工程拆分成一個一個的小工程。別小看這些小工程，它們也是“麻雀雖小，五臟俱全”，完全具備獨立的開發、運行能力。整個系統就將由這些小工程協同合作，實現所有頁面的展示與交互。

可以跟微服務這么對比著去理解：

微服務 微前端 一個微服務就是由一組接口構成，接口地址一般是 URL。當微服務收到一個接口的請求時，會進行路由找到相應的邏輯，輸出響應內容。 一個微前端則是由一組頁面構成，頁面地址也是 URL。當微前端收到一個頁面 URL 的請求時，會進行路由找到相應的組件，渲染頁面內容。 后端微服務會有一個網關，作為單一入口接收所有的客戶端接口請求，根據接口 URL 與服務的匹配關系，路由到對應的服務。 微前端則會有一個加載器，作為單一入口接收所有頁面 URL 的訪問，根據頁面 URL 與微前端的匹配關系，選擇加載對應的微前端，由該微前端進行進行路由響應 URL。 這里要注意跟 iframe 實現頁面嵌入機制的區別。微前端沒有用到 iframe，它很純粹地利用 JavaScript、MVVM 等技術來實現頁面加載。后面我們將介紹相關的技術實現。

為什么要用微前端

在介紹具體的改造方式之前，我想跟大家先說明下我們當時面臨的問題，以及改造后的對比，以便大家以此為對照，評判或決定使用。主要包括打包速度、頁面加載速度、多人多地協作、SaaS 產品定制化、產品拆分這幾個角度。

首先是打包速度。在 6 個月前，我們的 B 端工程那會兒還是一個 Monolith。當時已經有 20 多個依賴、60 多個公共組件、200 多個頁面，對接 700 多個接口。我們使用了 Webpack 2，并啟用 DLL Plugin、HappyPack 4。在我的個人主機上使用 4 線程編譯，大概要 5 分鐘。而如果不拆分，算下來現在我們已經有近 400 個頁面，對接1000 多個接口。

這個時間意味著什么？它不僅會耽誤我們開發人員的時間，還會影響整個團隊的效率。上線時，在 Docker、CI 等環境下，耗時還會被延長。如果部署后出幾個 Bug，要線上立即修復，那就不知道要熬到幾點了。

在使用微前端改造后，目前我們已經有 26 個微前端工程，平均打包時間在 30-45 秒之間(注意，這里還沒有應用 DLL + HappyPack)。

頁面加載速度其實影響到并不是很大，因為經過 CDN、gzip 后，資源的大小還能接受。這里只是給大家看一些直觀的數據變化。6 個月前，打包生成的 app.js 有 5MB(gzip 后 1MB)，vendor.js 有 2MB(gzip 后 700KB)，app.css 有 1.5MB(gzip 后 250KB)。這樣首屏大概要傳輸 2MB 的內容。拆分后，目前首屏只需要傳輸 800KB 左右。

在協作上，我們在全國有三個地方的前端團隊，這么多人在同一個工程里開發，遭遇代碼沖突的概率會很頻繁，而且沖突的影響面比較大。如果代碼中出現問題，導致 CI 失敗，所有其他人的代碼提交與更新也都會被阻塞。使用微前端后，這樣的風險就平攤到各個工程上去了。

再者就是定制化了。我們做的額是一款 toB 的產品，做成 SaaS 標準版產品大概是所有從業者的愿望。但整體市場環境與產品功能所限，經常要面臨一些客戶要求做本地化與定制化的要求。本地化就會有代碼安全方面的考量，最好是不給客戶源代碼，最差則是只給客戶購買功能的源代碼。而定制化從易到難則可以分為獨立新模塊、改造現有模塊、替換現有模塊。

通過微前端技術，我們可以很容易達到本地化代碼安全的下限——只給客戶他所購買的模塊的前端源碼。定制化里最簡單的獨立新模塊也變得簡單：交付團隊增加一個新的微前端工程即可，不需要揉進現有研發工程中，不占用研發團隊資源。而定制化中的改造現有模塊也可以比較好地實現：比如說某個標準版的頁面中需要增加一個面板，則可以通過一個新的微前端工程，同樣響應該頁面的 URL(當然要控制好順序)，在頁面的恰當位置插入一個新的 DOM 節點即可。

最后就是產品拆分方面的考量了。我們的產品比較大，有幾塊功能比較獨立、有特色。如果說將來需要獨立成一個子產品，有微前端拆分作為鋪墊，騰挪組合也會變得更加容易些。

其他目標

有了以上的一些原因與訴求，在決定進行微前端改造前，還需要設定一些額外的小目標：

• 不能對現有的前端開發方式帶來太大變化，至少要有平滑過渡的機制。
• 每個為前端工程都要求可以獨立運行，至少在本地開發時要能做到。
• 微前端在加載時，要實現預加載，并可以自由調整預加載順序，甚至是根據用戶的偏好來實現智能化、個性化的加載順序。

如何改造現有工程？

“Talk is cheap，show me the code“。下面就讓我們一起來看看具體的改造吧！我們的微前端工程可以劃分為 portal 工程、業務工程、common 工程這幾類。

portal 工程

portal，顧名思義，就是入口。這也就是上面所說的微前端加載器。當用戶打開瀏覽器，首次進入我們的頁面時，不管是什么 URL，首先加載的就是 portal。portal 里會配置所有業務工程的地址、匹配哪些 URL、需要加載哪些資源。如：

// 業務工程的名稱customer: { // URL 匹配模式 matchUrlHash: ['^/customer'], // 微前端地址 target: 'http://localhost:8101/mfe-customer/index.html', // 資源匹配模式 resourcePatterns: ['/app.*.css$', '/vendor.*.css$', '/manifest.*.js$', '/vendor.*.js$', '/app.*.js$'],}

portal 會定時、異步、并發地下載業務工程的資源，并將它們進行注冊，此時并不會加載這些業務工程。這里之所以要業務工程的地址(target)、資源(resourcePatterns)，是為了加載時確定地知道其所包含的 app.js、vendor.js、app.css 等資源的路徑。因為業務工程每次有變更，app.js 等資源路徑上都會帶有新的文件內容哈希值(Hash)，導致路徑不可預測。而它的 index.html 的路徑是固定的。我們讀取該 HTML，解析其內容，通過正則就能匹配到 app.js 等資源的路徑。

portal 在運行時，會監聽 URL 變化。目前我們只支持 URL Hash(如 #/customer)。當 Hash 發生變更時，匹配到業務工程，然后執行卸載、加載的工作。這個機制主要是利用 single-spa 來實現，但原理就是這么簡單。

import { registerApplication } from 'single-spa';registerApplication('customer',  // 下載微前端工程，獲取三個函數鉤子：bootstrap、mount、unmount () => { const html = fetch(mfeConfig.target); const {cssUrls, jsUrls} = match(html, mfeConfig.resourcePatterns); loadCss(cssUrls); loadJs(jsUrls); return windows['mfe:customer']; }, // 對當前瀏覽器 URL Hash 進行匹配，如果匹配(返回 true)，則加載該微前端(調用 mount)；否則卸載(調用 unmount) () => { return match(window.location.hash, mfeConfig.matchUrlHash); }, mfeConfig.customProps);

業務工程

業務工程就是普通的微前端工程，一般一個模塊一個工程。業務工程要扮演兩個角色，一個是可獨立運行的前端工程，一個是受 portal 控制的運行時。前者主要用于我們本地開發，后者則是線上集成時使用。在獨立運行時，它跟原來的前端工程沒有什么區別。以 Vue 工程為例，照樣使用 new Vue({el: '#app'}) 來啟動、渲染頁面。

new Vue({ el: '#app', i18n, router, store, template: '', components: { App }});

而當受控運行時，則是利用 UMD 方式輸出幾個鉤子函數，包括初始化、加載、卸載。

if(!window.IS_IN_MFE){ // 獨立運行時 new Vue({...})} else { // 受控運行時 module.exports = { bootstrap(){ // 注冊時執行 }, mount(customProps){ // 加載時執行 return Promise.resolve().then(()=>{ instance = new Vue({...}) }) }, unmount(){ // 卸載時執行 return Promise.resolve().then(()=>{ instance.$destroy() }) } }}

線上環境的 Webpack 配置：

output: { libraryTarget: "umd

總結

以上是生活随笔為你收集整理的bootstrap跟vue冲突吗_知道微服务，但你知道微前端吗？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。