Dynamic route replacement method, system and equipment based on micro front end and medium

Abstract

The invention provides a dynamic route replacement method, system and device based on a micro front end and a medium, which are applied to a micro front end container running in a browser, and the method comprises the following steps: receiving an access request sent by a user; the access request is a uniform resource path; acquiring a set routing mapping table in the micro front-end container; the set routing mapping table comprises first routing information and second routing information; determining a corresponding accessible route through a logic matching rule according to the access request and the set route mapping table; and loading and displaying the corresponding sub-application according to the accessible route. Compared with the traditional technical scheme, the method has the advantages that the route dynamic replacement logic is moved forward into the web container, so that the complexity of operation and maintenance deployment can be greatly reduced, and the problems of tedious maintenance and high maintenance cost are solved.

Description

Technical Field

[0001] The present application belongs to the field of computer front-end technology, and relates to a dynamic routing replacement method based on a micro front-end, and in particular to a dynamic routing replacement method, system, device and medium based on a micro front-end. Background Art

[0002] Web front-end technology is an important part of the Internet. Conventional web site development technology has formed a complete set of tool chains and engineering methods. Based on a complete tool chain and mature engineering methods, the development of single web applications has become extremely efficient and convenient. Conventional development teams can quickly build simple web sites to meet certain business goals.

[0003] As the content of a single site grows, the web front-end development process also puts forward the demand of splitting large single applications during development and combining multiple small single applications at runtime. The concept of micro front-end comes into being. More and more sites choose to use different micro front-end technologies to implement local business iteration, reduce the instability factors brought by some business updates to the system, and speed up the iteration of local business.

[0004] On the other hand, with the continuous iteration and update of large-scale web applications, the same web project needs to undergo business and technical reconstruction from time to time due to objective reasons such as experience improvement, business development, and technology upgrades. Sometimes the entire site is involved, and sometimes only a certain part (a sub-application in a micro front-end, or a web component) needs to perform the aforementioned operations.

[0005] In addition, when upgrading a complete web sub-application, sometimes there will be a situation where both the new and old frameworks need to coexist. For example, if the old business is too large and the migration cannot be completed in one go, the aforementioned micro-frontend technology can be used to develop the new and old applications in the form of two independent sub-applications. The micro-frontend container can access two different web projects at the same time to achieve the purpose of maintaining consistency between the new and old project experiences during the migration process. The R&D team maintains the old application while developing new businesses with the new framework in the new project, including migrating the old business from the old project to the new project. In this migration process, considering the user's consistent access consistency and browsing experience, the original route of the old business page needs to remain unchanged, but the loaded page and the running code are the products packaged by the new project. At this time, it is difficult to determine which static resources and running code are loaded by the route accessed by the user.

[0006] To solve this problem, for purely static sites, the prior art considers using a proxy gateway to determine the specific page static resources that need to be loaded by the route accessed by the user, such as using nginx (as a reverse proxy) configuration, konga configuration, etc., or by the static server itself, such as apache, nginx (as a static server). However, the prior art requires certain adjustments to the gateway and proxy, and even the development of special parsing scripts and additional routing mapping information. For some systems, there is no ability to effectively control the network middle layer, resulting in complex operation and maintenance deployment, cumbersome maintenance, and high maintenance costs. Summary of the invention

[0007] The purpose of the present application is to provide a dynamic route replacement method, system, device and medium based on a micro front-end, which is used to solve the problem that the method of loading different static resources by route in the prior art is complex in operation and maintenance deployment, resulting in cumbersome maintenance and high maintenance cost.

[0008] In the first aspect, the present application provides a dynamic route replacement method based on a micro-frontend, which is applied to a micro-frontend container running in a browser, and the method includes: receiving an access request sent by a user; the access request is a unified resource path; obtaining a set route mapping table in the micro-frontend container; the set route mapping table includes first routing information and second routing information; the first routing information includes a first accessible route and a sub-application corresponding to the first accessible route; the second routing information includes a second accessible route, a sub-application corresponding to the second accessible route, and a target replacement route corresponding to the second accessible route; the target replacement route is a route in the first accessible route; according to the access request and the set route mapping table, the corresponding accessible route is determined by a logical matching rule; according to the accessible route, the corresponding sub-application is loaded and displayed.

[0009] In an implementation of the first aspect, determining the corresponding accessible route through a logical matching rule according to the access request and the set route mapping table includes: obtaining the corresponding first accessible route in the first routing information through a logical matching rule according to the access request; searching in the target replacement route of the second routing information whether there is a route that is the same as the first accessible route; if so, using the second accessible route corresponding to the target replacement route that is the same as the first accessible route as the accessible route; if not, using the first accessible route as the accessible route.

[0010] In an implementation manner of the first aspect, the logic matching rule includes a prefix matching rule, a regular expression matching rule and / or a custom matching rule combined with business characteristics.

[0011] In an implementation of the first aspect, loading and displaying the corresponding sub-application according to the accessible route includes: obtaining the corresponding sub-application entry file and service code according to the accessible route; parsing the sub-application entry file according to the service code to obtain the corresponding page resources; loading and displaying the page resources.

[0012] In an implementation of the first aspect, parsing the sub-application entry file according to the service code to obtain corresponding page resources includes: parsing the sub-application entry file according to the service code to obtain a specific page route; obtaining the corresponding page routing code in the service code according to the specific page route; replacing the page route in the page routing code with the specific page route to obtain the replaced service code; loading and displaying the corresponding page resources according to the replaced service code.

[0013] In an implementation of the first aspect, parsing the sub-application entry file according to the service code to obtain corresponding page resources includes: parsing the sub-application entry file to obtain a specific page route; obtaining a corresponding page route mapping relationship in the service code according to the specific page route; obtaining a corresponding page route to be displayed according to the page route mapping relationship; loading and displaying corresponding page resources according to the page route to be displayed.

[0014] In an implementation of the first aspect, parsing the sub-application entry file according to the service code to obtain corresponding page resources includes: parsing the sub-application entry file according to the service code to obtain a specific page route; obtaining the corresponding page route to be displayed according to the specific page route and the set route mapping table; loading and displaying the corresponding page resources according to the page route to be displayed.

[0015] In the second aspect, the present application provides a dynamic routing replacement system based on a micro-frontend, the system comprising: an access request receiving module, used to receive an access request sent by a user; the access request is a unified resource path; a mapping table acquisition module, used to obtain a set routing mapping table in the micro-frontend container; the set routing mapping table includes first routing information and second routing information; the first routing information includes a first accessible route and a sub-application corresponding to the first accessible route; the second routing information includes a second accessible route, a sub-application corresponding to the second accessible route, and a target replacement route corresponding to the second accessible route; the target replacement route is a route in the first accessible route; a logic matching module, used to determine the corresponding accessible route through a logic matching rule according to the access request and the set routing mapping table; a loading module, used to load and display the corresponding sub-application according to the accessible route.

[0016] In a third aspect, the present application provides an electronic device, comprising: a memory for storing an executable program; and a processor for executing the executable program so that the electronic device executes the dynamic routing replacement method based on the micro-front end as described above.

[0017] In a fourth aspect, the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by an electronic device, implements the above-mentioned dynamic routing replacement method based on a micro-front end.

[0018] As described above, the micro-frontend-based dynamic routing replacement method, system, device, and medium described in the present application have the following beneficial effects:

[0019] In the process of loading static resources of different sub-applications according to routes, the present application registers and sets a route mapping table in the browser, so that the dynamic route replacement process is carried out in the micro-front-end container (web container). Compared with the traditional information technology solution of registering and mapping in the proxy layer or in the static server, the present application moves the dynamic route replacement logic forward to the web container, which can greatly reduce the complexity of operation and maintenance deployment, thereby solving the problems of cumbersome maintenance and high maintenance costs, and at the same time can also improve the flexibility and controllability of page resource loading on the business side.

[0020] This application performs a dynamic route replacement process in a micro-frontend container (web container), so that during the iteration, migration, and technology upgrade process of a web frontend project, the old route can be kept accessing the new page, reducing the problem of old route failure and redirection to the new route. At the same time, the sub-routes of the published frontend routes can be effectively replaced based on the dynamic route replacement method, thereby achieving the effect of dynamically replacing the intermediate pages of existing sub-applications, reducing the probability of re-releasing a complete new application during business iteration, thereby improving business iteration efficiency and solving a specific scenario problem in web frontend engineering.

[0021] In this application, the sub-application is loaded based on the micro-frontend container to dynamically resolve the sub-application static resources that need to be accessed, wherein the micro-frontend container and the sub-application are all running in the browser, and the code development is all in the business project. Therefore, this application can achieve this purpose without going through the network proxy layer. This application registers and sets the route mapping table in the browser so that the dynamic route replacement process is carried out in the micro-frontend container (web container), thereby solving the problem that the traditional solution of registering mapping information in the proxy layer or in the static server has complex operation and maintenance deployment and cumbersome maintenance, and in the process of service software delivery and implementation, the software service provider in most cases cannot or has limited control over the logic of the proxy layer.

[0022] This application registers and sets a route mapping table in the browser, loads the sub-application based on the micro-frontend container, and dynamically resolves the sub-application static resources that need to be accessed according to the set route mapping table. It is a method based on micro-frontends to replace new routes with old routes. This method has been applied in actual projects. Compared with traditional business upgrades and framework upgrades, the entire business development progress needs to be given up to the technical transformation of the entire project. The dynamic route replacement method based on micro-frontends described in this application does not need to wait for the complete application migration and upgrade to be completed. The entire team can switch to using new project frameworks and templates to develop new businesses. At the same time, the old project business code can be gradually migrated and the consistent access experience on the user side can be maintained, which greatly shortens the business iteration time and reduces the contradiction between technical upgrades and business progress.

[0023] This application dynamically parses the specific sub-application static resources that need to be accessed by loading sub-applications based on micro-frontend containers. When the intermediate pages of certain established businesses need to be temporarily adjusted in subsequent iterations, there is no need to copy, modify, and publish the historical code. Instead, new business pages can be directly developed, and new applications can be published by replacing routes. The specific static resources loaded by the old route sub-path are determined by the micro-frontend web container, which can achieve the purpose of adjusting the business logic of specific pages without intruding into the old code, and only keep the context input and output of the replaced page consistent, thereby reducing the difficulty and cost of maintaining old projects when individual businesses change. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 Shown is a schematic diagram of an application scenario of the dynamic routing replacement method based on micro-frontends described in an embodiment of the present application.

[0025] Figure 2 Shown is a flow chart of a dynamic routing replacement method based on a micro front end as described in an embodiment of the present application.

[0026] Figure 3A It is a schematic diagram showing the prior art of loading different static resources by route in an embodiment of the present application.

[0027] Figure 3B It is a schematic diagram showing the prior art of loading different static resources by routing in another embodiment of the present application.

[0028] Figure 3C Shown is a schematic diagram of loading different static resources by routing in an embodiment of the present application as described in the embodiment of the present application.

[0029] Figure 4A Shown is a schematic diagram of a sub-application page access process described in an embodiment of the present application in one embodiment.

[0030] Figure 4B Shown is a schematic diagram of the sub-application page access process described in an embodiment of the present application in another embodiment.

[0031] Figure 4C Shown is a schematic diagram of the sub-application page access process described in the embodiment of the present application in yet another embodiment.

[0032] Figure 5 Shown is an overall flow chart of the micro-frontend-based dynamic routing replacement method described in an embodiment of the present application.

[0033] Figure 6 Shown is a structural schematic diagram of a micro-frontend-based dynamic routing replacement system described in an embodiment of the present application.

[0034] Figure 7 Shown is a schematic diagram of the structure of an electronic device described in an embodiment of the present application.

[0035] Component number description

[0036] 1 Dynamic routing replacement system based on micro frontend

[0037] 11 Access request receiving module

[0038] 12 Mapping table acquisition module

[0039] 13 Logic matching module

[0040] 14 Loading Modules

[0041] 2 Electronic devices

[0042] 21 Memory

[0043] 22 Processor

[0044] S1~Sn Steps DETAILED DESCRIPTION

[0045] The following describes the embodiments of the present application through specific examples, and those skilled in the art can easily understand other advantages and effects of the present application from the contents disclosed in this specification. The present application can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present application. It should be noted that the following embodiments and features in the embodiments can be combined with each other without conflict.

[0046] It should be noted that the illustrations provided in the following embodiments are only schematic illustrations of the basic concept of the present application, and thus the drawings only show components related to the present application rather than being drawn according to the number, shape and size of components in actual implementation. In actual implementation, the type, quantity and proportion of each component may be changed at will, and the component layout may also be more complicated.

[0047] The following embodiments of the present application provide a dynamic route replacement method, system, device and medium based on a micro-frontend, which solves the problem that the method of loading different static resources by route in the prior art has complex operation and maintenance deployment, resulting in cumbersome maintenance and high maintenance costs.

[0048] This application provides an application scenario of a dynamic routing replacement method based on a micro front end, such as Figure 1 As shown, it includes a micro-frontend web container, a backend system service, several micro-frontend sub-applications, and a global static resource distribution service. The micro-frontend web container is connected to the backend system service, the micro-frontend web container is connected to each micro-frontend sub-application, and the micro-frontend web container and each micro-frontend sub-application are connected to the global static resource distribution service. Among them, the micro-frontend web container and each micro-frontend sub-application are running in the browser.

[0049] Each micro-frontend sub-application registers its own accessible routing information into the back-end system service. The micro-frontend web container reads the routing information accessible to each micro-frontend sub-application from the back-end system service, identifies the access request (browser address bar URL) entered by the user through the browser based on the read routing information, and matches the logical matching rules based on the mapping relationship between the routes in the read routing information to obtain the specific sub-application static resources that need to be loaded for the current user access request.

[0050] The global static resource distribution service is responsible for hosting static resources shared by all micro-front-end sub-applications, such as CSS and JavaScript files. The technical solution in the embodiment of the present application will be described in detail below in conjunction with the accompanying drawings in the embodiment of the present application.

[0051] like Figure 2 As shown, this embodiment provides a dynamic routing replacement method based on a micro-frontend, which is applied to a micro-frontend container running on a browser, and the method includes:

[0052] In step S1, an access request sent by a user is received; the access request is a uniform resource path.

[0053] Specifically, the access request is a uniform resource path, usually a URL (Uniform Resource Locator), which is a concise representation of the location and access method of resources on the Internet, commonly known as a "website address". The URL contains information such as the resource's protocol, host name, path, etc., and can uniquely identify resources on the Internet, allowing users to accurately find and access target resources.

[0054] In step S2, obtain the set route mapping table in the micro-frontend container; the set route mapping table includes first routing information and second routing information; the first routing information includes a first accessible route and a sub-application corresponding to the first accessible route; the second routing information includes a second accessible route, a sub-application corresponding to the second accessible route, and a target replacement route corresponding to the second accessible route; the target replacement route is a route in the first accessible route.

[0055] Specifically, the set routing mapping table includes but is not limited to the first routing information and the second routing information. The set routing mapping table contains the routing information of all sub-applications in the micro-frontend container and their target replacement routing information. Any mapping relationship of the sub-application routing that needs to be replaced is in this set routing mapping table.

[0056] In one embodiment, old and new represent two web front-end sub-applications that need to be loaded. The old sub-application needs to publish its accessible routing information to the business system, and return it to the micro-front-end web container as part of the routing list; the new sub-application needs to publish its accessible routing, as well as the target routing information (corresponding to the routing published in old) that each or each group of routing needs to replace to the business system, and also return it to the micro-front-end web container as part of the routing list. This constitutes the set routing mapping table.

[0057] In step S3, according to the access request and the set routing mapping table, a corresponding accessible route is determined by a logic matching rule;

[0058] In step S4, the corresponding sub-application is loaded and displayed according to the accessible route.

[0059] In one embodiment, the micro front-end container (web container) is a web front-end page developed using a micro front-end framework, such as qiankun, singla-spa, microapp, and boundless. The container can controllably select and load and display sub-applications based on the basic information of the web front-end sub-applications declared and installed in the system returned by the interface. The key logic is explained in detail in the instructions for use of each framework. The simple description is to perform certain logical matching based on the URL accessed by the current user, so as to access the specific sub-application static resources.

[0060] In one embodiment, the URL accessed by the user and the URL of the sub-application static resource actually accessed match each other.

[0061] like Figure 1 As shown, taking the URL accessed by the user as " / main / a / b / c" as an example, / main is the route of the micro-frontend container, and the URL of the sub-application loaded at this time is generally / a / b / c. However, what this application needs to achieve is that when the user accesses / main / a / b / c, the sub-application URL accessed is / x / y / z.

[0062] In an embodiment of the present application, according to the access request and the set route mapping table, determining the corresponding accessible route through a logic matching rule includes:

[0063] In step S31, according to the access request, a corresponding first accessible route is obtained from the first routing information through a logic matching rule;

[0064] In step S32, searching in the target replacement route of the second routing information whether there is a route that is the same as the first accessible route;

[0065] In step S33, if it exists, the second accessible route corresponding to the target replacement route having the same target as the first accessible route is used as the accessible route;

[0066] In step S34, if it does not exist, the first accessible route is used as the accessible route.

[0067] In one embodiment, the micro front-end container needs to obtain sufficient information to determine which resources should be used to present a specific route. Now, old and new are used to represent two web front-end sub-applications that need to be loaded.

[0068] In one implementation, before the old sub-application is replaced by the new sub-application: the old sub-application publishes the old route / a / b / c, the user accesses the page with / main / a / b / c, and the browser loads the / a / b / c page resource of the old sub-application.

[0069] In one implementation, after the old sub-application is replaced by the new sub-application: the new sub-application publishes a new route / x / y / z, and registers and declares the mapping relationship between the route / x / y / z and / a / b / c when the new sub-application is installed in the system (the / a / b / c route is presented with the resource pointed to by / x / y / z). The user accesses the page with the / main / a / b / c route, and the browser finds the / x / y / z page resource that needs to be loaded for the new sub-application according to the set route mapping table. At this time, the user sees that the browser is still accessing the / a / b / c route of the old sub-application, but the page actually presented is the / x / y / z page newly published by the new sub-application.

[0070] In one implementation, after the old sub-application is replaced by the new sub-application: the old sub-application also publishes the route / a / d / e, and the user accesses the page with / main / a / d / e. However, because there is no new route mapping relationship indicating that other resources need to be loaded, the browser still loads the / a / d / e page resource of the old sub-application.

[0071] It should be noted that the conventional solution of loading different static resources by route requires registering mapping information in the proxy layer or in the static server, which is determined by the proxy / server and is too cumbersome to maintain. In addition, in the process of service software delivery and implementation, the software service provider cannot or has limited control over the logic of the proxy layer in most cases (see Figure 3A and 3B ).

[0072] like Figure 3A As shown, the routing mapping information is registered in the static server, and the access page obtains the real access page 3 through the routing mapping information in the static server.

[0073] like Figure 3B As shown, the routing mapping information is registered in the gateway, and the access page obtains the real access page 3 through the routing mapping information in the gateway.

[0074] like Figure 3C As shown, the routing mapping information is registered in the browser, and the access page obtains the real access page 3 through the routing mapping information in the browser.

[0075] In this implementation, only some routes in the old sub-application are replaced by the new sub-application. The replacement process is completely performed in the web front-end container, and only the mapping relationship between the old and new routes needs to be registered with the business system (see Figure 3C ). This application will greatly reduce the complexity of operation and maintenance deployment by moving the routing dynamic replacement logic forward to the web container, and can also improve the flexibility and controllability of page resource loading on the business side.

[0076] In one embodiment, the old sub-application needs to publish its accessible routing information to the business system, and return it to the micro-frontend web container as part of the routing list; the new sub-application needs to publish its accessible routing and the target routing information (corresponding to the routing published in old) that each or each group of routing needs to replace to the business system, and also return it to the micro-frontend web container as part of the routing list. This constitutes the above-mentioned set routing mapping table.

[0077] In one embodiment, after the micro-frontend web container obtains the routing list accessible to the business system, it identifies the URL in the browser address bar accessed by the current user, and matches certain rules based on the description information of the routing list, generally prefixes, regular expressions or other judgment conditions combined with business characteristics, to determine the sub-application address that ultimately needs to be loaded, and thus loads it into the correct sub-application entry file (such as index.html), where the sub-application entry file may be slightly different based on different sub-application development frameworks and packaging solutions, and no specific restrictions are made here.

[0078] In one embodiment of the present application, the logic matching rule includes a prefix matching rule, a regular expression matching rule and / or a custom matching rule combined with business characteristics.

[0079] It should be noted that the logical matching rules include but are not limited to prefix matching rules, regular expression matching rules and / or custom matching rules combined with business characteristics. Users can customize matching rules according to actual business characteristics, and no specific restrictions are made here.

[0080] In one embodiment of the present application, loading and displaying the corresponding sub-application according to the accessible route includes:

[0081] In step S41, the corresponding sub-application entry file and service code are obtained according to the accessible route;

[0082] In step S42, the sub-application entry file is parsed according to the service code to obtain corresponding page resources;

[0083] In step S43, the page resource is loaded and displayed.

[0084] In one embodiment, during the matching and loading process through logical matching rules, the sub-application entry file begins to be loaded in the micro-frontend web container, and the browser begins to execute the standard page loading process, that is, parsing the sub-application entry file, loading the entry file defined in the entry file, and <script>、<style>、<link>等标签，此时访问的资源路径均为new子应用发布的资源路径。子应用资源加载完成后，new子应用的代码需要解析地址栏URL，并依据URL来提供对应的页面元素。

[0085] 于本申请一实施例中，根据所述服务代码对所述子应用入口文件进行解析以获取对应的页面资源包括：

[0086] 在步骤S421A、根据所述服务代码对所述子应用入口文件进行解析以获取具体页面路由；

[0087] 在步骤S422A、根据所述具体页面路由获取所述服务代码中对应的页面路由代码；

[0088] 在步骤S423A、将所述页面路由代码中的页面路由替换为所述具体页面路由，以获取替换后的服务代码；

[0089] 在步骤S424A、根据所述替换后的服务代码加载并展示对应的页面资源。

[0090] 于本申请一实施例中，根据所述服务代码对所述子应用入口文件进行解析以获取对应的页面资源包括：

[0091] 在步骤S421B、对所述子应用入口文件进行解析以获取具体页面路由；

[0092] 在步骤S422B、根据所述具体页面路由获取所述服务代码中对应的页面路由映射关系；

[0093] 在步骤S423B、根据所述页面路由映射关系获取对应的待展示页面路由；

[0094] 在步骤S424B、根据所述待展示页面路由加载并展示对应的页面资源。

[0095] 于本申请一实施例中，根据所述服务代码对所述子应用入口文件进行解析以获取对应的页面资源包括：

[0096] 在步骤S421C、根据所述服务代码对所述子应用入口文件进行解析以获取具体页面路由；

[0097] 在步骤S422C、根据所述具体页面路由和所述设定路由映射表获取对应的待展示页面路由；

[0098] 在步骤S423C、根据所述待展示页面路由加载并展示对应的页面资源。

[0099] 于一实施例中，常规的web前端项目都只能要求URL与代码中声明的路由完全一致，否则无法正确判断该提供哪些页面元素。因此子应用的路由逻辑需要重新定义，来满足上述所述的页面访问行为。

[0100] 在一实现方式中，修改子应用中路由表声明，一般为route对象，将子应用的子路由修改为替换目标的路由结构，仅仅在发布时将子应用发布到新的路由前缀下；如：被替换路由 / a / b / c，在浏览器中访问 / main / a / b / c，替换后新的前端子应用将读取浏览器地址栏路由 / main / a / b / c，拆解掉web容器的前缀后，子应用得到子路由 / a / b / c，那么子应用开发时内部的路由定义也定义成 / a / b / c即可正常运作，并且静态资源发布的路径是 / new / a / b / c(参阅图4A)。

[0101] 如图4A所示，浏览器根据用户输入的地址栏地址，去访问后端服务，获取到web容器，然后执行web容器，web容器的代码获取的浏览器地址栏。web容器运行后，通常按固定规则截取到地址栏上面的部分，拆分成两个部分(base和path，其中，base这个部分就是第三方router里面的一个全局参数，path是具体的路由)。子应用中的第三方router获取base和path信息之后，从静态路由表读取待展示页面路由(即path信息)，并将base和path(待展示页面路由)拼接起来去识别当前要匹配哪个页面。

[0102] 在一实现方式中，弃用传统的路由中间件，自定义路由和页面组件的映射规则，通过通用的路由匹配规则，来指向具体的页面组件，从而可以接受任意的路由地址；这是另一种决定路由和代码渲染内容的实现方式，上述实现方式描述的route对象主要作用就是自动将浏览器地址路径与具体业务页面对应起来，本质上就是一种映射而已，在浏览器地址可能因为不同的业务需求需要定义成不同的路由时，可以在代码层面定义一种映射关系，在匹配到特定路由规则时自动找到特定的页面代码，从而不用如上述所诉静态声明路由和页面的关系(参阅图4B)。

[0103] 如图4B所示，浏览器根据用户输入的地址栏地址，去访问后端服务，获取到web容器，然后执行web容器，web容器的代码获取的浏览器地址栏。web容器运行后，通常按固定规则截取到地址栏上面的部分，拆分成两个部分(base和path，其中，base这个部分就是第三方router里面的一个全局参数，path是具体的路由)。子应用中的自定义router获取base和path信息之后，同时从自定义静态路由表中读取待展示页面路由的页面路由映射关系，从页面路由映射关系中获取对应的待展示页面路由(即path信息)，并将base和path(待展示页面路由)拼接起来去识别当前要匹配哪个页面。其中，自定义静态路由表中包括子应用全部页面的路由信息和路由映射关系表，路由映射关系例如，代码中的地址栏是 / a / b / c，路由映射关系表记录的是 / a / b / c对应一个hash值，比如12345，而在web代码层面自定义实现的逻辑根据这个12345在代码中的页面列表里面做偏移找到具体页面，并返回给浏览器进行子应用渲染。

[0104] 需要说明的是，子应用渲染具体是指在微前端架构中，子应用在主应用中被加载、激活并显示其内容的过程。

[0105] 在一实现方式中，相较于前两种实现方式，本实现方式更为灵活，在子应用被加载时，向后端一次性调取本应用需要响应的目标路由及子应用内的页面映射关系，在运行时动态的确定本身需要呈现的页面元素。结合上述所述两种方案(图4A和4B)，图4B中的方案映射关系仍然是硬编码到代码中的，不利于进一步动态部署，因此可以将旧路由和新路由的映射关系保存到后端数据库中，在新服务加载时将映射关系下载到浏览器前端，从而在部署之前不用修改新项目代码来适应不同部署环境下的浏览器路由(参阅图4B)。

[0106] 如图4C所示，浏览器根据用户输入的地址栏地址，去访问后端服务，获取到web容器，然后执行web容器，web容器的代码获取的浏览器地址栏。web容器运行后，通常按固定规则截取到地址栏上面的部分，拆分成两个部分(base和path，其中，base这个部分就是第三方router里面的一个全局参数，path是具体的路由)。此时web容器通过自定义路由表读取旧路由和新路由的映射关系，此时可直接获取浏览器地址栏对应的待展示页面路由。子应用中的自定义router获取base和path信息以及待展示页面路由之后，可将base和path(待展示页面路由)拼接起来去识别当前要匹配哪个页面。

[0107] 需要注意的是，新旧路由替换必然是因为新旧业务页面有某种关联性，这种路由映射必然是在已知新旧业务替换后是业务兼容的才可以进行，虽然技术上可以直接将页面代码替换掉，但同时一定要坚固新旧业务代码的可替换性。比如，旧页面是提交一个表单并将结果传输到下一个页面进行后续操作，而新页面仅仅只是列表展示，没有表单内容传输到下一个页面，这种替换技术上可行，但明显打破了业务流程上的完整性，是不可取的。上述这几种方案可以根据实际情况各自实现。传统的静态路由映射，在代码开发完成的时候就已经确定了，复杂度逐步递增。

[0108] 于一实施例中，子应用还需要在开发阶段处理静态资源的引用方式。区别于浏览器地址栏路由，静态资源的访问地址可以不用替换，保持项目发布时的路径即可。子应用内所有的静态资源统一发布到全局静态文件服务，并通过使用绝对路径进行访问静态资源，不可采用相对路径。在路由替换行为之下，相对地址会以地址栏路由地址作为基础进行相对访问，但是实际的静态资源是发布在新服务的路由下的。如果存在内联资源，可以考虑使用webpack(一种流行的前端项目打包工具)来辅助管理这些资源的访问，经过webpack预处理的资源，可以在运行时方便的修改资源的路径前缀。

[0109] 其中，绝对地址格式为：https: / / domain / path / to / resource、 / path / to / resource。

[0110] webpack是一个前端资源加载和打包工具，它将项目中的JavaScript以及其他浏览器不支持的扩展语言转换成可以在浏览器中运行的代码。

[0111] 本申请实施例能够满足用户在不需要变更旧的访问路由的情况下，访问到新迁移的项目页面资源。

[0112] 需要说明的是，本申请不要求特定的微前端web容器框架、也不要求特定的子应用开发框架，在一定的静态资源访问形式的约定下，可以依托于任意的微前端方案、web前端开发框架来达到目的，其他的静态资源发布方案均参考行业通行准则即可。

[0113] 图5显示为本申请实施例所述的基于微前端的动态路由替换方法的整体流程图。如图5所示，首先开发web容器以支持动态加载子应用代码、加载子应用路由信息，部署web容器；

[0114] 其次开发web子应用以提供页面代码、路由信息，并部署子应用，静态资源服务负责托管所有子应用共享的静态资源，如CSS和JavaScript文件。通过配置如Nginx这样的静态资源服务器，可以高效地管理和分发这些资源。

[0115] 再次，开发路由注册接口以提供路由注册服务，并部署路由注册服务，根据所部署的子应用注册子应用路由，以完成路由注册服务。

[0116] Web容器通过从静态资源服务中加载子应用代码资源，从路由注册服务中加载子应用路由信息，根据所加载的子应用代码资源和子应用路由信息，通过执行子应用代码，来动态匹配子应用路由以获取待展示子应用，进而渲染待展示子应用，以提供web内容。

[0117] 本申请实施例所述的基于微前端的动态路由替换方法的保护范围不限于本实施例列举的步骤执行顺序，凡是根据本申请的原理所做的现有技术的步骤增减、步骤替换所实现的方案都包括在本申请的保护范围内。

[0118] 本申请实施例还提供一种基于微前端的动态路由替换系统，所述基于微前端的动态路由替换系统可以实现本申请所述的基于微前端的动态路由替换方法，但本申请所述的基于微前端的动态路由替换方法的实现装置包括但不限于本实施例列举的基于微前端的动态路由替换系统的结构，凡是根据本申请的原理所做的现有技术的结构变形和替换，都包括在本申请的保护范围内。

[0119] 如图6所示，本实施例提供一种基于微前端的动态路由替换系统，所述系统1包括：访问请求接收模块11、映射表获取模块12、逻辑匹配模块13和加载模块14。

[0120] 所述访问请求接收模块11用于接收用户所发送的访问请求；所述访问请求为统一资源路径；

[0121] 所述映射表获取模块12用于获取所述微前端容器中的设定路由映射表；所述设定路由映射表包括第一路由信息和第二路由信息；所述第一路由信息包括第一可访问路由和所述第一可访问路由对应的子应用；所述第二路由信息包括第二可访问路由、所述第二可访问路由对应的子应用和所述第二可访问路由对应的目标替换路由；所述目标替换路由为所述第一可访问路由中的路由；

[0122] 所述逻辑匹配模块13用于根据所述访问请求和所述设定路由映射表，通过逻辑匹配规则确定对应的可访问路由；

[0123] 所述加载模块14用于根据所述可访问路由加载并展示对应的子应用。

[0124] 需要说明的是，本申请实施例所述的访问请求接收模块11、映射表获取模块12、逻辑匹配模块13和加载模块14的功能或操作与上述基于微前端的动态路由替换方法中的步骤一一对应，故在此不再赘述。

[0125] 在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置或方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅是示意性的，例如，模块 / 单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块或单元可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

[0126] 作为分离部件说明的模块 / 单元可以是或者也可以不是物理上分开的，作为模块 / 单元显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块 / 单元来实现本申请实施例的目的。例如，在本申请各个实施例中的各功能模块 / 单元可以集成在一个处理模块中，也可以是各个模块 / 单元单独物理存在，也可以两个或两个以上模块 / 单元集成在一个模块 / 单元中。

[0127] 本领域普通技术人员应该还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

[0128] 如图7所示，本实施例提供一种电子设备，所述电子设备2包括：存储器21和处理器22。

[0129] 所述存储器21用于存储可执行程序；

[0130] 所述处理器22用于执行所述可执行程序，以使所述电子设备2执行上述所述的基于微前端的动态路由替换方法。

[0131] 本申请实施例还提供了一种计算机可读存储介质。本领域普通技术人员可以理解实现上述实施例的方法中的全部或部分步骤是可以通过程序来指令处理器完成，所述的程序可以存储于计算机可读存储介质中，所述存储介质是非短暂性(non-transitory)介质，例如随机存取存储器，只读存储器，快闪存储器，硬盘，固态硬盘，磁带(magnetic tape)，软盘(floppy disk)，光盘(optical disc)及其任意组合。上述存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。该可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如数字视频光盘(digital video disc，DVD))、或者半导体介质(例如固态硬盘(solid state disk，SSD))等。

[0132] 综上所述，本申请所述的基于微前端的动态路由替换方法、系统、设备及介质，具有以下有益效果：

[0133] 本申请在根据路由加载不同子应用静态资源的过程中，通过在浏览器中注册设定路由映射表，使得动态路由替换过程在微前端容器(web容器)中进行，相比传统的在代理层或者在静态服务器注册映射信息技术方案，本申请将路由动态替换逻辑前移到web容器中能够大大降低运维部署的复杂度，从而解决维护繁琐以及维护成本高的问题，同时能在业务侧也能够提高页面资源加载的灵活性、可控性。

[0134] 本申请通过在微前端容器(web容器)中进行动态路由替换过程，使得web前端项目在迭代、迁移、技术升级过程中，能够保持旧路由访问到新的页面，减少旧路由失效、重定向到新路由的问题。同时能够基于动态路由替换方法将已经发布的前端路由的子路由进行有效替换，从而达到动态替换已有子应用的中间页面的效果，减少业务迭代过程中重新发布完整新应用的概率，从而提高业务迭代效率，解决了web前端工程化中的一个特定场景的问题。

[0135] 本申请中通过基于微前端容器加载子应用，来动态解析需要访问的子应用静态资源，，其中，微前端容器及子应用均运行于浏览器中，代码开发均处于业务项目，因此本申请可以不通过网络代理层来达到此目的，本申请通过在浏览器中注册设定路由映射表，以使动态路由替换过程在微前端容器(web容器)中进行，从而能够解决通过在代理层或者在静态服务器注册映射信息的传统方案运维部署复杂、维护繁琐，且在服务软件交付实施过程中，软件服务提供方大多数情况下是无法或有限控制代理层的逻辑的问题。

[0136] 本申请通过在浏览器中注册设定路由映射表，基于微前端容器加载子应用，以根据设定路由映射表来动态解析需要访问的子应用静态资源，是一种基于微前端的、用旧路由替换新路由的方法，此方法已在实际项目中得到应用，相比传统的业务升级、框架升级，需要整个业务开发进度让渡于整个项目的技术改造，本申请所述的基于微前端的动态路由替换方法不需要等待完整的应用迁移、升级完成，就可以全团队转向使用新的项目框架、模版来进行新业务开发，同时可以渐进的迁移旧项目业务代码，并且保持用户侧的一致性访问体验，大大缩短了业务迭代的时间，减少了技术升级与业务进度之间的矛盾。

[0137] 本申请通过基于微前端容器加载子应用，来动态解析需要访问的具体的子应用静态资源，在后续迭代需要对某些既定业务的中间页面进行临时调整时，不需要对历史代码进行复制再修改再发布，而是能够直接开发新的业务页面，同时以替换路由方式发布新应用。由微前端web容器决定旧路由子路径加载的具体静态资源，能够实现不侵入旧代码，仅保持被替换页面的上下文输入输出一致，即可调整具体页面业务逻辑的目的，从而在个别业务变动时，降低对于旧项目的维护难度及成本。

[0138] 本申请实施例还可以提供一种计算机程序产品，所述计算机程序产品包括一个或多个计算机指令。在计算设备上加载和执行所述计算机指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机或数据中心进行传输。

[0139] 所述计算机程序产品被计算机执行时，所述计算机执行前述方法实施例所述的方法。该计算机程序产品可以为一个软件安装包，在需要使用前述方法的情况下，可以下载该计算机程序产品并在计算机上执行该计算机程序产品。

[0140] 上述各个附图对应的流程或结构的描述各有侧重，某个流程或结构中没有详述的部分，可以参见其他流程或结构的相关描述。

[0141] 上述实施例仅例示性说明本申请的原理及其功效，而非用于限制本申请。任何熟悉此技术的人士皆可在不违背本申请的精神及范畴下，对上述实施例进行修饰或改变。因此，举凡所属技术领域中具有通常知识者在未脱离本申请所揭示的精神与技术思想下所完成的一切等效修饰或改变，仍应由本申请的权利要求所涵盖。< / script>

Claims

1. A dynamic routing replacement method based on micro front-end, characterized in that: Applied to a micro-frontend container running on a browser, the method includes: Receive an access request sent by a user; the access request is a unified resource path; Obtain a set route mapping table in the micro-frontend container; the set route mapping table includes first route information and second route information; the first route information includes a first accessible route and a sub-application corresponding to the first accessible route; the second route information includes a second accessible route, a sub-application corresponding to the second accessible route, and a target replacement route corresponding to the second accessible route; the target replacement route is a route in the first accessible route; According to the access request and the set route mapping table, determining a corresponding accessible route through a logical matching rule; The corresponding sub-application is loaded and displayed according to the accessible route.

2. The method for dynamic routing replacement based on micro front-end according to claim 1, characterized in that: According to the access request and the set routing mapping table, determining the corresponding accessible route through a logical matching rule includes: According to the access request, obtaining a corresponding first accessible route in the first routing information through a logic matching rule; Searching whether there is a route identical to the first accessible route in the target replacement route of the second routing information; If so, taking the second accessible route corresponding to the target replacement route having the same destination as the first accessible route as the accessible route; If not present, the first accessible route is used as the accessible route.

3. The micro-frontend-based dynamic routing replacement method according to claim 1 or 2, characterized in that: The logical matching rules include prefix matching rules, regular expression matching rules and / or custom matching rules combined with business characteristics.

4. The method for dynamic routing replacement based on micro front-end according to claim 1, characterized in that: Loading and displaying corresponding sub-applications according to the accessible routes include: Obtain corresponding sub-application entry files and service codes according to the accessible routes; Parsing the sub-application entry file according to the service code to obtain corresponding page resources; Load and display the page resource.

5. The method for dynamic routing replacement based on micro front-end according to claim 4, characterized in that: Parsing the sub-application entry file according to the service code to obtain the corresponding page resource includes: Parsing the sub-application entry file according to the service code to obtain a specific page route; Acquire the corresponding page routing code in the service code according to the specific page routing; Replacing the page route in the page routing code with the specific page route to obtain a replaced service code; The corresponding page resources are loaded and displayed according to the replaced service code.

6. The method for dynamic routing replacement based on micro front-end according to claim 4, characterized in that: Parsing the sub-application entry file according to the service code to obtain the corresponding page resource includes: Parse the sub-application entry file to obtain specific page routing; Acquire a corresponding page route mapping relationship in the service code according to the specific page route; Obtaining the corresponding route of the page to be displayed according to the page route mapping relationship; Load and display the corresponding page resources according to the route of the page to be displayed.

7. The method for dynamic routing replacement based on micro front-end according to claim 4, characterized in that: Parsing the sub-application entry file according to the service code to obtain the corresponding page resource includes: Parsing the sub-application entry file according to the service code to obtain a specific page route; Acquire the corresponding to-be-displayed page route according to the specific page route and the set route mapping table; Load and display the corresponding page resources according to the route of the page to be displayed.

8. A dynamic routing replacement system based on micro front-end, characterized in that: The system comprises: An access request receiving module, used to receive an access request sent by a user; the access request is a unified resource path; A mapping table acquisition module, used to acquire a set route mapping table in the micro-frontend container; the set route mapping table includes first route information and second route information; the first route information includes a first accessible route and a sub-application corresponding to the first accessible route; the second route information includes a second accessible route, a sub-application corresponding to the second accessible route, and a target replacement route corresponding to the second accessible route; the target replacement route is a route in the first accessible route; A logic matching module, used to determine a corresponding accessible route through a logic matching rule according to the access request and the set route mapping table; The loading module is used to load and display the corresponding sub-application according to the accessible route.

9. An electronic device, characterized in that: The electronic device comprises: A memory for storing executable programs; A processor, configured to execute the executable program so that the electronic device executes the dynamic routing replacement method based on a micro front end according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by an electronic device, the dynamic routing replacement method based on a micro-front end as described in any one of claims 1 to 7 is implemented.

Images