為什么出現(xiàn)了微前端：

"單項目的弊端"：
1.打包項目的等待時間長
2.新的技術棧
3.不同團隊項目的融合层皱，不同的技術棧不兼容

一、為什么要使用微前端赠潦？

微服務：
微服務的核心就是將傳統(tǒng)的一站式應用叫胖，根據(jù)業(yè)務拆分成一個一個的服務，徹底的解耦她奥。每一個服務提供單個業(yè)務功能的服務瓮增。一個服務做一件事情。
從技術的角度看就是一種小而獨立的處理過程哩俭，類似進程的概念钉赁，能夠自行單獨啟動和銷毀，擁有自己獨立數(shù)據(jù)庫携茂。
微服務注重解耦你踩，微前端注重聚合，

• 不同團隊間開發(fā)同一個應用技術棧不同怎么辦讳苦？
• 希望每個團隊可以獨立開發(fā)带膜，獨立部署怎么辦？
• 項目中還需要老的應用代碼怎么辦鸳谜？
  微前端就是通過引入一種更優(yōu)雅的方式來解決面臨的問題

二膝藕、什么是微前端

微前端借鑒微服務的架構理念，將一個龐大的前端應用拆分為多個獨立靈活的小型應用咐扭，每個應用都可以獨立開發(fā)芭挽、獨立運行滑废、獨立部署，再將這些小型應用聯(lián)合為一個完整的應用袜爪。微前端既可以將多個項目融合為一蠕趁，又可以減少項目之間的耦合，提升項目擴展性辛馆，相比一整塊的前端倉庫俺陋，微前端架構下的前端倉庫傾向于更小更靈活

image.png

三、微前端的優(yōu)/劣勢

微前端優(yōu)勢

微前端特點：

• 技術棧無關 主項目框架不限制接入項目的技術棧昙篙，子應用可自由選擇技術棧
• 獨立開發(fā)/部署 團隊之間倉庫獨立腊状，單獨部署，互不依賴
• 增量升級 當一個項目龐大起來苔可，技術升級和重構都比較麻煩缴挖，而微應用具備漸進式升級的特性
• 獨立運行時 微應用之間運行時，互不依賴焚辅，狀態(tài)管理獨立
• 提升效率 項目越龐大醇疼，越難以維護，協(xié)作效率越低下法焰。微應用就可以很好拆分，提高效率
  資源復用
  場景：如果項目需要開發(fā)某個新功能倔毙，而另外一個項目已經(jīng)開發(fā)過這個功能埃仪，如果想直接復用，對于傳統(tǒng)的單頁面應用來說陕赃，需要考慮到技術不同卵蛉，版本不同以及別人的頁面有些自己項目的某些操作，這些都要考慮到
  微前端可以將我們所需要的一些頁面或者功能么库，通過特定的配置傻丝，快速集合進一個新的項目中，達到快速的可復用級應用頁面及資源

微前端劣勢

1.重復依賴诉儒，不同應用之間的依賴包有可能會存在很多重復的葡缰，由于各應用獨立開發(fā)、編譯忱反、部署泛释，難免會出現(xiàn)重復依賴，不同應用之間重復下載依賴温算，額外再增加了流量和服務端壓力
2.技術成本變高怜校，一個問題的跟蹤，有可能需要對應的人員注竿，懂微前端茄茁，又懂主應用和子應用魂贬，可能需要同時深入了解微前端和react和vue才能解決問題，復雜度由代碼轉向基建裙顽。
3.沒有健全的前端周邊讓其充分發(fā)揮架構的優(yōu)勢

微前端的設計

主要采用：組合式應用路由方案
核心：“主從思想”
包括一個基座（MainApp）應用付燥、公共應用（CommanApp）和多個單獨的微應用（MicroApp）組成
基座應用：前端VUE SPA項目，主要負責渲染公共的頁面元素锦庸，比如 header机蔗、footer、應用注冊甘萧、路由映射萝嘁、消息下發(fā)、菜單渲染扬卷、邏輯控制牙言、數(shù)據(jù)傳輸?shù)取?br> 公共應用：單獨的VUE SPA項目，包含一些公用的頁面怪得、組件以及登陸邏輯等咱枉，輔助基座應用進行運行，
微應用是獨立前端項目徒恋，這些項目不限制接入的技術棧蚕断，可自由選擇技術棧，每個微應用注冊到基座應用中入挣，由基座進行管理亿乳，但是如果脫離基座也是可以單獨訪問

四、微前端實現(xiàn)

1.常見微前端方案

• 基于iframe完全隔離的方案
  優(yōu)點：
  1.簡單無需任何改造
  2.js和css都是獨立的運行環(huán)境
  3.不限制使用径筏，可放多個iframe來組合業(yè)務
  缺點：
  1.刷新后路由狀態(tài)丟失葛假，無法保持路由狀態(tài)
  2.完全的隔離導致通訊交互困難，只能采用postMessage方式 全局上下文完全隔離滋恬，內(nèi)存變量不共享聊训。iframe 內(nèi)外系統(tǒng)的通信、數(shù)據(jù)同步等需求恢氯，主應用的 cookie 要透傳到根域名都不同的子應用中實現(xiàn)免登效果带斑。
  3.iframe中的彈窗無法突破其本身
  4.整個應用全量資源加載，加載太慢
• 基于single-spa路由劫持方案
  通過劫持路由的方式來做子應用之間的切換勋拟，（監(jiān)聽url的變化動態(tài)加載資源）但接入方式需要融合自身的路由遏暴，有一定的局限性。
  上手成本高
• 阿里qiankun
  qiankun基于single-spa做的封裝指黎，通過 import-html-entry 包解析 HTML 獲取資源路徑朋凉，然后對資源進行解析、加載醋安。
  優(yōu)點：
  1.基于single-spa封裝杂彭，提供了更加開箱即用的API
  2.接入微應用像接入iframe一樣簡單
  3.樣式隔離墓毒，確保微應用之間樣式互不打擾
  4.js沙箱，確保微應用之間全局變量/事件不沖突
  5.資源預加載亲怠，在瀏覽器空閑時間預加載未打開的微應用資源所计，加速微應用打開速度
  缺點：
  qiankun只能解決子項目之間的樣式污染，無法阻止子項目的樣式污染主項目的樣式

qiankun3.0籌備中团秽。主胧。。
3.0 里一個主要的功能是會把沙箱開放出去习勤，可以讓開發(fā)者自己根據(jù)場景制定沙箱規(guī)則踪栋。
比如上面提到的，有的場景你希望更嚴格的沙箱图毕，比如劫持 localStorage 的讀寫夷都，但是默認沙箱里沒有做，那你可以直接通過 api 把邏輯加進去予颤，
或者有的場景你覺得默認沙箱又太嚴格囤官，希望共享一些東西，那就可以通過一些配置蛤虐，把默認的行為關掉一些党饮。

（為什么不能在vite上使用微前端）
qiankun 是目前是社區(qū)主流微前端方案。它雖然很完善驳庭、流行刑顺，但最大的問題就是不支持 Vite。
因為 esm 的機制導致現(xiàn)在沒辦法把 js 拿來做手動 evaluate嚷掠，因為要支持沙箱，
如果看到社區(qū)中有qiankun+vite的方案荞驴，像這種是不支持沙箱的不皆。
它基于 import-html-entry 解析 HTML 來獲取資源，由于 qiankun 是通過 eval來執(zhí)行這些 js 的內(nèi)容熊楼，而 Vite 中的 script 標簽類型是 type="module"霹娄，里面包含 import/export 等模塊代碼， 所以會報錯：不允許在非 type="module" 的 script 里面使用 import鲫骗。

• 京東micro-app方案
  micro-app借鑒了 WebComponent 的思想犬耻，通過 CustomElement 結合自定義的 ShadowDom，將微前端封裝成一個類 webComponents 組件执泰，從而實現(xiàn)微前端的組件化渲染

image.png