背景

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

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

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

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.delux-kingway.cn/images/chaijie_default.png/remoteEntry.js',
            },
            shared: { react: { singleton: true }, 'react-dom': { singleton: true } },
            })
        ],
    };

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

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

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

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

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

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

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

缺點

對于webpack5以下的應用不支持

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

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

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

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

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

NPM包

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

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

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

Shared Component

; export default SharedComponent;

發(fā)布到NPM

npm publish

在父應用和子應用中安裝

npm install shared-component-library

在應用中使用

 import SharedComponent from 'shared-component-library';

 function App() {
 return ;
 }

 export default App;

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

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

使用 CDN

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

打包共享組件：

npm run build

上傳到 CDN。

在應用中引入：

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

優(yōu)點

性能提升：

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

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

帶寬優(yōu)化：

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

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

高可用性：

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

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

版本管理：

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

缺點

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

緩存一致性：

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

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

依賴性：

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

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

使用 iframe

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

優(yōu)點

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

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

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

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

缺點

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

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

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

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

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

總結

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

審核編輯 黃宇