Appearance
微前端架构
出于技术选型， 了解微前端架构的好处，了解微前端的实现方式，了解微前端的拆分方式。
- 什么是微前端？
- 架构发展历程
- 为什么选择微前端？
我的微前端架构选择 ？
1. 什么是微前端？
微前端的核心思想是将一个复杂的应用拆分成多个独立的子应用，每个子应用都可以独立开发、测试、部署。这样可以提高开发效率，降低维护成本，同时也可以提高应用的可扩展性和可维护性。
应用 = 应用A + 应用B + 应用C
每个应用可以选择不同的技术栈，甚至是不同的框架。
微前端不是一门具体的技术，而是一种架构思想。微前端的实现方式有很多种。
微前端解决问题
- 1、随着项目迭代应用越来越庞大，难以维护。
- 2、跨团队或跨部门协作开发项目导致效率低下的问题。
2.架构发展历程
单体应用 -> 前后端分离 -> 微服务化 -> 微前端化。
| 架构 | 项目结构 |
|---|---|
| 单体应用 | 1个团队(前端、后端) |
| 前后端分离 | 前端团队、后端团队 |
| 微服务化 | 前端团队、后端整合（服务1、服务2、服务3） |
| 微前端化 | 前端整合（服务1、服务2、服务3）、后端整合（服务1、服务2、服务3） |
3. 为什么选择微前端？
微前端的优势在于：
- 提高开发效率：每个子应用可以独立开发、测试、部署，降低了维护成本。
- 提高可扩展性：每个子应用可以根据业务需求独立扩展，提高了应用的灵活性。
- 提高可维护性：每个子应用可以独立维护，降低了整体应用的维护成本。
4. 微前端的拆分方式
更多根据业务需求来做，而不是技术决策
5. 微前端的实现方式有哪些？
1. Iframe 嵌入
- 实现方式：通过
<iframe>标签嵌入独立子应用，利用浏览器原生的隔离性实现独立运行。 - 优点：
- 天然的隔离性：CSS、JS 完全隔离，无全局污染。
- 技术栈无关：子应用完全独立，无需统一技术栈。
- 部署简单：子应用可独立部署，通过 URL 动态加载。
- 缺点：
- 通信复杂：需通过 postMessage 或 URL 参数跨域通信，开发成本高。
- 体验割裂：路由、加载状态、滚动条等无法统一控制。（子模块弹窗，无法居中）
- 性能问题：重复加载公共依赖，内存占用高。
- 总结： 又不是不能用
主流方案： 无界
无界微前端方案基于 webcomponent 容器 + iframe 沙箱， 来自腾讯团队- 使用成本低
- 继承 iframe 的优点，补足 iframe 的缺点。
- 利用 iframe 的隔离性，把 JS 代码放到 iframe 里执行（通过 Proxy）。
- 利用 Shadow DOM的隔离性，把子应用的 DOM 写到 ShadowRoot 里，实现样式隔离
2. 主从架构, 路由分发+资源处处理
- 实现方式：主应用作为基座，通过路由动态加载子应用（如 single-spa 或 qiankun、 Piral、 Garfish）。
- 优点：
- 灵活的技术栈：子应用可使用不同框架（React/Vue/Angular）。
- 动态加载：按需加载子应用，减少首屏资源体积。
- 统一入口：主应用控制路由、权限和公共依赖。
- 缺点：
- 依赖管理复杂：需统一公共库版本（如 React/Vue）。
- 全局污染风险：子应用可能修改全局变量（如 window）。
- 通信成本：主-子应用需通过自定义事件或状态管理工具通信。
- 总结： 使用占比大，花样繁多
主流方案： qiankun （乾坤）
qiankun是一个基于 single-spa 的微前端解决方案，来自蚂蚁金服团队。- 国内目前
影响力最大的面向生产的微前端方案
3.Webpack Module Federation（模块联邦, 去中心化心）
- 实现方式：通过 Webpack 5 的模块联邦功能，动态加载远程模块（如 @module-federation）。
- 优点：
- 高效共享依赖：公共库只需加载一次，子应用按需复用。
- 运行时动态集成：无需构建时绑定，适合敏捷开发。
- 技术栈自由：支持不同框架的模块混合使用。
- 缺点：
- 配置复杂：需统一 Webpack 版本和构建流程。
- 版本冲突风险：子应用依赖版本不一致可能导致问题。
- 调试困难：跨应用调试需额外工具支持。
主流方案：EMP
- EMP 是由欢聚时代业务中台前端团队推出的
4.Web Components
- 实现方式：子应用封装成 Web Components（自定义 HTML 标签），主应用直接引用。
- 优点：
- 原生隔离性：通过 Shadow DOM 实现样式和 DOM 隔离。
- 标准化：基于浏览器原生 API，无框架绑定。
- 复用性强：组件可跨项目复用。
- 缺点：
- 生态不完善：社区工具链（如状态管理、路由）较弱。
- 兼容性要求：需 Polyfill 支持旧浏览器。
- 开发成本高：需手动处理通信和生命周期。
Web Components 包含三项主要技术：
- Custom elements（自定义元素） ：一组 JavaScript API，允许你定义 custom elements 及其行为，然后可以在你的用户界面中按照需要使用它们。
- Shadow DOM （影子 DOM） ：一组 JavaScript API，用于将封装的“影子” DOM 树附加到元素（与主文档 DOM 分开呈现）并控制其关联的功能。通过这种方式，你可以保持元素的功能私有，这样它们就可以被脚本化和样式化，而不用担心与文档的其他部分发生冲突。
- HTML templates（HTML 模板） ：
<template>和<slot>元素使你可以编写不在呈现页面中显示的标记模板。然后它们可以作为自定义元素结构的基础被多次重用。
主流方案1：MicroApp
- 京东推出的一款年轻的、基于 WebComponent 进行渲染的微前端框架
主流方案2：Magic Microservices
- 字节开源的一款基于 Web Components 的轻量级的微前端工厂函数
5. Component-driven（组件驱动开发）
Component-driven（组件驱动开发） 是一种将用户界面拆解为独立、可复用组件的开发范式，强调以组件为最小单元进行开发、测试与协作3。在微前端架构中，该模式进一步演化为跨应用组件共享机制，允许不同子应用通过标准化接口调用公共组件，实现模块化复用
工作流：创建组件 - > 发布组件 -> 消费组件
优势
- ✅ 提升代码复用率（减少重复开发 30%-50%）3
- ✅ 降低多团队协作复杂度（组件即标准化交付物）26
- ✅ 支持渐进式升级（仅更新特定组件，无需全量发布）
劣势
- ❌ 组件开发成本高， 组件规范统一：需制定严格的接口标准与文档，避免组件滥用或兼容性问题
- ❌ 性能优化：跨应用加载组件可能增加网络请求，需结合懒加载或预加载策略
主流方案： BIT
- Bit 在本质上就是一个更易用、更强大、更贴合微前端场景的 npm
主流方案对比
| 名称 | 方案 | 官网 | 流行程度（个人感觉） | 开发团队 |
|---|---|---|---|---|
| qiankun | 主从架构 | 官网 | ⭐️⭐️⭐️⭐️⭐️ | 蚂蚁金服 |
| Bit | Component-driven组件驱动 | 官网 | ⭐️⭐️⭐️⭐️⭐️ | bit 国外 |
| 无界 | Iframe | 官网 | ⭐️⭐️⭐️⭐️ | 腾讯 |
| EMP | Webpack Module Federation | 官网 | ⭐️⭐️⭐️ | 欢聚时代 |
| MicroApp | Web Components | 官网 | ⭐️⭐️⭐️ | 京东 |
| Magic Microservices | Web Components | 官网 | ⭐️⭐️⭐️ | 字节 |
总结
wujie和micro-app对 vite 的支持友好， 构建改造成本低 （适合 系统渐进式迁移）qiankun文档全，社区活跃，调试、通信方便 （适合 多团队 和 多技术）wujieiframe物理隔离杜绝样式/js污染（适合 高安全、高敏感场景）Webpack Module Federation共享模块，减少重复代码 （适合 模块化应用）