基于Qiankun的微前端研究与应用
摘 要：在传统控制台类软件开发环境下，随着需求数量的增加，单个项目的规模不断变大，最后形成的巨无霸应用难以维护和迭代。同时，不同项目间难以避免的出现了重复的能力模块，但由于技术架构不同，无法集成到新开发的系统中。微前端概念的提出就是为了解决这些问题。本文记录了一次管理台的微前端化实践, 给出了基于Vue和Qiankun下的微前端方案，解决了微应用注册和加载、应用间通信、路由跳转、权限控制及样式控制等技术难点。
关键词：微前端；Qiankun框架；Vue；路由控制；
Application ofMicroFront-end based on Qiankun
CHEN Yong-tai, GUO Bin, WANG Zhi-yong
Abstract: In the traditional console software development environment, with the increase of the number of requirements, the scale of a single project becomes larger and larger, and the final giant application is difficult to maintain and iterate. On the other hand, it is in
nginx部署前端项目evitable that there will be repeated capability modules among different projects. However, they cannot be integrated into the newly developed system due to the different technical architectures. The concept of micro front-end is proposed to solve these problems. This paper records a micro-front-end practice of management console. A micro front-end scheme based on Vue and Qiankun is presented, which solves the technical difficulties of micro application registration and loading, inter-application communication, route jumping, permission control and style control.
Keywords: Micro front-end; Qiankun; Vue; VueRouter
一、引言
微前端旨在将一个巨石前端应用分解为多个独立的较小规模子应用，配置的形式动态组合为一个具有统一入口的应用（如图1所示）。
图1由多个子应用组成巨石应用
二、主流微前端解决方案
开发成本和用户体验度是微前端的两个关键。有别于传统的一体式大应用，微前端将项目分为多个应用进行开发。在多个应用进行组合时可能会出现JS冲突或样式冲突。此外，用户在实际使用时跳转不同应用可能会出现白屏闪烁等一些体验问题。因此微前端的解决方案需要同时考虑开发者及使用者两个维度。
目前，主流微前端解决方案有以下几种：（1）iframe（2）Nginx导航（3）Single-spa框架。
2.1iframe
iframe是浏览器提供的原生硬隔离方案，能够完美解决样式隔离、JS隔离等问题。但iframe的隔离性无法被突破，导致应用间上下文无法被共享。最终导致刷新出错、无法使用统一的标签导航等问题，用户的最终体验并不好。
2.2Nginx导航
Nginx通过路由转发，将不同的业务分发到不同的独立前端应用上。这种实现方式下，用户在应用间跳转需要刷新页面并会出现空白界面。
2.3Single-spa
Single-spa 框架实现了由多个微应用动态组成整体管理控制台的架构模式。微应用可以独立开发、测试、部署且与技术栈无关。更为关键的是，用户可在无感的情况下使用各个微应用。
除了上述方案外，也存在部分利用Webpack5的新特性Module Federation或基于Web Components和ES Module实现微前端的方案，但这些新特性都存在兼容性问题，只能作为面向未来的微前端手段。
三、基于Qiankun的微前端设计与实现
Qiankun是目前主流的微前端解决方案。Qiankun在Single-spa的基础上封装了一些开箱即用的API，开发者通过较为简单的配置及较少的代码修改即可将原有项目改造为微前端的模式。
在Qiankun中，巨石应用被拆分为一个主应用（基座）和多个子应用（能力模块）。这些应用可以部署在不同的IP及端口上，用户在使用时可通过主应用无感进入各个子应用。
2
3
3.1微应用注册与加载
为了使主应用能在正确的时机加载正确的子应用，需要在部署子应用后将子应用的访问位置及激活规则注册在主应用上。
部署名为DEMO和FORM的两个子应用后，在主应用中使用Qiankun提供的方法registerMicroApps()进行子应用注册。注册信息包括子应用的名称、运行地址及激活规则（图2所示）。
图2部署多个子应用并注册到主应用上
子应用信息注册完成后，Qiankun会监听浏览器url的变化。url变动后会触发 Qiankun 的匹配判断，当url符合子应用激活规则时，Qiankun将会加载该子应用（图3所示）。
图3 主应用加载微应用
3.2路由控制
Qiankun通过url匹配子应用，而Vue、React等框架使用路由匹配组件。路由实际上是截取了url的一部分，所以两者都是根据当前url决定渲染内容。
url变化时会触发路由解析和Qiankun判断两种匹配。若Qiankun判断当前url属于子应用，则会加载子应用，子应用的路由组件会再次解析当前的url并渲染对应组件（图4所示）。为了保证匹配结果正确，需要分别对主子应用的路由进行特殊处理。
图4 路由解析过程
3.2.1子应用路由处理
如图4，只有满足Qiankun匹配的路由才会触发子应用的加载。为使子应用任意路由都可以触发子应用的加载，子应用所有路由都应该符合Qiankun的匹配规则。以图2为例，子应用FORM的Qiankun匹配规则为：url以“/FORM”开头，故FORM子应用中所有的路由都需要以“/FORM”作为开头，例如FORM的首页路由可设置为“/FORM/home”。
3.2.2主应用路由处理
主应用最终展示的页面由两部分组成：主应用匹配到的组件及子应用匹配到的组件（图5所示）。由于主子应用的路由无关，子应用的路由在主应用中并无定义也无法正常解析。为了使所有子应用的路由都可以在主应用中正常匹配，需要额外加入通配路由。以图2为例，
主应用需要加入“/DEMO/*”及“/FORM/*”两条通配路由。若最终只想展示子应用的内容，可以将通配路由的组件设置为一个空白组件。
图5主应用渲染过程
3.3应用间通信
微前端应用实际上是由多个独立微应用组合形成，一个不可避免的问题是各个微应用间的通信与数据共享。相较于难以通信的iframe，Qiankun可以较为简单的实现应用间通信。根据类型可将微应用间的通信分为两种：（1）主子应用通信（2）子应用间通信。
3.3.1主子应用通信
以Vue框架为例，主子应用间的通信可通过传递主应用Vuex的store来实现。如下图6所示，主应用使用Qiankun框架注册子应用时传入自己的store实例，将其共享给所有子应用。
子应用在入口文件中处使用Vue.observable将主应用传递的store设置为可响应式对象并挂载在自己的Vue实例上，形成类似Vuex的效果。当主应用store中数据变化时，子应用可以监听到变化。反之，当子应用主动修改主应用store中的数据时，主应用也可以监听到变化。
图6共享Vuex实现主子应用通信
3.3.2子应用间通信
子应用间的通信可通过将主应用作为媒介，通过共享主应用Vuex的store来实现。多个子应用都收到了主应用的store实例（图7所示）。当子应用1修改了主应用store中的数据后，主应用及拥有主应用store实例的子应用2会立即收到消息。
图7子应用间通过主应用的Vuex通信
3.4样式隔离
Qiankun通过将子应用的DOM插入主应用容器DOM下实现微前端页面的展现。新插入的子应用DOM将会影响原有DOM中的同名元素，导致页面显示异常。为此，微前端需要进行样式隔离处理。样式隔离也可以分为两种情况：（1）子应用间样式隔离（2）主、子应用样式隔离
Qiankun提供了样式沙箱。开启沙箱可以确保单实例子应用之间的样式隔离，但无法保证主应用与子应用间的样式隔离。通过设置{ strictStyleIsolation: true }可以开启Qiankun的严格沙箱隔离模式。这是一个实验性特性，该模式下Qiankun会为每个子应用的容器包裹上一个shadowDom节点，从而确保子应用的样式不会对全局造成影响。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。