CN110708368A - 一种基于路由分发的微前端系统和方法 - Google Patents

Abstract

本发明涉及一种基于路由分发的微前端系统和方法，其中，系统包括：微前端注册发现模块，用于进行前端注册，并通过微前端发现机制，对各个前端进行动态配置；前端生命周期管理模块，用于对业务模块调用的前端进行加载和卸载管理；依赖管理模块在业务系统正式运行之前，将各个业务模块对应的前端资源通过文件扫描模块进行扫描，滤除重复文件，并对依赖资源库中的文件通过代码静态分析模块进行分析，删除无用代码；路由管理模块通过对各前端进行二级路由划分，使得各个业务模块共享同一个域名；缓存管理模块，进行页面的无刷新跳转，并结合依赖管理模块，对多次用到的资源文件进行细粒度缓存。

Description

一种基于路由分发的微前端系统和方法

技术领域

本发明属于计算机网络技术领域，特别涉及一种基于路由分发的微前端系统和方法。

背景技术

近年来，随着微服务架构的流行，企业内部IT资源和业务应用变得逐渐丰富，这在很大程度上提升了企业业务效能，但由于大部分业务系统都是基于B/S(浏览器/服务端)模式，于是催生了一个新的痛点：如何对现有的前端架构进行改造，以适配种类繁多的后端微服务。

通常来讲，一个大型业务系统会包含多个业务模块，每个业务模块由相应的后端微服务支撑，在正常开发过程中，每个微服务对应着一个独立的前端，同时，由于技术选型、领导决策、历史遗留等原因，各个前端所使用的技术栈可能新旧不一、架构各异，这必然会导致一些问题：

(1)各个前端虽然彼此独立，但却存在大量重复的依赖资源，这种冗余对存储空间、网络带宽和浏览器性能而言都是很大的浪费。

(2)由于每个前端页面的域名不同，当用户在不同业务模块的页面之间跳转时，会带来页面不统一的体验，同时各页面的切换会触发刷新，造成用户体验的下降。

(3)后端微服务有着成熟的治理平台，能够对所有微服务进行有效管控，但目前业界缺少对前端的统一治理方案，当前端数量日益增多时，其开发、编译、部署等流程将会愈发难以维护。

发明内容

本发明的目的在于提供一种微前端系统体系架构，用于解决上述现有技术的问题。

本发明一种微前端系统体系架构，其中，包括：微前端注册发现模块、生命周期管理模块、依赖管理模块、路由管理模块以及缓存管理模块，微前端注册发现模块，用于进行前端注册，并通过微前端发现机制，对各个前端进行动态配置；前端生命周期管理模块，用于对业务模块调用的前端进行加载和卸载管理；依赖管理模块在业务系统正式运行之前，将各个业务模块对应的前端资源通过文件扫描模块进行扫描，滤除重复文件，并对依赖资源库中的文件通过代码静态分析模块进行分析，删除无用代码；路由管理模块通过对各前端进行二级路由划分，使得各个业务模块共享同一个域名；通过Nginx反向代理与后端微服务进行解耦，使得后端微服务地址的变更不会影响到前端路由；缓存管理模块，进行页面的无刷新跳转，并结合依赖管理模块，对多次用到的资源文件进行细粒度缓存。

根据本发明的微前端系统体系架构的一实施例，其中，微前端注册发现模块的前端探测子模块能够对接业界主流持续集成和持续部署工具。

根据本发明的微前端系统体系架构的一实施例，其中，前端注册发现模块在前端完成开发时，捕捉到代码的更新，并自动对代码进行打包、测试和部署，前端注册发现模块的前端探测子模块发现当前网络环境中新增的前端部署包，继而对目标进行注册，注册后的信息保存在动态配置表中，动态配置表将对每个前端分配唯一的索引，当某一前端变更了基本信息，动态配置表依据索引进行更新。

根据本发明的微前端系统体系架构的一实施例，其中，生命周期管理模块将每个前端的生命周期分为四个部分，包括：(1)当某个前端注册到微前端系统，执行加载操作，将生命周期进行绑定；(2)当某个业务模块调用对应的前端时，将该前端标记为运行状态；(3)当业务模块停止调用该前端时，微前端系统将对该前端执行卸载操作。

根据本发明的微前端系统体系架构的一实施例，其中，路由管理模块管理各个前端页面的路径地址，在用户使用过程中，借助Nginx访问各前端对应的后端微服务，Nginx部署在开源的Docker容器之上。

根据本发明的微前端系统体系架构的一实施例，其中，缓存管理模块在页面首次加载时，前端向后端请求页面资源，缓存管理模块的缓存调度子模块对请求到的资源进行初始化并保存；当切换到新页面时，缓存调度子模块会预先分析是否有相同的资源依赖，如果有，则直接从缓存资源模块保存的缓存资源中给出响应，如果没有，就向后端发起请求；当切换回初始的页面时，缓存调度子模块判断出该页面被访问过，从保存的缓存资源中给出响应；在页面切换时，缓存调度子模块会调用浏览器的window.history API，进行页面的无刷新跳转。

本发明一种基于路由分发的微前端管理方法，其中，包括：步骤1：对独立部署的各个前端进行注册，当找到前端部署包之后，进行注册操作，将注册信息存储在一个动态配置表中，并对动态配置表进行管理；步骤2：将各个前端分别绑定生命周期；步骤3：对各个前端工程的资源文件进行扫描，滤除重复文件，并删除无用代码；步骤4：在前后端之间部署Nginx反向代理，读取动态配置表，当业务模块发起HTTP请求时，Nginx反向代理截获，识别请求路径并将请求转发到路径对应的后端微服务上，当微服务给出响应后，将响应数据发回；Nginx反向代理中的前后端映射数据来源于微前端注册发现模块的动态配置表；步骤5：当前端资源文件首次被加载并运行时，将该资源进行缓存管理；在业务系统使用中，当发生页面切换时，查找并判断当前缓存资源里是否存在有效的新页面所需的资源文件：如果存在，则直接从缓存资源中给出响应；如果不存在，则向服务器发起新的资源请求；当页面切换到已访问过的业务模块时，发现当前页面所需的资源存在于依赖资源库中，判断各缓存资源是否处于有效期内，如果有效，则直接从缓存资源中给出响应，如果无效，则向服务器发起新的资源请求。

根据本发明的基于路由分发的微前端管理方法的一实施例，其中，步骤1：对独立部署的各个前端进行注册，包括：当各个前端工程分别部署之后，对各个前端工程的部署目录进行扫描探测，从而发现前端部署包；当找到前端部署包之后，对目标进行注册操作，将注册信息存储在一个动态配置表中；当某个注册过的前端工程修改了自身信息，依据索引检测出是前端工程发生的变化，在动态配置表中更新该前端工程的注册信息，当某个注册过的前端工程被删除，在动态配置表中进行相关信息的删除。

根据本发明的基于路由分发的微前端管理方法的一实施例，其中，步骤2包括：(1)当某个前端工程注册后，执行初始化加载操作，表示该前端工程已处于准备状态；(2)当某个业务模块开始请求调用对应的前端工程时，将该前端工程由加载状态更改为运行状态，业务模块在浏览器端会运行该前端工程；(3)当业务模块停止调用该前端工程时，将该前端工程由运行状态更改为卸载状态。

根据本发明的基于路由分发的微前端管理方法的一实施例，其中，步骤3包括：对各个前端工程的资源文件进行扫描，通过Hash算法滤除重复文件；对于滤除后的文件，对其中的代码文件进行代码静态分析，找到定义了却没有使用的变量、函数、对象以及模块，进行删除；将精简过的资源文件存入依赖资源库，供业务模块请求调用。

本发明提出一种基于路由分发的微前端系统。通过对后端微服务思想的借鉴，在前端层面引入对路由、依赖、缓存等资源的管理功能，同时能够对前端的注册、加载、运行、卸载等全生命周期进行统一调度。

附图说明

图1所示为微前端系统体系架构示意图；

图2所示微前端注册发现模块的架构图

图3所示为前端生命周期管理示意图；

图4所示为依赖管理模块的示意图；

图5所示为路由管理的基本架构示意图；

图6所示为缓存管理模块的示意图；

图7所示为基于路由分发的微前端系统的使用流程图。

具体实施方式

为使本发明的目的、内容、和优点更加清楚，下面结合附图和实施例，对本发明的具体实施方式作进一步详细描述。

图1所示为微前端系统体系架构示意图，如图1所示，微前端系统由微前端注册发现模块、生命周期管理模块、依赖管理模块、路由管理模块、缓存管理模块组成，模块之间通过RPC(远程过程调用)进行高效率通信。

图2所示微前端注册发现模块的架构图，如图2所示，微前端注册发现模块通过注册机制，使得各个前端能够独立开发、独立部署及升级扩展，同时确保了维护的统一；另一方面，当业务模块变得复杂，前端部署位置可能会发生变更，以往的静态配置策略就显得鸡肋，通过微前端发现机制，能够对各个前端进行动态配置，这样保证了前端的高可用。

如图2所示，微前端注册发现模块的前端探测子模块能够对接业界主流CI/CD(持续集成/持续部署)工具，以Jenkins(Jenkins作为持续部署工具，并有着强大的扩展能力和丰富的插件，可以实现各种复杂的流程)为例，当某个前端完成开发时，Jenkins能够捕捉到代码的更新，并自动对代码进行打包、测试、部署。前端探测子模块通过与Jenkins的对接，能够自动发现当前网络环境中新增的前端部署包，继而对目标进行注册。注册后的信息(例如地址路径、开发框架信息、关联的微服务信息等)将被保存在动态配置表中，动态配置表对应着一个高可用的“键/值”存储服务，将对每个前端分配唯一的索引。一旦某个前端变更了基本信息，动态配置表能够自动依据索引进行更新。

图3所示为前端生命周期管理示意图，如图3所示，在本发明中，生命周期管理模块将每个前端的生命周期分为四个部分，包括：

(1)一旦某个前端注册到微前端系统，后者将自动执行“加载”操作，将前者的生命周期进行绑定。

(2)当某个业务模块调用对应的前端时，微前端系统将该前端标记为“运行”状态，。

(3)当业务模块停止调用该前端时，微前端系统将对该前端执行“卸载”操作，以节省计算和存储资源。

对前端进行生命周期管理有利于保证整个业务系统前端运行状态的稳定性和连贯性。

图4所示为依赖管理模块的示意图，如图4所示，在微前端系统中，前端数量众多，且开发框架可能不尽相同，不同的前端很有可能会引用相同的静态资源文件。例如对于两个前端，一个是基于Vue(一个创建单页应用的Web应用框架)进行开发，另一个是基于React(一个为数据提供渲染为HTML视图的开源JavaScript库)进行开发，它们在某些页面使用了同一个第三方库，因此两者会重复引用该第三方库的CSS文件和JavaScript文件，这将造成严重的网络带宽和浏览器性能的浪费。基于此，本发明引入依赖管理模块。

如图4所示，在业务系统正式运行之前，依赖管理模块将各个业务模块对应的前端资源通过文件扫描模块进行扫描，一方面，通过文件Hash算法滤除重复文件，另一方面，对依赖资源库中的文件通过代码静态分析模块进行分析，删除无用代码，从而减小依赖资源的体积，降低网络传输负载，提升前端运行性能。最终这些精简后的资源文件将被存入依赖资源库。

图5所示为路由管理的基本架构示意图，如图5所示，本发明采用路由分发机制实现微前端在大型业务系统中的表现层的统一性。路由管理模块会管理各个前端页面的路径地址，在用户使用过程中，借助Nginx(一种高性能的HTTP反向代理服务器)访问各前端对应的后端微服务。同时，Nginx部署在开源的Docker容器之上，由于Docker是一个可灵活配置并管理的独立运行环境，是目前业界轻量级虚拟化方案的最佳实践，因此能够有效实现路由分发功能的弹性、快速部署。

路由管理通过对各前端进行二级路由划分，一方面使得各个业务模块共享同一个域名，保证了业务URL的一致性；另一方面借助Nginx反向代理能够与后端微服务进行解耦，后端微服务地址的变更不会影响到前端路由。

图6所示为缓存管理模块的示意图，如图6所示，虽然路由管理模块已经将各前端的二级路由进行了划分，保证了各业务模块域名的统一，但由于各前端页面仍然是彼此独立的文件，导致页面切换时会触发浏览器刷新，造成用户体验的下降。针对此问题，本发明引入缓存管理模块，利用浏览器的window.history API实现页面的无刷新跳转；同时结合依赖管理模块，对多次用到的资源文件进行细粒度缓存，以节省重复请求带来的网络开销，并且能够提升业务系统在离线状态下的可访问性。

图6所示为缓存管理模块的组成示意图，如图6所示，(1)当页面首次加载时，前端向后端请求页面资源，此时缓存调度子模块会对请求到的资源进行初始化并保存，并且可以设置缓存时长和缓存更新条件。

(2)当切换到新页面时，缓存调度子模块会预先分析是否有相同的资源依赖，如果有，则直接从缓存资源模块保存的缓存资源中给出响应，如果没有，就向后端发起请求。

(3)当切换回最初的页面时，缓存调度子模块判断出该页面被访问过，因此直接从保存的缓存资源中给出响应。

(4)在页面切换时，缓存调度子模块会调用浏览器的window.history API，实现页面的无刷新跳转，提供良好的用户体验。

图7所示为基于路由分发的微前端系统的使用流程图，如图7所示，基于路由分发的微前端系统的使用流程包括以下步骤：

步骤1：对独立部署的各个前端进行注册。

步骤2：将各个前端分别绑定生命周期。

步骤3：对各个前端执行依赖抽取。

步骤4：依据用户访问的业务模块的不同，执行路由分发。

步骤5：在访问过程中，执行缓存管理。

如图7所示，基于路由分发的微前端系统的使用流程包括：

步骤1：对独立部署的各个前端进行注册。

(1)一个B/S模式的业务系统可能由多个业务模块组成，每个业务模块对应一个后端微服务，如果业务模块存在与之相对应的前端页面，则该业务系统可能存在多个前端工程，它们有新有旧，彼此独立，采用的开放框架也可能各不一样。当各个前端工程分别部署之后，微前端系统通过注册发现模块中的前端探测子模块对各个前端工程的部署目录进行扫描探测，从而发现前端部署包：如果前端工程采用CI/CD工具，则前端探测子模块能够自动与其进行对接；如果前端工程采用手动部署的方式，则前端探测子模块将会对部署目录(诸如index.html的文件)进行特征扫描。

(2)当找到前端部署包之后，微前端注册发现模块将对目标进行注册操作，即获取目标前端工程的地址路径、开发框架信息、关联的微服务信息等，然后会将这些注册信息存储在一个动态配置表中，该动态配置表类似于一个轻量级非关系型数据库，它维护着多个“键/值”对，每一个前端工程会被分配一个唯一的“键”作为查找时的索引，其“值”便包含了上述前端工程的自身信息。

(3)当某个注册过的前端工程修改了自身信息(地址路径变更、开发框架更新、或者关联的微服务发生改变等)，前端探测子模块便能自动依据索引检测出是哪个前端工程发生了变化，然后在动态配置表中更新该前端工程的注册信息。同样，当某个注册过的前端工程被删除，前端探测子模块也能自动在动态配置表中进行相关信息的删除。

步骤2：对各个前端分别绑定生命周期。

(1)当某个前端工程注册到微前端系统，后者将自动对前者执行初始化“加载”操作，表示该前端工程已处于准备状态。

(2)当某个业务模块开始请求调用对应的前端工程时，微前端系统将该前端工程由“加载”状态更改为“运行”状态。此时业务模块在浏览器端会运行该前端工程，例如创建并渲染DOM(文档对象模型，属于浏览器技术范畴)树、绑定用户事件等。

(3)当业务模块停止调用该前端工程时，微前端系统将该前端工程由“运行”状态更改为“卸载”状态。此时业务模块在浏览器端会停止运行该前端工程，例如删除DOM树、销毁用户事件等，这样能够节省浏览器端的计算和存储资源。

步骤3：对各个前端执行依赖抽取。

(1)当微前端系统注册了多个前端工程时，由于前端对应的各业务模块可能存在某些功能的重叠，因此有些前端工程可能会引用相同的静态资源文件，比如第三方JavaScript库和CSS样式表。此时微前端系统会对各个前端工程的资源文件进行扫描，通过Hash算法滤除重复文件，以此减少浏览器对资源文件的请求次数。

(2)对于滤除后的文件，微前端系统将对其中的代码文件进行代码静态分析，找到那些定义了却没有使用的变量、函数、对象、模块等，从而删除这些无用代码，减小依赖资源的体积，优化数据包的网络传输。

(3)经过文件扫描和代码静态分析后，微前端系统将精简过的资源文件存入依赖资源库，供业务模块请求调用。当前端工程文件有更新时，微前端注册发现模块能够感知到并通知依赖管理模块，以增量的形式更新依赖资源库。

步骤4：依据用户访问的业务模块的不同，执行路由分发。

为保证展示的统一，一个大型业务系统会使用一个域名，比如www.example.com，其包含的各业务模块会以路由进行划分，比如业务模块A的页面地址为www.example.com/pathA，业务模块B的页面地址为www.example.com/pathB。当业务模块调用各自前端资源时，用于域名相同，它们会向该域名所在的服务器发起请求，但是由于后端微服务和各前端工程都是独立部署，不存在部署在该统一域名下的服务，因此会造成请求失败，即“统一域名”和“独立部署”不可兼得。微前端系统通过引入路由分发机制解决这个问题。

(1)在前后端之间部署Nginx反向代理，它能读取微前端注册发现模块中的动态配置表，这样当业务模块发起HTTP请求时，Nginx反向代理能够将其截获，识别请求路径并将请求转发到该路径对应的后端微服务上。当微服务给出响应后，它又会将响应数据发回给业务模块。Nginx反向代理不仅有着数据转发的功能，也能在网络请求压力增大时起到负载均衡的作用。

(2)Nginx反向代理部署于Docker容器环境中，借助Docker的诸多优势，当后端微服务需要调整或迁移时，它也能够实现快速部署和弹性扩展。Nginx反向代理中的前后端映射数据来源于微前端注册发现模块的动态配置表，这种单向来源的特性能够确保配置信息的一致性。

步骤5：在访问过程中，执行缓存管理。

缓存管理模块利用浏览器的window.history API接口，保证了各业务模块的页面在切换时的用户体验，同时借助依赖管理模块提供了离线状态下的页面可访问性。

(1)当前端资源文件首次被加载并运行时，微前端系统会将该资源进行缓存，并提供两种缓存方式：1)缓存时长，可以设置缓存资源的有效期，当超过该有效期后，缓存资源自动删除；2)缓存更新条件，根据资源文件的Hash值或者文件修改时间戳来判断缓存资源是否需要更新。

(2)在业务系统使用中，当发生页面切换时，微前端系统会查找并判断当前缓存资源里是否存在有效的新页面所需的资源文件：如果存在，则直接从缓存资源中给出响应；如果不存在，则向服务器发起新的资源请求。同时，在页面切换时，微前端系统会调用浏览器的window.history API接口，实现页面的无刷新跳转，保证良好的用户体验。

(3)当页面切换到已访问过的业务模块时，微前端系统发现当前页面所需的资源都存在于依赖资源库中，然后判断各缓存资源是否处于有效期内，如果有效，则直接从缓存资源中给出响应，如果无效，则向服务器发起新的资源请求。

本发明借鉴成熟的微服务的架构，将分而治之、统一管理的思想引入前端，弥补了当前微服务架构在前端表现层的短板，这是现有技术所不具备的。同时它包含以下优点：

(1)借助前端注册发现机制，能够兼容新旧不同、框架各异的前端工程，提高了可扩展性。每个前端都能够独立开发、独立部署、独立运行，同时采用开源、成熟、高效的技术框架Nginx作为HTTP反向代理，后端地址的更改不影响前端路由寻址，这使得前端弹性管理成为可能。

(2)引入对前端的全生命周期管理，使得企业运维开发人员能够对当前的业务模块从后端到前端有一个全面系统的感知。另外，如果对各生命周期的钩子函数进行介入，还能开发出一套详尽高效的前端监控方案，这对于运行时错误捕捉和前端健康状态检查而言也是一个十分便捷的工具。

(3)一直以来，页面加载时间始终是前端性能方面最重要的瓶颈，它直接决定着用户体验，本发明通过依赖管理和缓存管理两个模块，对微前端天然的“分散”、“重复”的缺点进行了有效规避，将资源依赖合拢，将重复文件滤除，最大限度提升了页面加载效率，同时借助浏览器的原生API进一步提升用户体验。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明技术原理的前提下，还可以做出若干改进和变形，这些改进和变形也应视为本发明的保护范围。

Claims (10)

1.一种微前端系统体系架构，其特征在于，包括：微前端注册发现模块、生命周期管理模块、依赖管理模块、路由管理模块以及缓存管理模块，

微前端注册发现模块，用于进行前端注册，并通过微前端发现机制，对各个前端进行动态配置；

前端生命周期管理模块，用于对业务模块调用的前端进行加载和卸载管理；

依赖管理模块在业务系统正式运行之前，将各个业务模块对应的前端资源通过文件扫描模块进行扫描，滤除重复文件，并对依赖资源库中的文件通过代码静态分析模块进行分析，删除无用代码；

路由管理模块通过对各前端进行二级路由划分，使得各个业务模块共享同一个域名；通过Nginx反向代理与后端微服务进行解耦，使得后端微服务地址的变更不会影响到前端路由；

缓存管理模块，进行页面的无刷新跳转，并结合依赖管理模块，对多次用到的资源文件进行细粒度缓存。

2.如权利要求1所述的微前端系统体系架构，其特征在于，微前端注册发现模块的前端探测子模块能够对接业界主流持续集成和持续部署工具。

3.如权利要求2所述的微前端系统体系架构，其特征在于，前端注册发现模块在前端完成开发时，捕捉到代码的更新，并自动对代码进行打包、测试和部署，前端注册发现模块的前端探测子模块发现当前网络环境中新增的前端部署包，继而对目标进行注册，注册后的信息保存在动态配置表中，动态配置表将对每个前端分配唯一的索引，当某一前端变更了基本信息，动态配置表依据索引进行更新。

4.如权利要求1所述的微前端系统体系架构，其特征在于，生命周期管理模块将每个前端的生命周期分为四个部分，包括：

(1)当某个前端注册到微前端系统，执行加载操作，将生命周期进行绑定；

(2)当某个业务模块调用对应的前端时，将该前端标记为运行状态；

(3)当业务模块停止调用该前端时，微前端系统将对该前端执行卸载操作。

5.如权利要求1所述的微前端系统体系架构，其特征在于，路由管理模块管理各个前端页面的路径地址，在用户使用过程中，借助Nginx访问各前端对应的后端微服务，Nginx部署在开源的Docker容器之上。

6.如权利要求1所述的微前端系统体系架构，其特征在于，缓存管理模块在页面首次加载时，前端向后端请求页面资源，缓存管理模块的缓存调度子模块对请求到的资源进行初始化并保存；当切换到新页面时，缓存调度子模块会预先分析是否有相同的资源依赖，如果有，则直接从缓存资源模块保存的缓存资源中给出响应，如果没有，就向后端发起请求；当切换回初始的页面时，缓存调度子模块判断出该页面被访问过，从保存的缓存资源中给出响应；在页面切换时，缓存调度子模块会调用浏览器的window.history API，进行页面的无刷新跳转。

7.一种基于路由分发的微前端管理方法，其特征在于，包括：

步骤1：对独立部署的各个前端进行注册，当找到前端部署包之后，进行注册操作，将注册信息存储在一个动态配置表中，并对动态配置表进行管理；

步骤2：将各个前端分别绑定生命周期；

步骤3：对各个前端工程的资源文件进行扫描，滤除重复文件，并删除无用代码；

步骤4：在前后端之间部署Nginx反向代理，读取动态配置表，当业务模块发起HTTP请求时，Nginx反向代理截获，识别请求路径并将请求转发到路径对应的后端微服务上，当微服务给出响应后，将响应数据发回；Nginx反向代理中的前后端映射数据来源于微前端注册发现模块的动态配置表；

步骤5：当前端资源文件首次被加载并运行时，将该资源进行缓存管理；在业务系统使用中，当发生页面切换时，查找并判断当前缓存资源里是否存在有效的新页面所需的资源文件：如果存在，则直接从缓存资源中给出响应；如果不存在，则向服务器发起新的资源请求；当页面切换到已访问过的业务模块时，发现当前页面所需的资源存在于依赖资源库中，判断各缓存资源是否处于有效期内，如果有效，则直接从缓存资源中给出响应，如果无效，则向服务器发起新的资源请求。

8.如权利要求1所述的基于路由分发的微前端管理方法，其特征在于，步骤1：对独立部署的各个前端进行注册，包括：

当各个前端工程分别部署之后，对各个前端工程的部署目录进行扫描探测，从而发现前端部署包；

当找到前端部署包之后，对目标进行注册操作，将注册信息存储在一个动态配置表中；

当某个注册过的前端工程修改了自身信息，依据索引检测出是前端工程发生的变化，在动态配置表中更新该前端工程的注册信息，当某个注册过的前端工程被删除，在动态配置表中进行相关信息的删除。

9.如权利要求1所述的基于路由分发的微前端管理方法，其特征在于，步骤2包括：

(1)当某个前端工程注册后，执行初始化加载操作，表示该前端工程已处于准备状态；

(2)当某个业务模块开始请求调用对应的前端工程时，将该前端工程由加载状态更改为运行状态，业务模块在浏览器端会运行该前端工程；

(3)当业务模块停止调用该前端工程时，将该前端工程由运行状态更改为卸载状态。

10.如权利要求1所述的基于路由分发的微前端管理方法，其特征在于，步骤3包括：

对各个前端工程的资源文件进行扫描，通过Hash算法滤除重复文件；

对于滤除后的文件，对其中的代码文件进行代码静态分析，找到定义了却没有使用的变量、函数、对象以及模块，进行删除；

将精简过的资源文件存入依赖资源库，供业务模块请求调用。

Images