2023可能是最全的微前端方案调研

微前端是什么

微前端概念是从微服务概念扩展而来的，摒弃大型单体方式，将前端整体分解为小而简单的块，这些块可以独立开发、测试和部署，同时仍然聚合为一个产品出现在客户面前。

可以理解微前端是一种将多个可独立交付的小型前端应用聚合为一个整体的架构风格。

几个特性：无技术栈限制、应用单独开发、多应用整合

解决的问题

• 工程越来越大
• 在老的技术栈之上难以开发
• 由于项目越来越大，持续集成部署也越来越困难（影响别的代码风险、打包慢等）

优势

优势其实就是解决的问题

• 将大的工程分隔为独立的子应用
• 不限技术栈
• 独立的持续集成交付部署

分类

要实现微前端，本质上就是在运行时远程加载应用。

• 基座模式：通过搭建基座、配置中心来管理子应用。如基于SIngle Spa的偏通用的乾坤方案，也有基于本身团队业务量身定制的方案。
• 自组织模式： 通过约定进行互调，但会遇到处理第三方依赖等问题。
• 去中心模式： 脱离基座模式，每个应用之间都可以彼此分享资源。如基于Webpack 5 Module Federation实现的EMP微前端方案，可以实现多个应用彼此共享资源分享。

从构建的角度来看，分为编译时构建微前端和运行时构建微前端：

编译时：有点像组件库的编写，比如你开发一个类似 elementUI 的这种组件库，那么你可能会用到类似 monorepos 这种方案，也就是将库中的组件作为包，在构建时引入作为依赖。这种的缺点就是引入新的组件时要重新编译，不够灵活。编译时的微前端可以通过Web Components，Monorepo等方式来实现。其中Monorepo非常流行，常见的工具有nx，rush，lerna等。

运行时：是一次加载或通过延迟加载按需动态将微型前端注入到容器应用程序中时。当引入新的微前端的时候，不需要构建，可以动态在代码中定义加载。我眼中的微前端更多是指这种运行时加载的微前端，因为独立构建，部署和测试是我们对于“微”的定义。

相关技术

这里列举了一些和微前端相关的技术，市面上一些微前端框架就用到了下面的一种或多种技术

1、iframe

iframe虽然基本能做到微前端所要做的所有事情，它的最大问题也在于他的隔离性无法被突破，导致应用间上下文无法被共享，随之带来开发体验、产品体验的问题。

1. 不是单页应用，会导致浏览器刷新 iframe url 状态丢失、后退前进按钮无法使用。
2. 弹框类的功能无法应用到整个大应用中，只能在对应的窗口内展示。
3. 由于可能应用间不是在相同的域内，主应用的 cookie 要透传到根域名都不同的子应用中才能实现免登录效果。
4. 每次子应用进入都是一次浏览器上下文重建、资源重新加载的过程，占用大量资源的同时也在极大地消耗资源。
5. iframe的特性导致搜索引擎无法获取到其中的内容，进而无法实现应用的seo（当然一般后台应用不用seo，但是有的需要啊）

Why Not Iframe

2、Web Components

什么是Web Components

优点：

1. 技术栈无关：Web Components是浏览器原生组件，那即是在任何框架中都可以使用。
2. 独立开发：使用Web Components开发的应用无需与其他应用间产生任何关联。
3. 应用间隔离： Shadow DOM的特性，各个引入的微应用间可以达到相互隔离的效果。
   综

缺点：

1. 兼容性

3、ES Module

这个大家应该都不陌生，尤大大做的 Vite 核心就是ES Module，可以看我写的这篇文章

优点：

1. 无技术栈限制：ESM加载的只是js内容，无论哪个框架，最终都要编译成js，因此，无论哪种框架，ESM都能加载。
2. 应用单独开发： ESM只是js的一种规范，不会影响应用的开发模式。
3. 多应用整合： 只要将微应用以ESM的方式暴露出来，就能正常加载。
4. 远程加载模块: ESM能够直接请求cdn资源，这是它与生俱来的能力。

缺点：

1. 兼容性

技术框架

这里展示的都是企业级的、比较完善的微前端框架

1、single SPA

特点： 国外的项目，只解决了路由问题、应用入口

single-spa 就做了两件事，加载微应用（加载方法还是用户自己提供的）、维护微应用状态（初始化、挂载、卸载）。
所以人家本来就不是想成为一个完整的微前端框架，而是作为微前端环节中的一个工具。

优点：

• 功能比较稳定

不足：

• 只解决了路由问题、应用入口

地址： https://single-spa.js.org
这篇问诊详细解释 微前端：single-spa是什么

2、qiankun

特点： 蚂蚁出品，基于 single-spa

优点：

1. 基于single-spa封装，提供了更加开箱即用的 API
2. 技术栈无关，任意技术栈的应用均可 使用/接入，不论是 React/Vue/Angular/JQuery 还是其他等框架
3. HTML Entry 接入方式，让你接入微应用像使用 iframe 一样简单
4. 样式隔离，确保微应用之间样式互相不干扰
5. JS 沙箱，确保微应用之间 全局变量/事件 不冲突
6. 资源预加载，在浏览器空闲时间预加载未打开的微应用资源，加速微应用打开速度
7. umi 插件，提供了 @umijs/plugin-qiankun 供 umi 应用一键切换成微前端架构系统

不足：
基本上都达到了微前端的效果

地址： qinakun

3、EMP

特点： 欢聚时代，基于Webpack5的新特性Module Federation（模块联邦）

优点：

1. 基于Webpack5的新特性Module Federation实现，达到第三方依赖共享，减少不必要的代码引入的目的，什么是Module Federation这里就不再赘述。
2. 每个微应用独立部署运行，并通过cdn的方式引入主程序中，因此只需要部署一次，便可以提供给任何基于Module Federation的应用使用。并且此部分代码是远程引入，无需参与应用的打包。
3. 动态更新微应用：EMP是通过cdn加载微应用，因此每个微应用中的代码有变动时，无需重新打包发布新的整合应用便能加载到最新的微应用。
4. 去中心化，每个微应用间都可以引入其他的微应用，无中心应用的概念。
5. 跨技术栈组件式调用，提供了在主应用框架中可以调用其他框架组件的能力（目前已支持互相调用的框架及使用方式请参阅官方文档）。
6. 按需加载，开发者可以选择只加载微应用中需要的部分，而不是强制只能将整个应用全部加载。
7. 应用间通信，每一个应用都可以进行状态共享，就像在使用npm模块进行开发一样便捷。
8. 生成对应技术栈模板，它能像cerate-react-app一样，也能像create-vue-app一样，通过指令一键搭建好开发环境，减少开发者的负担。
9. 远程拉取ts声明文件，emp-cli中内置了拉取远程应用中代码声明文件的能力，让使用ts开发的开发者不再为代码报错而烦恼。

EMP除了具备微前端的能力外，还实现了跨应用状态共享、跨框架组件调用的能力，这是现有框架所不具备的优秀特性！

不足：

1. 对 webpack 强依赖，老旧项目不友好；

4、无界

特点：腾讯出品，webcomponent 容器 + iframe 沙箱

无界微前端方案基于 webcomponent 容器 + iframe 沙箱，能够完善的解决适配成本、样式隔离、运行性能、页面白屏、子应用通信、子应用保活、多应用激活、vite 框架支持、应用共享等用户的核心诉求。

优点：

• 接入成本低
• 速度快
• js通过iframe隔离，css

不足：

• 暂无

地址： https://github.com/Tencent/wujie

5、micro-app

特点： 京东zero团队， webcomponent + qiankun sandbox 的微前端方案。

优点：

• 使用 webcomponet 加载子应用相比 single-spa 这种注册监听方案更加优雅；
• 复用经过大量项目验证过 qiankun 的沙箱机制也使得框架更加可靠；
• 组件式的 api 更加符合使用习惯，支持子应用保活；
• 降低子应用改造的成本，提供静态资源预加载能力；

不足：

• 接入成本较 qiankun 有所降低，但是路由依然存在依赖；
• 多应用激活后无法保持各子应用的路由状态，刷新后全部丢失；
• css 沙箱依然无法绝对的隔离，js 沙箱做全局变量查找缓存，性能有所优化；
• 支持 vite 运行，但必须使用 plugin 改造子应用，且 js 代码没办法做沙箱隔离；
• 对于不支持 webcompnent 的浏览器没有做降级处理；

地址： https://micro-zoe.github.io/micro-app

总结

• qiankun 和 无界 目前看下来不错

参考资料

https://juejin.cn/post/6893307922902679560
https://github.com/efoxTeam/emp/wiki