微前端模块联邦实践系列(2) - 微前端与模块联邦

本系列大纲

• 微前端模块联邦实践系列(1) - 微前端入门
• 微前端模块联邦实践系列(2) - 微前端与模块联邦
• 微前端模块联邦实践系列(3) - 第一个案例
• 微前端模块联邦实践系列(4) - subApp之间共享libraries
• 微前端模块联邦实践系列(5) - Path to Production
• 微前端模块联邦实践系列(6) - 集成React & Vue
• 微前端模块联邦实践系列(7) - 路由管理
• 微前端模块联邦实践系列(8) - 消息通信

微前端与模块联邦（Module Federation）有紧密的关系，特别是在现代微前端架构中，Webpack 5 引入的模块联邦为微前端的实现提供了强大的工具。下面详细解释两者的关系、如何协同工作以及模块联邦如何增强微前端的能力。

模块联邦的基本概念

模块联邦是 Webpack 5 引入的一项功能，旨在允许多个独立的应用程序共享和加载彼此的模块。每个应用可以通过模块联邦动态加载其他应用中暴露出来的代码，而无需在构建时打包所有依赖。这种动态的模块加载机制特别适合微前端场景。

模块联邦的主要特点：

• 动态加载模块：应用程序可以在运行时（而不是构建时）从其他应用程序中加载模块，避免重复打包和加载相同的代码。
• 共享依赖：不同的应用可以共享相同的依赖（如 React、Vue 等库），从而减少冗余代码，提升性能。
• 独立部署：每个应用可以独立开发、独立构建和独立部署，而不会影响其他应用。这符合微前端的独立性需求。

微前端与模块联邦的协同工作

微前端架构的核心理念是将前端应用拆分为多个独立的、可复用的模块，这些模块可以由不同的团队独立开发和部署。模块联邦为这种架构提供了技术支持，特别是在模块共享和代码复用方面具有明显优势。

微前端的需求与模块联邦的解决方案：

• 独立开发与部署：微前端的一个关键需求是各个模块可以独立开发、构建和部署。模块联邦允许每个子应用在独立开发和构建的同时，仍然可以动态加载和使用其他应用的模块，从而实现灵活的模块组合。

  举例：假设有一个电商平台，包含多个微前端模块，如产品展示模块、购物车模块和支付模块。通过模块联邦，产品展示模块可以动态加载购物车模块的代码，从而在不重新构建整个系统的情况下，实现功能的组合。

• 共享依赖与代码复用：微前端架构通常面临一个挑战，即如何在不同的子应用之间共享公共依赖（如第三方库、通用组件等）。传统微前端实现（如 iframe 或 JavaScript 包）通常会导致多个子应用重复加载同一个库，这既增加了资源消耗，也影响性能。

  模块联邦通过共享依赖解决了这个问题。各个微前端应用可以声明自己的共享依赖，并在运行时动态决定使用本地版本还是从其他应用中获取已经加载的版本，避免重复加载。

  举例：假设有多个微前端子应用都依赖 React，使用模块联邦后，当一个应用已经加载了 React，其他应用可以直接复用该版本，而不需要重新加载。

• 模块的动态加载：微前端系统的另一个关键需求是按需加载模块，以减少初次加载时间和资源占用。模块联邦允许模块在运行时根据用户交互或页面路由的变化动态加载。这提高了微前端应用的性能，尤其适合那些具有较多功能模块的复杂系统。

  举例：用户在进入电商平台时，首先加载首页模块。当用户点击产品页面时，平台可以动态加载产品模块，不需要在初次加载时就下载整个应用的所有代码。

模块联邦与传统微前端方案的对比

模块联邦相比于传统的微前端实现方式（如 iframe、Web Components、JavaScript 包等），在多个方面都表现出显著的优势。

与 iframe 的对比

• 性能：iframe 会加载完整的独立应用，导致重复加载资源、性能开销大。模块联邦则避免了这种问题，通过共享依赖和动态加载来优化性能。
• 通信：iframe 需要使用复杂的通信机制（如 postMessage），而模块联邦使得共享模块和组件之间的直接调用成为可能，通信更加高效。

与 Web Components 的对比

• 组件复用：Web Components 提供了浏览器原生的组件封装，但它的复用和动态加载机制相对有限。模块联邦则可以动态加载模块，不仅支持复用组件，还可以共享整个模块甚至库。
• 技术栈独立性：Web Components 强调的是技术栈无关，而模块联邦虽然支持技术栈无关，但更适合用于现代 JavaScript 框架（如 React、Vue、Angular）之间的模块共享和协作。

与 JavaScript 包的对比

• 构建与部署：JavaScript 包的方式要求每个模块在构建时打包所有依赖，而模块联邦允许在运行时动态加载和共享模块，提升了部署的灵活性。
• 模块通信与依赖管理：JavaScript 包需要手动管理模块之间的依赖，而模块联邦可以自动处理依赖冲突和版本管理，简化了开发流程。

模块联邦主要的挑战

模块联邦（Module Federation）作为 Webpack 5 的新特性，极大地推动了微前端架构的发展，但它仍然面临一些挑战和未解决的问题。以下是使用模块联邦时可能遇到的主要挑战及目前尚未完全解决的问题：

1. 版本冲突和兼容性管理

模块联邦允许多个独立应用动态加载和共享模块，但如果不同应用使用的库或模块版本不同，就可能导致冲突或兼容性问题。

• 版本不一致：多个子应用可能依赖同一个库的不同版本，导致版本冲突。例如，一个子应用使用 React 17，另一个子应用使用 React 16，如果这两个应用都尝试共享 React，可能会出现不可预期的行为或错误。
• 向后兼容的挑战：在共享的模块中，如果模块的接口发生变化，旧版本的子应用可能无法正确工作，导致整个系统的可靠性下降。

当前的解决方案：

• Scoped（作用域）依赖：模块联邦可以允许不同版本的库共存，允许应用在需要时使用特定版本的依赖。
• 版本策略：通过严格的版本控制策略和依赖锁定来尽量避免版本冲突，确保共享模块的接口尽量保持向下兼容。

未完全解决的问题：

• 模块的细粒度兼容性：虽然模块联邦支持版本共存，但在实际项目中，如何在大型团队和应用中保持所有共享模块的兼容性仍然是一个巨大的挑战。每个子应用可能会逐渐演化，增加了维护的复杂性。
• 升级困难：一旦多个子应用共享同一模块，当该模块需要更新时，所有依赖它的子应用可能都需要进行调整，特别是当模块有不兼容的 API 变化时。

2. 全局JS以及CSS冲突

全局 CSS 冲突

在传统的 Web 开发中，CSS 是全局作用的，因此当多个微前端子应用共享同一个页面时，可能会出现样式冲突的情况。这些冲突主要源于：

• 命名冲突：不同的子应用使用相同的类名或 ID，导致样式覆盖。
• 全局样式污染：某个子应用的 CSS 影响到了整个页面，覆盖了其他应用的样式。
• 特定样式的优先级：不同子应用的 CSS 可能使用了不同的优先级（如 !important 或高权重的选择器），导致样式不按预期应用。

常见表现

• 子应用 A 的样式被子应用 B 的 CSS 覆盖，导致页面布局或样式异常。
• 某些组件样式不一致，或者样式意外地改变。
• 特定 UI 元素的样式变得不可控，或者局部样式混乱。

解决方案

1. CSS Modules（CSS 模块化） CSS Modules 是一种将 CSS 作用域限制在当前组件内的机制。每个 CSS 类名或 ID 都会被编译成一个唯一的类名，避免命名冲突。对于模块联邦中的每个子应用，使用 CSS Modules 是一个很好的选择。

2. Shadow DOM（影子 DOM） Shadow DOM 是 Web Components 的一部分，它可以为 DOM 元素创建一个隔离的样式和结构作用域。使用 Shadow DOM 的子应用可以完全避免外部样式的影响。但需要引入 Web Components 技术，且某些复杂的 UI 框架（如 React）与 Shadow DOM 集成存在一定难度。

3. BEM（块元素修饰符）命名规范 采用 BEM 命名规范（Block Element Modifier）是另一种解决命名冲突的方法。通过定义严格的命名规范，减少类名的冲突。每个子应用都可以有自己的命名空间，确保 CSS 不会无意中影响其他子应用。使用BEM，仅减少了命名冲突，但无法避免 CSS 全局作用的本质问题

4. Scoped CSS 某些前端框架（如 Vue 和 Angular）支持 Scoped CSS，即将 CSS 的作用范围限制在当前组件内。这种方法类似于 CSS Modules，但需要依赖特定的框架，不适用于纯 JavaScript 或其他非框架化的项目。

5. CSS-in-JS 一些现代 JavaScript 框架（如 React 和 Vue）支持 CSS-in-JS，这种方式将 CSS 与 JavaScript 逻辑绑定在一起，并生成唯一的样式作用域，确保样式的隔离。在某些场景下，这种方式并不能有效满足，比如mui会将生产环境下的CSS-in-JS中产生的class，自动缩写为jss1、jss2等，如果在多个subApp中采用这种方式，就可能出现覆盖的问题。

全局 JavaScript 冲突

JavaScript 的全局变量和函数同样容易在微前端场景中引发冲突，尤其是在不同子应用加载了相同或相似的库时。常见的冲突源包括：

• 全局变量命名冲突：不同子应用定义了相同的全局变量，导致变量值被覆盖。
• 共享库的版本冲突：不同子应用使用了相同的 JavaScript 库但版本不同，可能导致不可预测的错误。
• 全局事件监听器冲突：多个子应用监听同一全局事件（如 window 或 document 事件），引发冲突或多次触发。

常见表现

• 子应用 A 中的全局变量在子应用 B 加载后失效或被覆盖。
• 某个 JavaScript 库的函数出现不可预期的行为，通常是由于版本不一致。
• 全局事件（如滚动、点击等）在多个子应用中触发，导致多次重复的行为。

解决方案

1. 避免全局变量 在开发中避免使用全局变量和函数是解决冲突的首要方法。通过使用模块化系统（如 ES6 模块、CommonJS 或 AMD）将代码封装在模块内，确保每个子应用的 JavaScript 逻辑在其自己的作用域中执行，避免污染全局空间。

2. 共享库管理 模块联邦允许多个子应用共享 JavaScript 库，但在多个版本之间切换时，可能会产生冲突。通过共享库的版本锁定和合理配置，可以确保各个子应用使用同一个版本的库，减少版本冲突的风险。

   • 解决方案：

     • 在 Webpack 的 ModuleFederationPlugin 中配置共享的库（如 React、Lodash 等），并指定使用的版本。
     • 利用 singleton 属性强制所有子应用使用同一个库的实例，避免重复加载和版本冲突。

   new ModuleFederationPlugin({
     name: 'app',
     remotes: {
       remoteApp: 'remoteApp@http://localhost:3001/remoteEntry.js',
     },
     shared: {
       react: { singleton: true, requiredVersion: '^17.0.0' },
       'react-dom': { singleton: true, requiredVersion: '^17.0.0' },
     },
   });
   

3. 命名空间隔离 使用 JavaScript 的命名空间可以避免全局变量的冲突。例如，使用对象来封装全局变量和函数，确保这些全局状态只在特定的命名空间中生效。

   • 示例：

     window.appA = {
       someGlobalFunction: function () { /* ... */ }
     };
     

   这种方式并不能完全避免全局状态污染，只是减小冲突的概率。

4. 使用 iframe 隔离 如果微前端中的 JavaScript 冲突特别严重，可以考虑使用 iframe 将某些子应用完全隔离开来。iframe 会为每个子应用创建独立的 JavaScript 和 CSS 作用域，避免冲突。

5. 事件命名空间 为了避免全局事件监听器的冲突，可以为事件监听器添加命名空间，确保各个子应用的事件处理互不干扰。

   • 示例：

     document.addEventListener('click.appA', function () {
       // appA 的处理逻辑
     });
     

3. 运行时依赖管理和加载时序

模块联邦的动态加载意味着依赖是在运行时而不是构建时决定的，这带来了新的复杂性，特别是在依赖的加载时序和共享资源的管理上。

• 依赖的加载顺序：如果某个子应用依赖于多个模块，这些模块可能相互依赖，那么在运行时如何确保依赖模块按正确的顺序加载是一个挑战。
• 模块的并行加载与性能：在复杂的微前端应用中，如果多个子应用同时加载多个共享模块，可能会导致性能瓶颈，特别是在网络延迟较高或带宽有限的情况下。

当前的解决方案：

• 预加载策略：可以通过 Webpack 的 prefetch 和 preload 来优化模块的加载顺序，确保重要模块能够优先加载。
• 异步加载：通过 Webpack 的动态导入（import()）实现模块的按需加载，避免阻塞其他模块的加载。

未完全解决的问题：

• 依赖的循环引用：当两个模块彼此依赖时，模块联邦可能在加载时遇到问题，无法解决循环引用的依赖问题。这种情况在大型项目中尤为常见，需要开发人员手动优化和管理依赖关系。
• 首次加载时间：虽然按需加载模块可以减少初次加载的体积，但如果每个子应用都动态加载大量模块，首次加载时间可能仍然很长，影响用户体验。

4. 共享状态和全局状态管理

在微前端架构中，多个独立的子应用之间可能需要共享全局状态，如用户会话、权限或配置数据。模块联邦虽然允许共享代码和依赖，但共享状态的管理仍然是一个挑战。

• 状态同步：多个子应用需要共享全局状态时，如何确保状态在各个子应用之间同步更新是一个难点。例如，用户登录后，全局的用户信息需要在多个子应用中同步更新，任何子应用对状态的修改都应及时反映在其他应用中。
• 跨应用的状态管理工具：由于每个子应用可能使用不同的框架（如 React、Vue、Angular），共享状态变得更加复杂。如何找到一个通用的状态管理工具，支持跨技术栈的状态共享，是一个尚待解决的问题。

当前的解决方案：

• 共享 Store：可以通过共享一个状态管理工具来在多个应用间共享全局状态，子应用可以通过这些工具订阅和分发状态变化。
• API 中心化：通过服务层（如 REST 或 GraphQL），多个子应用通过同一个 API 获取和更新共享状态，从而减少跨应用状态同步的复杂性。

未完全解决的问题：

• 实时性和性能开销：虽然共享状态可以通过中心化的 API 或状态管理工具实现，但频繁的状态同步和跨应用的通信会带来性能开销，尤其是在复杂的状态变更场景中。
• 不同技术栈的状态管理差异：当微前端应用使用不同的框架时，不同框架的状态管理机制可能并不兼容，如何统一管理状态成为一个持续的挑战。

5. 独立部署和更新管理

模块联邦支持独立部署和动态加载模块，但如何在生产环境中协调多个应用的部署与更新仍然有很多实践上的难点。

• 更新协调：每个子应用可以独立部署，但如果一个子应用依赖于其他子应用的某些模块，这些模块更新时如何确保兼容性？是否需要强制同步更新，或允许部分版本失配？
• 缓存失效：由于模块是动态加载的，浏览器可能会缓存旧的模块版本。在更新模块时，如何确保缓存失效并加载最新版本也是一个挑战。

当前的解决方案：

• 版本控制：可以在每个模块的构建和发布过程中引入版本控制策略，确保兼容性，或者通过 semver（语义化版本控制）来标识共享模块的版本。
• 缓存清除机制：可以通过设置 HTTP 头（如 Cache-Control）或使用 Webpack 的 output.filename（动态文件名）来强制浏览器在模块更新时清除缓存。

未完全解决的问题：

• 跨应用的依赖更新协调：当多个应用共享同一个模块时，更新流程可能会涉及到多个团队，如何管理这些更新的协调是一大挑战，尤其是当更新会影响其他应用时。
• CI/CD 的复杂性：微前端应用的持续集成/持续交付（CI/CD）流水线可能需要同时处理多个子应用的构建和部署，模块联邦带来了灵活性，但同时增加了部署的复杂性。

使用模块联邦的最佳实践

在微前端架构中使用模块联邦时，有一些最佳实践可以帮助实现更好的性能和开发体验。

模块拆分与共享策略

尽量将公共的库（如 UI 组件库、工具函数、第三方库）拆分为独立的共享模块，让多个子应用可以动态加载和复用它们。同时，控制共享模块的粒度，避免过于细化或过于粗放。

版本控制与兼容性

为了避免多个子应用之间的依赖冲突，模块联邦支持不同版本的模块共存。确保对共享模块进行严格的版本控制，并在必要时实现向下兼容，以防止版本不一致导致应用崩溃。

按需加载与性能优化

通过模块联邦的动态加载功能，实现按需加载模块，减少初始页面的加载体积。特别是在大型应用中，应当根据用户的操作或页面路由动态加载特定功能模块。

---

总结

模块联邦是 Webpack 5 的一项强大功能，为微前端架构提供了灵活的模块共享和动态加载机制。通过模块联邦，微前端不仅可以实现独立开发、独立部署，还能够有效地共享模块和依赖，提升性能并减少冗余代码。

模块联邦与微前端的结合，使得现代前端架构更加灵活、高效，特别适用于大型、复杂的应用场景，在提升开发效率和用户体验方面发挥着重要作用。