⑴ 微前端 -- 干坤（一）
在 toB 的前端开发工作中，我们往往就会遇到如下困境：
基座模式
通过一个主应用，来管理其它应用。设计难度小，方便实践，但是通用度低。
自组织模式。应用之间是平等的，不存在相互管理的模式。设计难度大，不方便实施，但是通用度高。
就当前而言，基座模式实施起来比较方便，方案也是蛮多的。
注册表模式
和微服务架构相似，不论是哪种微前端方式，都需要有一个应用注册表的服务。这个应用注册表拥有每个应用及对应的入口，即路由。
它可以是一个固定值的配置文件，如 JSON 文件，又或者是一个可动态更新的配置，又或者是一种动态的服务。
作用：
应用注册。即提供新的微前端应用，向应用注册表注册功能。
应用发现。让主应用可以寻找到其它应用。
首先看一下它的用法：
https://qiankun.umijs.org/zh/guide/getting-started
微前端每个应用都拥有自己的生命周期：
bootstrap， 只会在微应用初始化的时候调用一次，下次微应用重新进入时会直接调用 mount 钩子，不会再重复触发 bootstrap。 通常我们可以在这里做一些全局变量的初始化，比如不会在 unmount 阶段被销毁的应用级别的缓存等。
Mount，应用每次进入都会调用 mount 方法，通常我们在这里触发应用的渲染方法
Unload，删除应用的生命周期
Unmount，应用每次 切出/卸载 会调用的方法，通常在这里我们会卸载微应用的应用实例
干坤，作为一款微前端领域的知名框架，其建立在single-spa基础上。相较于single-spa，干坤做了两件重要的事情，其一是加载资源，第二是进行资源隔离。而资源隔离又分为Js资源隔离和css资源隔离.
每个微应用对全局的影响都会局限在微应用自己的作用域内。比如 A 应用在 window 上新增了个属性 test，这个属性只能在 A 应用自己的作用域通过 window.test 获取到，主应用或者其他应用都无法拿到这个变量。
1、快照沙箱
2、支持多应用的代理沙箱
💪 HTML Entry 接入方式，让你接入微应用像使用 iframe 一样简单。
在使用 single-spa 加载微应用时，我们加载的不是微应用本身，而是微应用导出的 JS 文件，即JS Entry。
要接入一个微应用，就需要对微应用进行一系列的改造，然而 JS Entry 的问题就出在这儿，改造时对微应用的侵入行太强，而且和主应用的耦合性太强。
微应用改造一般分为三步：
l 微应用路由改造，添加一个特定的前缀
l 微应用入口改造，挂载点变更和生命周期函数导出
在js文件的入口中会导出一个对象，这个对象上有 bootstrap、mount、unmount 这三个接入 single-spa 框架必须提供的生命周期方法，其中 mount 方法规定了微应用应该怎么挂载到主应用提供的容器节点上。
l 打包工具配置更改
侵入型强其实说的就是第三点，更改打包工具的配置，使用 single-spa 接入微应用需要将微应用整个打包成一个 JS 文件，发布到静态资源服务器，然后在主应用中配置该 JS 文件的地址告诉 single-spa 去这个地址加载微应用。这就导致常见的打包优化基本上都没了，比如：按需加载、首屏资源加载优化、css 独立打包等优化措施。
项目发布以后出现了 bug ，修复之后需要更新上线，为了清除浏览器缓存带来的应用，一般文件名会带上 chunkcontent，微应用发布之后文件名都会发生变化，这时候还需要更新主应用中微应用配置，然后重新编译主应用然后发布，这套操作简直是不能忍受的。这也是 微前端框架 之 single-spa 从入门到精通 这篇文章中示例项目中微应用发布时的环境配置选择 development 的原因。
qiankun 框架为了解决 JS Entry 的问题，于是采用了 HTML Entry 的方式，让用户接入微应用就像使用 iframe 一样简单。
https://github.com/sy-l123/qiankun-demo
⑵ 微前端——干坤qiankun Demo
微前端就是将不同的功能按照不同的维度拆分成多个子应用。通过主应用来加载这些子应用。微前端的核心在于拆，拆完后在合！
我们可以将一个应用划分成若干个子应用，将子应用打包成一个个的 lib 。当路径切换 时加载不同的子应用。这样每个子应用都是独立的，技术栈也不用做限制了！从而解决了前端协同开发问题。
文档地址： https://qiankun.umijs.org/zh
2018 年 Single-SPA 诞生了， single-spa 是一个用于前端微服务化的 JavaScript 前端解决方案 ( 本身没有处理样式隔离， js 执行隔离 ) 实现了路由劫持和应用加载。
2019 年 qiankun 基于 Single-SPA, 提供了更加开箱即用的 API （ single-spa + sandbox + import-html-entry ） 做到了，技术栈无关、并且接入简单（像 i frame 一样简单）。
这里我们打算建立三个项目进行实操，一个Vue项目充当主应用，另一个Vue和React应用充当子应用
基座：qiankun-base 子应用：qiankun-vue、qiankun-react
react + react-router 技术栈的主应用：只需要让子应用的 activeRule 包含主应用的这个路由即可。
vue + vue-router 技术栈的主应用:
用绝对路径，不用用相对路径，例如
qiankun 只能解决子项目之间的样式相互污染，不能解决子项目的样式污染主项目的样式
冲突的样式，采用BEM命名方式
子应用，需要增加 update 钩子以便主应用手动更新微应用
主应用，直接调用子应用实例的 update 方法即可
⑶ 微前端前言
微前端是一种多个团队通过独立发布功能的方式来共同构建现代化 web 应用的技术手段及方法策略。
主框架不限制接入应用的技术栈，微应用具备完全自主权
微应用仓库独立，前后端可独立开发，部署完成后主框架自动完成同步更新
在面对各种复杂场景时，我们通常很难对一个已经存在的系统做全量的技术栈升级或重构，而微前端是一种非常好的实施渐进式重构的手段和策略
每个微应用之间状态隔离，运行时状态不共享
微前端架构旨在解决单体应用在一个相对长的时间跨度下，由于参与的人员、团队的增多、变迁，从一个普通应用演变成一个巨石应用后，随之而来的应用不可维护的问题。这类问题在企业级 Web 应用中尤其常见。
1.url 不同步。浏览器刷新 iframe url 状态丢失、后退前进按钮无法使用。
2.UI 不同步，DOM 结构不共享。想象一下屏幕右下角 1/4 的 iframe 里来一个带遮罩层的弹框，同时我们要求这个弹框要浏览器居中显示，还要浏览器 resize 时自动居中。
3.全局上下文完全隔离，内存变量不共享。iframe 内外系统的通信、数据同步等需求，主应用的 cookie 要透传到根域名都不同的子应用中实现免登效果。
4.慢。每次子应用进入都是一次浏览器上下文重建、资源重新加载的过程。
通过监听 url change 事件，在路由变化时匹配到渲染的子应用并进行渲染，这个思路也是目前实现微前端的主流方式。同时single-spa要求子应用修改渲染逻辑并暴露出三个方法：bootstrap、mount、unmount，分别对应初始化、渲染和卸载，这也导致子应用需要对入口文件进行修改。过于基础，成本太高，不建议。
qiankun是阿里推出的一个基于single-spa的微前端实现库，旨在帮助大家能更简单、无痛的构建一个生产可用微前端架构系统。因为是基于single-spa进行封装，所以single-spa的特点也被qiankun继承下来。成本低于single-spa，高于MicroApp。
MicroApp是京东推出的一款基于类WebComponent进行渲染的微前端框架，不同于目前流行的开源框架，它从组件化的思维实现微前端，旨在降低上手难度、提升工作效率。它是目前市面上接入微前端成本最低的框架，并且提供了JS沙箱、样式隔离、元素隔离、预加载、资源地址补全、插件系统、数据通信等一系列完善的功能。是目前市面上接入微前端成本最低的方案。
single-spa github地址： https://github.com/single-spa/single-spa
qiankun官网： https://qiankun.umijs.org/zh
MicroApp官网： https://cang.org/micro-app/
⑷ 干坤-微前端架构使用
1.价值
2.官方文档
https://qiankun.umijs.org/zh/guide
3.配置
主应用(history模式)
子应用
如果是vue-cli >=3,需要在根目录创建vue.config.js文件
如果是vue-cli >=3,在根目录vue.config.js文件中的configureWebpack中添加
如果是vue-cli >=3,在根目录vue.config.js文件中的devServer中添加
⑸ 轻量、高效、功能强大的微前端框架-MicroApp
这几年后端的微服务是比较火爆，我们公司目前只要是新项目，基本上都是基于微服务去架构的，那么微前端是什么呢？
微前端是借鉴了微服务的架构理念，核心在于将一个庞大的前端应用拆分成多个独立灵活的小型应用，每个应用都可以独立开发、独立运行、独立部署，再将这些小型应用融合为一个完整的应用，或者将原本运行已久、没有关联的几个应用融合为一个应用。微前端既可以将多个项目融合为一，又可以减少项目之间的耦合，提升项目扩展性，相比一整块的前端仓库，微前端架构下的前端仓库倾向于更小更灵活
以前我们为了把几个独立运行的小型应用合并成一个应用都是通过iframe的方式去实现的，如果不考虑体验问题，iframe 几乎是最完美的微前端解决方案了。
iframe 最大的特性就是提供了浏览器原生的硬隔离方案，不论是样式隔离、js 隔离这类问题统统都能被完美解决。但他的最大问题也在于他的隔离性无法被突破，导致应用间上下文无法被共享，随之带来的开发体验、产品体验的问题
micro-app不是基于iframe架构的
micro-app提供了js沙箱、样式隔离、元素隔离、预加载、数据通信、静态资源补全等一系列完善的开箱即用功能
micro-app没有任何依赖
为了保证各个业务之间独立开发、独立部署的能力，micro-app做了诸多兼容，在任何技术框架中都可以正常运行。
下面我讲一下如何在Vue中使用micro-app
1、初始化一个基座应用
2、基座应用的文件修改
main.js修改
router.js修改
3、main-page.vue页面
4、创建一个子应用
5、子应用的router.js文件修改
6、src目录下新建 public-path.js
7、 main.js 引入public-path.js
到此这个简单的微应用就搭好了
觉得效果不错的请帮忙加个关注点个赞，经常分享前端实用开发技巧
⑹ 微服务干坤框架
微前端架构具备以下几个核心价值：
1.技术栈无关
主框架不限制接入应用的技术栈，微应用具备完全自主权
2.独立开发、独立部署
微应用仓库独立，前后端可独立开发，部署完成后主框架自动完成同步更新
3.增量升级
在面对各种复杂场景时，我们通常很难对一个已经存在的系统做全量的技术栈升级或重构，而微前端是一种非常好的实施渐进式重构的手段和策略
4.独立运行时
每个微应用之间状态隔离，运行时状态不共享
$ yarn add qiankun # 或者 npm i qiankun -S
import { registerMicroApps, start } from 'qiankun';
registerMicroApps([
{
name: 'react app', // app name registered
entry: '//localhost:7100',
container: '#yourContainer',
activeRule: '/yourActiveRule',
},
{
name: 'vue app',
entry: { scripts: ['//localhost:7100/main.js'] },
container: '#yourContainer2',
activeRule: '/yourActiveRule2',
},
]);
start();