浅析微前端技术

介绍

微前端是一种类似于微服务的架构，是一种由独立交付的多个前端应用组成整体的架构风格，将前端应用分解成一些更小、更简单的能够独立开发、测试、部署的应用，而在用户看来仍然是内聚的单个产品。

通俗来说，就是在一个 web 应用中可以独立地运行另一个 web 应用，这样的使用场景其实不少：

• 比如制作一个统一运营平台，把已有的评论系统和申诉系统等一众运营平台统一接入到这个平台；
• 比如有一个巨大的应用，为了降低开发和维护成本，分拆成多个小应用进行开发和部署，然后用一个平台将这些小应用集成起来；
• 又比如一个应用使用 vue 框架开发，其中有一个比较独立的模块，开发者想尝试使用 react 框架来开发，等模块单独开发部署完，再把这个模块应用接回去

一个完整的微前端框架应该具备哪些能力呢？

• 子应用的加载和卸载能力

页面需要从一个子应用切换到另一个子应用，框架必须具备加载、渲染、切换的能力

• 子应用独立运行的能力

子应用运行会污染全局的 window 对象，样式会污染其他应用，必须有效的隔离起来

• 子应用路由状态保持能力

激活子应用后，浏览器刷新、前进、后退子应用的路由都应该可以正常工作

• 应用间通信的能力

应用间可以方便、快捷的通信

可以看出 single-spa 和 qiankun 是微前端方案的不二之选，无论是从其业界认可程度还是生态的活跃程度，都属于第一梯队。下面我们来介绍这些业界流行的方案：

流行方案

Single-spa

从名字上就可以推断出，Single-spa (https://single-spa.js.org/docs/getting-started-overview/) 是一个将多个单页面应用聚合为一个整体应用的 JavaScript 微前端框架，其主要实现思路：

• 预先注册子应用，包含激活路由、子应用资源、生命周期函数等；
• 监听路由的变化，匹配到了激活的路由则加载子应用资源，顺序调用生命周期函数并最终渲染到容器。

Single-spa 是微前端领域的先行者，下面介绍的几个框架也是借鉴了它不少设计思路，但由于它本身没有处理 CSS 样式隔离或是 JS 运行时隔离，因此只适合单应用的场景。

Qiankun

Qiankun (https://qiankun.umijs.org/zh) 是一个基于 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 脚本运行的能力较差

Garfish

Garfish (https://www.garfishjs.org/) 是字节跳动团队提出的一种微前端解决方案，其原理跟 qiankun 比较近似。

MicroApp

MicroApp (https://zeroing.jd.com/) 是京东开发的一种基于 WebComponent 进行渲染的微前端架构，它没有沿袭 single-spa 的思路，而是通过 CustomElement 结合自定义的 ShadowDom，将微前端封装成一个类 WebComponent 组件，从而实现微前端的组件化渲染。

优点：

• 使用简单，MicroApp 提供了 JS 沙箱、样式隔离、元素隔离、预加载、数据通信、静态资源补齐等一系列完整的功能
• MicroApp 没有任何依赖，这赋予了它小巧的体积和更高的扩展性

MicroApp 的实现方式其实就是2个概念：HTML Entry 和类 webComponent

• HTML Entry 其实就是 qiankun 的实现方式，通过加载远程 HTML，去解析其 DOM 结构从而获取 JS、CSS 等静态资源来实现渲染
• 类 webComponent 其实是将 CustomElement 结合自定义的 ShadowDom 实现 WebComponent 基本一致的功能。

无界

无界 (https://wujie-micro.github.io/doc/) 则是腾讯推出的一款微前端解决方案。与众不同的是，它是一种基于 iframe 的全新微前端方案，无界团队希望借助 iframe 的优点，努力补足 iframe 的缺点，让 iframe 焕发新生。

优点：

• 使用简单，使用没有任何心智负担；
• 基于 iframe 的天然沙盒，物理隔离，无论是 js、css、dom 都可以完全隔离开来；
• 支持多应用同时激活，页面上可以摆放多个 iframe 来组合业务

缺点：

• 路由状态丢失，刷新一下，iframe 的 url 状态就丢失了；
• dom 割裂严重，弹窗只能在 iframe ，内部展示，无法覆盖到全局
• 通信困难，只能通过 postmessage 传递序列化的消息

以上这些缺陷归根结底都是使用 iframe 带来的限制，无界团队逐一提出了解决方案：

针对弹窗适配问题，无界采用 webcomponent 来实现页面的样式隔离，子应用的实例在 iframe 中运行，DOM 在主应用容器下的 webcomponent 内，通过代理 iframe 的 document 到 webcomponent，可以实现两者的互联，从而使得iframe无法全局展示的问题。

针对路由状态丢失问题，无界提出了子应用“保活”模式。具体来说，当子应用发生切换，子应用的容器可以销毁，但 webcomponent 和 iframe 依然可以选择保留，这样等应用切换回来将 webcomponent 再挂载回容器上，使得其获得类似 vue 的 keep-alive 能力。

而针对通信难问题，无界提供了三种通信方式：props 注入机制、window.parent 通信机制和去中心化的 EventBus 通信机制。

微前端的适用场景

微前端的适用场景

• 中大型项目

建设微前端项目的初衷就是为未来可能的扩展开发提供可能，因此微前端非常适合具有

多个团队维护的大型项目。

• Web 项目

虽然说微前端这个概念不仅限于某种类型的平台，但是他在 Web 领域能够发挥出它的最大优势。诸如同属于大前端领域的 Native 应用，在这个领域的局限性就比较大，在开发过程中不能像 Web 项目灵活。

• 适用于垂类业务复杂的团队

综合来说，提高垂类业务的复杂度会增加应用的整体产品能力，但它却带来了额外的成本和维护挑战。

如果你把生产力放在首位，可以考虑 微前端 架构

微前端的劝退场景

• 业务边界不清晰的项目，在发起一个微前端项目前，你需要对该项目的业务领域及分工有着全面的了解。 如果你不知道某个特定的功能是由哪个团队负责开发及维护的，最终这个微前端项目将会变得一团乱，开发及维护成本极高，而由此带来的人效提升却很少，背离的微前端的初衷。
• 小型项目，在评估是否需要采用微前端架构前，你需要对平台的规模有大概的认知，不要为了

纸面上的优势而强行采用微前端方案，业界还有很多其他小而美的框架可以尝试。

微前端是前端发展的必然阶段。目前微前端框架也是属于百花齐放的阶段，基本上每一个大厂都有结合自己业务推出的方案，每个框架都有自己的优缺点，大家可以根据自己的项目去选择合适好用的即可。

但需要注意的是，微前端并非是最好的。他只是解决项目复杂性、代码检查及管控等问题的一种方式，对于架构设计的合理性提出了更高的挑战。