掃二維碼與項目經(jīng)理溝通
我們在微信上24小時期待你的聲音
解答本文疑問/技術(shù)咨詢/運營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流
微前端架構(gòu)具備以下的特點:

公司主營業(yè)務(wù):成都做網(wǎng)站、網(wǎng)站設(shè)計、移動網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實現(xiàn)互聯(lián)網(wǎng)宣傳,提高企業(yè)的競爭能力。成都創(chuàng)新互聯(lián)是一支青春激揚、勤奮敬業(yè)、活力青春激揚、勤奮敬業(yè)、活力澎湃、和諧高效的團隊。公司秉承以“開放、自由、嚴謹、自律”為核心的企業(yè)文化,感謝他們對我們的高要求,感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn),讓我們激情的團隊有機會用頭腦與智慧不斷的給客戶帶來驚喜。成都創(chuàng)新互聯(lián)推出淇濱免費做網(wǎng)站回饋大家。
微前端架構(gòu)旨在解決單體應(yīng)用在一個相對長的時間跨度下,由于參與的人員、團隊的增多、變遷,從一個普通應(yīng)用演變成一個巨石應(yīng)用(Frontend Monolith)后,隨之而來的應(yīng)用不可維護的問題。比如:
通過微前端拆分成一個容器應(yīng)用和多個子應(yīng)用之后,各個應(yīng)用能夠獨立部署,相互之間隔離,從而做到:
通過Nginx配置反向代理來實現(xiàn)不同路徑映射到不同應(yīng)用,例如www.abc.com/app1對應(yīng)app1,www.abc.com/app2對應(yīng)app2,這種方案本身并不屬于前端層面的改造,更多的是運維的配置。
優(yōu)點:
缺點:
父應(yīng)用單獨是一個頁面,每個子應(yīng)用嵌套一個iframe,父子通信可采用postMessage或者contentWindow方式。
優(yōu)點:
缺點:
每個子應(yīng)用需要采用純Web Components技術(shù)編寫組件,是一套全新的開發(fā)模式
優(yōu)點:
缺點:
使用 Module Federation,我們可以在一個應(yīng)用中動態(tài)加載并執(zhí)行另一個應(yīng)用的代碼,且與技術(shù)棧無關(guān),并且能夠共享模塊,從而減小編譯時間以及降低包體積。
優(yōu)點:
缺點:
每個子應(yīng)用獨立構(gòu)建和部署,運行時由父應(yīng)用來進行路由管理,應(yīng)用加載,啟動,卸載,以及通信機制。
優(yōu)點:
缺點:
組合式應(yīng)用路由分發(fā)是目前業(yè)內(nèi)普遍使用的一種方案,并且能夠滿足大部分需求,接下來我們詳細來看看這種實現(xiàn)方式。
該方案使用的是基座模式,通過一個主應(yīng)用(基座應(yīng)用-Main APP),來管理其它應(yīng)用(子應(yīng)用-MicroAPP)?;鶓?yīng)用大多數(shù)是一個前端 SPA 項目,主要負責(zé)應(yīng)用注冊,路由映射,消息下發(fā)等,而微應(yīng)用是獨立前端項目,這些項目不限于采用 React,Vue,Angular 或者 JQuery 開發(fā),每個微應(yīng)用注冊到基座應(yīng)用中,由基座進行管理,但是如果脫離基座也是可以單獨訪問。
當整個微前端框架運行之后,給用戶的體驗就是類似下圖所示:
簡單描述下就是基座應(yīng)用中有一些菜單項,點擊每個菜單項可以展示對應(yīng)的微應(yīng)用,這些應(yīng)用的切換是純前端無感知的
上面的實現(xiàn)過程主要如下:
注意:子應(yīng)用也可以將包打成多個,然后利用 webpack 的 webpack-manifest-plugin 插件打包出 manifest.json
文件,生成一份資源清單,然后主應(yīng)用的 loadApp 遠程讀取每個子應(yīng)用的清單文件,依次加載文件里面的資源;不過該方案也沒辦法享受子應(yīng)用的按需加載能力。
當主應(yīng)用和微應(yīng)用同屏渲染時,就可能會有一些樣式會相互污染,可以采取以下兩種方案:
而對于微應(yīng)用與微應(yīng)用之間的CSS隔離就非常簡單,在每次應(yīng)用加載時,將該應(yīng)用所有的link和style 內(nèi)容進行標記。在應(yīng)用卸載后,同步卸載頁面上對應(yīng)的link和style即可。
每當微應(yīng)用的 JavaScript 被加載并運行時,它的核心實際上是對全局對象 Window 的修改以及一些全局事件的改變,例如 jQuery 這個 js 運行后,會在 Window 上掛載一個 window.$ 對象,對于其他庫 React,Vue 也不例外。為此,需要在加載和卸載每個微應(yīng)用的同時,盡可能消除這種沖突和影響,最普遍的做法是采用沙箱機制(SandBox)。
沙箱機制的核心是讓局部的 JavaScript 運行時,對外部對象的訪問和修改處在可控的范圍內(nèi),即無論內(nèi)部怎么運行,都不會影響外部的對象。通常在 Node.js 端可以采用 vm 模塊,而對于瀏覽器,則需要結(jié)合 with 關(guān)鍵字和 window.Proxy 對象來實現(xiàn)瀏覽器端的沙箱。
微前端通常不會限制應(yīng)用采用的框架,如何在不同的應(yīng)用,框架之間進行通信是一個需要仔細考量的決定。應(yīng)用間通信有很多種方式,當然,要讓多個分離的微應(yīng)用之間要做到通信,本質(zhì)上仍離不開中間媒介或者說全局對象。
通過事件[3]進行通信應(yīng)該是最簡單、通用的方案了。
// 監(jiān)聽事件
window.addEventListener('message', (event) => {
// 處理事件
});
// 觸發(fā)事件
window.dispatchEvent(new CustomEvent('message', { detail: input.value }))
消息訂閱(pub/sub)模式的通信機制是非常適用的,在基座應(yīng)用中會定義事件中心Event,每個微應(yīng)用分別來注冊事件,當被觸發(fā)事件時再有事件中心統(tǒng)一分發(fā),這就構(gòu)成了基本的通信機制。
import { Observable } from 'windowed-observable';
const observable = new Observable('konoha');
observable.subscribe((ninja) => {
console.log(ninja)
})
observable.publish('Uchiha Shisui');
通過 Web Workers 進行事件通信。
import Worky from 'worky'
const worker = new Worky("some-worker.js");
worker.on("eventName", function (some, data) {
// 處理
});
worker.emit("someEvent", and, some, data);
主應(yīng)用創(chuàng)建 state store,共享給子應(yīng)用使用,適用于主、子應(yīng)用技術(shù)棧相同的場景。
微前端是一種將單個巨型應(yīng)用轉(zhuǎn)變?yōu)槎鄠€微型應(yīng)用聚合為一的應(yīng)用,能夠解決“巨石應(yīng)用”的維護性問題。實現(xiàn)微前端的方式有很多種,每種方案都需要考慮應(yīng)用隔離和應(yīng)用通信的問題,目前較為普遍使用的是組合式路由分發(fā)的方式。
[1]TECHNOLOGY RADAR:
https://www.thoughtworks.com/zh-cn/radar/techniques/micro-frontends
[2]import-html-entry:
https://www.npmjs.com/package/import-html-entry
[3]事件:
https://developer.mozilla.org/en-US/docs/Web/API/CustomEvent
[4]微前端(一)- 理念篇:
https://www.lumin.tech/blog/micro-frontends-1-concept/
[5]微前端-最容易看懂的微前端知識:
https://juejin.cn/post/6844904162509979662
[6]微前端在解決什么問題?:
https://cloud.tencent.com/developer/article/1546556
[7]微前端如何落地:
https://www.infoq.cn/article/xm_aaiotxmlppgwvx9y9
[8]微前端解決方案:
https://segmentfault.com/a/1190000040275586
[9]HTML Entry 源碼分析:
https://juejin.cn/post/6885212507837825038#heading-6

我們在微信上24小時期待你的聲音
解答本文疑問/技術(shù)咨詢/運營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流