背景
由于业务增长，团队拆分，我们需要将原有系统的一部分模块（Vue实现）迁移到另外一个系统（React）中。但两个系统技术栈不同，导致重构成本变大，但业务又希望在短期内看到效果，后面可以增量的重构。
要求是对用户无感知的，真正将两个系统融合到一起。
经过技术调研，我们决定用微前端的方式实现。
微前端是一种多个团队通过独立发布功能的方式来共同构建现代化 web 应用的技术手段及方法策略。
微前端架构旨在解决单体应用在一个相对长的时间跨度下，由于参与的人员、团队的增多、变迁，从一个普通应用演变成一个巨石应用(Frontend Monolith)后，随之而来的应用不可维护的问题。这跟我们现在的情况是相符的。它具有如下的特点：
- 技术栈无关。主框架不限制接入应用的技术栈，微应用具备完全自主权
- 独立开发、独立部署。微应用仓库独立，前后端可独立开发，部署完成后主框架自动完成同步更新
- 增量升级。在面对各种复杂场景时，我们通常很难对一个已经存在的系统做全量的技术栈升级或重构，而微前端是一种非常好的实施渐进式重构的手段和策略
- 独立运行时。每个微应用之间状态隔离，运行时状态不共享
技术选型
微前端是一种类似微服务的架构，目标是将单一的单体应用变成由多个小型应用聚合为一的应用。
经过调研，我们有以下的实现方案。
iframe
优点：
- 提供了浏览器原生的硬隔离方案，不论是样式隔离、js 隔离这类问题统统都能被完美解决
缺点：
- url 不同步。浏览器刷新 iframe url 状态丢失、后退前进按钮无法使用
- UI 不同步，DOM 结构不共享
- 全局上下文完全隔离，内存变量不共享。iframe 内外系统的通信、数据同步等需求，主应用的 cookie 要透传到根域名都不同的子应用中实现免登效果
- 慢。每次子应用进入都是一次浏览器上下文重建、资源重新加载的过程
缺点层面，暂时是无法满足业务的要求的，所以我们没有采取这种方案。
qiankun
qiankun 是一个基于 single-spa 的微前端实现库，旨在帮助大家能更简单、无痛的构建一个生产可用微前端架构系统。
它有以下的特性：
