CN113821194A

CN113821194A - 一种微前端系统

Info

Publication number: CN113821194A
Application number: CN202111063475.1A
Authority: CN
Inventors: 张矗; 高翔
Original assignee: Shanghai Yunzhou Information Technology Co ltd
Current assignee: Shanghai Yunzhou Information Technology Co ltd
Priority date: 2021-09-10
Filing date: 2021-09-10
Publication date: 2021-12-21

Abstract

本申请的目的是提供一种微前端系统。所述微前端系统包括若干个主应用，每个所述主应用包括若干个子应用。与现有技术相比，本申请在开发阶段，每个所述子应用由多webpack进程并发构建，每个所述子应用采用不同的端口启动，所述主应用直接加载编译后的代码，从而极大地提高所述微前端系统的开发构建速度。进一步地，所述微前端系统的子应用对外暴露生命周期函数，供对应的主应用调用，从而方便主应用加卸载子应用，提高系统效率。进一步地，本申请通过read‑on‑write方式代理所述主应用的window对象并传递给所述子应用，在哈希化时为每个所述子应用添加特殊前缀，从而有效地避免内存冲突问题。

Description

一种微前端系统

技术领域

本申请涉及信息技术领域，尤其涉及一种微前端技术。

背景技术

随着计算机技术的蓬勃发展，各个网站的用户交互界面愈加复杂，单个站点的代码行数动辄几十万行，甚至百万行。为了保证编译速度和开发效率，微前端方案应运而生。具体地，微前端是一种设计思想，在实践上可以采用MPA、IFrame、Single-SPA等多种方式。微前端解决的是超大型项目的开发问题，负责开发单个子应用的团队规模可以很小，甚至可以是单人。现在的前端技术在开发阶段一般采用ES6或者TS，经过webpack构建后在浏览器端运行，开发采用的代码和编译后的代码差异非常大。如果采用单一webpack进行构建，当代码量超过10万行时，构建速度会显著变慢，严重影响开发速度。

发明内容

本申请的一个目的是提供一种微前端系统。

根据本申请的一个方面，提供了一种微前端系统，其中，所述系统包括若干个主应用，每个所述主应用包括若干个子应用；

在开发阶段，每个所述子应用由多webpack进程并发构建，每个所述子应用采用不同的端口启动，所述主应用直接加载编译后的代码。

进一步地，每个所述主应用中的若干个所述子应用共用一个DOM节点。

进一步地，在主路由中根据预设规则加载所述子应用，将路由事件透传给所述子应用，让所述子应用选择需要加载的子页面。

进一步地，所述子应用对外暴露生命周期函数，供所述主应用调用。

进一步地，所述生命周期函数包括：bootstrap函数，用于构建子应用的容器；mount函数，用于渲染子应用；unmount函数，用于清理子应用。

进一步地，通过read-on-write方式代理所述主应用的window对象并传递给所述子应用。

进一步地，在哈希化时，为每个所述子应用添加特殊前缀。

进一步地，在所述主应用中引入公共库，并在所述子应用的webpack配置中迁出所述公共库的代码。

进一步地，所述子应用之间通过消息总线进行通信。

进一步地，所述主应用包含一级导航及公共模块，所述子应用包含二级导航及自身独有的业务逻辑。

本申请提供的方案中，所述微前端系统包括若干个主应用，每个所述主应用包括若干个子应用。与现有技术相比，本申请在开发阶段，每个所述子应用由多webpack进程并发构建，每个所述子应用采用不同的端口启动，所述主应用直接加载编译后的代码，从而极大地提高所述微前端系统的开发构建速度。进一步地，所述微前端系统的子应用对外暴露生命周期函数，供对应的主应用调用，从而方便主应用加卸载子应用，提高系统效率。进一步地，本申请通过read-on-write方式代理所述主应用的window对象并传递给所述子应用，在哈希化时为每个所述子应用添加特殊前缀，从而有效地避免内存冲突问题。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其他特征、目的和优点将会变得更明显：

图1是根据本申请实施例的一种微前端系统结构示意图；

图2是根据本申请实施例的一种应用异步加载示意图；

图3是根据本申请实施例的一种基于Single-SPA的路由交互示意图；

图4是根据本申请实施例的一种微前端与后端通信示意图。

附图中相同或相似的附图标记代表相同或相似的部件。

具体实施方式

下面结合附图对本申请作进一步详细描述。

在本申请一个典型的配置中，终端、服务网络的设备和可信方均包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体，可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的装置或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。

本申请实施例提供了一种微前端系统。在实际场景中，实现该微前端系统的设备可以是用户设备、网络设备或者用户设备与网络设备通过网络相集成所构成的设备。其中，所述用户设备包括但不限于智能手机、平板电脑、个人计算机(PC)等终端设备，所述网络设备包括但不限于网络主机、单个网络服务器、多个网络服务器集或基于云计算的计算机集合等实现。在此，云由基于云计算(Cloud Computing)的大量主机或网络服务器构成，其中，云计算是分布式计算的一种，由一群松散耦合的计算机集组成的一个虚拟计算机。

图1是根据本申请实施例的一种微前端系统结构示意图。所述微前端系统包括若干个主应用，每个所述主应用包括若干个子应用。

例如，基于微前端方案，可以将百万行代码级别的主应用拆分为多个子应用，每个子应用的代码行数不超过2万行，并能通过主应用进行调度，从而保证编译速度和开发效率。

所述微前端系统有如下一些特点：所有的应用都通过webpack编译，编译结果可以作为npm分发；主应用通过history API根据不同的路由条件来加载子应用；子应用对外暴露mount、unmount方法，供主应用调度；主应用和子应用可以通过yarn workspace做开发时依赖共享；子应用通过配置webpack external可以共享主应用的依赖，比如react、react-dom；所有的应用可以通过vscode workspace来统一管理、开发，也可以独立开发；应用间的公共函数和组件，以额外package的方式分发，通过rollup进行编译；主应用与子应用，以及应用间的通信通过eventBus总线；子应用不限技术栈，可以采用react、vue、angular等技术栈；子应用和主应用之间的相同变量，通过基于Proxy的沙箱进行隔离；子应用和主应用的相同样式，通过css module来hash化区分；为了保证CI/CD，主应用和子应用公用一个repo，采用巨石项目结构；子应用支持独立开发、编译、部署、测试，可插拔；单个子应用加载失败，不会影响其他子应用。

与现有技术相比，本申请实施例在开发阶段，每个所述子应用由多webpack进程并发构建，每个所述子应用采用不同的端口启动，所述主应用直接加载编译后的代码。

例如，本申请实施例可以实现应用异步加载，在开发阶段每个子应用可以多webpack进程并发构建，每个子应用采用不同的端口启动，而主应用直接加载编译后的代码，因此开发A应用时无须编译B应用。经过实践验证，应用本申请实施例之后，50万行代码的开发构建速度由原来的6分钟降低为20秒。

例如，如图2所示，每个应用其实都是html、js、css以及assets(如icon、image、video等)的集合，在iframe中，开发人员只需要制定一个url和一个iframe容器，浏览器会自动加载指定的页面去填充iframe。参考iframe的实现，也可以通过fetch去获取指定子应用的html content，然后分析html拿到root节点插入到主应用的子应用root节点，分析内外联的css插入到主应用中，最后分析内外联的JS并通过eval执行，从而可以实现与iframe相同的效果。

在一些实施例中，如图2所示，所述主应用包含一级导航及公共模块，所述子应用包含二级导航及自身独有的业务逻辑。

在一些实施例中，每个所述主应用中的若干个所述子应用共用一个DOM节点。

例如，微前端在实践上可以采用MPA、IFrame、Single-SPA等多种方式，本申请实施例主要采用Single-SPA方式。基于Single-SPA的微前端系统可以让多个子应用共用一个主DOM节点，在应用切换时无须重新加载整个页面，页面的快速响应可以带来更好的用户体验。

在一些实施例中，在主路由中根据预设规则加载所述子应用，将路由事件透传给所述子应用，让所述子应用选择需要加载的子页面。

例如，为了让不同的库(如React、VUE等)协同工作，如访问/app1加载React子应用，访问/app2加载VUE子应用；在SPA中，无论是React还是VUE都会监听history事件，根据不同的路径去加载页面。本申请实施例主要采用基于Single-SPA的微前端系统，Single-SPA的核心是在最外层引入路由守护，拦截window.history.popState事件，即先在主路由中根据预先设置的规则加载子应用，再把路由事件透传给子应用，让子应用自己决定加载哪个子页面。从而解决路由监听冲突的问题，让多个子应用能在同一个页面运行。以Single-SPA结合React-Router为例，具体交互方式如图3所示。

在一些实施例中，所述子应用对外暴露生命周期函数，供所述主应用调用。

例如，所有的子应用被对应的主应用托管，需要对外提供一系列钩子函数方便主应用加卸载。在此，所述钩子函数可以简单分为三个生命周期函数：bootstrap、mount、unmount。

在一些实施例中，所述生命周期函数包括：bootstrap函数，用于构建子应用的容器；mount函数，用于渲染子应用；unmount函数，用于清理子应用。

例如，bootstrap、mount、unmount三个函数是生命周期函数，也是异步函数。子应用对外暴露bootstrap、mount、unmount三个函数，供主应用调用。其中，bootstrap函数负责构建子应用的容器(container)，只会执行一次；mount函数负责子应用渲染，每次匹配路由都会执行；unmount函数负责清理子应用。具体的示例代码如下：

在一些实施例中，通过read-on-write方式代理所述主应用的window对象并传递给所述子应用。

例如，子应用的DOM、CSS、JS等会被插入到主应用中运行。假设主应用中定义了一个全局变量如CurrentUser，如果子应用也定义相同的变量CurrentUser，就会引发冲突。同理，CSS也会遇到这样的冲突问题，浏览器不同的tab页、iframe等都是内存隔离的，这种机制被称为沙箱(如图4所示)。本申请实施例主要采用基于Single-SPA的微前端系统，可以带来极致的用户体验，同时也必须解决内存冲突问题，避免出现页面加载错乱、程序报错等情况。

为解决内存冲突问题，本申请实施例针对JS的隔离，采用ES6中的Proxy特性，以read on write的方式代理主应用的window对象并传递给子应用，那么子应用接受的是代理过的window对象，无论如何改写都不会影响主应用的window对象。具体的示例代码如下：

在一些实施例中，在哈希化时，为每个所述子应用添加特殊前缀。

例如，沙箱可以解决JS的全局变量冲突；针对CSS的冲突问题，可以采用cssmodule hash化类名的方式，在哈希(hash)化时，每个子应用会添加特殊前缀，以避免生成的哈希(hash)名相同。

在一些实施例中，在所述主应用中引入公共库，并在所述子应用的webpack配置中迁出所述公共库的代码。

例如，微前端可以加载不同的架构。在实际场景中，微前端可能需要采用统一的技术栈(如React)，不同的子应用可能会采用相同的第三方库(如React、React-Router、Antd等)；为了避免公共依赖库重复打包，减少最终构建包的大小，本申请实施例采用webpack提供的external方案，在主应用中引入所有的公共库，并在子应用的webpack配置中用external迁出公共库的代码。具体的示例代码如下：

//主应用配置

import*as g_lodash from'lodash'

import*as g_react from'react'

import*as g_react_dom from'react-dom'

import*as g_moment from'moment'

import*as g_antd from'antd'

import*as g_bizcharts from'bizcharts'

import*as g_react_router from'react-router'

...

window.g_lodash＝g_lodash

window.g_react＝g_react

window.g_react_dom＝g_react_dom

window.g_moment＝g_moment.default

window.g_antd＝g_antd

window.g_bizcharts＝g_bizcharts

window.g_react_router＝g_react_router

...

//webpack配置

config.externals＝{

lodash:'g_lodash',

react:'g_react',

'react-dom':'g_react_dom',

moment:'g_moment',

antd:'g_antd',

bizcharts:'g_bizcharts',

'react-router':'g_react_router'

...

}

在一些实施例中，所述子应用之间通过消息总线进行通信。

例如，应用间的通信可以分为主应用与子应用间的通信和子应用之间的通信。由于主应用与子应用共享内存空间，本申请实施例用一个简单的消息总线就可以实现应用间的通信。具体的示例代码如下：

综上所述，所述微前端系统包括若干个主应用，每个所述主应用包括若干个子应用。与现有技术相比，本申请实施例在开发阶段，每个所述子应用由多webpack进程并发构建，每个所述子应用采用不同的端口启动，所述主应用直接加载编译后的代码，从而极大地提高所述微前端系统的开发构建速度。

另外，本申请的一部分可被应用为计算机程序产品，例如计算机程序指令，当其被计算机执行时，通过该计算机的操作，可以调用或提供根据本申请的方法和/或技术方案。而调用本申请的方法的程序指令，可能被存储在固定的或可移动的记录介质中，和/或通过广播或其他信号承载媒体中的数据流而被传输，和/或被存储在根据程序指令运行的计算机设备的工作存储器中。在此，本申请的一些实施例提供了一种计算设备，该设备包括用于存储计算机程序指令的存储器和用于执行计算机程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发所述设备执行前述本申请的多个实施例的方法和/或技术方案。

此外，本申请的一些实施例还提供了一种计算机可读介质，其上存储有计算机程序指令，所述计算机可读指令可被处理器执行以实现前述本申请的多个实施例的方法和/或技术方案。

需要注意的是，本申请可在软件和/或软件与硬件的组合体中被实施，例如，可采用专用集成电路(ASIC)、通用目的计算机或任何其他类似硬件设备来实现。在一些实施例中，本申请的软件程序可以通过处理器执行以实现上文所述步骤或功能。同样地，本申请的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中，例如，RAM存储器，磁或光驱动器或软磁盘及类似设备。另外，本申请的一些步骤或功能可采用硬件来实现，例如，作为与处理器配合从而执行各个步骤或功能的电路。

对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其他的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。装置权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。

Claims

1.一种微前端系统，其中，所述系统包括若干个主应用，每个所述主应用包括若干个子应用；

2.根据权利要求1所述的系统，其中，每个所述主应用中的若干个所述子应用共用一个DOM节点。

3.根据权利要求2所述的系统，其中，在主路由中根据预设规则加载所述子应用，将路由事件透传给所述子应用，让所述子应用选择需要加载的子页面。

4.根据权利要求1所述的系统，其中，所述子应用对外暴露生命周期函数，供所述主应用调用。

5.根据权利要求4所述的系统，其中，所述生命周期函数包括：

bootstrap函数，用于构建子应用的容器；

mount函数，用于渲染子应用；

unmount函数，用于清理子应用。

6.根据权利要求1至5中任一项所述的系统，其中，通过read-on-write方式代理所述主应用的window对象并传递给所述子应用。

7.根据权利要求1至6中任一项所述的系统，其中，在哈希化时，为每个所述子应用添加特殊前缀。

8.根据权利要求1至7中任一项所述的系统，其中，在所述主应用中引入公共库，并在所述子应用的webpack配置中迁出所述公共库的代码。

9.根据权利要求1至8中任一项所述的系统，其中，所述子应用之间通过消息总线进行通信。

10.根据权利要求1至9中任一项所述的系统，其中，所述主应用包含一级导航及公共模块，所述子应用包含二级导航及自身独有的业务逻辑。