文章將講述業(yè)界各大知名IT企業(yè)使用的微前端解決方案，以及其帶來的利弊之處，因?yàn)槟切┍锥?，使得我們團(tuán)隊(duì)自己探究了一套目前認(rèn)為最好的微前端解決方案。通過本文，可以快速幫您理清楚微前端方案的利弊，從而做出有利于您團(tuán)隊(duì)的更好更明智的選擇。

一、寫在前面

在之前的文章中，我們已經(jīng)深入剖析了 微前端究竟是什么，可以帶來什么收益 ，現(xiàn)在讓我們復(fù)習(xí)一下微前端的概念：

Techniques, strategies and recipes for building a modern web app with multiple teams that can ship features independently. 

中文釋義：

可以由多個(gè)團(tuán)隊(duì)獨(dú)立開發(fā)的現(xiàn)代web應(yīng)用程序的技術(shù)、策略和方案。

本文則是在此基礎(chǔ)上對(duì)現(xiàn)有的微前端解決方案進(jìn)行對(duì)比總結(jié)，廢話少說，讓我們開始今天的課題。

二、現(xiàn)有微前端解決方案

查找了大量的資料后，我總結(jié)了以下主流的能夠真正實(shí)現(xiàn)微前端概念的解決方案，如有遺漏，歡迎小伙伴們補(bǔ)充~

1、iframe

眾所周知， iframe 是 html 提供的標(biāo)簽， 能加載其他web應(yīng)用的內(nèi)容 ，并且它能兼容所有的瀏覽器，因此，你可以用它來 加載任何你想要加載的web應(yīng)用 。

iframe最大的特性就是提供了瀏覽器原生的硬隔離方案，不論是樣式隔離、js 隔離這類問題統(tǒng)統(tǒng)都能被完美解決。讀到這時(shí)，相信小伙伴們跟我一樣，覺得iframe與微前端概念中提到的 獨(dú)立開發(fā) 、 獨(dú)立維護(hù) 、 相互隔離 非常的吻合，有種直接上ifame就完事兒了的想法，但為何它到現(xiàn)在也不是微前端主要的實(shí)現(xiàn)方式呢，后來有幸拜讀了 qiankun技術(shù)圓桌 中一篇關(guān)于微前端 Why Not Iframe 的思考，總結(jié)的很到位，現(xiàn)復(fù)述其中的一段描述

iframe雖然基本能做到微前端所要做的所有事情，但它的最大問題也在于他的隔離性無法被突破，導(dǎo)致應(yīng)用間上下文無法被共享，隨之帶來開發(fā)體驗(yàn)、產(chǎn)品體驗(yàn)的問題。

以下是我對(duì)該文中總結(jié)部分的總結(jié)：

• 不是單頁應(yīng)用，會(huì)導(dǎo)致瀏覽器刷新 iframe url 狀態(tài)丟失、后退前進(jìn)按鈕無法使用。

• 彈框類的功能無法應(yīng)用到整個(gè)大應(yīng)用中，只能在對(duì)應(yīng)的窗口內(nèi)展示。

• 由于可能應(yīng)用間不是在相同的域內(nèi)，主應(yīng)用的 cookie 要透傳到根域名都不同的子應(yīng)用中才能實(shí)現(xiàn) 免登錄 效果。

• 每次子應(yīng)用進(jìn)入都是一次瀏覽器上下文重建、資源重新加載的過程，占用大量資源的同時(shí)也在極大地消耗資源。

• iframe的特性導(dǎo)致搜索引擎無法獲取到其中的內(nèi)容，進(jìn)而無法實(shí)現(xiàn)應(yīng)用的 seo

我猜，以上原因便是 iframe 沒能作為官方微前端方案的原因吧。

2、Web Components

或許很多小伙伴對(duì) Web Components 不是很了解,它是由 google 推出的瀏覽器的原生組件, MDN 對(duì) Web Components 的定義是這樣的：

作為開發(fā)者，我們都知道盡可能多的重用代碼是一個(gè)好主意。這對(duì)于自定義標(biāo)記結(jié)構(gòu)來說通常不是那么容易 — 想想復(fù)雜的HTML（以及相關(guān)的樣式和腳本），有時(shí)您不得不寫代碼來呈現(xiàn)自定義UI控件，并且如果您不小心的話，多次使用它們會(huì)使您的頁面變得一團(tuán)糟。

Web Components旨在解決這些問題 — 它由三項(xiàng)主要技術(shù)組成，它們可以一起使用來創(chuàng)建封裝功能的定制元素，可以在你喜歡的任何地方重用，不必?fù)?dān)心代碼沖突。

它的 三項(xiàng)主要技術(shù) 是指：

• Custom elements（自定義元素）：一組JavaScript API，允許您定義custom elements及其行為，然后可以在您的用戶界面中按照需要使用它們。

• Shadow DOM（影子DOM）：一組JavaScript API，用于將封裝的“影子”DOM樹附加到元素（與主文檔DOM分開呈現(xiàn)）并控制其關(guān)聯(lián)的功能。通過這種方式，您可以保持元素的功能私有，這樣它們就可以被腳本化和樣式化，而不用擔(dān)心與文檔的其他部分發(fā)生沖突。

• HTML templates（HTML模板）： <template> 和 <slot> 元素使您可以編寫不在呈現(xiàn)頁面中顯示的標(biāo)記模板。然后它們可以作為自定義元素結(jié)構(gòu)的基礎(chǔ)被多次重用。

通過以上描述，再結(jié)合微前端的概念，我們來看看 Web Components 是如何做到微前端：

• 技術(shù)棧無關(guān)： Web Components 是瀏覽器原生組件，那即是在任何框架中都可以使用。

• 獨(dú)立開發(fā)：使用 Web Components 開發(fā)的應(yīng)用無需與其他應(yīng)用間產(chǎn)生任何關(guān)聯(lián)。

• 應(yīng)用間隔離： Shadow DOM 的特性，各個(gè)引入的微應(yīng)用間可以達(dá)到相互隔離的效果。

綜上所述， Web Components 是有能力以組件加載的方式將微應(yīng)用整合在一起作為微前端的一種手段，但不幸的是， Web Components 是瀏覽器的新特性，所以它的兼容性不是很好，如果有兼容性要求的項(xiàng)目還是無法使用，具體請(qǐng)查看 can i use 。

3、ESM

ESM 是 ES Module 的縮寫，是 Ecma script 2015 中提出的一種前端模塊化手段，那么，它又是如何做到微前端的呢？其實(shí)，微前端無外乎三大特性， 無技術(shù)棧限制 、 應(yīng)用單獨(dú)開發(fā) ， 多應(yīng)用整合 ，只要抓住了這三個(gè)特性，那就不難理解 ESM 如何做的了：

• 無技術(shù)棧限制： ESM 加載的只是js內(nèi)容，無論哪個(gè)框架，最終都要編譯成js，因此，無論哪種框架， ESM 都能加載。

• 應(yīng)用單獨(dú)開發(fā)：ESM只是js的一種規(guī)范，不會(huì)影響應(yīng)用的開發(fā)模式。

• 多應(yīng)用整合：只要將微應(yīng)用以 ESM 的方式暴露出來，就能正常加載。

• 遠(yuǎn)程加載模塊: ESM 能夠直接請(qǐng)求 cdn 資源，這是它與生俱來的能力。

ESM 是能做到微前端的核心思想，但是它也存在著 兼容性 這一大弊端，盡管 ESM 已經(jīng)很優(yōu)秀了，但是 大部分老版的瀏覽器 仍然無法直接使用，這也是babel等編譯工具出現(xiàn)的原因，幸運(yùn)的是，他可以通過 webpack 、 rollup 、 esbuild 、 snowpack 等編譯工具成為兼容性的代碼。

4、qiankun

在微前端界， qiankun 算得上是最早成型且知名度最廣的框架了，它是真正意義上的單頁微前端框架，那么 qiankun 到底有哪些特點(diǎn)呢，在其 官網(wǎng) 中我找到了如下概括：

• 基于 single-spa 封裝，提供了更加開箱即用的 API

• 技術(shù)棧無關(guān)，任意技術(shù)棧的應(yīng)用均可 使用/接入，不論是 React/Vue/Angular/JQuery 還是其他等框架

• HTML Entry 接入方式，讓你接入微應(yīng)用像使用 iframe 一樣簡單

• 樣式隔離，確保微應(yīng)用之間樣式互相不干擾

• JS 沙箱，確保微應(yīng)用之間 全局變量/事件 不沖突

• 資源預(yù)加載，在瀏覽器空閑時(shí)間預(yù)加載未打開的微應(yīng)用資源，加速微應(yīng)用打開速度

• umi 插件，提供了 @umijs/plugin-qiankun 供 umi 應(yīng)用一鍵切換成微前端架構(gòu)系統(tǒng)除了最后一點(diǎn)拓展以外，微前端想要達(dá)到的效果都已經(jīng)達(dá)到。

5、EMP

EMP是由歡聚時(shí)代業(yè)務(wù)中臺(tái)自主研發(fā)的最年輕的 單頁微前端解決方案

那么，他有哪些特性呢，下面我們一起看看：

• 基于 Webpack5 的新特性 Module Federation 實(shí)現(xiàn)，達(dá)到 第三方依賴共享，減少不必要的代碼引入 的目的，什么是Module Federation這里就不再贅述。

• 每個(gè)微應(yīng)用獨(dú)立部署運(yùn)行，并通過cdn的方式引入主程序中，因此只需要部署一次，便可以提供給任何基于 Module Federation 的應(yīng)用使用。并且此部分代碼是遠(yuǎn)程引入，無需參與應(yīng)用的打包。

• 動(dòng)態(tài)更新微應(yīng)用： EMP 是通過 cdn 加載微應(yīng)用，因此每個(gè)微應(yīng)用中的代碼有變動(dòng)時(shí)，無需重新打包發(fā)布新的整合應(yīng)用便能加載到最新的微應(yīng)用。

• 去中心化，每個(gè)微應(yīng)用間都可以引入其他的微應(yīng)用，無中心應(yīng)用的概念。

• 跨技術(shù)棧組件式調(diào)用，提供了在主應(yīng)用框架中可以調(diào)用其他框架組件的能力（目前已支持互相調(diào)用的框架及使用方式請(qǐng)參閱官方文檔）。

• 按需加載，開發(fā)者可以選擇只加載微應(yīng)用中需要的部分，而不是強(qiáng)制只能將整個(gè)應(yīng)用全部加載。

• 應(yīng)用間通信，每一個(gè)應(yīng)用都可以進(jìn)行狀態(tài)共享，就像在使用npm模塊進(jìn)行開發(fā)一樣便捷。

• 生成對(duì)應(yīng)技術(shù)棧模板，它能像 cerate-react-app 一樣，也能像 create-vue-app 一樣，通過指令一鍵搭建好開發(fā)環(huán)境，減少開發(fā)者的負(fù)擔(dān)。

• 遠(yuǎn)程拉取ts聲明文件， emp-cli 中內(nèi)置了拉取遠(yuǎn)程應(yīng)用中代碼聲明文件的能力，讓使用ts開發(fā)的開發(fā)者不再為代碼報(bào)錯(cuò)而煩惱。

細(xì)心的小伙伴應(yīng)該發(fā)現(xiàn)， EMP 除了具備微前端的能力外，還實(shí)現(xiàn)了跨應(yīng)用狀態(tài)共享、跨框架組件調(diào)用的能力，這是現(xiàn)有框架所不具備的優(yōu)秀特性！

三. 總結(jié)

又到了下課的最后五分鐘時(shí)間，一起來看看今天的分享都有哪些關(guān)鍵的知識(shí)需要掌握：

1. 現(xiàn)有微前端解決方案：

• iframe

• Web Components

• ESM

• qiankun

• EMP

2. 各解決方案的利弊：

• • iframe 可以直接加載其他應(yīng)用，但無法做到單頁導(dǎo)致許多功能無法正常在主應(yīng)用中展示。

  • web Components 及 ESM 是瀏覽器提供給開發(fā)者的能力，能在單頁中實(shí)現(xiàn)微前端，不過后者需要做好代碼隔離，并且他們都是瀏覽器的新特性，都存在 兼容性 問題，微前端方面的探索也不成熟，只能作為面向未來的微前端手段。

  • qiankun 基本上可以稱為單頁版的iframe，具有 沙箱隔離 及 資源預(yù)加載 的特點(diǎn)，幾乎無可挑剔。

  • EMP 作為最年輕微前端解決方案，也是吸收了許多web優(yōu)秀特性才誕生的，它在實(shí)現(xiàn)微前端的基礎(chǔ)上，擴(kuò)充了 跨應(yīng)用狀態(tài)共享 、 跨框架組件調(diào)用 、 遠(yuǎn)程拉取ts聲明文件 、 動(dòng)態(tài)更新微應(yīng)用 等能力。同時(shí)，細(xì)心的小伙伴應(yīng)該已經(jīng)發(fā)現(xiàn)， EMP 能做到 第三方依賴的共享 ，使代碼盡可能地重復(fù)利用，減少加載的內(nèi)容。