qiankun 微前端架构详解

什么是微前端:

微前端项目，简单来说，就是把那些可以独立开发、独立测试、独立部署的子项目，统一集成到一个主项目之下。对用户而言，最终看到的仍然是一个完整的产品；而背后的加载、拼接与渲染过程，则是完全透明、无感的。

微前端不仅能够兼容不同的开发环境，还可以兼容多种技术栈，从而在更大程度上实现应用解耦，提升项目的可维护性与扩展性。

spa网页

[image.png]

微前端网页

[image.png]

为什么需要微前端：

1. 当前应用规模较大，需要拆分为多个独立模块进行开发
2. 多个业务团队协作，要求能够并行开发同一个项目
3. 中台类、平台类的聚合型项目需要统一管理多个子系统
4. 同一个主应用下需要兼容不同架构的项目，例如 Vue、React、Angular 等

微前端的特点：

1. 几乎任何 JS 框架都可以兼容接入，使用门槛较低，接入方式简单。
2. 解决了 iframe 在主页面刷新后，子页面路由状态难以控制的问题。
3. 能够更好地处理主应用与子应用之间的通信与数据交互问题。

为什么不是iframe

1. iframe 通过 src 嵌入，当子页面发生路由跳转后，主页面再次刷新时，往往会回到初始位置。
2. 内嵌页与主页面的通信存在限制，通过 postMessage 或 url 传参时，url 传参本身也不够安全。
3. 内嵌页之间的通信与状态共享也比较困难。
4. DOM 结构无法共享，如果需要在子页面弹出遮罩层或 loading，主页面很难做出联动响应。

qiankun微前端，微前端的落地实现

qiankun的特点：

1. 基于 single-spa 封装，提供了更加开箱即用的 API。import { registerMicroApps, start } from 'qiankun';registerMicroApps( { name: 'vueApp', // app的name，需要与微应用打包对应 entry: '//localhost:8081', // 微应用的端口，同时微应用需要启动 container: '#app2, activeRule: '/mydemo', // 如果是 hash模式 需要 #/mydemo });

// 启动 qiankun

调用 start(); 之后，如果主应用的路由地址是 http://localhost:8080，那么当访问 http://localhost:8080/mydemo 时，对应的微应用就会被拉起并渲染。

1. 技术栈无关，任意技术栈的应用均可 使用/接入，不论是 React、Vue、Angular、JQuery 还是其他框架。
2. HTML Entry 接入方式，让微应用接入体验像使用 iframe 一样简单。
3. 样式隔离，确保不同微应用之间的样式互不干扰。
4. JS 沙箱机制，保证微应用之间的全局变量和事件不会冲突。
5. 资源预加载，会在浏览器空闲时间提前加载未打开的微应用资源，从而提升打开速度。

配置参考https://qiankun.umijs.org/

配置项细节和踩坑

微应用需要启动

微应用需要独立启动，并且配置的端口要与主应用注册时填写的微应用端口保持一致。

主应用

[yi2phmv72c.png]

entry端口需要与微应用一致，同时微应用需要运行

微应用的路由以及路由跳转

假设 是两个 vue的应用

主应用

[image.png]

错误情况：当子页面路由没有添加前缀(activeRule)

{
path: '/',
name: 'Home',
component: Home
}

显示效果

[image.png]

正确情况

{
path: '/subvue/',
name: 'Home',
component: Home
}

path为 微应用的激活规则

[image.png]

正确的路由跳转

[image.png]

子应用的跳转需要加入前缀！！

history模式下设置路由更方便

微应用渲染时 在base上设置微应用的范围

router = new VueRouter({
    base: window.__POWERED_BY_QIANKUN__ ? '/subvue/' : '/',
    mode: 'history',
    routes
  })

此时，所有的子路由内跳转都会自动加上 /subvue/，因此 routers 内就不需要手动再添加前缀。

[image.png]

hash模式下，打包发布正式需要处理的更少！！

[image.png]