背景

我們的很多web應(yīng)用在持續(xù)迭代中功能越來越復(fù)雜，參與的人員、團隊不斷增多，導(dǎo)致項目出現(xiàn)難以維護的問題，這種情況PC端尤其常見，微前端為我們提供了一種高效管理復(fù)雜應(yīng)用的方案。但是在使用微前端的過程中，通常會有一些公共方法或公共組件，本文將對如何實現(xiàn)父子應(yīng)用以及兄弟應(yīng)用之間進行方法及組件共享提出幾種解決方案以及其各自優(yōu)缺點及適用場景

模塊聯(lián)邦（Module Federation）

webpack5引入了模塊聯(lián)邦，可以讓不同的應(yīng)用共享模塊。具體步驟如下：

Remote（提供者模塊）

    // webpack.config.js
    module.exports = {
        // 其他配置...
        plugins: [
            new ModuleFederationPlugin({
            name: 'component_app',
            filename: 'remoteEntry.js',
            exposes: {
                './Button': './src/Button.jsx',
                './Dialog': './src/Dialog.jsx',
                './Logo': './src/Logo.jsx',
                './ToolTip': './src/ToolTip.jsx',
            },
            shared: { react: { singleton: true }, 'react-dom': { singleton: true } },
            }),
        ],
    };

作為提供方，component 將自己的 Button、Dialog等組件暴露出去，同時將 react 和 react-dom 這兩個依賴共享出去。

host（使用者模塊）

    // webpack.config.js
    module.exports = {
        entry: './index.js',
        // ...
        plugins: [
            new ModuleFederationPlugin({
            name: 'main_app',
            //遠程訪問地址入口 
            remotes: {
                'component-app': 'component_app@http://www.brongaenegriffin.com/images/chaijie_default.png/remoteEntry.js',
            },
            shared: { react: { singleton: true }, 'react-dom': { singleton: true } },
            })
        ],
    };

作為消費者的 main 應(yīng)用需要定義需要消費的應(yīng)用的名稱以及地址，同時 main 應(yīng)用也將自己的 react 和 react-dom 這兩個依賴共享出去。

通過以上方式可以實現(xiàn)不同應(yīng)用之間共享公共方法和組件，雖然vite本身不支持模塊聯(lián)邦，但是我們可以使用vite-plugin-federation這個插件。
優(yōu)點

代碼共享：不同的微應(yīng)用可以共享相同的依賴庫，減少重復(fù)下載和加載，提高性能。

獨立部署：各個微應(yīng)用可以獨立開發(fā)、測試和部署，減少了團隊之間的耦合，提高了開發(fā)效率。

動態(tài)加載：可以在運行時動態(tài)加載模塊，按需加載，減少初始加載時間。

版本控制：支持不同版本的模塊共存，解決了版本沖突的問題。

團隊協(xié)作：各個團隊可以獨立開發(fā)自己的模塊，減少了對中央倉庫的依賴，提高了協(xié)作效率。

缺點

對于webpack5以下的應(yīng)用不支持

復(fù)雜性增加：配置和管理模塊聯(lián)邦需要一定的學(xué)習(xí)成本和經(jīng)驗，增加了項目的復(fù)雜性。

調(diào)試困難：由于模塊是動態(tài)加載的，調(diào)試和追蹤問題可能會變得更加困難。

性能開銷：雖然減少了初始加載時間，但動態(tài)加載模塊可能會在運行時引入額外的性能開銷。

依賴管理：需要仔細管理共享依賴的版本，避免潛在的兼容性問題。

安全性：動態(tài)加載外部模塊可能會引入安全風(fēng)險，需要額外的安全措施來防止惡意代碼注入。

NPM包

將共享組件打包成一個 NPM 包，然后在父子應(yīng)用中分別安裝和使用。

創(chuàng)建共享組件/方法庫

import React from 'react';
const SharedComponent = () => 

Shared Component

; export default SharedComponent;

發(fā)布到NPM

npm publish

在父應(yīng)用和子應(yīng)用中安裝

npm install shared-component-library

在應(yīng)用中使用

 import SharedComponent from 'shared-component-library';

 function App() {
 return ;
 }

 export default App;

優(yōu)點
1. 模塊化管理：通過npm包管理公共組件，可以實現(xiàn)模塊化開發(fā)，便于維護和更新。
2. 版本控制：npm包自帶版本控制功能，可以方便地進行版本管理，確保不同微應(yīng)用使用兼容的組件版本。
3. 依賴管理：npm包可以自動管理依賴關(guān)系，減少手動處理依賴的復(fù)雜性。
4. 復(fù)用性高：公共組件封裝成npm包后，可以在多個微應(yīng)用中復(fù)用，減少重復(fù)開發(fā)，提高開發(fā)效率。
5. 社區(qū)支持：npm生態(tài)系統(tǒng)龐大，很多問題可以通過社區(qū)資源解決，減少開發(fā)難度。

缺點
1. 發(fā)布和更新成本：每次更新公共組件都需要重新發(fā)布npm包，并在各個微應(yīng)用中更新依賴，增加了一定的工作量。
2. 版本兼容性問題：不同微應(yīng)用可能對同一組件有不同的版本需求，處理版本兼容性問題可能會比較復(fù)雜。
3. 性能開銷：由于npm包需要通過網(wǎng)絡(luò)下載和安裝，可能會增加構(gòu)建時間和初始加載時間。
4. 調(diào)試復(fù)雜性：npm包作為獨立模塊，調(diào)試時可能需要額外的配置和步驟，增加了調(diào)試的復(fù)雜性。
5. 安全性問題：使用第三方npm包時，需要注意其安全性，防止引入潛在的安全漏洞。

使用 CDN

將共享組件打包并上傳到 CDN，然后在父子應(yīng)用中通過 URL 引入。

打包共享組件：

npm run build

上傳到 CDN。

在應(yīng)用中引入：

// 假設(shè)共享組件暴露為全局變量 SharedComponent
function App() {
  return ;
}
export default App;

優(yōu)點

性能提升：

快速加載：CDN 服務(wù)器分布在全球各地，用戶可以從最近的服務(wù)器獲取資源，從而減少加載時間。

緩存機制：CDN 提供了強大的緩存機制，可以減少服務(wù)器的負載，提高響應(yīng)速度。

帶寬優(yōu)化：

減輕服務(wù)器壓力：通過將靜態(tài)資源托管在 CDN 上，可以減輕原始服務(wù)器的帶寬壓力。

分布式傳輸：CDN 可以將流量分散到多個節(jié)點，避免單點瓶頸。

高可用性：

冗余備份：CDN 通常有多個備份節(jié)點，即使某個節(jié)點出現(xiàn)故障，其他節(jié)點也能繼續(xù)提供服務(wù)。

自動故障切換：CDN 能夠自動檢測并切換到可用的節(jié)點，確保服務(wù)的連續(xù)性。

版本管理：

統(tǒng)一管理：通過 CDN 可以統(tǒng)一管理公共組件的版本，確保所有微應(yīng)用使用相同的組件版本，減少兼容性問題。

缺點

安全性問題：依賴第三方：使用第三方 CDN 服務(wù)可能會帶來安全隱患，特別是如果 CDN 提供商遭到攻擊或出現(xiàn)故障。

緩存一致性：

緩存更新延遲：CDN 的緩存機制可能導(dǎo)致更新的資源不能及時傳播到所有節(jié)點，造成版本不一致的問題。

緩存失效：需要手動管理緩存失效策略，否則可能會導(dǎo)致舊版本資源被長期緩存。

依賴性：

網(wǎng)絡(luò)依賴：如果用戶的網(wǎng)絡(luò)環(huán)境較差，可能會影響到通過 CDN 獲取資源的速度和穩(wěn)定性。

服務(wù)依賴：過度依賴 CDN 可能會導(dǎo)致在 CDN 服務(wù)出現(xiàn)問題時，整個應(yīng)用的可用性受到影響。

使用 iframe

如果組件之間的交互較少，可以考慮使用 iframe 嵌入子應(yīng)用。
在父應(yīng)用中嵌入 iframe：

優(yōu)點

隔離性強：iframe 提供了一個獨立的瀏覽上下文，能夠有效隔離不同微應(yīng)用之間的樣式和腳本，避免相互干擾。

安全性高：由于 iframe 的隔離特性，能夠防止跨站腳本攻擊（XSS）和其他安全問題。

兼容性好：iframe 是瀏覽器原生支持的技術(shù)，兼容性較好，能夠在大多數(shù)現(xiàn)代瀏覽器中正常工作。

獨立部署：各個微應(yīng)用可以獨立部署和更新，不需要擔心對其他應(yīng)用的影響。

缺點

性能問題：iframe 會增加頁面的加載時間和內(nèi)存消耗，尤其是在嵌套多個 iframe 的情況下。

通信復(fù)雜：iframe 與父頁面之間的通信需要通過 postMessage 等機制實現(xiàn)，增加了開發(fā)的復(fù)雜性。

SEO 不友好：搜索引擎對 iframe 內(nèi)容的抓取和索引支持較差，可能影響 SEO 效果。

樣式和布局問題：iframe 的內(nèi)容與父頁面的樣式和布局是獨立的，可能需要額外的工作來確保一致性。

調(diào)試困難：iframe 內(nèi)部的調(diào)試相對復(fù)雜，尤其是在跨域的情況下，調(diào)試工具的使用會受到限制。

總結(jié)

不同的方案有各自的特點，需要根據(jù)具體的應(yīng)用場景和需求進行權(quán)衡。

審核編輯 黃宇