A method for dynamic registration and anomaly monitoring of sub-applications based on micro-frontends

Abstract

This application belongs to the field of front-end multi-application integration, and presents a method for dynamic registration and exception monitoring of sub-applications based on micro-frontends. First, detailed sub-application information is configured in the management center, and dynamic menu routes are generated based on this information. Then, sub-applications are filtered according to their current status, enabling dynamic registration. When a sub-application menu is clicked, the route changes, automatically triggering route matching rules. After the sub-application is mounted, the user is redirected to the corresponding sub-application page. Finally, event tracking is implemented in the sub-applications to enable global exception capture. When a front-end exception occurs in a sub-application, it is automatically captured, and the sub-application information and error logs are reported to the main application. The main application processes the error logs and stores them in the database. This effectively avoids the complex operation of modifying configuration files when integrating sub-applications, while also enabling visual management of sub-application status and reducing the workload of operation and maintenance management of the micro-frontend architecture.

Description

Technical Field

[0001] This application belongs to the field of front-end multi-application integration, and specifically relates to a method for dynamic registration and anomaly monitoring of sub-applications based on micro-frontends. Background Technology

[0002] As the manufacturing industry moves towards informatization, the iteration frequency of application software is accelerating with increasing business demands. Therefore, enterprise middleware and frontware need higher development efficiency and operational capabilities. Current enterprise information platforms integrate multiple business domains, each of which can be divided into several specific business types, requiring collaborative development by multiple project teams. However, different teams use different technology stacks (React, Vue, Umi, etc.), making multi-technology stack integration a hot research topic, leading to the concept of micro-frontends.

[0003] As business complexity increases and the need for aggregation arises as businesses grow, front-end development is increasingly trending towards monolithic applications. In traditional models, while various management tools minimize development complexity, a lightweight application can gradually evolve into a "monolithic application" as the number of participants increases, teams change, and business logic becomes more refined. This results in poor application performance and high development and maintenance costs, leading to the emergence of micro-frontend architectures.

[0004] Micro-frontend architecture primarily involves breaking down a monolithic application according to certain logic, transforming it into an aggregate of multiple small frontend applications. These frontend applications operate independently, capable of being developed, packaged, deployed, and run autonomously, thus achieving decoupling between various business modules.

[0005] Qiankun, as a mainstream micro-frontend solution, does not restrict the technology stack when integrating sub-applications. However, it still requires configuring the specific information of the sub-applications in the main application code, which is complex and requires reconfiguration and deployment every time a registration is made. Therefore, the registration process urgently needs to be improved. At the same time, due to the lack of management and exception monitoring for sub-applications, when an exception occurs within a sub-application, it can easily cause chaos and exacerbate internal friction, increasing the complexity of development and daily operation and maintenance.

[0006] The main problems with existing micro-frontend technology solutions are as follows:

[0007] (1) The registration and access of sub-applications affects the main application.

[0008] In the existing Qiankun technical solution, when sub-applications register and integrate, developers still need to modify the main application code or database-related files, making batch registration of sub-applications impossible. The entire integration process suffers from complex configuration and is difficult to maintain. If multiple sub-applications undergo changes, it will result in a large amount of repetitive work and frequent deployment of the main application.

[0009] (2) Lack of state management for sub-applications

[0010] Existing technologies propose a method for managing sub-applications, but this method lacks state management functionality for sub-applications and cannot dynamically switch their online status. When individual sub-applications are in offline maintenance mode, their status in the main application cannot be directly changed, and dynamic registration is not available.

[0011] (3) Lack of monitoring for abnormal states of sub-applications, making it impossible to automatically distinguish the source of abnormalities.

[0012] Existing technologies have proposed a performance testing method for sub-applications, but they lack monitoring of abnormal states within the sub-applications. When an anomaly occurs in a sub-application, it is impossible to quickly locate the problem, leading to untimely problem handling, chaos, and increased workload for developers and operational complexity.

[0013] Therefore, how to efficiently monitor the abnormal state of sub-applications is a problem that needs to be solved. Summary of the Invention

[0014] The purpose of this application is to provide a method for dynamic registration and anomaly monitoring of sub-applications based on micro-frontends, so as to solve the problem that micro-frontends lack state management and anomaly monitoring of sub-applications in the prior art.

[0015] The technical solution of this application is: a method for dynamic registration and anomaly monitoring of sub-applications based on micro-frontends, comprising:

[0016] The main application is initialized and logged in. The main application retrieves a list of information for all sub-applications by calling the reserved information query interface for all sub-applications, and stores it in a specified location in both the browser and the main application.

[0017] The system filters out sub-applications that are online from the sub-application information list and registers them sequentially into the main application's dynamic routing table.

[0018] Activate all online sub-applications using routes in the dynamic routing table, select and execute the lifecycle function corresponding to the sub-application, and record and save the running status information of the sub-application in real time.

[0019] The sub-application is initialized and instrumented within its lifecycle function. Abnormal data of runtime status information is captured through the instrumentation. If abnormal data is captured, the pre-set abnormal log reporting logic is triggered, and the abnormal information is sent to the main application through the abnormal log reporting logic.

[0020] The main application records and stores the exception logs of each sub-application.

[0021] Preferably, the design method for the exception log reporting logic is as follows: A global state pool and an observer pool are set up, and the global state pool and observer pool are connected to each sub-application and the main application. The observer pool reads the exception log information and user information in the global state pool in real time. When exception data is generated in a sub-application, it reports it to the global state pool, generating an exception log. When the observer pool determines that the exception log in the global state pool has changed, it sends the change information of the global state pool to the main application. The main application reads and saves the exception log in the global state pool.

[0022] Preferably, when the global state pool receives abnormal data reported by a sub-application, the new abnormal log will overwrite the original abnormal log.

[0023] Preferably, the observer pool can register and record the observer functions of all sub-applications. When the main application completes login, it sends the logged-in user information to the global state pool. When the user information in the observer pool changes, it reads the user information from the global state pool and sends it to each sub-application. Each sub-application then verifies the user to determine whether they are authorized to log in to that sub-application.

[0024] Preferably, the method for designing the event tracking points is as follows: setting up a window listening function and an exception response function respectively, configuring the exception response function globally through a lifecycle function, and continuously running the window listening function and the exception response function to globally monitor the running status information within the sub-application.

[0025] Preferably, the method for generating the dynamic routing table is as follows: create a dynamic routing menu for all sub-applications based on the information list of the sub-applications, and append the dynamic routing menu to the main application's basic routing menu. Then, recursively process all routes in the main application's basic routing menu, append all sub-application routes to the routing whitelist, define routing rules, and mount the routing module to form a dynamic routing table.

[0026] This application presents a method for dynamic registration and anomaly monitoring of sub-applications based on a micro-frontend. First, detailed sub-application information is configured in the management center, generating dynamic menu routes based on this information. Then, sub-applications are filtered according to their current status, enabling dynamic registration. When a sub-application menu is clicked, the route changes, automatically triggering route matching rules. After the sub-application is mounted, the user is redirected to the corresponding sub-application page. Finally, event tracking is implemented in the sub-applications, enabling global anomaly capture. When a frontend anomaly occurs in a sub-application, it is automatically captured, and the sub-application information and error logs are reported to the main application. The main application processes the error logs and stores them in the database. This effectively avoids the complex operations of modifying configuration files during sub-application integration, while also enabling visual management of sub-application status. This reduces the workload of operation and maintenance management of the micro-frontend architecture and provides data support for developers to monitor sub-application status and perform performance analysis. Attached Figure Description

[0027] To more clearly illustrate the technical solutions provided in this application, the accompanying drawings will be briefly described below. Obviously, the drawings described below are merely some embodiments of this application.

[0028] Figure 1 This is a schematic diagram of the sub-application registration and loading process based on the micro-frontend in this application;

[0029] Figure 2 This is a flowchart illustrating the dynamic registration and state management method for sub-applications under the micro-frontend architecture of this application.

[0030] Figure 3 This is a flowchart of an embodiment of the sub-application anomaly monitoring method based on qiankun in this application;

[0031] Figure 4 This is a schematic diagram of the abnormal information communication method for the micro front-end application in this application. Detailed Implementation

[0032] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0033] A method for dynamic registration and anomaly monitoring of sub-applications based on micro-frontends is proposed. This method controls the dynamic registration of sub-applications by adjusting their online status, while simultaneously monitoring the frontend anomalies of each application in real time, thereby reducing the operation and maintenance costs of sub-applications.

[0034] like Figure 2 As shown, it includes the following steps:

[0035] Step S100: Initialize the main application and log in. After initialization is complete, load and render the login page.

[0036] The main application retrieves a list of information for all sub-applications by calling the reserved information query interface for all sub-applications, and stores it in both the browser and the main application's localstage, thus completing the acquisition of basic information for all sub-applications.

[0037] When retrieving the information list of sub-applications, you can simply call the localstage.

[0038] Step S200: Filter the sub-applications that are online through the sub-application information list.

[0039] As a specific implementation, after configuring sub-application information in the management center, dynamic registration can be achieved based on the current status of the sub-applications. First, the list of sub-applications to be loaded is obtained. Based on the sub-application list cached locally (localstage), the `filter` function is used to filter out all offline sub-applications, retaining only the information of sub-applications with registration permissions (i.e., online sub-applications), and returning detailed information such as the sub-application name, entry point, mounting node, and routing rules. Then, the sub-application registration function `registerApps` is overridden, passing the sub-application name as a parameter to the `filterApps` function for filtering. Based on the input application name, the function searches for detailed information in the previous sub-application list and returns it. Finally, the returned sub-application is registered using the `loadMicroApp` function.

[0040] In this embodiment, the registration is dynamically generated by combining the online status of sub-applications and filtering cached sub-application information, ensuring that only sub-applications that are online are registered, and information on inactive sub-applications is not obtained.

[0041] After the filtering is completed, the sub-applications that are online will be registered into the dynamic routing table of the main application in turn.

[0042] As a specific implementation method, the dynamic routing table is generated as follows: create a dynamic routing menu for all sub-applications based on the information list of the sub-applications, and append the dynamic routing menu to the main application's basic routing menu. Then, recursively process all routes in the main application's basic routing menu, append all sub-application routes to the routing whitelist, define routing rules, and mount the routing module to form a dynamic routing table.

[0043] This makes the main application's routing menu more complete, including not only the main application's basic routing information but also dynamic routing data for sub-applications. This step solves the problem of manually appending sub-application routes to the main application's static routing file every time a sub-application is integrated, saving the workload of route maintenance in the micro-frontend. By implementing dynamic registration through the above steps, monitoring only needs to monitor sub-applications that are online, rather than inactive ones, significantly reducing memory usage.

[0044] Step S300: Activate all online sub-applications using routes in the dynamic routing table, select and execute the lifecycle function corresponding to the sub-application, and record and save the running status information of the sub-application in real time.

[0045] As one specific implementation, the route activation process is as follows: both the main application and sub-applications use history routing mode. When a menu is clicked, the route is checked and the specific sub-application is loaded. Based on the returned list of sub-applications and their activeRule rules, activation is determined. Since the activeRule rule triggered by the sub-application is a string, it is intercepted automatically using route interception. Qiankun binds to route listening events. After the sub-application completes registration, when a route change is detected in the browser, Qiankun's matching logic is automatically triggered. All sub-applications configured with activeRule matching rules are mounted to the specified location according to their mount node (container).

[0046] As a specific implementation, the lifecycle functions are executed as follows: after a route change, the `hashChange` event is triggered; upon detecting an address change, the `reroute` function is executed; and when Qiankun is already running, the sub-application objects in the four states are modified accordingly, and the corresponding lifecycle hooks are triggered. Then, the entry HTML file of the sub-application is processed via `import-html-entry`, parsing out the sub-application's style template and exported lifecycle functions such as `bootstrap`, `mount`, and `unmount`. This is then encapsulated in a sandbox, and the sub-application is rendered after executing the script and adding stylesheets.

[0047] Figure 2This paper illustrates the process of dynamic registration and status management of sub-applications based on a micro-frontend, as described in this application. This mainly includes a sub-application management center, sub-application status switching, sub-application information storage, and dynamic sub-application registration, as follows: After logging in, users access the application management center to manage sub-applications. Sub-applications are registered within the main application using a general central routing base. The main application only possesses the common functions of the platform framework, such as the top navigation bar, side menu, menu management, and application management center. The application management center is specifically used to manage the status of connected sub-applications, involving four preset data interfaces: query, edit, add, and delete. The query interface receives all sub-application information returned from the backend and allows for additional filtering conditions, such as fuzzy searching based on the input sub-application name. The edit interface allows modification of the current status of a sub-application. Since this attribute is used to determine registration permissions during sub-application registration, controlling the switching of sub-application online / offline states enables dynamic registration of sub-applications. When registering a new sub-application in the management center, basic information is required, including the sub-application name, entry point, routing rules, and current status. Since the main framework does not restrict the technology stack of the integrated application, the sub-application has complete autonomy. Therefore, the technology stack used by the sub-application also needs to be recorded. Then, the detailed sub-application information is stored in the database through the add interface. Additionally, the delete interface can be used to remove obsolete sub-applications. Changes to sub-application information will synchronously update the list of all sub-application information cached in the local stage, avoiding resource waste caused by duplicate interface requests.

[0048] Therefore, it is evident that dynamic registration of sub-applications can be achieved by configuring detailed sub-application information in the application management center. The entire sub-application integration process no longer requires modification of the main application code, eliminating complex configuration procedures and avoiding frequent deployments of the main application. This effectively reduces the workload when integrating sub-applications and improves the management, development, and maintenance efficiency of sub-applications in a micro-frontend architecture.

[0049] like Figure 3 As shown, in step S400, the sub-application is initialized and data points are embedded in the lifecycle function. In one specific implementation, after clicking the sub-application menu, the browser route is switched to the corresponding menu route. At this time, the browser will jump to the corresponding sub-application according to the route matching rules. After the sub-application completes initialization, the page details are loaded.

[0050] As a specific implementation method, the design method for event tracking is as follows: set up a window listening function and an exception response function respectively, configure the exception response function globally through a lifecycle function, and continuously run the window listening function and the exception response function to globally monitor the running status information within the sub-application.

[0051] This system captures runtime status information and exception data, including listeners for JavaScript exceptions, Promise exceptions, and Vue project exceptions. Global JavaScript exception listening uses the `window.addEventListener` function, which can capture errors from synchronous tasks, asynchronous tasks, and resource loading. The error information obtained includes: specific exception details, the URL of the exception file, the specific location of the exception (line number, column number), and the exception stack trace. When an exception is captured, pre-defined exception logging logic is triggered. Since `addEventListener` and `try-catch` cannot capture exceptions thrown by Promise instances, when many Promise instances are used in a sub-application, especially when using the Promise-based asynchronous request library axios, the timing of exceptions thrown by asynchronous requests is unpredictable, causing these internal Promise exceptions to not be captured and handled in a timely manner. Therefore, a global Promise exception capture event, `unhandledrejection`, needs to be added. When the sub-application is a Vue project, `window.addEventListener` cannot capture Vue exceptions occurring in Vue files. Since version 2.2.0, Vue has added a unified framework exception capture tool called errorHandler. It can be configured globally using Vue.config.errorHandler to capture errors in the lifecycle hooks of specified components, as well as errors inside Vue custom event handlers, and obtain specific error information and the corresponding Vue instance.

[0052] If abnormal data is captured, the pre-set abnormal log reporting logic is triggered, and the abnormal information is sent to the main application through the abnormal log reporting logic.

[0053] As a specific implementation method, the design approach for the exception log reporting logic is as follows: A global state pool and an observer pool are set up, and these pools are connected to each sub-application and the main application. The observer pool reads exception log information and user information from the global state pool in real time. When exception data is generated in a sub-application, it is reported to the global state pool, generating an exception log. When the observer pool determines that the exception log in the global state pool has changed, it sends the change information to the main application. The main application reads and saves the exception log in the global state pool.

[0054] The observer pool registers and records observer functions from all sub-applications. When the main application completes login, it sends the logged-in user information to the global state pool. When the user information in the observer pool changes, it reads the user information from the global state pool and sends it to each sub-application. Each sub-application then verifies the user's legitimacy to determine if they are qualified to log in, thus preventing erroneous logins.

[0055] In step S500, the main application records and stores the exception logs of each sub-application.

[0056] As a specific implementation, when a sub-application modifies the global public state data of actions, the main application's observer function `onGlobalStateChange` is immediately triggered. Logic for handling sub-application error information is added to this listener function. First, the returned sub-application error logs are preprocessed and summarized. The unified error information includes: sub-application name, sub-application route, file name, column number, row number, error name, error stack trace, and error time. Then, it is stored in the database through an error log addition interface, and the corresponding sub-application error log can be queried in the main application's exception log. Because the returned error information includes the corresponding sub-application information, the problem of difficulty in tracing the source of exceptions in micro-frontend runtime monitoring is effectively solved, improving the efficiency and quality of operation and maintenance work.

[0057] Figure 4 This application illustrates the sub-application exception information communication method based on a micro-frontend.

[0058] As a specific implementation, communication between the main and sub-applications uses actions. First, the main application initializes and exports the global public state actions using the `initGlobalState` function. Then, it imports the actions instance in the front-end entry file and registers observers in the observer pool. When registering a sub-application, the global state actions are passed via props, configuring the sub-application's global state actions. The global state actions must have the same variable and property names as those in the main application. An empty actions instance is declared to receive actions passed from the main application, and an observer function `onGlobalStateChange` is registered to respond to changes in the global state pool `globalState`. The actions instance is then injected into the `mounted` lifecycle hook. When the main application or a sub-application updates the global state pool using the `setGlobalState` function, it notifies the observers, triggering all observer functions. When a user logs into the main application, their token is stored in the global state pool `globalState`, at which point all applications with registered observer functions can use the user token. Clicking a sub-application's menu triggers a route monitoring event, mounting the corresponding sub-application. Upon entering a sub-application, actions are used to retrieve the user token from the global state pool for user verification within the sub-application. After obtaining the corresponding user information, page loading and data rendering are completed. When an exception is detected within the sub-application, the sub-application immediately updates the error log to the global state pool, notifies the main application to trigger the observer function, and stores the updated exception log in the database.

[0059] In summary, this application first configures detailed sub-application information in the management center and generates dynamic menu routes based on this information. Then, it filters sub-applications based on their current status, enabling dynamic registration. When a sub-application menu is clicked, the route changes, automatically triggering route matching rules. After the sub-application is mounted, it redirects to the corresponding sub-application page. Finally, it incorporates event tracking within the sub-applications, enabling global exception handling. When a front-end exception occurs in a sub-application, it automatically captures the exception and reports the sub-application information and error logs to the main application. The main application then processes the error logs and stores them in the database. This effectively avoids the complex operations of modifying configuration files during sub-application integration, while also providing visualized management of sub-application status. This reduces the workload of operation and maintenance management for the micro-frontend architecture and provides data support for developers to monitor sub-application status and perform performance analysis.

[0060] Finally, the following points should be noted: First, in the description of this application, it should be noted that, unless otherwise specified and limited, the terms "installation", "connection", and "linkage" should be interpreted broadly, and can be mechanical or electrical connections, or internal connections between two components, or direct connections. "Up", "down", "left", "right", etc. are only used to indicate relative positional relationships. When the absolute position of the described object changes, the relative positional relationship may change.

[0061] Secondly: The accompanying drawings of the embodiments disclosed in this invention only involve the structures involved in the embodiments disclosed in this invention. Other structures can refer to the general design. In the absence of conflict, the same embodiment and different embodiments of this invention can be combined with each other.

[0062] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for dynamic registration and anomaly monitoring of sub-applications based on micro-frontends, characterized in that, include: The main application is initialized and logged in. The main application retrieves a list of information for all sub-applications by calling the reserved information query interface for all sub-applications, and stores it in a specified location in both the browser and the main application. The system filters out sub-applications that are online from the sub-application information list and registers them sequentially into the main application's dynamic routing table. Activate all online sub-applications using routes in the dynamic routing table, select and execute the lifecycle function corresponding to the sub-application, and record and save the running status information of the sub-application in real time. The sub-application is initialized and instrumented within its lifecycle function. Abnormal data of runtime status information is captured through the instrumentation. If abnormal data is captured, the pre-set abnormal log reporting logic is triggered, and the abnormal information is sent to the main application through the abnormal log reporting logic. The main application records and stores the exception logs of each sub-application; The design method for the exception log reporting logic is as follows: a global state pool and an observer pool are set up, and the global state pool and the observer pool are connected to each sub-application and the main application; the observer pool reads the exception log information and user information in the global state pool in real time, and when exception data is generated in the sub-application, it reports it to the global state pool to generate exception logs; when the observer pool determines that the exception logs in the global state pool have changed, it sends the change information of the global state pool to the main application, and the main application reads and saves the exception logs in the global state pool; When the global state pool receives abnormal data reported by sub-applications, it will overwrite the original abnormal logs with the new abnormal logs.

2. The method for dynamic registration and anomaly monitoring of sub-applications based on micro-frontends as described in claim 1, characterized in that: The observer pool can register and record the observer functions of all sub-applications. When the main application completes the login, it sends the logged-in user information to the global state pool. When the user information in the observer pool changes, it reads the user information in the global state pool and sends it to each sub-application. Each sub-application verifies the user to determine whether the user can log in to the sub-application.

3. The method for dynamic registration and anomaly monitoring of sub-applications based on micro-frontends as described in claim 1, characterized in that: The design method for the event tracking is as follows: set up a window listening function and an exception response function respectively, configure the exception response function globally through a lifecycle function, and continuously run the window listening function and the exception response function to globally monitor the running status information within the sub-application.

4. The method for dynamic registration and anomaly monitoring of sub-applications based on micro-frontends as described in claim 1, characterized in that: The method for generating the dynamic routing table is as follows: create a dynamic routing menu for all sub-applications based on the information list of the sub-applications, and append the dynamic routing menu to the main application's basic routing menu. Then, recursively process all routes in the main application's basic routing menu, append all sub-application routes to the routing whitelist, define routing rules, and mount the routing module to form a dynamic routing table.

Images