A Dynamic Routing Replacement Method, System, Device and Medium Based on Micro Frontends

Abstract

The present application provides a dynamic routing replacement method, system, device and medium based on micro frontends, which is applied to a micro frontend container running in a browser. The method includes: receiving an access request sent by a user; the access request is a uniform resource path; obtaining a set routing mapping table in the micro frontend container; the set routing mapping table includes first routing information and second routing information; determining an accessible route corresponding thereto through a logical matching rule according to the access request and the set routing mapping table; and loading and displaying a corresponding sub-application according to the accessible route. Compared with traditional technical solutions, moving the routing dynamic replacement logic forward to the web container in the present application can greatly reduce the complexity of operation and maintenance deployment, thereby solving the problems of cumbersome maintenance and high maintenance costs.

Description

Technical Field

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

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

[0003] On the premise that the content of a single site is gradually growing, the development process of the web front-end also puts forward the requirement of splitting the monolithic large application during development and combining and presenting multiple tiny monolithic applications during runtime, and the concept of micro front-end emerges as the times require. More and more sites choose to use different micro front-end technologies to achieve local iteration of business, reduce the unstable factors brought by partial business updates to the system, and accelerate the iteration speed of local business.

[0004] On the other hand, with the continuous iterative update of large web applications, due to objective reasons such as experience improvement, business development, and technology upgrade, the same web project needs to be reorganized in business and technology irregularly. Sometimes it involves the entire site, and sometimes only a certain part (sub-application in micro front-end, or a certain web component) needs to perform the foregoing operations.

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

[0006] To solve this problem, for pure static sites, in the prior art, a proxy gateway is considered to determine the specific page static resources that need to be loaded for the route accessed by the user. For example, nginx (used as a reverse proxy) configuration, Konga configuration, etc. are utilized, or it is determined by the static server itself, such as Apache or nginx (used as a static server). However, in the prior art, certain adjustments need to be made to the gateway and proxy, and even special parsing scripts need to be developed and additional route mapping information needs to be attached. For some systems, they are unable to effectively control the network intermediate layer, resulting in problems such as complex operation and maintenance deployment, cumbersome maintenance, and high maintenance costs. Summary of the Invention

[0007] The purpose of this application is to provide a dynamic route replacement method, system, device, and medium based on micro frontends, which are used to solve the problems in the prior art that the method of loading different static resources according to routes has complex operation and maintenance deployment, resulting in cumbersome maintenance and high maintenance costs.

[0008] In the first aspect, this application provides a dynamic route replacement method based on micro frontends, which is applied to a micro frontend container running in a browser. The method includes: receiving an access request sent by a user; the access request is a uniform resource path; obtaining 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; determining a corresponding accessible route according to the access request and the set route mapping table through a logical matching rule; loading and displaying a corresponding sub-application according to the accessible route.

[0009] In an implementation manner of the first aspect, determining a corresponding accessible route according to the access request and the set route mapping table through a logical matching rule includes: obtaining a corresponding first accessible route in the first route information through a logical matching rule according to the access request; searching in the target replacement route of the second route information to see if there is a route identical to the first accessible route; if it exists, using the second accessible route corresponding to the target replacement route identical to the first accessible route as the accessible route; if it does not exist, using the first accessible route as the accessible route.

[0010] In an implementation manner of the first aspect, the logical 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 presenting 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 presenting the page resources.

[0012] In an implementation of the first aspect, parsing the sub-application entry file according to the service code to obtain the corresponding page resources includes: parsing the sub-application entry file according to the service code to obtain the specific page route; obtaining the corresponding page route code in the service code according to the specific page route; replacing the page route in the page route code with the specific page route to obtain the replaced service code; loading and presenting 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 the corresponding page resources includes: parsing the sub-application entry file to obtain the specific page route; obtaining the corresponding page route mapping relationship in the service code according to the specific page route; obtaining the corresponding page route to be presented according to the page route mapping relationship; loading and presenting the corresponding page resources according to the page route to be presented.

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

[0015] In a second aspect, the present application provides a dynamic route replacement system based on micro frontends. The system includes: an access request receiving module for receiving an access request sent by a user; the access request is a uniform resource path; a mapping table obtaining module for obtaining 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 the sub-application corresponding to the first accessible route; the second route information includes a second accessible route, the sub-application corresponding to the second accessible route, and the target replacement route corresponding to the second accessible route; the target replacement route is a route in the first accessible route; a logical matching module for determining the corresponding accessible route according to the access request and the set route mapping table through logical matching rules; a loading module for loading and presenting the corresponding sub-application according to the accessible route.

[0016] In a third aspect, the present application provides an electronic device, which includes: 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 micro frontends as described above.

[0017] In a fourth aspect, the present application provides a computer-readable storage medium, on which a computer program is stored, and when the program is executed by an electronic device, it implements the dynamic routing replacement method based on micro frontends as described above.

[0018] As described above, the dynamic routing replacement method, system, device, and medium based on micro frontends provided by the present application have the following beneficial effects:

[0019] During the process of loading static resources of different sub-applications according to the route in the present application, by registering and setting a route mapping table in the browser, the dynamic routing replacement process is carried out in the micro frontend container (web container). Compared with the traditional information technology solution of registering the mapping in the proxy layer or in the static server, the present application moving the routing dynamic replacement logic forward to the web container can greatly reduce the complexity of operation and maintenance deployment, thus solving the problems of cumbersome maintenance and high maintenance cost. At the same time, it can also improve the flexibility and controllability of page resource loading on the business side.

[0020] By carrying out the dynamic routing replacement process in the micro frontend container (web container) in the present application, during the iteration, migration, and technology upgrade of the web front-end project, it is possible to keep the old route accessing the new page, reducing the problems of the old route becoming invalid and redirecting to the new route. At the same time, it is possible to effectively replace the sub-routes of the already published front-end routes based on the dynamic routing replacement method, thus achieving the effect of dynamically replacing the intermediate pages of the existing sub-applications, reducing the probability of re-publishing the complete new application during the business iteration process, thereby improving the business iteration efficiency and solving a problem in a specific scenario of web front-end engineering.

[0021] In the present application, by loading the sub-application based on the micro frontend container to dynamically resolve the static resources of the sub-application to be accessed, where both the micro frontend container and the sub-application run in the browser and the code development is in the business project, so the present application can achieve this purpose without passing through the network proxy layer. By registering and setting a route mapping table in the browser, the dynamic routing replacement process is carried out in the micro frontend container (web container), thus being able to solve the problems of complex operation and maintenance deployment and cumbersome maintenance of the traditional solution of registering the mapping information in the proxy layer or in the static server, and in the process of software service delivery and implementation, in most cases, the software service provider has no or limited control over the logic of the proxy layer.

[0022] This application sets up a routing mapping table through registration in the browser, loads sub-applications based on a micro-frontend container, and dynamically resolves the static resources of the sub-applications to be accessed according to the set routing mapping table. It is a method based on micro-frontends that replaces old routes with new routes. This method has been applied in actual projects. Compared with traditional business upgrades and framework upgrades, which require the entire business development progress to be sacrificed for the technical transformation of the entire project, the dynamic routing 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 the new project framework and templates for new business development. 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, greatly shortening the business iteration time and reducing the contradiction between technical upgrades and business progress.

[0023] This application dynamically resolves the specific static resources of the sub-applications to be accessed by loading sub-applications based on a micro-frontend container. When temporary adjustments need to be made to the intermediate pages of certain established businesses during subsequent iterations, there is no need to copy, modify, and republish the historical code. Instead, new business pages can be directly developed, and the new application can be published in the form of 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 specific page business logic without invading the old code and only maintaining the consistency of the input and output of the context of the replaced page. Thus, when individual business changes occur, the maintenance difficulty and cost of the old project can be reduced. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 It shows a schematic diagram of the application scenario of the dynamic routing replacement method based on micro-frontends described in the embodiments of this application.

[0025] Figure 2 It shows a schematic diagram of the process of the dynamic routing replacement method based on micro-frontends described in the embodiments of this application.

[0026] Figure 3A It shows a schematic diagram of the prior art loading different static resources according to routes in one embodiment described in the embodiments of this application.

[0027] Figure 3B It shows a schematic diagram of the prior art loading different static resources according to routes in another embodiment described in the embodiments of this application.

[0028] Figure 3C It shows a schematic diagram of this application loading different static resources according to routes in one embodiment described in the embodiments of this application.

[0029] Figure 4A It shows a schematic diagram of the access process of the sub-application page in one embodiment described in the embodiments of this application.

[0030] Figure 4B It shows a schematic diagram of the sub-application page access process described in the embodiments of the present application in another embodiment.

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

[0032] Figure 5 It shows an overall flowchart of the dynamic routing replacement method based on micro frontends described in the embodiments of the present application.

[0033] Figure 6 It shows a schematic structural diagram of the dynamic routing replacement system based on micro frontends described in the embodiments of the present application.

[0034] Figure 7 It shows a schematic structural diagram of the electronic device described in the embodiments of the present application.

[0035] Description of Component Labels

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

[0037] 11 Access request receiving module

[0038] 12 Mapping table acquisition module

[0039] 13 Logic matching module

[0040] 14 Loading module

[0041] 2 Electronic device

[0042] 21 Memory

[0043] 22 Processor

[0044] Steps S1 to Sn Detailed implementation manners

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

[0046] It should be noted that the illustrations provided in the following embodiments only schematically illustrate the basic concept of the present application. Therefore, only the components related to the present application are shown in the drawings, rather than being drawn according to the number, shape, and size of the components in actual implementation. The type, quantity, and ratio of each component in actual implementation can be arbitrarily changed, and the component layout type may also be more complex.

[0047] The following embodiments of the present application provide a dynamic route replacement method, system, device, and medium based on micro frontends, which solve the problems of complex operation and maintenance deployment, cumbersome maintenance, and high maintenance costs in the prior art method of loading different static resources according to routes.

[0048] The present application provides an application scenario of a dynamic route replacement method based on micro frontends, such as Figure 1 shown, including 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 communicatively connected to the backend system service, the micro frontend web container is communicatively connected to each micro frontend sub-application, and the micro frontend web container and each micro frontend sub-application are respectively communicatively connected to the global static resource distribution service. Among them, the micro frontend web container and each micro frontend sub-application both run in the browser.

[0049] Each micro frontend sub-application registers the route information accessible to itself into the backend system service. The micro frontend web container reads the route information accessible to each micro frontend sub-application from the backend system service, identifies the access request (browser address bar URL) input by the user through the browser according to the read route information, and performs matching of the logical matching rules according to the mapping relationship between the routes in the read route 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 the static resources shared by all micro frontend sub-applications, such as CSS and JavaScript files. The technical solutions in the embodiments of the present application will be described in detail below with reference to the accompanying drawings in the embodiments of the present application.

[0051] As Figure 2 shown, this embodiment provides a dynamic route replacement method based on micro frontends, which is applied to a micro frontend container running in a browser. The method includes:

[0052] In step S1, receive the access request sent by the user; the access request is a unified resource path.

[0053] Specifically, the access request is a unified 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 "web address". The URL contains information such as the protocol, host name, and path of the resource, and can uniquely identify resources on the Internet, enabling users to accurately find and access the target resource.

[0054] In step S2, obtain the set routing mapping table in the micro front-end container; the set routing mapping table includes first routing information and second routing information; the first routing information includes a first accessible route and the sub-application corresponding to the first accessible route; the second routing information includes a second accessible route, the sub-application corresponding to the second accessible route, and the target replacement route corresponding to the second accessible route; the target replacement route is the 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 front-end container and their target replacement routing information. The mapping relationship of any sub-application route that needs to be replaced is in this set routing mapping table.

[0056] In one embodiment, use old and new to represent two web front-end sub-applications that need to be loaded. The old sub-application needs to publish its own 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 own accessible routes and the target routes (corresponding to the routes published in the old) that each or each group of routes need to be replaced to the business system, and also return it to the micro front-end web container as part of the routing list. That is, the set routing mapping table is formed.

[0057] In step S3, according to the access request and the set routing mapping table, determine the corresponding accessible route through the logical matching rule;

[0058] In step S4, load and display the corresponding sub-application 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, unbounded. This container can controllably select, load, and display sub-applications according to the basic information of the web front-end sub-applications installed and declared in the system returned by the interface. The key logic is explained in detail in the usage instructions publicly available for each framework. Briefly described, it makes certain logical matches based on the URL accessed by the current user to access the specific static resources of the sub-application.

[0060] In one embodiment, the URL accessed by the user and the URL of the static resources of the sub - application actually accessed are mutually matched.

[0061] Such as Figure 1 shown, taking the URL accessed by the user as " / main / a / b / c" as an example, / main is the route of the micro - front - end container. At this time, the URL of the sub - application to be loaded is generally / a / b / c. What this application needs to achieve is that when the user accesses / main / a / b / c, the URL of the sub - application accessed is / x / y / z.

[0062] In one embodiment of this application, according to the access request and the set routing mapping table, determining the corresponding accessible route through the logical matching rule includes:

[0063] In step S31, according to the access request, obtain the corresponding first accessible route in the first routing information through the logical matching rule;

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

[0065] In step S33, if there is, use the second accessible route corresponding to the target replacement route that is the same as the first accessible route as the accessible route;

[0066] In step S34, if not, use the first accessible route as the accessible route.

[0067] In one embodiment, the micro - front - end container needs to obtain sufficient information to determine whether a specific route should be presented by which resources. Now use old and new 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 resources 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 from the route / x / y / z to / a / b / c when the new sub-application is installed in the system (present the / a / b / c route with the resources pointed to by / x / y / z). When the user accesses the page with the / main / a / b / c route, the browser looks up the / x / y / z page resources of the new sub-application that need to be loaded according to the set route mapping table. At this time, the user still sees that the route accessed in the browser is the / a / b / c route of the old sub-application, but what is 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. When the user accesses the page with / main / a / d / e, but since there is no new route mapping relationship indicating that other resources need to be loaded, the browser still loads the / a / d / e page resources of the old sub-application.

[0071] It should be noted that the conventional traditional scheme of loading different static resources according to the route needs to register mapping information in the proxy layer or in the static server. It is decided by the proxy / server and is too cumbersome to maintain. And during the implementation process of software service delivery, in most cases, the software service provider has no or limited control over the logic of the proxy layer (refer to Figure 3A and 3B ).

[0072] As Figure 3A shown, if the route mapping information is registered in the static server, then when accessing the page, the real access page 3 is obtained through the route mapping information in the static server.

[0073] As Figure 3B shown, if the route mapping information is registered in the gateway, then when accessing the page, the real access page 3 is obtained through the route mapping information in the gateway.

[0074] As Figure 3C shown, if the route mapping information is registered in the browser, then when accessing the page, the real access page 3 is obtained through the route mapping information in the browser.

[0075] In this implementation, only some routes in the old sub-application are replaced by the new sub-application. This replacement process is completely carried out in the web front-end container, and only the mapping relationship between the old and new routes needs to be registered in the business system (refer to Figure 3C ). By moving the route dynamic replacement logic forward to the web container, this application will greatly reduce the complexity of operation and maintenance deployment, 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 the route information it can access to the business system and return it to the micro-frontend web container as part of the route list; the new sub-application needs to publish its accessible routes and the target routes (corresponding to the routes published in the old one) that each or each group of routes need to replace to the business system, and also return it to the micro-frontend web container as part of the route list. That is, the set route mapping table described above is constituted.

[0077] In one embodiment, after the micro-frontend web container obtains the route list accessible to the business system, it identifies the URL in the browser address bar accessed by the current user, and performs matching according to certain rules based on the description information of the route list, generally prefix, regular expression or other determination conditions combined with business characteristics, to determine the address of the sub-application that finally needs to be loaded, so as to load the correct sub-application entry file (such as index.html). Among them, the sub-application entry file may vary slightly based on different sub-application development frameworks and packaging schemes, and no specific restrictions are made here.

[0078] In one embodiment of the present application, the logical matching rules include 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 a prefix matching rule, a regular expression matching rule, and / or a custom matching rule combined with business characteristics. Users can customize the matching rules according to the 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, obtain the corresponding sub-application entry file and service code according to the accessible route;

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

[0083] In step S43, load and display the page resources.

[0084] In one embodiment, during the process of matching and loading through the logical matching rules, the sub-application entry file starts to be loaded in the micro-frontend web container, and at the same time, the browser starts to execute the standard page loading process, that is, parse the entry file of the sub-application and load the <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 frontends, characterized in that, Applied to a micro front-end container running in a browser, the method includes: Receiving an access request sent by a user; the access request is a uniform resource path; Obtaining a set routing mapping table in the micro front-end 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; According to the access request and the set routing mapping table, determining a corresponding accessible route through a logical matching rule; according to the access request, obtaining a corresponding first accessible route in the first routing information through a logical matching rule; searching in the target replacement route of the second routing information to check if there is a route identical to the first accessible route; if there is, using the second accessible route corresponding to the target replacement route identical to the first accessible route as the accessible route; if not, using the first accessible route as the accessible route; Loading and displaying a corresponding sub-application according to the accessible route.

2. The dynamic routing replacement method based on micro frontends according to claim 1, wherein The logical matching rule includes a prefix matching rule, a regular expression matching rule, and / or a custom matching rule combined with business characteristics.

3. The dynamic routing replacement method based on micro frontends according to claim 1, characterized in that, Loading and displaying a corresponding sub-application according to the accessible route includes: Obtaining a 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 corresponding page resources; Loading and displaying the page resources.

4. The dynamic routing replacement method based on micro frontends according to claim 3, wherein 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 a corresponding page route code in the service code according to the specific page route; Replacing the page route in the page route code with the specific page route to obtain a replaced service code; Loading and displaying corresponding page resources according to the replaced service code.

5. The dynamic routing replacement method based on micro frontends according to claim 3, characterized in that 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.

6. The dynamic routing replacement method based on micro frontends according to claim 3, wherein 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 a corresponding page route to be displayed according to the specific page route and the set routing mapping table; Loading and displaying corresponding page resources according to the page route to be displayed.

7. A dynamic routing replacement system based on micro frontends, characterized in that, The system includes: An access request receiving module, configured to receive an access request sent by a user; the access request is a uniform resource path; A mapping table obtaining module, configured to obtain a set routing mapping table in a micro front-end 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 logical matching module, configured to determine a corresponding accessible route according to the access request and the set routing mapping table through a logical matching rule; obtain a corresponding first accessible route in the first routing information according to the access request through the logical matching rule; check whether there is a route identical to the first accessible route in the target replacement route of the second routing information; if there is, use the second accessible route corresponding to the target replacement route identical to the first accessible route as the accessible route; if not, use the first accessible route as the accessible route; A loading module, configured to load and display a corresponding sub-application according to the accessible route.

8. An electronic device, characterized in that, The electronic device includes: A memory, configured to store an executable program; 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 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the electronic device, it implements the dynamic routing replacement method based on a micro front-end according to any one of claims 1 to 6.

Images