1.路由分發(fā)式旁仿。通過HTTP服務(wù)器的反向代理功能，將請求路由到對應(yīng)的應(yīng)用上
路由分發(fā)式微前端，即通過路由將不同的業(yè)務(wù)分發(fā)到不同的獨立前端應(yīng)用上锯厢，每當(dāng)用戶從A應(yīng)用轉(zhuǎn)換到B應(yīng)用的時候皮官，往往需要刷新一下頁面、重新加載資源文件
2.前端容器化实辑。將iframe作為容器來容納其他前端應(yīng)用
3.微應(yīng)用捺氢。通過軟件工程的方式，在部署構(gòu)建環(huán)境中剪撬，把多個獨立的應(yīng)用組合成一個單體應(yīng)用
微應(yīng)用化是指摄乒，在開發(fā)時應(yīng)用都是以單一、微小應(yīng)用的形式存在的残黑，而在運行時則通過構(gòu)建系統(tǒng)合并這些應(yīng)用馍佑，組合成一個新的應(yīng)用
微應(yīng)用化與前端微服務(wù)化架構(gòu)類似，他們在開發(fā)時都是獨立應(yīng)用梨水，在構(gòu)建時又可以按照需求單獨加載
如果以微前端的單獨開發(fā)挤茄、單獨部署、運行時聚合的基本思想來看冰木，微應(yīng)用化就是微前端的一種實踐穷劈。只是使用微應(yīng)用化意味著我們只能使用唯一的一種前端框架
除了限制開發(fā)人員使用同一個框架，它還有一些缺點：
所有應(yīng)用的依賴需要統(tǒng)一踊沸，一旦依賴版本不一致歇终，可能會帶來其他問題
高度依賴于持續(xù)集成，每個子應(yīng)用在提交的時候逼龟，都會重新構(gòu)建出整個應(yīng)用评凝，一旦一個子應(yīng)用出錯，系統(tǒng)就會出錯
微應(yīng)用化的形式是腺律，在構(gòu)建時以單體應(yīng)用的形式構(gòu)建奕短；在運行時，以應(yīng)用模塊的形式存在匀钧。從原理上說翎碑，我們做的只是從多個項目中復(fù)制出代碼，然后合并到一個項目中
microapps
? app-routing.module.ts
? reports.module.ts
? ...
dashboard
? dashboard.module.ts
? ...
reports
? reports.module.ts
? ...
settings
? settings.module.ts
? ...
除了主的app模塊之斯，還包含了dashboard日杈、settings、reports三個模塊佑刷。在微應(yīng)用化里莉擒，上述應(yīng)用便是最后構(gòu)建過程中的應(yīng)用。在構(gòu)建之前這些模塊是以獨立App的形式存在的瘫絮，可以獨立的開發(fā)運行涨冀。而主的App模塊下的功能，則可以變成主工程麦萤。這時鹿鳖，一共會有四個代碼倉庫
主代碼庫扁眯，只包含一個空白的框架式代碼，它是一個單獨的應(yīng)用栓辜，可以獨立構(gòu)建，構(gòu)建完成則成為包含另外三個應(yīng)用的完整工程
dashboard應(yīng)用垛孔，在構(gòu)建時復(fù)制對應(yīng)模塊藕甩、目錄的代碼到主工程
4.前端微服務(wù)化。在不同的框架之上設(shè)計通信和加載機(jī)制周荐，以在一個頁面內(nèi)加載對應(yīng)的應(yīng)用
每個前端應(yīng)用都是完全獨立（技術(shù)棧狭莱、開發(fā)、部署概作、構(gòu)建獨立）
采用這種方式意味著腋妙，一個頁面上同時存在兩個及以上的前端應(yīng)用在運行
在加載應(yīng)用時的事件綁定及應(yīng)用入口
在卸載應(yīng)用時的事件解綁
目前都采用基座化的方式來加載其他應(yīng)用，基座化方式可以支持加載不同的前端框架讯榕，以及在基座工程上綁定業(yè)務(wù)邏輯
整體的工作流程：
主工程在運行的時候骤素，會去服務(wù)器獲取最新的應(yīng)用配置
主工程在獲取配置后，將逐一創(chuàng)建應(yīng)用愚屁，并為應(yīng)用綁定生命周期
當(dāng)主工程監(jiān)測到路由變化的時候济竹，將尋找是否有對應(yīng)的路由匹配到應(yīng)用
當(dāng)匹配到對應(yīng)的應(yīng)用時，則加載相應(yīng)的應(yīng)用
基座包含以下功能：
管理其他子應(yīng)用
負(fù)責(zé)應(yīng)用間的通信
設(shè)計路由的響應(yīng)機(jī)制
支持嵌入常規(guī)及iframe模式
Single-SPA自稱是一個JavaScript的原框架霎槐，他可以用于構(gòu)建可共存的微前端應(yīng)用送浊，每個前端應(yīng)用都可以用自己的框架編寫。它能實現(xiàn)如下內(nèi)容：
在同一頁面上使用多個框架而不用刷新頁面
使用新的框架編寫前端代碼丘跌，而無需重寫現(xiàn)有的應(yīng)用程序
延時加載前端應(yīng)用和代碼袭景，用于改善初始加載時間
缺點：
系統(tǒng)構(gòu)建復(fù)雜，應(yīng)用需要集成在一起進(jìn)行構(gòu)建
不支持不同應(yīng)用的部署分離
代碼結(jié)構(gòu)復(fù)雜
有額外的大量學(xué)習(xí)成本
5.微件化闭树。開發(fā)一個新的構(gòu)建系統(tǒng)耸棒，將部分業(yè)務(wù)功能構(gòu)建成一個獨立的chunk代碼，使用時只需要遠(yuǎn)程加載即可
每個業(yè)務(wù)團(tuán)隊編寫自己的業(yè)務(wù)代碼报辱，并將編譯好的代碼部署（上傳或者放置）到指定的服務(wù)器榆纽。在運行時，我們只需要加載相應(yīng)的業(yè)務(wù)模塊即可
如果存在第三方開發(fā)組件捏肢，就不得不考慮尋找如iframe這樣的隔離方案奈籽。微件化并不適合復(fù)雜的前端應(yīng)用。
對于傳統(tǒng)的多頁面應(yīng)用來說鸵赫，微件化是相當(dāng)容易實施的方案衣屏。在傳統(tǒng)的多頁面應(yīng)用結(jié)構(gòu)中，只需要編寫相應(yīng)的HTML辩棒、CSS狼忱、JavaScript膨疏，就可以在加載微件時創(chuàng)建相應(yīng)的組建和元素，再替換到相應(yīng)的DOM結(jié)點上钻弄，這種方式類似于WebComponents
6.應(yīng)用組件化佃却。借助于Web Components技術(shù)，來構(gòu)建框架的前端應(yīng)用
對于不能從頭使用Web Components窘俺，有兩種方式可以結(jié)合Web Components來構(gòu)建微前端應(yīng)用
使用Web Components構(gòu)建獨立于框架的組件饲帅，并在對應(yīng)的框架中引入這些組件
在Web Components中引入現(xiàn)有的框架，類似于iframe的形式
方式 開發(fā)成本 維護(hù)成本 可行性 同一框架要求 實現(xiàn)難度 潛在風(fēng)險
路由分發(fā) 低 低 高 否 *
iframe 低 低 高 否 *
微服務(wù)化 高 低 中 否 **** 針對每個框架做定制及Hook
微件化 高 中 低 是 **** 正對構(gòu)建系統(tǒng)瘤泪，如webpack進(jìn)行hack
微應(yīng)用化 中 中 高 是 *** 統(tǒng)一不同應(yīng)用的構(gòu)建規(guī)范
WebComponents 高 低 高 否 ** 新技術(shù)灶泵，瀏覽器的兼容問題
js 隔離
一個子應(yīng)用從加載到運行，再到卸載对途，有可能會對全局產(chǎn)生一些污染赦邻。這些污染包括但不限于：添加、刪除实檀、修改全局變量（比如：window.$ = jQuery）惶洲、綁定全局事件（比如：window.addEventListener、修改原生方法或?qū)ο螅ū热纾篜romise）膳犹、修改原生方法或?qū)ο蟮脑玩湥ū热纾篨MLHttpRequest.prototype.open）湃鹊。而所有這些子應(yīng)用造成的影響都可能引起潛在的全局沖突。為此镣奋，我們需要在加載和卸載一個應(yīng)用的同時币呵，盡可能消除這種影響
硬隔離
簡單來說，就是在每個子應(yīng)用加載之前侨颈，都進(jìn)行一次 reload余赢，這樣可以保證每個子應(yīng)用在渲染時都是一個全新的環(huán)境，哪怕是上一個子應(yīng)用把 window 上的屬性改了個遍哈垢，也絲毫沒有影響
css 隔離
子應(yīng)用與子應(yīng)用之間的 css 隔離非常簡單妻柒，我們只需要在子應(yīng)用加載時，標(biāo)記該子應(yīng)用所有的 link 和 style 文件耘分。在子應(yīng)用卸載后举塔，同步卸載所有的 link 和 style 即可
子項目原本需要加載的公共部分（如vue、vuex求泰、vue-router央渣、ivew/element、私有npm包等）渴频，全部由主項目調(diào)度芽丹，配合webpack的externals功能通過外鏈的方式按需加載，一旦有一個子項目加載過卜朗，下一個子項目就不需要再加載拔第，這樣一來每個子項目的dist文件里就只有子項目自己的業(yè)務(wù)代碼（最終子項目包的體積縮小了80%咕村，只有幾十k），項目實際加載速度快了很多
umijs/qiankun
