微前端之什么是微前端
什么是微前端
微前端（Micro Frontends）是一种软件架构模式，它借鉴了后端微服务架构的思想，将复杂单一的前端应用拆分为多个可独立开发、部署和维护的小型前端应用。每个小应用关注特定的业务域，并能够以一种无缝的方式集成到同一个主框架或者容器中，形成统一的用户体验。
在微前端架构下，不同的团队或项目组可以采用不同的技术栈来开发各自的前端模块，这些模块在运行时进行组合加载，共享公共资源，同时保持各自的功能和样式独立。这种方式有助于提高开发效率，降低代码耦合度，便于迭代升级与维护，并且支持大型组织内部的并行开发和快速交付。
常见的微前端实现方式包括以下几种：
- 基于路由分发：不同的子应用负责不同的路由空间，根据路由变化加载对应的前端应用。
- Web Components 或 Custom Elements：利用标准化的Web组件技术封装各个子应用。
- iframe集成：每个子应用在一个单独的iframe中运行，通过消息传递机制进行通信。
- 动态加载JS模块：利用JavaScript模块加载器，按需加载不同团队编写的模块。
- 微应用沙箱：使用类似Shadow DOM或者其他隔离技术，在同一页面上运行多个互不干扰的前端环境。
- 容器化方案：如webpack模块联邦、single-spa等工具提供的微前端解决方案。
通过微前端架构，企业可以更好地适应大规模分布式团队协作以及快速响应变化的需求，同时避免传统单体前端应用所带来的复杂性问题。
更多详细内容，请微信搜索“前端爱好者“， 戳我 查看 。
微前端分类
当然，下面是一些微前端分类的具体实现方式及其示例说明：
基于路由的微前端：
- 实现原理：根据用户访问的路由（URL），加载对应的微前端应用。
- 示例：假设一个电商网站有商品列表页、购物车页面和结算页面三个功能模块，由三个团队独立开发，每个团队创建一个独立的SPA应用，然后在主应用中配置路由规则，当用户导航至不同的URL时，主应用加载对应微应用的JS包并渲染相应的页面。
组件化微前端：
- 实现原理：将每个子应用设计成Web Components或其他框架的自定义组件，可以直接在DOM中插入并独立运行。
- 示例：利用Stencil、Polymer等构建Web Components，或者在React/Vue/Angular等框架中，将子应用封装成定制化的组件，然后在主应用中直接调用这些组件来加载子应用的内容。
iframe嵌入式微前端：
- 实现原理：通过在主应用中嵌入多个iframe，每个iframe承载一个独立的子应用。
- 示例：在主应用的一个div内动态生成iframe元素，指向不同子应用的服务地址，各子应用可以在各自的iframe中运行，通过
window.postMessage或专用的通信库进行跨窗口交互。
优点
- 非常简单，使用没有任何心智负担
- web应用隔离的非常完美，无论是js、css、dom都完全隔离开来
缺点
- 路由状态丢失，刷新一下，iframe的url状态就丢失了
- dom割裂严重，弹窗只能在iframe内部展示，无法覆盖全局
- web应用之间通信非常困难
- 每次打开白屏时间太长，对于SPA 应用来说无法接受
动态加载/懒加载微前端：
- 实现原理：使用模块加载器（如Webpack、SystemJS）将子应用分割成可动态加载的部分，主应用根据需要动态请求并执行子应用的代码。
- 示例：主应用通过Webpack的异步加载机制，在特定时机（如点击按钮或路由切换时）异步加载子应用的JS bundle，然后通过约定的API初始化子应用。
微应用容器化方案：
- 实现原理：使用专门的微前端框架（如single-spa、qiankun等）来管理和调度多个微应用的生命周期，包括注册、加载、挂载、卸载等。
- 示例：在single-spa项目中，每个微应用作为一个注册单元，通过配置声明其入口和激活条件。主应用启动时，single-spa会根据当前路由状态自动加载和运行相应的微应用，确保它们之间的状态隔离和通信协调。
以上各类方法均旨在实现前端应用的模块化和解耦，允许不同的团队独立开发、测试和部署，从而提升整个系统的灵活性和扩展性。
微前端解决方案
微前端是一种将大型单体前端应用拆分为多个小型、独立可部署的前端应用的技术方案，这些小应用可以在同一个宿主环境中共存并协同工作。以下列举几种常见的微前端解决方案及简要说明：
single-spa
single-spa 是一种流行的微前端框架，它通过监听 URL 变化并在路由级别管理各个子应用的加载、挂载和卸载过程。子应用需要暴露特定的生命周期钩子函数（如 bootstrap、mount 和 unmount）以便与 single-spa 框架集成。
阿里巴巴 Cloud Alfa
阿里巴巴Cloud Alfa 是一款企业级微前端解决方案，提供了对多种技术栈的支持，强调开箱即用和无代码侵入性，还具备完善的微前端生态支持以及安全的前端容器沙箱环境，适用于大规模团队协作和复杂场景下的微服务化前端架构。
iframe 方案
使用 iframe 将各个子应用独立包装，这种方式简单易行，但是因为iframe本身的局限性，可能导致样式隔离困难、性能瓶颈以及复杂的父子窗口间通信等问题。
Web Components
Web Components 提供了一种原生的自定义元素能力，允许开发者创建可重用、封装良好的UI组件。结合Web Components，可以通过定制化组件的方式来实现微前端，但在实际应用中，由于浏览器兼容性和生态系统成熟度的原因，可能需要配合polyfills或其他框架辅助实现。
Module Federation
webpack 5 引入了Module Federation特性，允许不同应用之间共享代码和模块，从而实现微前端架构。通过远程模块导入，可以在主应用中动态加载子应用的代码片段。
qiankun
qiankun 是蚂蚁金服开源的一款轻量级微前端框架，它采用类似于single-spa的路由驱动模式，同时也支持按需加载和运行时动态注入资源，具有较高的灵活性和扩展性。
Custom Elements / StencilJS / Polymer
这些技术或框架可以帮助构建自定义元素，进而实现微前端组件化，使得子应用能够以标准Web Components的形式嵌入到任何支持Web Components的宿主应用中。
每种方案都有其适用场景和优缺点，选择微前端策略时，通常需要考虑团队技术水平、现有系统复杂性、未来维护扩展性等因素。
single-spa 方案
single-spa 官网：https://zh-hans.single-spa.js.org/docs/getting-started-overview
single-spa是一个目前主流的微前端技术方案，其主要实现思路：
- 预先注册子应用(激活路由、子应用资源、生命周期函数)
- 监听路由的变化，匹配到了激活的路由则加载子应用资源，顺序调用生命周期函数并最终渲染到容器
乾坤微前端架构对其优化
乾坤微前端架构则进一步对single-spa方案进行完善，主要的完善点：
- 子应用资源由 js 列表修改进为一个url，大大减轻注册子应用的复杂度
- 实现应用隔离，完成js隔离方案 （window工厂） 和css隔离方案 （类vue的scoped）
- 增加资源预加载能力，预先子应用html、js、css资源缓存下来，加快子应用的打开速度
优点
- 监听路由自动的加载、卸载当前路由对应的子应用
- 完备的沙箱方案，js沙箱做了SnapshotSandbox、LegacySandbox、ProxySandbox三套渐进增强方案，css沙箱做了两套strictStyleIsolation、experimentalStyleIsolation两套适用不同场景的方案
- 路由保持，浏览器刷新、前进、后退，都可以作用到子应用
- 应用间通信简单，全局注入
缺点
- 基于路由匹配，无法同时激活多个子应用，也不支持子应用保活
- 改造成本较大，从 webpack、代码、路由等等都要做一系列的适配
- css 沙箱无法绝对的隔离，js 沙箱在某些场景下执行性能下降严重
- 无法支持 vite 等 ESM 脚本运行
无界方案
在乾坤的issue中一个议题非常有意思，有个开发者提出能否利用iframe来实现js沙箱能力，这个idea启发了无界方案
应用加载机制和 js 沙箱机制
将子应用的js注入主应用同域的iframe中运行，iframe是一个原生的window沙箱，内部有完整的history和location接口，子应用实例instance运行在iframe中，路由也彻底和主应用解耦，可以直接在业务组件里面启动应用。
优势
- 组件方式来使用微前端：
不用注册，不用改造路由，直接使用无界组件，化繁为简 - 一个页面可以同时激活多个子应用:
子应用采用 iframe 的路由，不用关心路由占用的问题 - 天然 js 沙箱，不会污染主应用环境:
不用修改主应用window任何属性，只在iframe内部进行修改 - 应用切换没有清理成本:
由于不污染主应用，子应用销毁也无需做任何清理工作
路由同步机制
在iframe内部进行history.pushState，浏览器会自动的在joint session history中添加iframe的session-history，浏览器的前进、后退在不做任何处理的情况就可以直接作用于子应用
劫持iframe的history.pushState和history.replaceState，就可以将子应用的url同步到主应用的query参数上，当刷新浏览器初始化iframe时，读回子应用的url并使用iframe的history.replaceState进行同步
优势
- 浏览器刷新、前进、后退都可以作用到子应用
- 实现成本低，无需复杂的监听来处理同步问题
- 多应用同时激活时也能保持路由同步
iframe 连接机制和 css 沙箱机制
无界采用webcomponent来实现页面的样式隔离，无界会创建一个wujie自定义元素，然后将子应用的完整结构渲染在内部
子应用的实例instance在iframe内运行，dom在主应用容器下的webcomponent内，通过代理 iframe的document到webcomponent，可以实现两者的互联。
将document的查询类接口：getElementsByTagName、getElementsByClassName、getElementsByName、getElementById、querySelector、querySelectorAll、head、body全部代理到webcomponent，这样instance和webcomponent就精准的链接起来。
当子应用发生切换，iframe保留下来，子应用的容器可能销毁，但webcomponent依然可以选择保留，这样等应用切换回来将webcomponent再挂载回容器上，子应用可以获得类似vue的keep-alive的能力.
优势
- 天然 css 沙箱:
直接物理隔离，样式隔离子应用不用做任何修改 - 天然适配弹窗问题:
document.body的appendChild或者insertBefore会代理直接插入到webcomponent，子应用不用做任何改造 - 子应用保活:
子应用保留iframe和webcomponent，应用内部的state不会丢失 - 完整的 DOM 结构:
webcomponent保留了子应用完整的html结构，样式和结构完全对应，子应用不用做任何修改
通信机制
承载子应用的iframe和主应用是同域的，所以主、子应用天然就可以很好的进行通信，在无界我们提供三种通信方式
props 注入机制
子应用通过$wujie.props可以轻松拿到主应用注入的数据
window.parent 通信机制
子应用iframe沙箱和主应用同源，子应用可以直接通过window.parent和主应用通信
去中心化的通信机制
无界提供了EventBus实例，注入到主应用和子应用，所有的应用可以去中心化的进行通信
无界方案 优势
- 多应用同时激活在线
框架具备同时激活多应用，并保持这些应用路由同步的能力
- 组件式的使用方式
无需注册，更无需路由适配，在组件内使用，跟随组件装载、卸载
- 应用级别的 keep-alive
子应用开启保活模式后，应用发生切换时整个子应用的状态可以保存下来不丢失，结合预执行模式可以获得类似ssr的打开体验
-
纯净无污染
- 无界利用iframe和webcomponent来搭建天然的js隔离沙箱和css隔离沙箱
- 利用iframe的history和主应用的history在同一个top-level browsing context来搭建天然的路由同步机制
- 副作用局限在沙箱内部，子应用切换无需任何清理工作，没有额外的切换成本
-
性能和体积兼具
- 子应用执行性能和原生一致，子应用实例instance运行在iframe的window上下文中，避免with(proxyWindow){code}这样指定代码执行上下文导致的性能下降，但是多了实例化iframe的一次性的开销，可以通过 preload 提前实例化
- 体积比较轻量，借助iframe和webcomponent来实现沙箱，有效的减小了代码量
-
开箱即用
- 不管是样式的兼容、路由的处理、弹窗的处理、热更新的加载，子应用完成接入即可开箱即用无需额外处理，应用接入成本也极低
参考文档：
- https://wujie-micro.github.io/doc/guide/
旨在为数千万中国开发者提供一个无缝且高效的云端环境，以支持学习、使用和贡献开源项目。
更多推荐
29
0- 0
已为社区贡献11条内容
所有评论(0)