【乾坤qiankun】微前端的一次详细记录

要点总结

1.微前端产生的背景
2.微前端的概念以及常见的框架
3.微前端的实际意义
4.微前端使用分享

微前端产生背景：

• 随着这些年互联网的飞速发展，很多企业的web应用在持续迭代中功能越来越复杂，参与的人员、团队不断增多，导致项目出现难以维护的问题，这种情况PC端尤其常见，许多研发团队也在找寻一种高效管理复杂应用的方案，于是微前端被提及的越来越频繁。

• 微前端并不是一项新的技术，而是一种架构理念，它将单一的web应用拆解成多个可以独立开发、独立运行、独立部署的小型应用，并将它们整合为一个应用。

• 在实际业务中，我们也遇到同样的问题，并且在不同的业务场景下尝试了各种解决方案，如iframe、npm包、微前端框架，并对各种方案的优劣进行了对比。

• iframe：在所有微前端方案中，iframe是最稳定的、上手难度最低的，但它有一些无法解决的问题，例如性能低、通信复杂、双滚动条、弹窗无法全局覆盖，它的成长性不高，只适合简单的页面渲染。

• npm包：将子应用封装成npm包，通过组件的方式引入，在性能和兼容性上是最优的方案，但却有一个致命的问题就是版本更新，每次版本发布需要通知接入方同步更新，管理非常困难。

• 微前端框架：流行的微前端框架有single-spa和qiankun，它们将维护成本和功能上达到一种平衡，是目前实现微前端备受推崇的方案。

• 由于iframe和npm包存在问题理论上无法解决，在最初我们采用qiankun作为解决方案，qiankun是在single-spa基础上进行了封装，提供了js沙箱、样式隔离、预加载等功能，并且与技术栈无关，可以兼容不同的框架。

微前端的概念以及常见微前端框架：

什么是微前端？. 微前端（Micro-Frontends）是一种类似于微服务的架构，它将微服务的理念应用于浏览器端，即将 Web 应用由单一的单体应用转变为多个小型前端应用聚合为一的应用。各个前端应用还可以独立运行、独立开发、独立部署。

最初的微前端框架：single-spa

项目中使用的是Qiankun 在single-spa进行改造和填充

关于qinkun和single-spa的思考

1. 在single-spa和qiankun中都是通过监听url
   change事件，在路由变化时匹配到渲染的子应用并进行渲染。这种基于路由监听渲染是single-spa最早实现的，作为出现最早、最有影响力的微前端框架，single-spa被很多框架和公司借鉴，也导致目前实现的微前端的方式大多是基于路由监听。

2. 同时single-spa要求子应用修改渲染逻辑并暴露出三个方法：bootstrap、mount、unmount，分别对应初始化、渲染和卸载，这也导致子应用需要对入口文件进行修改。这个特点也被qiankun继承下来，并且需要对webpack配置进行一些修改。

主要以乾坤（ali）为例进行讲解：

微前端架构具备以下几个核心价值： 技术栈无关 主框架不限制接入应用的技术栈，微应用具备完全自主权 独立开发、独立部署 微应用仓库独立，前后端可独立开发，部署完成后主框架自动完成同步更新 增量升级 在面对各种复杂场景时，我们通常很难对一个已经存在的系统做全量的技术栈升级或重构，而微前端是一种非常好的实施渐进式重构的手段和策略 独立运行时 每个微应用之间状态隔离，运行时状态不共享 微前端架构旨在解决单体应用在一个相对长的时间跨度下，由于参与的人员、团队的增多、变迁，从一个普通应用演变成一个巨石应用(Frontend Monolith)后，随之而来的应用不可维护的问题。这类问题在企业级 Web 应用中尤其常见。

特性：

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

样式隔离和js隔离：

• qiankun
  将会自动隔离微应用之间的样式（开启沙箱的情况下），你可以通过手动的方式确保主应用与微应用之间的样式隔离。比如给主应用的所有样式添加一个前缀，或者假如你使用了
  ant-design 这样的组件库，你可以通过这篇文档中的配置方式给主应用样式自动添加指定的前缀。
• 样式隔离： 乾坤中的样式隔离 严格样式隔离和 scoped 样式隔离。
• 样式只作用于加了该属性的元素上面 项目中： 尽量不要使用可能冲突全局的 class 或者直接为标签定义样式； 定义唯一的 class
  前缀，现在的项目都是用诸如 antd 这样的组件库，这类组件库都支持自定义组件 class 前缀； 主应用一定要有自定义的 class
  前缀； Css 样式隔离：https://juejin.cn/post/6992944363798003743
  方案待解决…

案例（遇到的问题）：

子应用影响主应用：在主应用中添加classNaame

在子应用中

微应用的配置

• 四个生命周期且必须导出

• qiankun 做沙箱隔离主要分为三种：

  legacySandBox proxySandBox snapshotSandBox。

• legacySandBox 的核心思想是什么呢？legacySandBox 的本质上还是操作 window
  对象，但是他会存在三个状态池，分别用于子应用卸载时还原主应用的状态和子应用加载时还原子应用的状态：
  addedPropsMapInSandbox： 存储在子应用运行时期间新增的全局变量，用于卸载子应用时还原主应用全局变量； modifiedPropsOriginalValueMapInSandbox：存储在子应用运行期间更新的全局变量，用于卸载子应用时还原主应用全局变量；
  currentUpdatedPropsValueMap：存储子应用全局变量的更新，用于运行时切换后还原子应用的状态；

  所以，总结起来，legacySandBox 还是会操作 window
  对象，但是他通过激活沙箱时还原子应用的状态，卸载时还原主应用的状态来实现沙箱隔离的

  Js隔离 全局的window隔离 常用 proxy 为了支持多实例的场景，proxySandBox 不会直接操作 window
  对象。并且为了避免子应用操作或者修改主应用上诸如 window、document、location 这些重要的属性，会遍历这些属性到子应用
  window 副本（fakeWindow）上

因为 proxySandBox 不直接操作 window，所以在激活和卸载的时候也不需要操作状态池更新 /
还原主子应用的状态了。相比较看来，proxySandBox 是现阶段 qiankun 中最完备的沙箱模式，完全隔离了主子应用的状态，不会像
legacySandBox 模式下在运行时期间仍然会污染 window。
snapshotSandBox 最后一种沙箱就是 snapshotSandBox，在不支持 Proxy 的场景下会降级为 snapshotSandBox，如同他的名字一样，snapshotSandBox 的原理就是在子应用激活 /
卸载时分别去通过快照的形式记录/还原状态来实现沙箱的。 总结起来，对当前的 window 和记录的快照做 diff 来实现沙箱。

实现原理

qiankun 在实现 sandbox 时，先构建一个空对象 - fakeWindow 作为一个假的 window 对象，然后在
fakeWindow 的基础上通过原生的 Proxy 创建一个 proxy 对象，这个 proxy 最后会作为子应用 js
代码执行时的全局变量。有了这个 proxy，我们就可以很方便的劫持 js
代码中对全局变量的读写操作。当子应用中需要添加(修改)全局变量时，直接在 fakeWindow
中添加(修改)；当子应用需要从全局变量中读取某个属性(方法)时，先从 fakeWindow 中获取，如果 fakeWindow
中没有，再从原生 window 中获取。

• 拓展 京东微前端框架 microApp

  Github https://github.com/micro-zoe/micro-app

  官网 https://zeroing.jd.com/micro-app/docs.html#/

  补充待续…

  相关资料： Import-Html-entry https://github.com/kuitos/import-html-entry
  Qiankun : https://github.com/liyongning/qiankun Git ssl :
  https://www.cnblogs.com/lvhuayan/p/14538106.html