一种微前端架构及资源处理方法

技术领域

本发明涉及微前端技术领域，尤其是涉及一种微前端架构及资源处理方法。

背景技术

随着网络速度、计算机硬件水平的提升和Web标准的演进，前端新的框架架构、技术、概念层出不穷。目前，前端应用已经具备更好的性能、更快的开发效率。但随着而来的是应用的复杂程度更高、涉及的团队规模更广、更高的性能要求，应用复杂度已经成为阻塞业务发展的重要瓶颈；尽管随着Web标准的演进，前端工程化也在不断演变，从模块化到组件化在到现在的工程化，但在面对跨团队大规模开发、跨团队企业级应用协作，现有的分治设计模式仍然显得有心无力；急需一种架构思想来解决现有研发模式，因此，借助于后端微服务架构思想的“微前端”一词逐渐被提起以及被广泛的研究与应用在前端项目中，逐渐形成的现在微前端框架，这种架构思想技术也就应运而生了。

“微前端”是一种类似于微服务的架构，是一种由独立运行的多个前端应用项目组成整体的架构，将前端应用分解成一些更小、更简单的能够独立开发、测试、部署的应用，方便统一的管理，更好的代码复用，基础库复用以及相互之间的通信功能，具备局部更新，提前预加载子项目应用信息，提高用户体验，但在使用时仍然是表现为内聚的单个产品等优点。

然而，现有的为微前端架构在应用过程中存在以下技术问题：

在加载子应用时主应用文件与子应用文件之间、两个子应用之间可能存在相互依赖关系，导致子应用之间融合出现错误，使得项目前端开发周期长、进度缓慢、效率不理想。

发明内容

有鉴于此，本发明的目的在于提供一种微前端架构及资源处理方法。

第一方面，本发明实施例提供了一种微前端架构，所述微前端架构包括：

主加载器，用于加载主应用；

静态资源加载器，与所述主加载器连接；所述静态资源加载器用于将所述主应用下的至少一个子应用的静态资源信息储存于对应的子条目静态容器内；

事件监听器，与所述主加载器连接；所述事件监听器用于将所述子应用的子条目订阅监听事件储存与对应的子条目通信事件容器内；

子条目容器，与所述主加载器连接，用于存储所述子应用的子条目信息；

渲染加载器，用于加载所述子应用对应的所述子条目信息，并将所述子应用对应的所述静态资源信息、所述子条目信息以及所述子条目订阅监听事件组合并渲染；

渲染生成器，用于根据渲染加载器渲染得到的信息生成所述子应用对应的子应用页面；所述渲染生成器还用于根据所述子应用的渲染入口标签，将所述子应用页面传输至渲染入口，以展示所述子应用对应的所述子应用页面。

结合第一方面，所述子条目容器包括：

单页面子条目容器，有多个，所述单页面子条目容器用于储存单页面的所述子应用的子条目信息；

多页面子条目容器，有多个，所述多页面子条目容器用于储存多页面的所述子应用的子条目信息。

结合第一方面，所述渲染生成器还与API连接，用于接收所述API发送的应用信息，所述应用信息至少包括所述主应用以及各个所述子应用对应的生命周期钩子、数据通信函数及路由跳转函数。

第二方面，本申请提供一种资源处理方法，所述方法应用于上述的微前端架构；所述方法包括：

接收微前端应用的主应用加载请求；所述主应用加载请求中包括主应用的入口文件和配置信息；

主加载器初始化所述入口文件，根据所述配置信息加载所述主应用；

接收微前端应用的子应用加载请求；

获取所述配置信息中所述主应用对应的至少一个子应用信息；所述子应用信息包括所述子应用的加载方式；

针对每个所述子应用，根据所述子应用的加载方式加载所述子应用；

对所述子应用渲染后显示于所述子应用的显示页面。

结合第二方面，所述针对每个所述子应用，根据所述子应用的加载方式加载所述子应用的步骤之后，还包括：

获取所述子应用对应的静态资源信息、事件监听函数和子条目信息；

所述静态资源加载器将所述静态资源信息储存于对应的子条目静态容器中，同时，所述事件监听器将所述事件监听函数储存于对应的子条目通信事件容器中，同时，将所述子条目信息存储于对应的子条目容器；

建立所述静态资源信息与所述事件监听函数之间的第一映射关系；

将所述子条目信息与所述第一映射关系关联，得到所述子条目信息、所述静态资源信息和所述事件监听函数一一对应的第二映射关系。

结合第二方面，所述主应用提供页面标签列表，所述页面标签列表中储存有所述子应用的配置信息，所述配置信息还包括所述子应用的名称、地址；所述加载方式为页面模板标签中加载；

所述根据所述子应用的加载方式加载所述子应用的步骤，包括：

获取所述主应用的页面标签；

根据所述页面标签加载所述子应用。

结合第二方面，所述加载方式为js动态加载；

所述根据所述子应用的加载方式加载所述子应用的步骤，包括：

获取所述子应用的属性信息；所述属性信息至少包括：css与js隔离级别；

根据所述属性信息，通过loadEntry方法加载所述子应用。

结合第二方面，所述子条目容器包括多个单页面子条目容器和多个多页面子条目容器；

将所述子条目信息存储于对应的子条目容器的步骤，包括：

判断所述子应用是否为单页面子应用；

若是，将所述子应用对应的子条目信息存储于对应的所述单页面条目容器；

若否，将所述子应用对应的子条目信息存储于对应的所述多页面条目容器。

结合第二方面，所述静态资源加载器将所述静态资源信息储存于对应的子条目静态容器中的步骤，还包括：

将所述静态资源信息的地址信息映射至所述子条目静态容器中对应的指定沙箱区域；

根据hash算法，对所述静态资源信息添加对应的唯一命名并储存。

结合第二方面，所述渲染生成器对所述子应用渲染后显示于所述子应用的显示页面的步骤，包括：

所述渲染生成器根据所述第二映射关系将所述子条目信息、所述静态资源信息和所述事件监听函数，以webComponent方式渲染生成所述子应用对应的子应用页面；

获取所述子应用对应的渲染入口标签；

根据所述渲染入口标签，将所述子应用页面传输至所述渲染入口标签对应的渲染入口，以展示所述子应用页面。

本发明实施例带来了以下有益效果：本申请提供的微前端架构及资源处理方法，所述微前端架构包括主加载器，用于加载主应用；静态资源加载器，与所述主加载连接；所述静态资源加载器用于将所述主应用下的至少一个子应用的静态资源信息储存于对应的子条目静态容器内；事件监听器，与所述主加载器连接；所述事件监听器用于将所述子应用的子条目订阅监听事件储存与对应的子条目通信事件容器内；子条目容器，与所述主加载器连接，包括多个用于存储所述子应用的子条目信息的子条目储存空间；渲染加载器，用于加载所述子应用对应的所述子条目信息，并将所述子应用对应的所述静态资源信息、所述子条目信息以及所述子条目订阅监听事件组合并渲染；渲染生成器，用于根据渲染加载器渲染得到的信息生成所述子应用对应的子应用页面；所述渲染生成器还用于根据所述子应用的渲染入口标签，将所述子应用页面传输至渲染入口，以展示所述子应用对应的所述子应用页面。

本申请提供的微前端架构可对各个部件进行独立开发，通过整合可以提升前端代码复用功能以及功能模块复用，对于每个子应用，将子应用对应的静态资源信息、子条目信息和子条目监听事件单独存放，不易出现混乱，从而提高了项目开发效率、减小了项目开发难度和成本。

本发明的其他特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。

为使本发明的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本发明具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施方式，对于本领域技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的微前端架构示意图；

图2为本发明实施例提供的资源处理方法流程图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合附图对本发明的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

为了便于对本实施例进行理解，下面先对本申请设计的技术用语进行简单介绍。

微前端是一种多个团队通过独立发布功能的方式来共同构建现代web应用的技术手段及方法策略。微前端借鉴了微服务器的架构理念，将一个庞大的前端应用拆分为多个独立灵活的小应用，每个应用都可以独立开发，独立运行、独立部署，再将这些小型应用联合为一个完整的应用。微前端即可以将项目融合为一，又可以减少项目之间的耦合，提升项目扩展性，相比一整块的前端仓库，微前端架构下的前端仓库倾向于更小更灵活。

在介绍了本申请涉及的技术用语后，接下来，对本申请实施例的应用场景和设计思想进行简单介绍。

现有的为微前端架构在应用过程中存在以下技术问题：

在加载子应用时主应用文件与子应用文件之间、两个子应用之间可能存在相互依赖关系，由于信息存放于同一位置、难以区分，使得项目前端开发过程中信息提取时间长、易出现混乱，导致开发周期长、进度缓慢、效率不理想。

基于此本申请实施例提供一种微前端架构及资源处理方法。

实施例1

本申请提供一种微前端架构，微前端架构包括：主加载器、静态资源加载器、事件监听器、子条目容器和渲染生成器。

主加载器用于加载主应用。

静态资源加载器与主加载器连接；静态资源加载器用于将主应用下的至少一个子应用的静态资源信息储存于对应的子条目静态容器内。

事件监听器与主加载器连接；事件监听器用于将子应用的子条目订阅监听事件储存与对应的子条目通信事件容器内。

子条目容器与主加载器连接，用于存放子应用对应的子条目信息。

渲染加载器，用于加载子应用对应的子条目信息，并将子应用对应的静态资源信息、子条目信息以及子条目订阅监听事件组合并渲染。

渲染生成器，用于根据渲染加载器渲染得到的信息生成子应用对应的子应用页面；渲染生成器还用于根据子应用的渲染入口标签，将子应用页面传输至渲染入口，以展示子应用对应的子应用页面。

本申请提供的微前端架构可对各个部件进行独立开发，通过整合可以提升前端代码复用功能以及功能模块复用，对于每个子应用，将子应用对应的静态资源信息、子条目信息和子条目监听事件单独存放，避免出现混乱。这样，可以减小了项目开发难度和成本、提高项目开发效率。

结合第一方面，子条目容器包括：多个单页面子条目容器和多页面子条目容器。

单页面子条目容器用于储存单页面的子应用的子条目信息。

多页面子条目容器用于储存多页面的子应用的子条目信息。

这样，将单页面的子应用的子条目信息和多页面的子应用的子条目信息区分存储，有利于查找、调取，不易出现混乱。

结合第一方面，渲染生成器还与API连接，用于接收API发送的应用信息，应用信息至少包括主应用以及各个子应用对应的生命周期钩子、数据通信函数及路由跳转函数。

在实际应用中，该应用信息还可以包括其他信息，如子应用对应的属性函数(例如，preload、keepAlive、disableScopecss、shadowDOM、disableSandbox等)，还可以包括数据通信函数(addDataListener、clearDataListener等)、资源加载之前(beforeMount)、资源加载之后(beforeMounted)、资源更新前(beforeUpdate)、资源更新后(beforeUpdated)、资源销毁(beforeDestory、destoryed)、子应用加载错误(error)等)。

第二方面，本申请提供一种资源处理方法应用于上述的微前端架构；结合图1所示，该方法包括：

S110，接收微前端应用的主应用加载请求；主应用加载请求中包括主应用的入口文件和配置信息。

S120，主加载器初始化入口文件，根据配置信息加载主应用；

S130，接收微前端应用的子应用加载请求。

S140，获取配置信息中主应用对应的至少一个子应用信息；子应用信息包括子应用的加载方式。

S150，针对每个子应用，根据子应用的加载方式加载子应用。

S160，对子应用渲染后渲染显示于子应用的显示页面。

在本实施例中，结合图2所示，在加载主应用后响应于微前端应用的子应用加载请求，根据子应用的加载方式加载子应用，之后通过渲染生成器进行渲染，以生成子应用对应的子应用页面。

结合第二方面，主应用提供页面标签列表，页面标签列表中储存有子应用的配置信息，配置信息还包括子应用的名称、地址；加载方式为页面模板标签中加载。此时，S150根据子应用的加载方式加载子应用的步骤，包括：

S151，获取主应用的页面标签；

S152，根据页面标签加载子应用。

结合第二方面，加载方式为js动态加载；

S153，根据子应用的加载方式加载子应用的步骤，包括：

S154，获取子应用的属性信息；属性信息至少包括：css与js隔离级别；

S155，根据属性信息，通过loadEntry方法加载子应用。

在本实施例中，子应用的加载方式可以为根据页面模板标签加载或js动态加载，通过这两种方式均可以实现子应用加载。在页面模板标签加载方式下，自动读取子应用对应的entry标签信息，根据该标签信息加载对应的子应用；在js动态加载方式下，通过loadEntry方法加载子应用的基本信息以及对应属性后，在初始化主应用入口标签时，加载对应loadEntry传入对象信息，以完成加载。

对子应用来说，子应用对应的标签上对应配置参数(open Cores true或false)，在标签为open Cores true)时表示开启了对应跨域允许访问，即该子应用可以与主应用进行通信、绑定对应事件监听，这样才可完成对应子应用加载；若需要在主应用进行初始化(即主应用生命周期befoeMount时初始化，及内存中加载对应子应用)时添加对应监听事件，根据监听对象不同，需对监听事件名称进行特殊处理，若监听主应用则监听事件名以“_master”结尾，若监听子应用，监听事件名需以“_子应用名称”结尾；对应监听事件建立后，主应用以及子应用均可通过$emit触发该监听事件，来完成主子应用以及子应用之间的数据通信，其中，$emit为触发事件表标识。此外，在加载子应用时，若去中心化配置为false时，此子应用仅仅直接被加载到主应用中，主应用无法感知到该子应用下的子应用信息；若为true时，所有子孙应用均加载到主应用容器下，主应用能够管理到所有子应用加载与销毁整个生命周期过程。这样，主应用于子应用子、子应用与其他子应用之间通信更加方便，接收方建立对应事件监听，发送放触发对应事件监听并发送对应数据，以此完成双方数据交互，同时提供通信api功能，使得通信如同在一个项目中进行，简化了主应用的依赖，提高了项目灵活度以及维护成本。

结合第二方面，步骤S150针对每个子应用，根据子应用的加载方式加载子应用的步骤之后，还包括：

S210，获取子应用对应的静态资源信息、事件监听函数和子条目信息。

S220，静态资源加载器将静态资源信息储存于对应的子条目静态容器中，同时，事件监听器将事件监听函数储存于对应的子条目通信事件容器中，同时，将子条目信息存储于对应的子条目容器。

S230，建立静态资源信息与事件监听函数之间的第一映射关系。

S240，将子条目信息与第一映射关系关联，得到子条目信息、静态资源信息和事件监听函数一一对应的第二映射关系。

具体的步骤S210通过主加载器对加载的子应用进行扫描，以获取到子应用对应的静态资源信息、事件监听函数和子条目信息，之后步骤S220将得到的上述信息分别储存于对应的储存容器中，并在步骤S230、S240建立上述三种信息映射关系。

(1)通过对应静态资源加载器、事件监听器以及子条目容器，可以有效的解决项目之间通信、跳转、预加载、项目保活等问题。供对应子条目静态资源容器缓存对应子项目静态资源，建立三种信息间的映射关系，同时可提供对应隔离级别配置，在子应用渲染入口处建立对应隔离级别配置，灵活完成对应静态资源加载。

结合第二方面，子条目容器包括多个单页面子条目容器和多个多页面子条目容器。步骤S220将子条目信息存储于对应的子条目容器的步骤，具体包括：

S221，判断子应用是否为单页面子应用。

若是，执行步骤S222，若否执行步骤S223。

S222，将子应用对应的子条目信息存储于对应的单页面子条目容器。

S223，将子应用对应的子条目信息存储于对应的多页面子条目容器。

主加载器通过对应子应用属性配置信息确定子应用为单页面的子应用或多页面的子应用。之后，将子应用对应的子条目信息存储与对应的子条目容器中。这样，可以有效的解决了前端传统多页面项目与单页面融合，有效避免的传统项目融合缺项(如iframe嵌套项目以及nignx代理)等问题。

结合第二方面，步骤S150静态资源加载器将静态资源信息储存于对应的子条目静态容器中的步骤，还包括：

S156，将静态资源信息的地址信息映射至子条目静态容器中对应的指定沙箱区域。

S157，根据hash算法，对静态资源信息添加对应的唯一命名并储存。

这样，通过获取子应用对应的静态资源信息，通过静态资源加载器将静态资源信息映射至对应的一个固定的沙箱区域，并以hash随机命名对应静态资源信息，使其相互子应用之间相互独立。这样，可以解决子应用过程中信息混乱的问题。

结合第二方面，S160渲染生成器对子应用渲染后显示于子应用的显示页面的步骤，包括：

S161，渲染加载器根据第二映射关系将子条目信息、静态资源信息和事件监听函数，以webComponent方式渲染生成子应用对应的子应用页面；

S162，获取子应用对应的渲染入口标签；

S163，根据渲染入口标签，将子应用页面传输至渲染入口标签对应的渲染入口，以展示子应用页面。

渲染加载器获取需渲染的子应用对应的子条目，通过S240建立的第二映射关系获取子应用对应的静态资源信息、事件监听函数和子条目信息，将上述三个信息组合生成对应页面信息后，经渲染生成器放入到渲染入口中，展示对应页面信息。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统和装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

另外，在本发明实施例的描述中，除非另有明确的规定和限定，术语“安装”、“相连”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域技术人员而言，可以具体情况理解上述术语在本发明中的具体含义。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

在本发明的描述中，需要说明的是，术语“中心”、“上”、“下”、“左”、“右”、“竖直”、“水平”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。此外，术语“第一”、“第二”、“第三”仅用于描述目的，而不能理解为指示或暗示相对重要性。

最后应说明的是：以上实施例，仅为本发明的具体实施方式，用以说明本发明的技术方案，而非对其限制，本发明的保护范围并不局限于此，尽管参照前述实施例对本发明进行了详细的说明，本领域技术人员应当理解：任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本发明实施例技术方案的精神和范围，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。