微前端是一种类似于微服务的架构#xff0c;它将微服务的理念应用于浏览器端#xff0c;即将单页面前端应用由单一的单体应用转变为把多个小型前端应用聚合为一体的应用。

这就意味着前端应用…初识微前端

微前端是一种类似于微服务的架构它将微服务的理念应用于浏览器端即将单页面前端应用由单一的单体应用转变为把多个小型前端应用聚合为一体的应用。

这就意味着前端应用的拆分拆分后的应用实现应用自治、单一职责、技术栈无关三大特性再进行基座模式或自由组合的模式进行聚合达到微前端的目的。

自由组组织模式指的就是系统内部子系统之间能自行按照某种规则形成一定的结构或功能。

核心拆合

在前端框架、技术、概念层出不穷且随着前端标准的演进前端已经具备更好的性能和开发效率但是随之而来的是应用的复杂度更高、涉及的团队规模更广、更高的性能要求应用复杂度已经成为阻塞业务发展的重要瓶颈。

为什么使用微前端

为了解决团队平台系统多且相互独立系统体量大且页面多开发效率低、接入成本高。

当前应用痛点

项目中的组件和功能模块会越来越多导致整个项目的打包速度变慢因为文件夹的数量会随着功能模块的增多而增多查找代码会变得越来越慢如果只改动其中一个模块的情况需要把整个项目重新打包上线所有的项目都基本只能使用同一技术框架不便引入新技术栈。

如react、vue等

微前端优势

微前端架构倾向于编写和维护更小、更简单、更容易开发的项目。

技术栈无关各项目可以使用不同的技术栈。

增量升级

支持渐进式重构先让新旧代码和谐共存再逐步转化旧代码直到整个重构完成。

独立部署

各子项目之间不存在依赖关系保持隔离。

单一职责每个子项目只做和自己相关的业务工作。

微前端现有方案

qiankun是基于single-spa的二次封装因此在谈qiankun之前我们先来简单了解一下single-spa。

single-spa的核心就是定义了一套协议。

协议包含主应用的配置信息和子应用的生命周期通过这套协议主应用可以方便的知道在什么情况下激活哪个子应用。

生命周期

single-spa中提供了registerApplication方法来注册子应用。

这个方法中接受几个特定的参数

singleSpa.registerApplication({

//注册微前端服务name:

匹配规则表示啥时候开始走这个子应用的生命周期customProps:

自定义

启动主应用在single-spa中并未实现加载子应用的方法需要使用者自己实现比如通过动态创建script或者可以使用System.import()。

⚠️SystemJS

}上面这种暴露生命周期的方式也就是single-spa中子应用对外暴露变量的方式。

使用不当会导致全局环境的污染。

因此的appName比如唯一否则会覆盖同名的子应用qiankun里面的沙箱机制就很好的解决了这种问题。

一般来说主应用注册并加载完微应用并不会立即初始化。

而是等到执行完start后。

当window.location.href匹配到url时去执行start方法后进行初始化调用子应用的bootStrap开始走对应子App的这一套生命周期。

所以single-spa还要监听url的变化然后执行子app的生命周期流程。

在上面我们了解到主应用监听路由url的切换匹配到相应的路由就根据对应路由去挂载和卸载微应用。

子应用卸载时需要在unmount方法中添加卸载逻辑在update方法中添加更新逻辑。

single-spa的挂载、更新、卸载并未提供而是需要用户自定实现。

single-spa

只起控制状态的作用它自己本身不亲自操刀的无论下载、挂载、卸载等这样也能做到更好的扩展性用户想怎么下载、挂载、卸载他们自己来决定只要你传入规范的参数即可。

single-spa为不同技术栈提供了一些逻辑抽象封装来对子应用进行包装。

比如single-spa-vue\single-spa-react等。

这些封装的模版里面对子应用进行包装然后在对应的生命周期钩子函数执行子应用挂载卸载更新等操作。

应用的加载与切换路由问题、应用入口、应用加载应用的隔离与通信js隔离、css样式隔离、应用间通信

路由问题、应用入口

两个问题但是应用的加载并未实现。

因此qiankun在此基础上封装了一个应用加载方案并给出了js隔离、css样式隔离和应用间通信三个问题的解决方案同时提供了预加载功能。

qiankun

url所以不用再自行维护子应用的资源列表了。

并且对旧有的项目作为子应用接入成本几乎为零开发体验与独立开发时保持不变相较于

single-spa

qiankun框架中子应用不需要关注qiankun框架无需引用其包只需按照标准实现导出接口即可

1.子应用集成

qiankun有两种集成微应用的方式基于路由配置、手动加载微应用

基于路由配置微应用

将微应用关联到一些url规则的方式实现当浏览器url发生变化时自动加载相应的微应用。

lifeCycles?)注册子应用

{state.microapp.unmount()})⚠️基座中展示的子应用关闭路由页面并未直接卸载子应用实例仍然占据内存并且下次打开也不是全新的。

因此我们需要在应用卸载子应用。

2.运行时沙箱

loadApp时执行createSandbox生成运行时沙箱样式沙箱和js沙箱,qiankun

框架默认开启预加载、单例模式、样式沙箱

样式沙箱包含了严格沙箱模式(默认开启)和实验性沙箱模式两种模式不可共存。

shadow

DOM可以将一个隐藏的、独立的DOM附加到一个元素上即微应用的容器。

Shadow

document.createElement(div);//3将内容放入shadowDom容器containerDom.innerHTML

appElement

appElement;//4清楚这个元素,便于后面追加shadowDOMappElement.innerHTMLlet

shadow;if

appElement.createShadowRoot();}//追加shadowDomshadow.innerHTML

innerHTML;return

document.querySelector(#shadow-dom);const

appElement

}/stylep内部文本/p/div);shadowDOMSection.appendChild(appElement);

shadow

原理将微应用中的style全部提取出来将所有的选择器进行替换。

标签来插入外联的样式但考虑在未来支持这部分场景。

现阶段仅支持style

const

element.querySelectorAll(style)

(stylesheetElement:

appName);});/*拿到样式节点中的所有样式规则然后重写样式选择器*

含有根元素选择器的情况用前缀替换掉选择器中的根元素选择器部分*

普通选择器将前缀插到第一个选择器的后面Ï*/process(styleNode:

HTMLStyleElement,

document.createTextNode(styleNode.textContent

);//

节点将样式内容添加到这个节点下this.swapNode.appendChild(textNode);const

sheet

arrayifyCSSRule(sheet?.cssRules

[]);/***

含有根元素选择器的情况用【前缀】替换掉选择器中的根元素选择器部分*

css

no-param-reassignstyleNode.textContent

css;//

cleanupthis.swapNode.removeChild(textNode);return;}......}实现步骤

1获取样式节点

4获取到textNode的根div元素为其打上data-app-nameappName的标记

stylep{color:red;}

https://www.wenjiangs.com/wiki/en-US/docs/Web/API/CSSRule

js沙箱

proxySandBox、legacySandBox、snapshotSandBox

proxySandBox

fakeWindow对象所有更改都基于fakeWindow从而保证每个ProxySandbox实例之间属性互不影响。

激活时

1被激活的沙箱数1开启沙箱运行标识sandboxRunningtrue

失活时

1被激活的沙箱数-1开启沙箱运行标识sandboxRunningfalse

设置全局变量时先判断fakeWindow上是否有该属性若无则更改window若有该值则直接修改fakeWindow。

获取全局变量时先判断该属性是否为原生属性如果是原生属性则直接从window上获取非原生属性则优先从fakeWindow上获取。

window

legacySandbox是一种单例沙箱这个模式和proxySandBox类似基于proxy实现的。

legacySandbox原理基于

对象恢复到上次即将失活时的状态遍历currentUpdatedPropsValueMap

失活时将

对象恢复为初始状态遍历addedPropsMapinSandbox和modifiedPropsOrginalMapInSandbox

关于在legacySandbox模式下获取全局属性设置全局属性。

legacySandbox为了记录在修改或者添加属性时window的变更设置了三个变量池具体看下图

设置全局变量时

1window上不存在该属性则向addedPropsMapInSandbox添加该属性

2存在该属性但modifiedPropsOriginalValueMapInSandbox中不存在该属性则记录该初始值

3记录新增和修改的属性currentUpdatedPropsValueMap直接设置原生

window

的作用是维护三个状态池分别用于子应用卸载时还原主应用的状态和子应用加载时还原子应用的状态

优缺点

缺点兼容性不如proxySandBox只能支持加载一个程序。

单例模式

snapshotSandBox快照模式

对象做浅拷贝windowSnapshot将windowSnapshot的变更存成一个

Hash

1将上一次的变更记录modifyPropsMap应用到微应用的全局window,无变更记录则跳过

2对主应用的window对象做浅拷贝用于后面还原主应用的window

当微应用umount时

1将微应用的window与快照window做Diff,Diff的结果modifyPropsMap用于下次恢复微应用环境的依据。

2根据当前的快照对象windowSnapshot还原window

举个例子说明一下

对于window和windowSnap生成diff后的对象modifyPropsMap

根据windowSnap还原window

元素中。

当用户访问子应用时浏览器会自动加载这些资源以便更快地加载子应用。

Prefetch

});//在这里配置或者如果是多个实用prefetchApps()预加载的好处可以加速微应用的打开速度。

通过在浏览器空闲时间预加载未打开的微应用资源可以减少用户等待时间提高用户体验。

从微前端的设计初衷来看我们需要尽可能少的进行应用间的通信。

使我们的微前端架构可以更加灵活可控但是由于业务需要还是会存在应用间通信的。

Actions

通信方案是通过全局状态池和观察者函数进行应用间通信比较适合业务划分清晰应用间通信较少的微前端应用场景。

qiankun

时的逻辑子应用需要先了解状态池的细节再进行通信由于状态池无法跟踪通信场景较多时容易出现状态混乱、维护困难等问题

问题汇总

子应用中给弹窗设置了样式加载到主应用后主应用中查看弹窗发现样式失效。

body

上的shadowDOM外部无法影响内部内部也无法影响外部子所以子应用中设置的全局样式会不生效。

那么另一种沙箱scoped

css添加样式后的代码也是给容器内部的元素添加样式前缀并未给外部添加。

【解决方式】

qiankun的子应用的router由于是子应用自己的路由所有的跳转均基于子应用的base因此没法直接通过

或者用

/window.location.href链接可以跳转过去但是会刷新页面用户体验并不好将主应用的路由实例通过

props

原因父子应用的域名不一样某些业务场景下cros同源策略可能会引发跨域问题

解决找运维配置nigix解决跨域问题

解决webpack中配置url-loader把图标转为base64格式

常规webpack配置

/.(png|jpe?g|gif|webp|woff2?|eot|ttf|otf)$/i,use:

[{loader:

在修改window对象之前先获取到qiankun提供的sandbox对象然后通过sandbox对象来修改window对象上的属性。

例如

const

沙箱都不是十全十美的我们只能通过各种约束来避免沙箱出现问题的可能。

例如建立团队前缀命名空间

CSS、事件、本地存储和

6localStorage、sessionStorage应用覆盖问题

localStorage、sessionStorage、cookie,

这些方法就会造成数据覆盖问题注意微应用之间数据冲突、数据覆盖问题这里改写一个

setItem

问题1start()启动时机不对在main.js中启动页面挂载的容器并未生成导致挂载容器失败。

问题2在路由页面的created中,调用start()方法首次正常显示切换路由失败因为每次切换路由相当于重新加载一次页面挂载的id虽然一致但是页面路由切换被销毁重建因此加载失败

全局注册registerMicroApps子应用改为局部注册loadMicroApp在app.vue中写挂载的容器。

判断路由是属于子路由则展示容器否则展示

8子应用生命周期导出失败测试环境无法正常加载子应用、本地和线上正常。

排查思路

最终发现问题beetle的脚本插入逻辑与乾坤的子应用读取逻辑冲突

如果两种都没有找到,则需要检查修改qiankun子应用的配置文件将微应用的

name

CSS的技术实现的。

在这种技术中每个子应用的CSS都会被添加一个独特的属性选择器这样它们就不会影响到其他应用的样式。

然而这种方法也有一些潜在的问题

CSS样式污染虽然Qiankun有自己的样式隔离机制但这个机制并不完全。

例如子应用的样式仍然可能会影响到全局的样式如body、html标签或者全局CSS类。

这是因为CSS沙箱无法阻止子应用修改全局CSS规则。

性能问题为了实现样式隔离Qiankun需要遍历并修改所有的CSS规则这在某些情况下可能会对性能产生影响。

样式覆盖问题由于Qiankun是通过为每个子应用的CSS规则添加一个独特的属性选择器来实现样式隔离的所以如果子应用中有使用了!important的样式规则可能无法被正确的隔离。

第三方库的样式隔离如果子应用使用了一些第三方库这些库的样式可能会泄露到全局环境中从而影响到其他子应用或者主应用的样式。

动态添加的样式隔离如果子应用在运行时动态添加了一些样式例如通过document.createElement(‘style’)

或document.styleSheets[0].insertRule()

总是微前端是什么呢一句话在路由变化的时候去加载对应子应用的代码并在容器内跑起来。

缩小项目打包体积解决系统上线拥挤问题用户使用无感知海盗乾派业务拆分、项目拆分拼装更灵活技术栈逐步统一

避免样式污染问题需要制定一定的规范。

如果你也想要tab切换不刷新(使用keep-alive)那需要做的工作更多主要是处理缓存防止堆内存溢出用chrome自带的performance

就目前来看基本没有什么问题

无论是那种微前端方案都会存在自己的适配用户。

而采用微前端后也并不会让系统的复杂度凭空消失而是会由之前的代码层面的设计转向了系统架构设计划分的设计挑战。

应用场景上一般微前端还是应用在B端C端应用比较少。

主要原因是移动端应用一般不会特别复杂。

当然也有一些例外工具类的C端管理项目等。

并不是所有场景都适合微前端尤其是项目规模小、数量少的不建议使用微前端也并不是所有系统的归宿应该由场景、业务发展以及价值去决定。