Ⅰ qiankun 微前端应用实践与部署（四）
一般情况下，我们对应用进行配置打包，要对图片字体等资源进行下面配置，使得资源路径正常加载。但是，在微前端模式下，子应用打包部署后，往往会出现子应用 css 文件里面引入资源路径加载失败的问题，下面就让我们来探究一下。
👉 独立应用下的 url-loader 配置：
因为 url-loader 的 options 项的属性 publicPath 属性默认是 '' ，表示相对路径，即打包出来的资源引用 url 都会加上相对路径寻找 static 静态资源入口，比如：
所有应用编译打包部署后，当主应用加载子应用，子应用加载自身的 css 文件样式时，由于 其对应的 css 文件里面的图片 url 引用是相对路径，会出现子应用的资源相对路径拼接主应用 domain 的情况，即子应用的 ../../static/img/bg_header.790a94f4.png 会在主应用的 domain 下进行资源的寻找，导致加载失败 404 的情况。
如果项目有用到第三方库，比如 element-ui ，那么就更有必要进行处理了。因为 element-ui 的字体图标是在 css 里面引入的，还有相关背景图片的引入也是在 css 里，所以需要配置 webpack 的 url-loader ，生产模式情况下直接指定资源前缀，使之成为绝对路径。
这样配置后，打包出来的 css 样式文件会变成：
资源是绝对路径，就不会出现上面子应用资源加载失败的情况。
但是，这种前端配置文件写死路径的做法灵活性并不好，比如不能做到编译一次，任意部署，因为路径写死，所以如果需要部署到其他服务器的话，就需要重新编译了。
接下来，讲的是实现灵活部署的方案。
我们在只编译打包一次前端应用的前提下，为了实现灵活部署，需要借助 nginx 来实现。
下面以 vue-cli 3 的配置为例，与 vue-cli 2 只是写法上的区别，其他都一样。
假设主应用部署地址是 192.168.2.192 ，子应用的部署地址是 192.168.2.192:7102 。
打包编译部署后，子应用的 css 文件里面的图片资源引用 url 如下：
主应用加载子应用的时候，子应用的资源拼接主应用 domian 后，子应用的 css 文件里面的图片资源加载路径 url 就会变成：
此时的关键就是要访问到子应用的资源，而不是去主应用资源目录去找。
所以我们采用 nginx 路径代理转发端口的方案，当应用访问 192.168.2.192/live 这个路径时，经过 nginx 进行路径代理转发配置，转发到子应用端口。
配置 nginx 代理规则：
此时真正访问的资源路径（子应用资源路径）是：
👋 至此，通过修改配置 url-loader 的 publicPath 以及配置 nginx 的路径代理转发，就可以实现编译打包一次，到处部署的目的。
Ⅱ 阿里 qiankun 微前端框架实践
qiankun ——— 一套完整的微前端解决方案： https://github.com/umijs/qiankun
如图所示，在qiankun框架中，有主程序与子程序。主程序会留出指定的DOM作为子程序的容器，并且通过主程序里的路由转发加载子应用。
修改主程序main.js注册子应用
修改主程App.vue注册子应用的容器
main.js
Demo： github.com/justworkhar…
与传统的父子组件通信一样，父程序通过props向子程序传递信息。子程序通过回调函数向父程序传递信息。
qiankun框架说白了就是通过在主程中添加一个展示子程序的DOM，经过路由判断做转发加载子程序。
Ⅲ qiankun微前端框架处理
https://blog.csdn.net/qq_41694291/article/details/113842872
概念：微前端的概念借鉴于后端的微服务，一般以业务功能为拆分单元
解决问题：大型项目的变更、扩展、维护困难的问题
总体积变大，插件可上传cdn，但公共函数资源不便于共享
iframe ：隔离性和兼容性好，性能和使用感差（性能差因为不会有缓存，每次重新加载）
基座模式 ：基于 路由分发 ，由基座监听路由变化，加载不同的应用，实现应用解耦，single-spa、qiankun
组合式集成 ：组件单独打包发布，类似于npm包
EMP ：主要基于Webpack5 Mole Federation
web components ：
我们采用的是qiankun，主要思路是将一个大应用，拆分为更小的、可独立开发、测试、部署的子应用。
传统的大型项目：所有模块都在一个应用里，由应用本身负责路由管理，属于 应用分发路由 方式
拆分微应用的项目：属于基座模式下的系统架构，各应用互相独立，单独运行在不同的服务上，基座（基座一般是用户最终访问的应用）根据路由去加载不同的应用到页面上，即 路由分发应用 方式
微前段主要需要解决的问题有两个
qiankun和single-spa对比
activePath与当前的hash对比一致
Ⅳ 微前端前言
微前端是一种多个团队通过独立发布功能的方式来共同构建现代化 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/
Ⅳ qianKun + VUE 实现微前端架构 (基于vue2实现)
创建两个项目作为实现demo，一个为主应用，一个为子应用
3.配置函数文件 microAppSetting
4.微应用出口文件 index.js
5.在App.vue内配置微应用容器及跳转菜单
6.在main.js文件内引入微应用出口文件 index.js
7.运行后展示
8.在配置完子应用后的主应用展示
点击子应用菜单
1.修改子应用路由文件内路由实例属性： base 为 "/child"
2.在main.js文件内导出生命周期钩子
3.配置Webpack、跨域与端口号
在vue.config.js内添加：
4.运行后展示
package.json
Ⅵ 微前端quankun Vue应用 action+Vuex通信方式的实现
action + Vuex 通信主要是使用官方的 action 进行通信，之后再将值更新到 vuex 中
1、初始化 action
创建 src -> shared -> actions.js
2、在 Vue 组件中使用
1、把主应用中的初始化的action映射到微应用中
创建 src -> shared -> actions.js
2、在mounted的生命周期里注入actions实例
main.js
3、在 Vue 组件中使用
这样就实现 action + Vuex 的通信方式。
主要还是开篇这句话：
action + Vuex 通信主要是使用官方的 action 进行通信，之后再将值更新到 vuex 中
主要参考文章：
干坤官网通信API
微前端qiankun Vue应用间通信的思考
qiankun的简单使用和通信
Ⅶ 微前端——干坤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 方法即可
Ⅷ 微前端qiankun
微前端qiankun 使用，一些注意事项。附上 qiankun官网
主应用(vue)
1、安装qiankun
2、修改 main.js
主应用到这就可以了，下面的是一些扩展加载微应用事项
3、router页面配置加载微应用
修改主应用router.js
在About.vue文件中加入
4、如果在vue-admin模板中使用干坤，需要注意的是：
<div id="container"></div> 不能写在页面中，只能写在Appmain.vue 中，
路由需要配置重定向
判断改变路由（这里可写配置文件，偷懒就写死了）
AppMain.vue,需要判断显示的是哪个微应用，改变其id显示
微应用（vue）
1、在 src 目录新增 public-path.js：
2、 main.js 修改。
3、打包配置修改（vue.config.js）：
微应用（react）
1、在 src 目录新增 public-path.js：
2、设置 history 模式路由的 base：
3、 index.js 修改
4、webpack 配置
安装插件 @rescripts/cli。
根目录新增 .rescriptsrc.js：
修改 package.json：
Ⅸ 微前端 -- 干坤（一）
在 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