微前端架構(gòu)的示例分析

小編給大家分享一下微前端架構(gòu)的示例分析，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

一、什么是微前端

而提到微前端就離不開(kāi)微服務(wù)，大家對(duì)微服務(wù)都比較熟悉了，微服務(wù)允許后端體系結(jié)構(gòu)通過(guò)松散耦合的代碼庫(kù)進(jìn)行擴(kuò)展，每個(gè)代碼庫(kù)負(fù)責(zé)自己的業(yè)務(wù)邏輯，并公開(kāi)一個(gè)API，每個(gè)API均可獨(dú)立部署，并且各自由不同的團(tuán)隊(duì)擁有和維護(hù)。

前端架構(gòu)經(jīng)歷了從單體，到前后端分離，再到微服務(wù)，最終發(fā)展到現(xiàn)在的微前端的過(guò)程如下圖所示：

微前端的思路是把微服務(wù)的架構(gòu)引入到前端，其核心都是要能夠以業(yè)務(wù)為單元構(gòu)建端到端的垂直架構(gòu)，使得單個(gè)的團(tuán)隊(duì)能夠獨(dú)立自主的進(jìn)行相關(guān)的開(kāi)發(fā)，同時(shí)又具備相當(dāng)?shù)撵`活性，按需求來(lái)組成交付應(yīng)用。

“微前端”一詞最早于2016年底在ThoughtWorks  技術(shù)雷達(dá)中提出的。它將微服務(wù)的概念擴(kuò)展到了前端世界。當(dāng)前的趨勢(shì)是構(gòu)建一個(gè)功能強(qiáng)大且功能強(qiáng)大的瀏覽器應(yīng)用程序(也稱為單頁(yè)應(yīng)用程序)，該應(yīng)用程序位于微服務(wù)架構(gòu)之上。隨著時(shí)間的流逝，通常由一個(gè)單獨(dú)的團(tuán)隊(duì)開(kāi)發(fā)的前端層會(huì)不斷增長(zhǎng)，并且變得更加難以維護(hù)。

微前端背后的想法是將網(wǎng)站或Web應(yīng)用程序視為由獨(dú)立團(tuán)隊(duì)擁有的功能的組合。每個(gè)團(tuán)隊(duì)都有自己關(guān)心和專長(zhǎng)的不同業(yè)務(wù)或任務(wù)領(lǐng)域。一個(gè)團(tuán)隊(duì)是跨職能的，并且從數(shù)據(jù)庫(kù)到用戶界面，端到端地開(kāi)發(fā)其功能。

但是，這個(gè)想法并不新鮮。它與“單體系統(tǒng)”概念有很多共同點(diǎn)。在過(guò)去，類似的方法被稱為“垂直系統(tǒng)的前端集成”。但是微前端顯然是一個(gè)更友好，更輕巧的術(shù)語(yǔ)。

在微服務(wù)的架構(gòu)中，后臺(tái)的服務(wù)已經(jīng)按照業(yè)務(wù)進(jìn)行了分離，而前端仍然是一個(gè)單體構(gòu)建，通過(guò)網(wǎng)關(guān)來(lái)調(diào)用不同的后臺(tái)服務(wù)。這個(gè)微服務(wù)的思路是相違背的，這也就造成了你的后端團(tuán)隊(duì)是按照業(yè)務(wù)分割的，但是前端團(tuán)隊(duì)仍然是一個(gè)整體。微前端可以有效地改進(jìn)這一點(diǎn)。

微前端的核心思路其實(shí)是遠(yuǎn)程應(yīng)用程序，包含組件/模塊/包的運(yùn)行時(shí)加載。

如上圖，對(duì)于用戶而言，訪問(wèn)的是一個(gè)微前端的容器(container)，容器加載運(yùn)行在遠(yuǎn)程服務(wù)上的應(yīng)用，把這些遠(yuǎn)程應(yīng)用作為組件/模塊/包在本地瀏覽器中加載。

• 組件是底層UI庫(kù)的構(gòu)建單元

• 模塊是相應(yīng)運(yùn)行時(shí)的構(gòu)建單元

• 包是依賴性解析器的構(gòu)建單元

• 微前端是所提出的應(yīng)用程序的構(gòu)建塊

二、為什么需要微前端?

它有什么優(yōu)勢(shì)?

在前面我們看到的微前端之前的架構(gòu)，所有的前端還是一個(gè)單體，前端團(tuán)隊(duì)會(huì)依賴所有的服務(wù)或者后臺(tái)的API，前端開(kāi)發(fā)會(huì)成為整個(gè)系統(tǒng)的瓶頸。使用微前端，就是要讓前端業(yè)務(wù)從水平分層變?yōu)榇怪睉?yīng)用的一部分，進(jìn)入業(yè)務(wù)團(tuán)隊(duì)，剝離耦合。

那么微前端有什么好處，為什么要采用微前端架構(gòu)呢?

• 各個(gè)團(tuán)隊(duì)獨(dú)立開(kāi)發(fā)，相互不影響，獨(dú)立開(kāi)發(fā)、獨(dú)立部署，微應(yīng)用倉(cāng)庫(kù)獨(dú)立，前后端可獨(dú)立開(kāi)發(fā)，部署完成后主框架自動(dòng)完成同步更新

• 增量升級(jí)，在面對(duì)各種復(fù)雜場(chǎng)景時(shí)，通常很難對(duì)一個(gè)已經(jīng)存在的系統(tǒng)做全量的技術(shù)棧升級(jí)或重構(gòu)，而微前端是一種非常好的實(shí)施漸進(jìn)式重構(gòu)的手段和策略。因?yàn)槭沁\(yùn)行時(shí)加載，可以在沒(méi)有重建的情況下添加，刪除或替換前端的各個(gè)部分。

• 不受技術(shù)影響，每個(gè)團(tuán)隊(duì)都應(yīng)該能夠選擇和升級(jí)其技術(shù)棧，而無(wú)需與其他團(tuán)隊(duì)進(jìn)行協(xié)調(diào)。也就是說(shuō)A應(yīng)用可以用React，而B(niǎo)應(yīng)用使用Vue，大家可以通過(guò)同一個(gè)微前端來(lái)加載

• 獨(dú)立運(yùn)行時(shí)，每個(gè)微應(yīng)用之間狀態(tài)隔離，運(yùn)行時(shí)狀態(tài)不共享。隔離團(tuán)隊(duì)代碼，即使所有團(tuán)隊(duì)都使用相同的框架，也不要共享運(yùn)行時(shí)。構(gòu)建自包含的獨(dú)立應(yīng)用程序。不要依賴共享狀態(tài)或全局變量。

• 建立團(tuán)隊(duì)命名空間，對(duì)于CSS，事件，本地存儲(chǔ)和Cookies，可以避免沖突并闡明所有權(quán)。

因此，微前端和微服務(wù)的本質(zhì)都是關(guān)于去耦合。而只有當(dāng)應(yīng)用程序達(dá)到一定規(guī)模時(shí)，這才開(kāi)始變得更有意義。

三、如何實(shí)現(xiàn)微前端架構(gòu)

微前端不是一個(gè)庫(kù)，是一種前端架構(gòu)的設(shè)計(jì)思路，要實(shí)現(xiàn)微前端，本質(zhì)上就是在運(yùn)行時(shí)遠(yuǎn)程加載應(yīng)用。

實(shí)現(xiàn)微前端，有幾個(gè)思路，從構(gòu)建的角度來(lái)看有兩種，編譯時(shí)構(gòu)建微前端和運(yùn)行時(shí)構(gòu)建微前端：

• 編譯時(shí)微前端，通常將第三方庫(kù)中的組件作為包，在構(gòu)建時(shí)引入依賴。這種實(shí)現(xiàn)引入新的微前端需要重新編譯，不夠靈活。編譯時(shí)的微前端可以通過(guò)Web  Components，Monorepo等方式來(lái)實(shí)現(xiàn)。其中Monorepo非常流行，常見(jiàn)的工具有nx，rush，lerna等。

• 運(yùn)行時(shí)微前端，是一次加載或通過(guò)延遲加載按需動(dòng)態(tài)將微型前端注入到容器應(yīng)用程序中時(shí)。當(dāng)引入新的微前端的時(shí)候，不需要構(gòu)建，可以動(dòng)態(tài)在代碼中定義加載。我眼中的微前端更多是指這種運(yùn)行時(shí)加載的微前端，因?yàn)楠?dú)立構(gòu)建，部署和測(cè)試是我們對(duì)于“微”的定義。

從前后端責(zé)任分層來(lái)看，可以從前端或者后端來(lái)實(shí)現(xiàn)。

通過(guò)客戶端框架來(lái)實(shí)現(xiàn)

微前端通常由客戶端工具來(lái)支持實(shí)現(xiàn)(聽(tīng)上去好有道理)，有許多支持客戶端開(kāi)發(fā)微前端的實(shí)現(xiàn)工具，包括：Piral，Open  Components，qiankun，Luigi，F(xiàn)rint.js等。其中qiankun是螞蟻金服開(kāi)發(fā)的。

在客戶端還可以通過(guò)輔助庫(kù)的方式來(lái)實(shí)現(xiàn)，輔助庫(kù)可以為共享依賴項(xiàng)，路由事件或不同的微前端及其生命周期來(lái)提供一些基礎(chǔ)架構(gòu)。

下面的一個(gè)示例是通過(guò)諸如導(dǎo)入映射或打包特定塊等機(jī)制處理共享依賴關(guān)系。

相關(guān)的工具有Webpack5 Module Federation，Siteless，Single SPA，Postal.js等

通過(guò)服務(wù)器端實(shí)現(xiàn)

微前端并非只能在客戶端來(lái)實(shí)現(xiàn)，類似于服務(wù)端渲染，同樣可以通過(guò)服務(wù)端來(lái)實(shí)現(xiàn)。

服務(wù)端微前端的支持工具有：Mosaic，PuzzleJs，Podium，Micromono等。

好了，說(shuō)了這么多我相信你是一臉懵逼的，到底怎么實(shí)現(xiàn)的?我們拋開(kāi)架構(gòu)不說(shuō)，來(lái)看看到底如何實(shí)現(xiàn)吧。

四、運(yùn)行時(shí)微前端的具體實(shí)現(xiàn)方式

Iframe

iframes是可以在html中嵌入另一個(gè)HTML。下面就是用iframe實(shí)現(xiàn)微前端的一個(gè)例子：

<!DOCTYPE html> <html> <body> <iframe src="http://localhost:3006" width="600" height="900">   <p>Your browser does not support iframes.</p> </iframe> <iframe src="http://localhost:3007" width="600" height="900">   <p>Your browser does not support iframes.</p> </iframe> </body> </html>

如果不考慮體驗(yàn)問(wèn)題，iframe 幾乎是最完美的微前端解決方案了。iframe 提供了瀏覽器原生的隔離方案，不論是樣式隔離、js  隔離這類問(wèn)題統(tǒng)統(tǒng)都能被完美解決。但它的最大問(wèn)題也在于他的隔離性無(wú)法被突破，導(dǎo)致應(yīng)用間上下文無(wú)法被共享，隨之帶來(lái)的開(kāi)發(fā)體驗(yàn)、產(chǎn)品體驗(yàn)的問(wèn)題。這里的主要問(wèn)題包括：

• url 不同步。瀏覽器刷新 iframe url 狀態(tài)丟失、后退前進(jìn)按鈕無(wú)法使用。

• UI 不同步，DOM 結(jié)構(gòu)不共享。

• 全局上下文完全隔離，內(nèi)存變量不共享。

• 慢。每次子應(yīng)用進(jìn)入都需要次瀏覽器上下文的重建、資源重新加載。

所以雖然使用iframe可以實(shí)現(xiàn)遠(yuǎn)程加載的效果，但是因?yàn)檫@些限制，很少會(huì)有應(yīng)用會(huì)使用。

Nginx路由

利用Ngix路由，我們可以把不同的請(qǐng)求路由到不同的微前端的應(yīng)用。

例如Nginx的路由能力，在前端可以動(dòng)態(tài)請(qǐng)求不同的后端應(yīng)用，而每一個(gè)后端應(yīng)用獨(dú)立運(yùn)行，前端可以把這些不同的后端應(yīng)用加載，編排在一起。下面的代碼是一個(gè)Nginx的配置，customers/users/admins分別表示了三個(gè)不同的應(yīng)用，前端通過(guò)路由來(lái)加載位于不同服務(wù)的后端應(yīng)用。

worker_processes 4; events { worker_connections 1024; } http {     server {         listen 80;         root  /usr/share/nginx/html;         include /etc/nginx/mime.types;         location /app1 {             try_files $uri app1/index.html;         }          location /app2 {             try_files $uri app2/index.html;         }          location /app3 {             try_files $uri app3/index.html;         }     } }

無(wú)論你采用哪一種的微前端架構(gòu)，Nginx方向代理或者其它的API網(wǎng)關(guān)的解決方案都能夠提供方便靈活的后端路由功能。但是通過(guò)這種方式，需要定義一個(gè)通用可擴(kuò)展的路由規(guī)則，否則當(dāng)引入新的應(yīng)用的時(shí)候，還需要修改Nginx的路由配置，那就很不方便了。

Webpack 5 Module Federation

Webpack5 的Module  Federation是一個(gè)令人興奮的革新，它能夠很方便的支持微前端的構(gòu)建。模塊聯(lián)合允許JavaScript應(yīng)用程序從另一個(gè)應(yīng)用程序動(dòng)態(tài)加載代碼，并在此過(guò)程中能共享依賴關(guān)系。如果使用Module  Federation的應(yīng)用程序不具有聯(lián)合代碼所需的依賴關(guān)系，則Webpack將從該聯(lián)合構(gòu)建源中下載缺少的依賴關(guān)系。

在Module  Federation的上下文中，啟動(dòng)代碼是一種將運(yùn)行時(shí)代碼附加到遠(yuǎn)程容器啟動(dòng)序列的實(shí)施策略。這真的很有用，因?yàn)橥ㄟ^(guò)Hook無(wú)法訪問(wèn)ModuleFederation及其運(yùn)行時(shí)，無(wú)法對(duì)其進(jìn)行擴(kuò)展或添加一行代碼，這些代碼可以像動(dòng)態(tài)設(shè)置遠(yuǎn)程容器的公共路徑那樣進(jìn)行操作。這在普通的webpack應(yīng)用程序中是微不足道的，但是在一個(gè)無(wú)法訪問(wèn)的自定義運(yùn)行時(shí)容器中卻很難做到，該容器為模塊聯(lián)合遠(yuǎn)程編排提供了動(dòng)力。簡(jiǎn)單來(lái)說(shuō)，Module  Federation注入一段運(yùn)行時(shí)的代碼來(lái)負(fù)責(zé)加載和編排遠(yuǎn)程的應(yīng)用代碼，并能夠管理和加載遠(yuǎn)程應(yīng)用的依賴。

下面是一個(gè)對(duì)應(yīng)的例子：

module.exports = {     mode: 'development',     devServer: {         port: 8080,     },     plugins: [         new ModuleFederationPlugin({             name: 'container',             remotes: {                 microFrontEnd1: 'microFrontEnd1@http://localhost:8081/remoteEntry.js',                 microFrontEnd2: 'microFrontEnd2@http://localhost:8082/remoteEntry.js',            },         })     ] };

上面的代碼是微前端的容器端的配置，容器負(fù)責(zé)加載其它遠(yuǎn)程應(yīng)用的代碼。這個(gè)例子里，它加載了兩個(gè)遠(yuǎn)程應(yīng)用。

module.exports = {     mode: 'development',     devServer: {         port: 8081,     },     plugins: [         new ModuleFederationPlugin({             name: 'microFrontEnd1',             filename: 'remoteEntry.js',             exposes: {                 './MicroFrontEnd1Index': './src/index',             },         }),     ] };

每一個(gè)微前端的Webpack配置如上。

利用ModuleFederationPlugin，remote可以用來(lái)加載遠(yuǎn)端的應(yīng)用，而Expose可以把自己的組件暴露為遠(yuǎn)端組件。

在container中，只需要調(diào)用以下的代碼來(lái)加載遠(yuǎn)端組件。

import 'microFrontEnd1/MicroFrontEnd1Index'; import 'microFrontEnd2/MicroFrontEnd2Index';

Module Federation的加載過(guò)程如上圖所示：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2. localhost 加載index.html

3. main.js 是Module Federation的核心的編排代碼，負(fù)責(zé)加載遠(yuǎn)程組件。

4. remoteEntry.js 是Module Federation暴露的遠(yuǎn)程組件的代碼

5. src_ 是打包后的代碼，其中 bootstrap_js是容器側(cè)的代碼，index_js是微前端側(cè)的代碼。

Module Federation實(shí)現(xiàn)了類似動(dòng)態(tài)鏈接庫(kù)的能力，可以在運(yùn)行時(shí)加載遠(yuǎn)程代碼，遠(yuǎn)程代碼本質(zhì)上是一個(gè)加載在window上的全局變量，Module  Federation可以幫助解決依賴的問(wèn)題。Javascrip作為上古語(yǔ)言，沒(méi)有提供依賴管理，導(dǎo)致留給各路大神各種發(fā)揮的空間。

Module Federation的缺點(diǎn)就是依賴Webpack 5，包直接掛載為全局變量。

EMP微前端是基于Module Federation的微前端解決方案。

Single SPA

單頁(yè)面應(yīng)用是當(dāng)今為Web應(yīng)用的主流，區(qū)別于傳統(tǒng)的多頁(yè)面應(yīng)用，整個(gè)SPA只有一個(gè)頁(yè)面，其內(nèi)容都是通過(guò)Javascript的功能來(lái)加載。

SPA是一個(gè)Web應(yīng)用程序，僅包含一個(gè)HTML頁(yè)面。提供動(dòng)態(tài)更新，它允許在不刷新頁(yè)面的情況下與頁(yè)面進(jìn)行交互。利用單頁(yè)應(yīng)用程序，可以顯著降低服務(wù)器負(fù)載并提高加載速度，從而獲得更好的用戶體驗(yàn)，因?yàn)镾PA僅在先前加載整個(gè)頁(yè)面時(shí)才按需導(dǎo)入數(shù)據(jù)。

除了開(kāi)發(fā)復(fù)雜，對(duì)于SEO不友好，但頁(yè)面應(yīng)用的最大技術(shù)缺陷是URL不適合共享，因?yàn)镾PA只有一個(gè)地址。

single-spa是一個(gè)框架，用于將前端應(yīng)用程序中的多個(gè)JavaScript微前端組合在一起。

使用single-spa構(gòu)建前端可以帶來(lái)很多好處，例如：

• 在同一頁(yè)面上使用多個(gè)框架而無(wú)需刷新頁(yè)面(React，AngularJS，Angular，Embe)

• 獨(dú)立部署微前端

• 使用新框架編寫代碼，而無(wú)需重寫現(xiàn)有應(yīng)用程序

• 延遲加載代碼可縮短初始加載時(shí)間

single-spa應(yīng)用程序包含以下內(nèi)容：

• single-spa根配置，用于呈現(xiàn)HTML頁(yè)面和注冊(cè)應(yīng)用程序的JavaScript。每個(gè)應(yīng)用程序都注冊(cè)了以下三項(xiàng)內(nèi)容：name，加載應(yīng)用程序代碼的函數(shù)，確定應(yīng)用程序何時(shí)處于活動(dòng)狀態(tài)/非活動(dòng)狀態(tài)的函數(shù)，

• 打包成模塊的單頁(yè)應(yīng)用程序的應(yīng)用程序。每個(gè)應(yīng)用程序必須知道如何從DOM引導(dǎo)，安裝和卸載自身。傳統(tǒng)SPA和Single-SPA應(yīng)用程序之間的主要區(qū)別在于，它們必須能夠與其他應(yīng)用程序共存，因?yàn)樗鼈兏髯詻](méi)有自己的HTML頁(yè)面。例如，React或Angular  SPA應(yīng)用程序。處于活動(dòng)狀態(tài)時(shí)，他們可以偵聽(tīng)url路由事件并將內(nèi)容放在DOM上。處于不活動(dòng)狀態(tài)時(shí)，它們不偵聽(tīng)url路由事件，并且已從DOM中完全刪除。

Single-SPA注冊(cè)的應(yīng)用程序擁有普通SPA所具有的所有功能，只是它沒(méi)有HTML頁(yè)面。SPA包含許多已注冊(cè)的應(yīng)用程序，每個(gè)應(yīng)用程序都有其自己的框架。已注冊(cè)的應(yīng)用程序具有其自己的客戶端路由和它們自己的框架/庫(kù)。它們呈現(xiàn)自己的HTML，并且在安裝時(shí)有完全的自由去做他們想做的任何事情。掛載的概念是指已注冊(cè)的應(yīng)用程序是否正在將內(nèi)容放在DOM上。決定是否掛載已注冊(cè)應(yīng)用程序的是其活動(dòng)功能。每當(dāng)未掛載已注冊(cè)的應(yīng)用程序時(shí)，它都應(yīng)保持完全休眠狀態(tài)直到掛載。

Single SPA的樣例代碼如下：

1. 微前端代碼：

import React from "react"; import ReactDOM from "react-dom"; import singleSpaReact from "single-spa-react"; import Root from "./root.component"; const lifecycles = singleSpaReact({   React,   ReactDOM,   rootComponent: Root,   errorBoundary(err, info, props) {     // Customize the root error boundary for your microfrontend here.     return null;   }, }); export const { bootstrap, mount, unmount } = lifecycles;

Single SPA的微前端是純的JS組件，不包含HTML，需要通過(guò)容器來(lái)加載。

2.容器的Root Config

在容器側(cè)，需要通過(guò)Import Map或者Webpack來(lái)定義遠(yuǎn)程組件，并注冊(cè)遠(yuǎn)程應(yīng)用。

{   "imports": {     "@naughty/root-config": "//localhost:9000/naughty-root-config.js",     "@naughty/app": "//localhost:8500/naughty-app.js",     "react": "https://cdn.jsdelivr.net/npm/react@16.13.1/umd/react.production.min.js",     "react-dom": "https://cdn.jsdelivr.net/npm/react-dom@16.13.1/umd/react-dom.production.min.js"   } }

容器側(cè)的HTML文件使用import  map來(lái)定義遠(yuǎn)程依賴，其中root-config是編排代碼，負(fù)責(zé)遠(yuǎn)程應(yīng)用的注冊(cè)和加載。同時(shí)需要定義所有共享的依賴，這里例子中是react和react-dom

import { registerApplication, start } from "single-spa"; registerApplication({   name: "@single-spa/welcome",   app: () =>     System.import(       "https://unpkg.com/single-spa-welcome/dist/single-spa-welcome.js"     ),   activeWhen: ["/welcome"], }); registerApplication(   '@naughty/app',   () => System.import('@naughty/app'),   location => location.pathname.startsWith('/app') ); start({   urlRerouteOnly: true, });

在root-config中，我們注冊(cè)了兩個(gè)遠(yuǎn)程應(yīng)用，使用不同的url來(lái)加載。/welcome會(huì)加載welcome應(yīng)用，而/app會(huì)加載我們的app應(yīng)用。

Single SPA的核心是利用不同的URL路由來(lái)加載遠(yuǎn)程組件，它可以和Webpack(打包時(shí)構(gòu)建依賴)或者Import  Map(運(yùn)行時(shí)使用瀏覽器導(dǎo)入依賴)一起工作。注意，不要在你的微前端中混用兩種依賴機(jī)制。

Single SPA還提供一個(gè)layout 引擎，可以幫助你快速的構(gòu)建微前端。

相比Module Federation，Single SPA的代碼和生命周期的管理更清楚，提供清晰的接口，缺點(diǎn)是共享的依賴需要手工通過(guò)import  map來(lái)管理。

要做一個(gè)好的微前端因?yàn)槭芟抻跒g覽器和JS的一些特性，并不容易。除了我們今天分享的內(nèi)容，還面臨著諸多的挑戰(zhàn)：如何解決css/js的沖突，使得組件和應(yīng)用完全隔離;如何解決不同應(yīng)用間的通信;如何處理路由;如何保證UI風(fēng)格的統(tǒng)一等等。

五、微前端的問(wèn)題和缺點(diǎn)

講了這么多的優(yōu)點(diǎn)和實(shí)現(xiàn)，那么微前端是不是解決前端開(kāi)發(fā)問(wèn)題的銀彈呢?當(dāng)然不是。所有的架構(gòu)都是取舍和權(quán)衡，這個(gè)世界上并不存在銀彈，微前端架構(gòu)和微服務(wù)一樣也存在他的弊端，單體架構(gòu)未必就差。

1. 微前端的構(gòu)建通常比較復(fù)雜，從工具，打包，到部署，微前端都是更為復(fù)雜的存在，天下沒(méi)有免費(fèi)的午餐，對(duì)于小型項(xiàng)目，它的成本太高。

2.  每個(gè)團(tuán)隊(duì)可以使用不同的框架，這個(gè)聽(tīng)上去很美，但是實(shí)際操作起來(lái)，除了要支持歷史遺留的應(yīng)用，它的意義不大。同時(shí)也為帶來(lái)體驗(yàn)上的問(wèn)題?？梢赃h(yuǎn)程加載不同的框架代碼是一回事，把它們都用好是另一回事。

3.  性能上來(lái)看，如果優(yōu)化得不好微前端的性能可能會(huì)存在問(wèn)題，至少微前端框架是額外的一層加載。如果不同的微前端使用了不同的框架，那么每一個(gè)框架都需要額外的加載。

微前端架構(gòu)還在發(fā)展之中，本文提到的iframe/nginx/module  federation/single-spa只是諸多解決方案中的一小部分，前端的發(fā)展變化和生態(tài)系統(tǒng)實(shí)在是豐富，其他的方案諸如umd/乾坤，Piral，open  comonent等等。當(dāng)使用你也可以選擇標(biāo)準(zhǔn)的Web Component或者ES  Modules來(lái)構(gòu)建微前端，但是這些標(biāo)準(zhǔn)的瀏覽器支持不是特別好，這個(gè)是前端開(kāi)發(fā)永遠(yuǎn)的痛。

以上是“微前端架構(gòu)的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對(duì)大家有所幫助，如果還想學(xué)習(xí)更多知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道！