Supply chain front-end architecture method for multi-industry dynamic switching and routing adaptation

Abstract

The invention provides a supply chain front-end architecture method for multi-industry dynamic switching and routing adaptation, which relates to the technical field of front-end architecture and comprises the following steps: establishing a hierarchical model by scanning a component dependency relationship, setting a progressive switching strategy, constructing a routing adaptation layer to realize multi-dimensional decision, monitoring a state and executing difference synchronization. And replacing the components according to a preset sequence and setting rollback points. According to the invention, smooth switching of components in different industries is realized, the coupling degree between the components is reduced, the adaptability and reliability of the front-end architecture are improved, and the system is enabled to maintain stable operation in a multi-industry scene.

Description

Technical Field

[0001] The present invention relates to front-end architecture technology, and in particular to a supply chain front-end architecture method for multi-industry dynamic switching and routing adaptation. Background Art

[0002] With the rapid development of e-commerce and supply chain management, supply chain front-end systems need to support business scenarios of multiple industries simultaneously. The supply chain front-end architecture refers to the software architecture that provides user interfaces and interaction functions for the supply chain management system, and it needs to adapt to business rules, processes, and data structures of different industries. The following defects and deficiencies exist in the existing technology in the supply chain front-end architecture for multi-industry dynamic switching and routing adaptation:

[0003] The existing front-end architecture lacks an effective component dependency management mechanism during the industry switching process, resulting in problems such as component dependency confusion and call link interruption when switching industry scenarios, and it is unable to ensure the stability and continuity of the system during the switching process.

[0004] The existing technology lacks a systematic component layering marking strategy, and is unable to effectively distinguish and manage business components at different levels, making the boundaries between industry-specific functions and general functions blurred, and it is difficult to accurately identify the components that need to be replaced when switching industries, reducing the switching efficiency and increasing system risks.

[0005] The existing routing adaptation mechanisms generally adopt static configuration methods, and are unable to dynamically adjust routing rules according to industry switching requirements, lacking a routing decision-making mechanism and exception recovery ability for multi-industry scenarios, and it is difficult to achieve rapid rollback and state recovery in case of switching exceptions, seriously affecting the usability and business continuity of the system in a multi-industry environment. Summary of the Invention

[0006] Embodiments of the present invention provide a supply chain front-end architecture method for multi-industry dynamic switching and routing adaptation, which can solve the problems in the existing technology.

[0007] In a first aspect of embodiments of the present invention, a supply chain front-end architecture method for multi-industry dynamic switching and routing adaptation is provided, including:

[0008] Scanning the dependency relationships of front-end components, extracting the call links, data flows, and life cycle hooks between components, and generating a component dependency graph;

[0009] Based on the component dependency graph, hierarchically marking the front-end components, marking basic components, industry general components, and industry specific components as the first layer, the second layer, and the third layer respectively, and establishing a component layering model;

[0010] Set a progressive switching strategy according to the component layering model. On the basis of keeping the basic components of the first layer running stably, inject the industry - general components of the second layer into the switching buffer. The switching buffer isolates the component running environments of different industries through virtual component containers, and at the same time includes the industry - specific components of the third layer in the replacement queue; construct a routing adaptation layer based on the component layering model, and the routing adaptation layer updates the routing rules through a multi - dimensional routing decision mechanism and hierarchical storage management; monitor the state changes of the original - industry components and target - industry components in the switching buffer, and perform differential synchronization;

[0011] Read the component information in the replacement queue, and replace the original - industry components one by one with the industry - specific components of the target industry in the order preset by the component dependency graph. During the replacement process, maintain the call link between components, record the current system state after each successful component replacement, and mark the current system state as a rollback point; when detecting component replacement anomalies, restore the system to the system state corresponding to the nearest rollback point.

[0012] In an alternative embodiment,

[0013] The steps of scanning the dependency relationships of front - end components, extracting the call links, data flow directions, and life - cycle hooks between components, and generating a component dependency graph include:

[0014] Collect the running data of component instances, record the method call relationships, event trigger records, data transfer paths, and life - cycle state changes between components to form a component behavior log;

[0015] Construct a component communication graph based on the component behavior log. The component communication graph records the method call frequencies, event trigger times, state manager data transfer volumes, and message bus communication volumes between components;

[0016] Perform a timing analysis on the component communication graph, identify the initialization hook call order, update hook trigger chain, data dependency relationships, and destruction hook call order of components, and organize the identified component life - cycle dependency relationships into a component life - cycle dependency tree;

[0017] Calculate the call weights in the component communication graph and the life - cycle weights in the component life - cycle dependency tree, and perform normalization processing on the call weights and the life - cycle weights, and then obtain the dependency strength through weighted summation;

[0018] Generate a component dependency graph based on the call weights and the life - cycle weights, where nodes represent components, edges represent dependency relationships, and the weight of an edge is the normalized dependency strength. When the dependency strength is greater than the preset strength threshold, establish a directed edge between the corresponding nodes.

[0019] In an alternative embodiment,

[0020] The steps of hierarchically marking the front-end components include:

[0021] Construct a component dependency matrix, where the matrix elements of the component dependency matrix represent the degree of dependency between components; extract component feature vectors based on the component dependency matrix, and the component feature vectors include component reuse degree, component coupling degree, component timing weight, and component state complexity. Among them, the component reuse degree is calculated according to the usage frequency of the component in different industry scenarios, the component coupling degree is obtained based on the row and column sums of the component dependency matrix, the component timing weight reflects the position of the component in the business process, and the component state complexity represents the number of states maintained by the component;

[0022] Perform weighted calculation on the component reuse degree, the inverse value of the component coupling degree, the component timing weight, and the inverse value of the component state complexity to obtain the component hierarchy score;

[0023] Calculate dynamic hierarchical thresholds based on the component hierarchy score. The dynamic hierarchical thresholds include a first threshold and a second threshold. The first threshold is the sum of the mean and standard deviation of the component hierarchy score, and the second threshold is the difference between the mean and standard deviation of the component hierarchy score;

[0024] Mark the components hierarchically according to the dynamic hierarchical thresholds, and divide the components into different levels;

[0025] Calculate the ratio of the dependency degree between components in the same layer to the dependency degree between components in different layers to obtain the inter-layer isolation degree. When the inter-layer isolation degree is greater than the preset isolation degree threshold, trigger re-hierarchization.

[0026] In an alternative embodiment,

[0027] The steps of isolating the component running environments of different industries through virtual component containers include:

[0028] Construct an outer resource isolation container, which performs memory isolation, Document Object Model (DOM) isolation, and style isolation on the components. The memory isolation is achieved by allocating independent heap memory spaces for the components and defining access boundaries. The DOM isolation is achieved by creating independent Shadow DOMs and setting access interception rules. The style isolation is achieved by generating unique namespace identifiers and rewriting selector rules;

[0029] Build an inner-layer runtime isolation container, which isolates the running environment, loading, and network requests of components. The running environment isolation is achieved by creating independent JavaScript execution contexts, the loading isolation is achieved by building independent component registries, and the network request isolation is achieved by setting up independent request queues;

[0030] Build an inter-container communication channel between the outer-layer resource isolation container and the inner-layer runtime isolation container. The inter-container communication channel includes point-to-point message transmission, broadcast message transmission, and resource access control. The point-to-point message transmission and the broadcast message transmission are scheduled based on message priorities, and the resource access control determines resource access rules based on access permission tables and resource locking states.

[0031] In an alternative embodiment,

[0032] Build a routing adaptation layer based on the component hierarchical model. The steps of updating routing rules through a multi-dimensional routing decision mechanism and hierarchical storage management in the routing adaptation layer include:

[0033] Analyze the interaction characteristics of components at each level in the component hierarchical model, extract component communication boundaries, and build the basic framework of the routing adaptation layer. The routing adaptation layer is responsible for coordinating request forwarding and response processing between components in different industries;

[0034] Calculate routing weights based on industry dimension, user role dimension, business process dimension, and system load dimension. The routing weights are obtained by weighting component call frequencies, data transfer volumes, and business importance levels. Generate initial routing rules through the routing weights. The initial routing rules record the call relationships and data transmission rules between components;

[0035] Divide the initial routing rules into a memory fast layer and a persistent layer according to the routing weights. Obtain a routing migration index by calculating routing access heat. Trigger rules to migrate between layers based on the routing migration index, and at the same time create backup copies of the routing rules in the memory fast layer;

[0036] Extract request parameter characteristics, call chain characteristics, and business scenario characteristics, generate request fingerprint identifiers, and match and verify the request fingerprint identifiers with industry identifiers. When the verification results are inconsistent, recalculate the routing weights and update the routing rules;

[0037] Collect routing hit rates, routing latencies, exception rates, and business completion rates, calculate routing health scores. When the routing health score is lower than the third threshold, enable the backup copies for request forwarding. When the routing health score is lower than the fourth threshold, rebuild the routing rules based on the request fingerprint identifiers;

[0038] Calculate the routing rule compatibility based on the historical request matching rate and the routing health score, perform atomic replacement on the routing rules with a compatibility higher than the preset compatibility threshold, establish a two-way mapping relationship for the routing rules with a compatibility lower than the preset compatibility threshold, and deploy them for active-active operation. The two-way mapping relationship maintains the data conversion rules between the old and new rules.

[0039] In an alternative embodiment,

[0040] The steps of listening for the state changes of the original industry components and the target industry components in the switching buffer and performing differential synchronization include:

[0041] Intercept the read and write operations of component attributes through the proxy mode to generate an attribute access trace graph, calculate the attribute change weight based on the attribute access trace graph. The attribute change weight is obtained by weighting the change frequency and the access frequency. Dynamically adjust the collection frequency of the state collection points based on the attribute change weight, and record the state transition path;

[0042] Construct a state dependency graph based on the state transition path. The state dependency graph determines the influence scope of state changes through depth-first traversal. Organize the states of the original industry components and the target industry components in the state dependency graph into a state snapshot tree in time series. The nodes of the state snapshot tree record the state version numbers;

[0043] Calculate the state difference set based on the state snapshot tree, sort the state changes in the state difference set according to the difference weight to generate a priority queue. The difference weight is calculated based on the state change amount, state priority, and hierarchical depth influence factor;

[0044] Perform a two-phase commit on the state difference set in the order of the priority queue. Calculate the feasibility score of state merging for each state change item in the pre-commit phase. The feasibility score is calculated based on the conflict resolution rate and the data consistency degree. When the feasibility score meets the preset security threshold, perform the confirm commit;

[0045] Generate a state version number and construct a version link when performing the confirm commit. Roll back the state through the version link when detecting a state synchronization exception.

[0046] In an alternative embodiment,

[0047] Read the component information in the replacement queue, replace the original industry components one by one with the dedicated components of the target industry in the order preset by the component dependency graph, maintain the call link between components during the replacement process, record the current system state after each successful component replacement, and mark the current system state as a rollback point. The steps of restoring the system to the system state corresponding to the nearest rollback point when detecting a component replacement exception include:

[0048] Read the component identification to be replaced from the replacement queue, calculate the component replacement priority score based on the component dependency graph, where the replacement priority score is calculated by weighting the dependency depth, call frequency, and resource occupancy rate between components, and sort the components in the replacement queue according to the replacement priority score;

[0049] Extract the components to be replaced from the sorted replacement queue in sequence, load the target industry components corresponding to the components to be replaced into the component status buffer, and collect the runtime status of the components to be replaced, where the runtime status includes memory data, call parameters, and execution progress;

[0050] Establish a component call mapping table in the component status buffer, where the component call mapping table records the corresponding relationship between the call methods of the original industry components and the target industry components, and migrate the runtime status to the target industry components based on the component call mapping table to complete component replacement and update the call link;

[0051] Collect the system operation metrics after replacement, where the system operation metrics include response time, resource occupancy rate, and business success rate. When the system operation metrics meet the stability requirements, record the current system state as a rollback point and continue to perform the replacement of the next component in the replacement queue;

[0052] When the system operation metrics do not meet the stability requirements, restore the system to the nearest rollback point, mark the currently replaced component as an item to be optimized and write it into the optimization task queue, and the components in the optimization task queue are re-added to the replacement queue after being reconstructed by the component adapter.

[0053] In a second aspect of the embodiments of the present invention, there is provided an electronic device, including:

[0054] A processor;

[0055] A memory for storing instructions executable by the processor;

[0056] Wherein, the processor is configured to call the instructions stored in the memory to execute the method described above.

[0057] In a fourth aspect of the embodiments of the present invention, there is provided a computer-readable storage medium, on which computer program instructions are stored, and when the computer program instructions are executed by a processor, the method described above is implemented.

[0058] Through component dependency relationship scanning and hierarchical marking, the present invention realizes the systematic management of front-end components, makes the component structures in different industry scenarios clearly visible, facilitates targeted optimization and maintenance, and improves the maintainability and scalability of the system.

[0059] The present invention realizes smooth switching between different industry scenarios, reduces system instability during the switching process, provides a more coherent user experience, and at the same time, the multi-dimensional decision-making mechanism of the routing adaptation layer improves the system's adaptability to different industry business rules, enabling the front-end architecture to flexibly respond to complex and changing industry requirements.

[0060] During the component replacement process of the present invention, a rollback point mechanism is set up, combined with an ordered replacement strategy guided by the component dependency graph, which greatly improves the system's fault recovery ability and fault tolerance during industry switching, reduces the risk of system crashes caused by component replacement failures, and ensures the stable operation of the front-end supply chain system in a multi-industry environment. BRIEF DESCRIPTION OF THE DRAWINGS

[0061] Figure 1 is a flowchart of the method for the front-end supply chain architecture of multi-industry dynamic switching and routing adaptation according to an embodiment of the present invention;

[0062] Figure 2 is a schematic diagram of the architecture of the front-end component dependency scanning system;

[0063] Figure 3 is a schematic diagram of the simulation of the operation of components isolated from different industries by virtual component containers;

[0064] Figure 4 is a schematic diagram of the comparison of performance indicators of the differential state synchronization method. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0065] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0066] The technical solutions of the present invention will be described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments.

[0067] Figure 1 is a flowchart of the method for the front-end supply chain architecture of multi-industry dynamic switching and routing adaptation according to an embodiment of the present invention, as Figure 1 shown, the method includes:

[0068] Scan the dependency relationships of front-end components, extract the call links, data flows, and life cycle hooks between components, and generate a component dependency graph;

[0069] Based on the component dependency graph, perform hierarchical marking on the front-end components, mark the basic components, industry-general components, and industry-specific components as the first level, the second level, and the third level respectively, and establish a component hierarchical model;

[0070] Set a progressive switching strategy according to the component hierarchical model. On the basis of keeping the first-level basic components running stably, inject the second-level industry-general components into the switching buffer. The switching buffer isolates the component running environments of different industries through virtual component containers, and at the same time include the third-level industry-specific components in the replacement queue; construct a routing adaptation layer based on the component hierarchical model. The routing adaptation layer updates the routing rules through a multi-dimensional routing decision mechanism and hierarchical storage management; monitor the state changes of the original industry components and target industry components in the switching buffer, and perform differential synchronization;

[0071] Read the component information in the replacement queue, replace the original industry components one by one with the industry-specific components of the target industry in the order preset by the component dependency graph, maintain the call link between components during the replacement process, record the current system state after each successful component replacement, and mark the current system state as a rollback point; when detecting component replacement anomalies, restore the system to the system state corresponding to the nearest rollback point.

[0072] Exemplarily, comprehensively scan the front-end component dependencies by combining static analysis and dynamic monitoring. In the static analysis stage, the system parses the source code and extracts import / export statements, event bindings, and property references; in the dynamic monitoring stage, the system collects component interaction data during application runtime. The two are combined to generate an accurate component dependency graph, which includes method calls, event transmissions, data flows, and life cycle associations between nodes.

[0073] Based on the above dependency graph, the system performs component hierarchical marking. The hierarchical process first constructs a component dependency matrix, calculates component eigenvectors (including reuse degree, coupling degree, timing weight, state complexity), and divides the components into three levels through a dynamic threshold algorithm: the first-level basic components (such as UI controls, utility functions), the second-level industry-general components (such as general forms, data processing), and the third-level industry-specific components (such as specific business processes). The system also calculates the inter-layer isolation degree to ensure the rationality of the hierarchical results.

[0074] After the layering is completed, the system designs a progressive switching strategy. The switching process adopts the strategy of "stabilizing the core, buffering the transition, and gradually replacing", keeping the basic components of the first layer running stably, injecting the industry-general components of the second layer into the switching buffer, and at the same time incorporating the dedicated components of the third layer into the replacement queue. The switching buffer isolates the operating environments of different industries through virtual component container technology to prevent interference between components. The virtual container adopts a two-layer isolation architecture: the outer layer is responsible for resource isolation (memory, DOM, style), and the inner layer is responsible for runtime isolation (execution environment, component loading, network request). Necessary data exchange is achieved through a secure channel between the two layers.

[0075] At the same time, the system constructs a routing adaptation layer based on the component layering model as a bridge between components of different industries. The routing adaptation layer analyzes the interaction characteristics of components, extracts communication boundaries, and establishes a rule system for request forwarding and response processing. Routing decisions are based on multi-dimensional factors such as industry, user role, business process, and system load. The access efficiency is improved through hierarchical storage in the memory fast layer and the persistent layer, and adaptive optimization is achieved.

[0076] During the component switching process, the system continuously monitors the state changes of the original industry components and target industry components in the switching buffer. By intercepting the reading and writing of attributes through the proxy mode, constructing a state dependency graph and calculating the state difference set, a two-phase commit is executed according to the priority to ensure the consistency of state synchronization. At the same time, a version link is constructed to support state rollback in case of exceptions.

[0077] The system extracts components from the replacement queue in the preset order, calculates the replacement priority, loads the target industry components into the state buffer, establishes a call mapping relationship, migrates the runtime state, and completes the component replacement. After each successful replacement, the system collects operation metrics. If the stability requirements are met, the rollback point is recorded; if not, it rolls back to the previous state point, and the problem component is sent to the optimization queue for reconstruction.

[0078] Through the above steps of collaborative work, the present invention realizes the dynamic switching and adaptation of front-end components in multi-industry scenarios, ensures business continuity and system stability, and improves the flexibility and adaptability of the front-end system of the supply chain.

[0079] In an alternative embodiment, the steps of scanning the dependency relationships of front-end components, extracting the call links, data flow directions, and life cycle hooks between components, and generating a component dependency graph include:

[0080] Collect the running data of component instances, record the method call relationships, event trigger records, data transfer paths, and life cycle state changes between components to form a component behavior log;

[0081] Construct a component communication graph based on the component behavior logs, where the component communication graph records the method call frequency, event trigger count, state manager data transfer volume, and message bus communication volume among components;

[0082] Perform a timing analysis on the component communication graph to identify the initialization hook call order, update hook trigger chain, data dependency relationship, and destruction hook call order of components, and organize the identified component lifecycle dependency relationships into a component lifecycle dependency tree;

[0083] Calculate the call weight in the component communication graph and the lifecycle weight in the component lifecycle dependency tree, and perform normalization processing on the call weight and the lifecycle weight, and then obtain the dependency strength through weighted summation;

[0084] Generate a component dependency relationship graph based on the call weight and the lifecycle weight, where nodes represent components, edges represent dependency relationships, and the weight of an edge is the normalized dependency strength. When the dependency strength is greater than a preset strength threshold, a directed edge is established between the corresponding nodes.

[0085] Figure 2 It is a schematic diagram of the front-end component dependency relationship scanning architecture. Exemplarily, in the component instance running data collection stage, the system monitors the components in the front-end application through the instrumentation technology. The system will inject log recording code at the entry and exit of the component's method calls to record the method name, call time, calling component identifier, called component identifier, and the passed parameter values. For example, when component A calls the updateData method of component B, the system will record the timestamp of the call occurrence, the unique identifier of component A, the unique identifier of component B, the updateData method name, and the passed data object. Similarly, the system will listen for the event triggers between components and record the event name, triggering component, receiving component, and event data. For the data flow path, the system will track the component property changes and status update operations and record the data flow from the source component to the target component. For the lifecycle hooks, the system will record the call time, execution time consumption, and context status of each component lifecycle method. These data will be organized into structured component behavior logs in chronological order and stored in JSON format for subsequent analysis and processing.

[0086] When constructing a component communication graph based on component behavior logs, the system extracts communication information between components from the logs and builds a weighted directed graph. In this graph, nodes represent components and edges represent communication relationships between components. The system counts the frequency of method calls between components. For example, within a session period, if component A calls component B's method 15 times in total, the weight 15 is marked on the directed edge. At the same time, the system records the number of event triggers. If component A triggers 10 data update events to component B, this information is also reflected in the weight of the edge. For data passed through a state manager (such as Redux or Vuex), the system calculates the number of data changes and the size of the data volume. For example, if component A passes a total of 500KB of data to component C through the state manager in 20 updates, this information is recorded as the state management traffic from A to C. The message bus traffic is also recorded. For example, component D sends 8 messages to component E through the event bus, with a total data volume of 120KB. Based on these statistical data, the system generates a complete component communication graph, reflecting the interaction intensity and frequency between components.

[0087] In the timing analysis stage, the system analyzes the execution order and dependency relationships of component lifecycle hooks. The system first extracts the call records of all lifecycle hooks from the component behavior logs, sorts them by timestamp, and identifies the hook call sequence during the component initialization process. For example, the system may observe that the mounted hook call of component F triggers the created hook call of component G, indicating that the creation of G depends on the completion of the mounting of F. The system also analyzes the component update chain. For example, when it is detected that the updated hook of component H is triggered and then immediately causes the beforeUpdate and updated hook calls of components I and J, it can be determined that there is an update dependency relationship among H, I, and J. By analyzing the component destruction sequence, the system can identify the destruction dependencies between components. For example, the beforeDestroy hook call of component K causes the destroy method of component L to be triggered, indicating that the destruction of L depends on the destruction process of K. These dependency relationships are organized into a component lifecycle dependency tree, where nodes are components, edges represent lifecycle dependencies, and the dependency types (such as initialization dependency, update dependency, or destruction dependency) are marked on the edges.

[0088] During the dependency strength calculation phase, the system quantifies the call weights in the component communication graph and the lifecycle weights in the component lifecycle dependency tree. The call weights are calculated based on factors such as method call frequency, event trigger count, and data transfer volume. For example, the method call frequency weight can be set to 1 point per call. If a component calls another component 30 times, the weight is 30. The event trigger weight can be set to 1.5 points per event. If there are 20 event triggers, the weight is 30. The data transfer volume weight can be calculated as 5 points per 100KB of data. If 300KB of data is transferred, the weight is 15. The lifecycle weights are assigned different weights according to the importance of initialization dependencies, update dependencies, and destruction dependencies. For example, the initialization dependency weight is 10, the update dependency weight is 5, and the destruction dependency weight is 3. For components M and N, if M has 2 initialization dependencies, 3 update dependencies, and 1 destruction dependency on N, the total lifecycle weight is 2×10 + 3×5 + 1×3 = 38. To make the weights in different dimensions comparable, the system normalizes the call weights and lifecycle weights separately, mapping them to the range between 0 and 1. The final dependency strength is obtained by weighted summation of the normalized call weights and lifecycle weights. For example, the call weight ratio can be set to 0.6 and the lifecycle weight ratio can be set to 0.4.

[0089] In the stage of generating the component dependency graph, the information of the component communication graph and the component lifecycle dependency tree is integrated. First, the node sets of the two source graphs are merged to ensure that all components are represented. Then, for each pair of component nodes (A, B), their call weight values (such as the weighted sum of method call frequency, event triggering, and data transfer volume) are extracted from the component communication graph, and their lifecycle weight values (such as the weighted sum of initialization, update, and destruction dependencies) are extracted from the lifecycle dependency tree. Min-Max normalization is applied respectively to map the two weight values into the range of [0, 1]. The system applies a configurable weighted formula (such as 0.6 × normalized call weight + 0.4 × normalized lifecycle weight) to calculate the comprehensive dependency strength between components. Nodes represent each front-end component, edges represent the comprehensive dependency relationship between components, and the thickness or color of the edges is used to visually represent the dependency strength. The system sets a preset strength threshold based on business requirements, such as 0.5. When the comprehensive dependency strength between two components exceeds this threshold, the system establishes a directed edge between these two nodes to ensure that only truly significant dependency relationships are represented. For example, the normalized weight of component P's method call to component Q is 0.85 (indicating frequent calls), and the normalized lifecycle weight is 0.78 (indicating key lifecycle dependencies). Applying the weighted formula 0.6 × 0.85 + 0.4 × 0.78 = 0.822, the comprehensive dependency strength is obtained as 0.82, which exceeds the threshold of 0.5. The system then establishes a directed edge from P to Q in the dependency graph and marks the weight 0.82. The finally generated component dependency graph not only reflects the communication frequency and data flow between components but also reflects the coupling degree of the lifecycle, comprehensively demonstrating the dependency network among front-end components and providing a key basis for industry switching decisions.

[0090] The present invention realizes the accurate identification and quantification of component dependencies by collecting component behavior logs to construct a component communication graph and performing time series analysis, enabling the system to automatically discover implicit dependencies and key call paths between components, providing a reliable dependency relationship basis for multi-industry dynamic switching, reducing component conflicts and anomalies during industry switching, and improving system stability and industry adaptation efficiency.

[0091] In an alternative embodiment, the steps of hierarchically marking the front-end components include:

[0092] Construct a component dependency matrix, where the matrix elements of the component dependency matrix represent the dependency degree between components; extract component feature vectors based on the component dependency matrix, and the component feature vectors include component reuse degree, component coupling degree, component time series weight, and component state complexity. The component reuse degree is calculated according to the usage frequency of the component in different industry scenarios, the component coupling degree is obtained based on the row and column sums of the component dependency matrix, the component time series weight reflects the position of the component in the business process, and the component state complexity represents the number of states maintained by the component;

[0093] Perform a weighted calculation on the component reuse degree, the inverse value of the component coupling degree, the component timing weight, and the inverse value of the component state complexity to obtain the component hierarchy score;

[0094] Calculate the dynamic stratification thresholds based on the component hierarchy score. The dynamic stratification thresholds include a first threshold and a second threshold. The first threshold is the sum of the mean and the standard deviation of the component hierarchy score, and the second threshold is the difference between the mean and the standard deviation of the component hierarchy score;

[0095] Mark the components according to the dynamic stratification thresholds and divide the components into different levels;

[0096] Calculate the ratio of the dependency degree between components in the same layer and the dependency degree between components in different layers to obtain the inter-layer isolation degree. When the inter-layer isolation degree is greater than the preset isolation degree threshold, trigger re-stratification.

[0097] Exemplarily, during the process of component stratification marking, construct a component dependency matrix. This matrix scans the project code through a static code analysis tool, extracts the import and export relationships between components, and forms an n×n matrix A, where n is the total number of components. The matrix element a[i][j] represents the dependency degree of component i on component j. The dependency degree can be quantified by the number of times component j is referenced in component i. For example, if component A references the attributes or methods of component B 3 times, then a[A][B]=3. For example, in a system with 5 components, the following component dependency matrix is obtained: 0 2 1 0 3; 1 0 2 0 0; 0 1 0 2 1; 3 0 1 0 0; 0 2 0 1 0;

[0099] Based on the component dependency matrix, extract component feature vectors, including component reuse degree, component coupling degree, component timing weight, and component state complexity. The component reuse degree is calculated by analyzing the usage frequency of the component in different industry scenarios. For example, if a certain form component is used 8 times, 5 times, and 3 times in the e-commerce, finance, and education scenarios respectively, then its reuse degree is 16. The component coupling degree is obtained based on the row and column sums of the component dependency matrix, that is, the coupling degree of component i is equal to the sum of the elements in the i-th row and the sum of the elements in the i-th column of matrix A, representing the strength of the dependency relationship between this component and other components.

[0100] The component timing weight reflects the position of the component in the business process and is obtained by analyzing the business process diagram. Components at the front end of the business process have a lower component timing weight, while those at the back end have a higher component timing weight. For example, in the process of login - browse - purchase - payment, the component timing weight of the login component can be set to 0.2, the browse component to 0.4, the purchase component to 0.6, and the payment component to 0.8. The component state complexity represents the number of states maintained within the component and is obtained by counting with a code analysis tool. For example, if a component maintains three states: user information, shopping cart data, and order status, then its state complexity is 3.

[0101] Perform a weighted calculation on the extracted feature vectors to obtain the component - level score. The calculation formula is: Component - level score = w1×Component reuse degree + w2×(1 / Component coupling degree)+w3×Component timing weight + w4×(1 / Component state complexity), where w1, w2, w3, w4 are weight coefficients, and w1 + w2 + w3 + w4 = 1. Different weights can be set according to the project characteristics. For example, w1 = 0.3, w2 = 0.3, w3 = 0.2, w4 = 0.2. Considering that the higher the component reuse degree, the lower the coupling degree, the higher the timing weight, and the lower the state complexity, the component should be at a higher level. Therefore, the inverse values are taken for the coupling degree and state complexity.

[0102] Taking 5 components in a certain project as an example, the component feature vectors and level scores calculated are as follows: Component A (reuse degree 10, coupling degree 12, timing weight 0.3, state complexity 2), and the calculated level score is 10×0.3+(1 / 12)×0.3+0.3×0.2+(1 / 2)×0.2 = 3.075. Similarly, the level score of Component B is 2.56, Component C is 3.82, Component D is 1.93, and Component E is 2.71.

[0103] Statistically analyze the hierarchical scores of all components, and calculate their mean value μ and standard deviation σ. The first threshold T1 is μ + σ, and the second threshold T2 is μ - σ. For example, if the mean value of the above 5 component hierarchical scores is 2.817 and the standard deviation is 0.683, then T1 = 3.5 and T2 = 2.134. Mark the components according to the dynamic hierarchical threshold. After the layering is completed, calculate the inter-layer isolation degree, which is the ratio of the dependency degree between components in the same layer to the dependency degree between components across layers. The dependency degree between components in the same layer is the sum of the dependency relationships between components within the same hierarchy, and the dependency degree between components across layers is the sum of the dependency relationships between components in different hierarchies. For example, in the above layering result, the sum of the dependencies between components in the same layer is 11, and the sum of the dependencies between components across layers is 14, then the inter-layer isolation degree is 11 / 14 ≈ 0.786. When the inter-layer isolation degree is greater than the preset isolation degree threshold (such as 0.8), it indicates that the component layering is not ideal enough, and re-layering will be triggered. Re-layering can be achieved by adjusting the weights of the feature vectors or modifying the layering threshold. For example, if the inter-layer isolation degree is 0.786, which is close to but does not exceed the threshold of 0.8, there is no need for re-layering; if it exceeds the threshold, the weight of the reuse degree can be considered to be increased or the weight of the coupling degree can be reduced to make the component layering more reasonable.

[0104] After completing the division of component level scores based on dynamic hierarchical thresholds, the system will mark components as three types: basic components, industry - general components, and industry - specific components according to the business attributes and level scores of the components. Specifically, components with a level score higher than the first threshold T1 are marked as first - level basic components. These components usually have high reusability, low coupling, moderate timing weights, and low state complexity. For example, UI basic controls, tool function libraries, general data - processing components, etc. They have less association with specific industry business logics. Components with level scores between the first threshold T1 and the second threshold T2 are marked as second - level industry - general components. These components have certain reuse value in multiple industries but contain specific business logics, such as general form validation, data visualization, file upload, and other functional components. Components with level scores lower than the second threshold T2 are marked as third - level industry - specific components. These components usually have low reusability, high coupling, high timing weights, and high state complexity, such as business - process components and professional calculation modules in specific industries. In the above example, component C (score 3.82) is marked as a first - level basic component, component A (score 3.075) and component E (score 2.71) are marked as second - level industry - general components, and component B (score 2.56) and component D (score 1.93) are marked as third - level industry - specific components. After completing the marking, the system establishes a component - layering model. This model not only includes the hierarchical attributes of components but also records information such as the dependency relationships between layers, the industry application scope of components, and the call rules between components, forming a complete component - dependency and layering knowledge base, providing a decision - making basis for subsequent dynamic switching and routing adaptation. This layering model is stored in a graph database, supporting fast query and dynamic update to adapt to the evolution of the component library and the changes in industry requirements.

[0105] The present invention uses dynamic hierarchical thresholds for component - layering marking, enabling the system to intelligently identify and classify components in various industries, forming a clear hierarchical structure, reducing unnecessary dependencies between cross - layer components, improving component reuse efficiency, and ensuring the rationality of layering through inter - layer isolation - degree monitoring, providing a stable and reliable component - level architecture foundation for industry dynamic switching; it can effectively identify the hierarchical attributes of components, guide developers to develop components in a reasonable dependency direction, avoid circular dependencies, and improve code quality and maintainability.

[0106] In an alternative embodiment, the steps of isolating the operating environments of components in different industries through virtual component containers include:

[0107] Build an outer-layer resource isolation container, which isolates the memory, Document Object Model, and styles of components. The memory isolation is achieved by allocating independent heap memory spaces for components and defining access boundaries. The Document Object Model isolation is achieved by creating independent Shadow DOMs and setting access interception rules. The style isolation is achieved by generating unique namespace identifiers and rewriting selector rules.

[0108] Build an inner-layer runtime isolation container, which isolates the runtime environment, loading, and network requests of components. The runtime environment isolation is achieved by creating independent JavaScript execution contexts. The loading isolation is achieved by constructing independent component registries. The network request isolation is achieved by setting independent request queues.

[0109] Build an inter-container communication channel between the outer-layer resource isolation container and the inner-layer runtime isolation container. The inter-container communication channel includes point-to-point message transmission, broadcast message transmission, and resource access control. The point-to-point message transmission and the broadcast message transmission are scheduled based on message priorities. The resource access control determines resource access rules based on access permission tables and resource lock states.

[0110] Exemplarily, when building the outer-layer resource isolation container, the memory isolation is achieved by allocating independent heap memory spaces for each component and defining access boundaries. Specifically, the system creates a virtual memory manager that maintains a component memory allocation table, recording each component ID and its corresponding starting address and size of the memory area. For example, the system allocates 8MB of memory space for component A, with a starting address of 0x80000000 and an ending address of 0x80800000; and allocates 12MB of memory space for component B, with a starting address of 0x81000000 and an ending address of 0x81C00000. When a component attempts to access memory, the virtual memory manager checks whether the access address is within its allocated range. If it exceeds the range, the access request is intercepted and an access denied error is returned. Memory access interception is achieved by rewriting the memory allocation function of the JavaScript engine, wrapping native objects with Proxy objects, and adding boundary check logic to the get and set operations.

[0111] Document object model isolation is achieved by creating an independent Shadow DOM for each component and setting access interception rules. The system creates an independent Shadow DOM root node for each component, and all DOM elements rendered by the components are used as child nodes of this root node. For example, the Shadow DOM root node ID of component A is shadow-root-A, and the root node ID of component B is shadow-root-B. The access interception rules are implemented by overriding relevant methods of the document object, such as querySelector, getElementById, etc., so that these methods can only query elements within the component's own Shadow DOM by default. When a component calls document.querySelector('div.class1'), what is actually executed is shadowRoot.querySelector('div.class1'), where shadowRoot is the Shadow DOM root node of this component. For cross-component DOM operations, the system maintains a DOM access permission table to record the DOM access permission relationships between components and only allows cross-component access with explicit authorization.

[0112] Style isolation is achieved by generating a unique namespace identifier and overriding selector rules. The system generates a 32-bit hash value as the unique identifier for each component. For example, the identifier of component A is "comp-7a8b9c0d", and the identifier of component B is "comp-1e2f3g4h". When parsing the CSS style sheet of a component, the system adds a namespace prefix before each selector, such as converting ".header" to "[data-namespace=comp-7a8b9c0d] .header". At the same time, the system adds the corresponding data-namespace attribute to the root DOM element of the component. To handle possible style conflicts, the system also maintains a style priority table and calculates the finally applied style based on component importance and style specificity. For example, when two components define the same global style, the system decides which style to finally apply according to the component priority, and the style of the component with a higher priority will be retained.

[0113] When building an isolated container for the inner-layer runtime, runtime isolation is achieved by creating independent JavaScript execution contexts. The system creates a sandbox environment for each component, including an independent global object, scope chain, and execution context. The specific implementation method is to use the iframe element or the with statement in JavaScript to create an isolated environment. For example, the system creates an invisible iframe and loads the component code in it, so that the component runs in the window object context of the iframe, isolated from the window object of the main application. For the global APIs that need to be accessed, the system provides proxy objects to perform permission checks and behavior restrictions on API calls. For example, when a component calls the setTimeout function, the actual function called is the proxy function provided by the system, which limits the minimum delay time to 100ms to prevent malicious code from consuming system resources through high-frequency timers.

[0114] Loading isolation is achieved by building an independent component registry. The system maintains a component registry that records the detailed information of the loaded components, including component IDs, version numbers, dependency lists, loading status, etc. When a component needs to be loaded, the system first checks whether the component has been loaded. If not, it starts the loading process; if it has been loaded, it reuses the existing instance. For example, for multiple components that depend on the React library, the system only loads the React library once and injects it into the components that need it. Component loading is asynchronous and is achieved by dynamically creating script tags or using the import() function. After loading is completed, the component status is updated to "loaded".

[0115] Network request isolation is achieved by setting up independent request queues. The system creates an independent network request queue for each component to manage and restrict network requests such as XHR and fetch initiated by the component. The request queue configuration includes the maximum number of concurrent requests, request timeout, retry policy, etc. For example, the maximum number of concurrent requests for component A is 5, and the request timeout is 30 seconds; the maximum number of concurrent requests for component B is 3, and the request timeout is 15 seconds. When a component initiates a network request, the system adds the request to the corresponding queue, processes it according to the first-in, first-out principle, and performs a URL whitelist check based on the component's network permissions to deny access to unauthorized domains.

[0116] A container - to - container communication channel is built between the outer - layer resource isolation container and the inner - layer runtime isolation container. Point - to - point message transmission is achieved through the message event mechanism. Components can send messages to other components via the postMessage method. The message structure includes fields such as sender ID, receiver ID, message type, message content, timestamp, and priority. For example, the message object for component A to send a message to component B is {sender: "comp - A", receiver: "comp - B", type: "data - update", content: {dataId: 123, value: "new - value"}, timestamp: 1623145678, priority: 2}. The system validates the message to ensure that the sender has the permission to send this type of message to the receiver and schedules it according to the priority.

[0117] Broadcast message transmission allows components to send messages to all other components or specific groups of components. The system maintains component grouping information, such as financial groups, medical groups, education groups, etc. divided by industry. The broadcast message includes fields such as sender ID, target group ID, message type, message content, timestamp, and priority. The system schedules messages based on the message priority and the status of the receiving components. High - priority messages are processed first, and idle components receive messages first.

[0118] Resource access control determines resource access rules based on the access permission table and the resource locking status. The system maintains a resource permission table that records the access permission levels of components to various resources (such as DOM, storage, network, etc.). For example, the permission level of component A for localStorage is "read - write", and the permission level for the camera is "forbidden"; the permission level of component B for localStorage is "read - only", and the permission level for the camera is "ask when using". When a component requests access to a resource, the system checks the permission table and the current locking status of the resource to decide whether to allow access. The resource locking mechanism prevents multiple components from modifying shared resources simultaneously. The system uses a read - write lock mode to manage resource access, allowing multiple components to read the resource simultaneously, but only allowing one component to write to the resource.

[0119] When dealing with the scenario of coexistence of components from different industries, the prior art is difficult to balance the isolation intensity and communication efficiency, resulting in problems such as resource conflicts, state pollution, and performance loss. The present invention proposes a two-layer isolation container architecture, which separates the resource isolation and runtime isolation for processing. The outer-layer resource isolation container realizes precise memory boundary control through a virtual memory manager, achieves DOM isolation by using the Shadow DOM technology and access interception rules, and solves style conflicts by using namespaces and dynamic priority calculation. The inner-layer runtime isolation container realizes execution context isolation through a configurable sandbox environment, designs a component registration center to achieve dependency sharing and version control, and constructs a request queue and a permission system to achieve network isolation. A communication channel based on priority is designed between the two layers of containers, which solves the contradiction between isolation and interaction; realizes complete isolation of the running environments of components from different industries, avoids resource conflicts and interference between components, enables components from multiple industries to run in parallel in the same system without affecting each other, and at the same time the communication channel between the containers ensures the necessary data exchange between components, ensuring the stability and security of the system during the industry switching process.

[0120] Figure 3 It is a schematic diagram of the operation simulation of isolating components from different industries for a virtual component container. From the isolation intensity curve, it can be seen that as the isolation level increases, the isolation intensity shows a stepped upward trend and reaches an ideal level of 100% after achieving full outer-layer isolation, indicating that the combination of the Shadow DOM and namespace style isolation technologies can effectively block cross-component pollution. The memory consumption curve shows that although adding an isolation layer will bring additional overhead, through the boundary control and resource sharing mechanism of the virtual memory manager, the memory occupancy under the complete two-layer isolation is only 20%, far lower than the expected level.

[0121] In terms of communication efficiency, it gradually decreases from 100% of pure memory isolation to 60% of complete two-layer isolation. This moderate decrease is the result of the design of the communication channel between the containers. Through the point-to-point message transmission and priority scheduling mechanism, acceptable communication performance is maintained while ensuring isolation. The data line of the resource conflict rate is the most persuasive, significantly decreasing from the initial 80% to 0% under complete two-layer isolation, proving the excellent performance of this technology in preventing resource conflicts.

[0122] In an alternative embodiment, the steps of constructing a routing adaptation layer based on the component hierarchical model and updating routing rules through a multi-dimensional routing decision mechanism and hierarchical storage management include:

[0123] Analyze the interaction characteristics of components at each level in the component hierarchical model, extract the component communication boundaries, and construct the basic framework of the routing adaptation layer, which is responsible for coordinating the request forwarding and response processing between components from different industries;

[0124] Calculate routing weights based on industry dimension, user role dimension, business process dimension, and system load dimension. The routing weights are obtained by weighting component call frequency, data transfer volume, and business importance. Generate initial routing rules through the routing weights. The initial routing rules record the call relationships and data transfer rules between components;

[0125] Divide the initial routing rules into a memory fast layer and a persistence layer according to the routing weights. Obtain a routing migration index by calculating the routing access heat. Trigger rules to migrate between layers based on the routing migration index. At the same time, establish a backup copy for the routing rules in the memory fast layer;

[0126] Extract request parameter features, call chain features, and business scenario features to generate a request fingerprint identifier. Match and verify the request fingerprint identifier with the industry identifier. When the verification result is inconsistent, recalculate the routing weights and update the routing rules;

[0127] Collect routing hit rate, routing latency, exception rate, and business completion rate, and calculate the routing health score. When the routing health score is lower than the third threshold, enable the backup copy to forward requests. When the routing health score is lower than the fourth threshold, reconstruct the routing rules based on the request fingerprint identifier;

[0128] Calculate the routing rule compatibility based on the historical request matching rate and the routing health score. Perform atomic replacement on routing rules with a compatibility higher than the preset compatibility threshold. Establish a two-way mapping relationship for routing rules with a compatibility lower than the preset compatibility threshold and deploy dual-active operation. The two-way mapping relationship maintains the data conversion rules between the old and new rules.

[0129] Exemplarily, comprehensively analyze the interaction characteristics of components at each level in the component layering model. By deeply exploring the data exchange patterns between financial industry components and medical industry components, extract the component communication boundaries. For example, when a financial payment component needs to interact with a medical appointment component, the system identifies the interface differences, data format differences, and security policy differences between the two, so as to construct adaptation and conversion rules. As an intermediate coordination layer, the routing adaptation layer establishes a unified request format conversion mechanism to convert JSON format requests from financial components into XML format that can be received by medical components, realizing seamless docking between heterogeneous systems.

[0130] The routing weight calculation process involves a comprehensive evaluation of multi-dimensional factors. In the industry dimension, the system assigns basic weight values to different industry components such as finance, healthcare, and education. For example, the initial weight of the financial transaction component is 80 points, and the initial weight of the medical data component is 75 points. In the user role dimension, the operation path weight of the administrator is 90 points, and the operation path weight of the ordinary user is 60 points. In the business process dimension, the core transaction process weight is 85 points, and the auxiliary query process weight is 50 points. In the system load dimension, the weight is dynamically adjusted according to the real-time CPU occupancy rate and memory usage. When the system load exceeds 80%, the relevant routing weight is reduced by 15%. Based on component call statistics, the system records that the call frequency of component A reaches 200 times per second, the data transfer volume is 50MB / s, and the business importance is "critical". Based on this, the routing weight of component A is calculated to be 92 points. According to these weight data, the system generates initial routing rules. The system extracts call relationships from component call logs. For example, it is found that the financial component frequently calls the report component. The routing weight is applied to these call relationships, and the path with the higher weight is preferentially selected. Combined with business conditions, rules in the "condition-action" format are formed. For example, when it is found that the "financial administrator" has a high-frequency call from the finance component to the report component with a high weight during "monthly settlement", the system automatically generates a rule: "When the user role is 'financial administrator' and the business process is'monthly settlement', the request is routed from the finance component to the report component". Each rule also records data format requirements, parameter mapping, and timeout settings to ensure the correct transmission of data between components.

[0131] The hierarchical storage management of routing rules achieves a balance between efficient access and reliability. The system places rules with a routing weight higher than 85 points in the memory fast layer, such as financial transaction routing rules and user authentication routing rules. Rules with a weight lower than 85 points are stored in the persistent layer, such as log query routing rules and data statistics routing rules. The system calculates the routing access heat every hour. When the access times of the medical appointment routing rule increase from 10 times per minute to 100 times per minute, the routing migration index increases from 40 to 90, triggering the migration of this rule from the persistent layer to the memory fast layer. At the same time, the system creates a backup copy of the financial payment routing rule in the memory fast layer and stores it in the distributed cache cluster to achieve fast recovery in case of failures.

[0132] The request fingerprint identification mechanism ensures accurate routing matching. When the system receives a medical appointment request, it extracts the request parameter features (such as patient ID, department code, appointment time period), calls the chain features (the request comes from the mobile end and passes through the identity authentication service and hospital selection service), and the business scenario features (regular outpatient appointment) to generate a unique request fingerprint identification "MED-REG-APP-2023110501". The system matches and verifies this identification with the medical industry identification. If it is found that the request carries bank payment information but does not contain a medical security verification code, it is determined that the verification is inconsistent, the routing weight is recalculated (down from the original 78 points to 65 points), and the routing rules are updated to add a security verification check node.

[0133] The routing health monitoring ensures system stability. The system regularly collects various routing metrics, such as the routing hit rate of the financial component is 98%, the routing delay is 15ms, the exception rate is 0.5%, and the business completion rate is 99.5%. The calculated routing health score is 92 points. When the routing health score of the education resource drops to 65 points (below the third threshold of 70 points), the system automatically enables the backup copy to handle request forwarding. When the routing health score of the medical data further drops to 45 points (below the fourth threshold of 50 points), the system reconstructs the routing rules based on the stored request fingerprint identification "MED-DATA-QUERY-2023110502", adjusts the data query path, and avoids performance bottleneck nodes.

[0134] The routing rule update adopts a smooth transition strategy. The system calculates that the compatibility between the V2 version and the V1 version of the financial payment routing rule is 92% (higher than the preset compatibility threshold of 85%), and performs an atomic replacement operation to complete the rule switch within 100 milliseconds. However, the compatibility between the V3 version and the V2 version of the medical imaging routing rule is 75% (lower than the preset compatibility threshold). The system establishes a two-way mapping relationship, dynamically converts the DICOM format data of the V2 version into the compressed DICOM+ format of the V3 version, and the two versions of the rules run simultaneously for 30 days to ensure business continuity. The two-way mapping table stores the field correspondence relationships, such as "patientInfo" in the V2 version is mapped to "patientProfile" in the V3 version, to ensure lossless data conversion.

[0135] Traditional front-end routing is mainly based on URL path matching and lacks multi-dimensional decision-making capabilities. Although the API gateway supports complex routing rules, it focuses on inter-service communication rather than component-level routing. The present invention innovatively proposes a routing adaptation layer that combines a multi-dimensional routing decision mechanism with hierarchical storage management. In terms of the decision mechanism, a comprehensive weight calculation model for industry dimension, user role dimension, business process dimension, and system load dimension is introduced to achieve precise context-aware routing. In terms of storage management, a two-layer structure of a memory fast layer and a persistent layer is designed, and the access efficiency is optimized through a dynamic routing heat migration mechanism. What is particularly innovative is the request fingerprint identification and health monitoring mechanism. The former realizes precise request classification through multi-feature fusion, and the latter realizes fault self-healing through multi-index monitoring. The dual-active deployment strategy and the bidirectional mapping relationship solve the version compatibility problem.

[0136] In an alternative embodiment, the steps of listening to the state changes of the original industry component and the target industry component in the switching buffer and performing differential synchronization include:

[0137] Intercept the read and write operations of component attributes through the proxy mode to generate an attribute access trace graph, calculate the attribute change weight based on the attribute access trace graph, where the attribute change weight is obtained by weighting the change frequency and the access frequency, dynamically adjust the collection frequency of the state collection point based on the attribute change weight, and record the state transition path;

[0138] Construct a state dependency graph based on the state transition path. The state dependency graph determines the influence range of state changes through depth-first traversal, and organizes the states of the original industry component and the target industry component in the state dependency graph into a state snapshot tree in time series. The nodes of the state snapshot tree record the state version numbers;

[0139] Calculate a state difference set based on the state snapshot tree, sort the state changes in the state difference set according to the difference weight to generate a priority queue, where the difference weight is calculated based on the state change amount, state priority, and hierarchical depth influence factor;

[0140] Perform a two-phase commit of the state difference set based on the priority queue. Calculate the feasibility score of state merging for each state change item in the pre-commit phase. The feasibility score is calculated based on the conflict resolution rate and the data consistency degree. When the feasibility score meets the preset security threshold, perform a confirm commit;

[0141] Generate a state version number and construct a version link when performing the confirm commit. Roll back the state through the version link when a state synchronization exception is detected.

[0142] Exemplarily, the system intercepts the read and write operations of component attributes through the proxy mode. The system creates a proxy layer using the Proxy object in JavaScript to intercept the get and set operations of the component object. When a component attribute is read or modified, the proxy layer records the access path, timestamp, operation type, and attribute value, thus generating an attribute access trace graph. For example, when a user operates the shopping cart function in an e-commerce component, the proxy layer will record operation sequences such as "ShoppingCart.items.add" and "ShoppingCart.totalPrice.update". The system calculates the change frequency based on the recorded attribute access time intervals, and at the same time counts the number of times an attribute is accessed per unit time to determine the access frequency. When calculating the attribute change weight, the change frequency accounts for 70% and the access frequency accounts for 30%. For example, if the change frequency of the number of items in the shopping cart attribute is 10 times per minute and the access frequency is 30 times per minute, then its change weight is 10×0.7 + 30×0.3 = 16. Based on the calculated attribute change weights, the system dynamically adjusts the frequency of state collection. The collection frequency of attributes with high weights is increased, and the collection frequency of attributes with low weights is decreased. For example, attributes with a change weight greater than 15 are collected for status every 2 seconds, those with a weight between 5 - 15 are collected every 5 seconds, and those with a weight below 5 are collected every 10 seconds. At the same time, the system records the conversion path of the component status from one value to another, forming a complete tracking record of the state migration.

[0143] Based on the recorded state conversion path, the system constructs a state dependency graph. The state dependency graph uses a directed graph structure, where nodes represent component states and edges represent the dependency relationships between states. The system traverses the state dependency graph using the depth-first search algorithm to determine the impact scope of a certain state change on other states. For example, in the scenario of converting a financial component to an e-commerce component, the system identifies that the change in the "account balance" state will affect the "available payment methods" and "transaction limit" states. Subsequently, the system organizes the states of the original financial component and the target e-commerce component in chronological order into a state snapshot tree. Each node of the state snapshot tree saves the component state snapshot at a specific time point and is marked with a unique state version number, and the version number format is "YYYYMMDD - HHMMSS - component ID - random code". For example, the version number "20231015 - 143025 - finance001 - 8a7b" represents the state snapshot of the financial component generated at 14:30:25 on October 15, 2023.

[0144] The system calculates the state difference set based on the state snapshot tree. By comparing the state snapshots of the original industry components and the target industry components at the corresponding time points, a list of state change items to be synchronized is generated. The difference calculation uses a structured comparison algorithm to identify three types of differences: attribute value change, attribute addition, and attribute deletion. The system calculates the difference weight for each state change item, and the difference weight calculation considers three factors: the amount of state change, the state priority, and the hierarchical depth impact factor. The amount of state change represents the magnitude of the attribute value change, such as the relative change percentage of numerical attributes; the state priority is preset according to business rules, for example, the state priority related to transactions is 5, and the state priority related to user preferences is 3; the hierarchical depth impact factor reflects the position of the state in the component hierarchy, with the top-level state impact factor being 1.0, and decreasing by 0.1 for each level deeper. The final calculated result range of the difference weight is 0-100, and the system sorts the state change items according to the difference weight to form a priority queue. For example, the difference weight for the change in the total amount of the shopping cart is 85 and is displayed at the front of the queue, while the difference weight for the change in the page background color is 20 and is ranked at the back of the queue.

[0145] Based on the constructed priority queue, the system performs a two-phase commit of the state difference set. In the pre-commit phase, the system calculates the feasibility score for the state merge of each state change item. The feasibility score is calculated based on two metrics: the conflict resolution rate and the data consistency degree. The conflict resolution rate represents the proportion of successful resolutions in the presence of conflicts, and the data consistency degree represents the degree to which the merged data meets the business rules. The system first attempts to apply the state change to the in-memory copy of the target component, detects whether conflicts occur, and applies predefined conflict resolution strategies. For example, when there is a conflict between the "payment method" of the original financial component and the "payment method" of the target e-commerce component, the system will retain the union of the two. The system executes data validation rules to check the consistency of the merge result, such as verifying whether the total amount is equal to the sum of the amounts of each item. The feasibility score ranges from 0 to 100. When the score exceeds the preset safety threshold of 75 points, the system performs a confirm commit and formally applies the state change to the target component; otherwise, the system marks the state change item as requiring manual intervention.

[0146] In the confirm commit phase, the system generates a new state version number for each state update and constructs a version link by associating it with the previous version. The version link adopts a doubly linked list structure, which is convenient for tracing the state change history forward or backward. When the system detects an abnormal state synchronization, such as data inconsistency or violation of business rules, it will locate the nearest stable state version through the version link and perform a rollback operation. During the rollback process, the system restores the target component to the state of the specified version and records the rollback event for subsequent analysis. For example, when it is detected that the calculation of the commodity price in the e-commerce component is incorrect, the system can roll back to the previous state version with the correct price to ensure business continuity.

[0147] Traditional front-end state management uses one-way data flow or responsive design, but lacks an accurate mechanism for cross-component state synchronization; although the existing snapshot and time travel debugging functions can record state changes, they are not optimized for component replacement scenarios. These technologies face problems such as state loss, difficulty in conflict handling, and waste of resources when dealing with state migration between components in different industries. Especially in real-time switching scenarios to maintain business continuity, accurate state difference synchronization and abnormal recovery cannot be achieved, resulting in data inconsistency and user experience interruption. The present invention innovatively introduces the concept of database transaction processing into the field of front-end state synchronization, and designs an attribute access trajectory graph and adaptive acquisition mechanism based on the proxy mode. Through weighted analysis of change frequency and access frequency, accurate capture of key states and efficient use of resources are achieved. The original state dependency graph and impact range analysis solve the problem of complex dependencies between states, and the state snapshot tree provides timing guarantees. The present invention monitors state changes and performs differentiated synchronization through a proxy mode, thereby realizing accurate state migration between original industry components and target industry components. The system can intelligently identify key state changes and synchronize them first, thus reducing resource consumption of state synchronization. Meanwhile, the two-phase submission mechanism and version link ensure the consistency and rollback of state synchronization, thus improving data integrity and system resilience during industry switching.

[0148] Figure 4 This is a schematic diagram for comparing the performance indicators of differentiated state synchronization methods. From the perspective of state synchronization speed, this method reaches 60.0 MB / s, which is significantly better than traditional state replication (30.0 MB / s) and snapshot comparison method (40.0 MB / s), and is close to the ideal benchmark value (75.0 MB / s), reflecting the optimization effect based on attribute access trajectory graph and state dependency graph. In terms of memory usage, this method (45.0 MB) is more efficient than traditional methods (75.0 MB) and snapshot comparison method (60.0 MB), indicating that the strategy of dynamically adjusting the state acquisition frequency effectively reduces resource consumption.

[0149] Particularly noteworthy is the state loss rate indicator. This method is only 20.0%, which is much lower than the traditional method (67.5%) and the snapshot comparison method (50.0%), and close to the ideal value (5.0%), proving the advantages of the state snapshot tree and the difference weight sorting mechanism in ensuring data integrity. In terms of the conflict resolution rate and rollback success rate, this method reached 80.0% and 85.0% respectively, which are significantly improved compared with the traditional method and the snapshot comparison method, and close to the ideal value (90.0% respectively), fully verifying the effectiveness of the two-phase commit mechanism and version link technology in handling state synchronization anomalies.

[0150] In an alternative embodiment, the steps of reading the component information in the replacement queue, replacing the original industry components one by one with the dedicated components of the target industry in the order preset by the component dependency graph, maintaining the call link between components during the replacement process, recording the current system state after each successful component replacement, and marking the current system state as a rollback point; when detecting an abnormal component replacement, restoring the system to the system state corresponding to the nearest rollback point include:

[0151] Read the component identifier to be replaced from the replacement queue, calculate the component replacement priority score based on the component dependency graph, where the replacement priority score is calculated by weighted calculation according to the dependency depth, call frequency, and resource occupancy rate between components, and sort the components in the replacement queue according to the replacement priority score;

[0152] Extract the components to be replaced in sequence based on the sorted replacement queue, load the target industry components corresponding to the components to be replaced into the component status buffer, and collect the runtime status of the components to be replaced, where the runtime status includes memory data, call parameters, and execution progress;

[0153] Establish a component call mapping table in the component status buffer, where the component call mapping table records the corresponding relationship between the call methods of the original industry components and the target industry components, and migrate the runtime status to the target industry components based on the component call mapping table to complete the component replacement and update the call link;

[0154] Collect the system operation metrics after replacement, where the system operation metrics include response time, resource occupancy rate, and business success rate. When the system operation metrics meet the stability requirements, record the current system state as a rollback point and continue to perform the replacement of the next component in the replacement queue;

[0155] When the system operation metrics do not meet the stability requirements, restore the system to the nearest rollback point, mark the currently replaced component as an item to be optimized and write it into the optimization task queue, and the components in the optimization task queue are re-added to the replacement queue after being reconstructed by the component adapter.

[0156] Exemplarily, read the component identifier to be replaced from the replacement queue. The system will call the queue management module and obtain the component information stored in the replacement queue through the queue interface. This information includes component ID, component type, function description, interface definition, and dependency relationship, etc. For example, for a component named "Payment Processing Module", the system will obtain its ID as "PAY001", type as "Payment Processing", and dependencies on "User Authentication Module" and "Order Management Module", etc.

[0157] After obtaining the component information, the system calculates the replacement priority score for each component based on the component dependency graph. The system traverses the component dependency graph to calculate the replacement priority score for each component. The specific calculation method is to perform a weighted calculation on the dependency depth between components, the call frequency, and the resource occupancy rate. The dependency depth represents the hierarchical position of the component in the dependency graph, and the component at the lower level has a higher priority; the call frequency represents the number of times the component is called in the system, and the component with a lower call frequency has a higher priority; the resource occupancy rate represents the degree of resource occupancy of the component in the system, and the component with a lower occupancy rate has a higher priority. For example, for a component with a call frequency of 10 times per second, a resource occupancy rate of 5%, and a dependency depth of 3, the calculated priority score is 75. The system sorts the components in the replacement queue according to the calculated priority scores, and the components with higher scores will be replaced first.

[0158] After the sorting is completed, the system extracts the components to be replaced in sequence. For the component with the highest priority, the system loads the corresponding target industry component into the component status buffer. The component status buffer is a dedicated area in the system memory for temporarily storing component data and status. The system collects the runtime status of the component to be replaced, including memory data, call parameters, and execution progress. Memory data includes the temporary data and intermediate results generated during the operation of the component; call parameters include the input parameters received by the component and the output parameters returned to the calling party; the execution progress represents the current execution status and progress of the component. For example, for a component that is processing an order, its runtime status may include an order ID of "ORD20230515001", a processing progress of "payment verification stage", call parameters including a payment amount of "1000 yuan" and a payment method of "online payment", etc.

[0159] To ensure the integrity of the call chain during the component replacement process, the system establishes a component call mapping table in the component status buffer. The component call mapping table records the corresponding relationship between the call methods of the original industry component and the target industry component. For example, the method "processPayment" in the original industry component corresponds to the method "handlePaymentProcess" in the target industry component. The system migrates the runtime status to the target industry component based on the component call mapping table. During the migration process, the system converts the memory data of the original component into a format that the target component can recognize and process, and adjusts the call parameters and execution flow according to the mapping relationship. After the status migration is completed, the system updates the call chain to ensure that other components can correctly call the replaced component.

[0160] After the replacement is completed, the system collects the operation metrics of the replaced system, including response time, resource occupancy rate, and business success rate. The response time represents the time for the system to process requests. For example, the average response time is reduced from 50 milliseconds to 40 milliseconds; the resource occupancy rate represents the usage of resources such as CPU and memory by the system. For example, the memory occupancy rate is reduced from 40% to 35%; the business success rate represents the proportion of successful business processing. For example, the success rate is increased from 99.5% to 99.8%. The system compares these metrics with the preset stability requirements. The stability requirements usually include: the response time does not exceed the preset threshold (such as 100 milliseconds), the resource occupancy rate does not exceed the preset threshold (such as 60%), and the business success rate is not lower than the preset threshold (such as 99%).

[0161] When the system operation metrics meet the stability requirements, the system records the current system state as a rollback point. The rollback point contains the state information, configuration information, and dependency relationships of all current components. The system serializes this information and stores it in persistent storage, and generates a unique identifier, such as "Rollback_20230515_142530". The system continues to execute the replacement of the next component in the replacement queue and repeats the above process until the replacement queue is empty or an exception occurs.

[0162] When the system operation metrics do not meet the stability requirements, such as the response time exceeds 200 milliseconds or the business success rate drops to 95%, the system will trigger the rollback mechanism. The system reads the information of the most recently recorded rollback point from the persistent storage and restores the system state to the state corresponding to that rollback point. The restoration process includes reloading components, restoring component states, and reconstructing call chains. The system marks the currently replaced component as an item to be optimized and writes it into the optimization task queue. The optimization task queue is a queue specifically for storing the information of components that need to be optimized. The system will process the tasks in this queue regularly. After a component enters the optimization task queue, it will be reconstructed through a component adapter. The adapter will analyze the problem points of the component, such as performance bottlenecks or compatibility issues, and perform corresponding optimizations and adjustments on the component. After the optimization is completed, the component will rejoin the replacement queue and wait for the next round of replacement.

[0163] Through the above process, the system can achieve a smooth replacement from the original industry components to the target industry components while ensuring stability, and ensure business continuity and system reliability.

[0164] The present invention realizes an orderly and smooth replacement of the special components of the target industry through component replacement priority sorting and runtime state migration. The component call mapping table ensures the correct conversion of the call relationships between components. The system operation metric monitoring and rollback point mechanism provide security guarantees for the replacement process. At the same time, the optimization task queue mechanism enables abnormal components to participate in the replacement again after being adapted and reconstructed, improving the success rate and adaptability of industry switching.

[0165] In a second aspect of the embodiments of the present invention, there is provided an electronic device, comprising:

[0166] a processor;

[0167] a memory for storing instructions executable by the processor;

[0168] wherein the processor is configured to call the instructions stored in the memory to execute the method described above.

[0169] In a third aspect of the embodiments of the present invention, there is provided a computer-readable storage medium, on which computer program instructions are stored, and when the computer program instructions are executed by a processor, the method described above is implemented.

[0170] The present invention may be a method, an apparatus, a system, and / or a computer program product. The computer program product may include a computer-readable storage medium, on which computer-readable program instructions for executing various aspects of the present invention are uploaded.

[0171] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements for some or all of the technical features. However, such modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A supply chain front-end architecture method for multi-industry dynamic switching and routing adaptation, characterized in that Including: Scanning the dependencies of the front-end components, extracting the call chains, data flows, and life cycle hooks between the components, and generating a component dependency graph; Based on the component dependency graph, hierarchically labeling the front-end components, labeling the basic components, industry-general components, and industry-specific components as the first layer, the second layer, and the third layer respectively, and establishing a component hierarchical model; Setting a progressive switching strategy according to the component hierarchical model. On the basis of keeping the first-layer basic components running stably, injecting the second-layer industry-general components into the switching buffer zone. The switching buffer zone isolates the component running environments of different industries through virtual component containers, and at the same time includes the third-layer industry-specific components in the replacement queue; constructing a routing adaptation layer based on the component hierarchical model. The routing adaptation layer updates the routing rules through a multi-dimensional routing decision mechanism and hierarchical storage management; monitoring the state changes of the original industry components and target industry components in the switching buffer zone, and performing differential synchronization; Reading the component information in the replacement queue, replacing the original industry components one by one with the industry-specific components of the target industry in the order preset by the component dependency graph, maintaining the call chains between the components during the replacement process, recording the current system state after each successful component replacement, and marking the current system state as a rollback point; when detecting component replacement anomalies, restoring the system to the system state corresponding to the nearest rollback point.

2. The method according to claim 1, wherein The steps of scanning the dependencies of the front-end components, extracting the call chains, data flows, and life cycle hooks between the components, and generating a component dependency graph include: Collecting the running data of component instances, recording the method call relationships, event trigger records, data transfer paths, and life cycle state changes between the components, and forming a component behavior log; Constructing a component communication graph based on the component behavior log. The component communication graph records the method call frequencies, event trigger times, state manager data transfer volumes, and message bus communication volumes between the components; Performing a timing analysis on the component communication graph, identifying the initialization hook call order, update hook trigger chain, data dependency relationships, and destruction hook call order of the components, and organizing the identified component life cycle dependency relationships into a component life cycle dependency tree; calculating the call weights in the component communication graph and the life cycle weights in the component life cycle dependency tree, and performing normalization processing on the call weights and the life cycle weights and then obtaining the dependency strength through weighted summation; Generating a component dependency graph based on the call weights and the life cycle weights, where nodes represent components, edges represent dependency relationships, and the weights of the edges are the normalized dependency strengths. When the dependency strength is greater than the preset strength threshold, a directed edge is established between the corresponding nodes.

3. The method according to claim 1, characterized in that The steps of hierarchically labeling the front-end components include: Construct a component dependency matrix, where the matrix elements of the component dependency matrix represent the degree of dependency between components; extract component feature vectors based on the component dependency matrix, and the component feature vectors include component reuse degree, component coupling degree, component timing weight, and component state complexity. Among them, the component reuse degree is calculated according to the usage frequency of the component in different industry scenarios, the component coupling degree is obtained based on the row and column sums of the component dependency matrix, the component timing weight reflects the position of the component in the business process, and the component state complexity represents the number of states maintained by the component; Perform weighted calculation on the component reuse degree, the inverse value of the component coupling degree, the component timing weight, and the inverse value of the component state complexity to obtain the component hierarchy score; Calculate the dynamic stratification threshold based on the component hierarchy score. The dynamic stratification threshold includes a first threshold and a second threshold. The first threshold is the sum of the mean and standard deviation of the component hierarchy score, and the second threshold is the difference between the mean and standard deviation of the component hierarchy score; Perform stratification marking on the components according to the dynamic stratification threshold, and divide the components into different layers; Calculate the ratio of the inter-layer component dependency degree to the cross-layer component dependency degree to obtain the inter-layer isolation degree. When the inter-layer isolation degree is greater than the preset isolation degree threshold, trigger re-stratification.

4. The method according to claim 1, characterized in that, The steps of isolating the component running environments of different industries through a virtual component container include: Construct an outer-layer resource isolation container, which isolates the memory, document object model, and styles of the components. The memory isolation is achieved by allocating an independent heap memory space for the component and defining the access boundary. The document object model isolation is achieved by creating an independent Shadow DOM and setting access interception rules. The style isolation is achieved by generating a unique namespace identifier and rewriting the selector rules; Construct an inner-layer runtime isolation container, which isolates the runtime environment, loading, and network requests of the components. The runtime environment isolation is achieved by creating an independent JavaScript execution context. The loading isolation is achieved by constructing an independent component registry. The network request isolation is achieved by setting up an independent request queue; Construct an inter-container communication channel between the outer-layer resource isolation container and the inner-layer runtime isolation container. The inter-container communication channel includes point-to-point message transmission, broadcast message transmission, and resource access control. The point-to-point message transmission and the broadcast message transmission are scheduled based on the message priority. The resource access control determines the resource access rules based on the access permission table and the resource locking state.

5. The method according to claim 1, wherein The steps of constructing a routing adaptation layer based on the component stratification model and updating the routing rules through a multi-dimensional routing decision mechanism and hierarchical storage management include: Analyze the interaction characteristics of the components at each layer in the component stratification model, extract the component communication boundaries, and construct the basic framework of the routing adaptation layer. The routing adaptation layer is responsible for coordinating the request forwarding and response processing between components in different industries; Calculate the routing weight based on the industry dimension, user role dimension, business process dimension, and system load dimension. The routing weight is obtained by weighting the component call frequency, data transfer volume, and business importance. Generate an initial routing rule through the routing weight. The initial routing rule records the call relationship and data transmission rule between components; Divide the initial routing rule into a memory fast layer and a persistence layer according to the routing weight. Calculate the routing migration index by calculating the routing access heat. Trigger rules to migrate between layers based on the routing migration index, and at the same time establish a backup copy for the routing rule in the memory fast layer; Extract the request parameter feature, call chain feature, and business scenario feature to generate a request fingerprint identifier. Match and verify the request fingerprint identifier with the industry identifier. When the verification result is inconsistent, recalculate the routing weight and update the routing rule; Collect the routing hit rate, routing latency, exception rate, and business completion rate, calculate the routing health score. When the routing health score is lower than the third threshold, enable the backup copy to forward requests. When the routing health score is lower than the fourth threshold, reconstruct the routing rule based on the request fingerprint identifier; Calculate the routing rule compatibility based on the historical request matching rate and the routing health score. Perform atomic replacement on the routing rules with a compatibility higher than the preset compatibility threshold. Establish a two-way mapping relationship for the routing rules with a compatibility lower than the preset compatibility threshold and deploy dual-active operation. The two-way mapping relationship maintains the data conversion rule between the old and new rules.

6. The method according to claim 1, wherein Monitor the status changes of the original industry components and target industry components in the switching buffer, and the steps for performing differential synchronization include: Intercept the read and write operations of component attributes through the proxy mode to generate an attribute access trace diagram. Calculate the attribute change weight based on the attribute access trace diagram. The attribute change weight is obtained by weighting the change frequency and access frequency. Dynamically adjust the collection frequency of the status collection point based on the attribute change weight, and record the status conversion path; Construct a state dependency graph based on the status conversion path. The state dependency graph determines the influence range of the status change through depth-first traversal. Organize the status of the original industry components and target industry components in the state dependency graph into a state snapshot tree in time series. The nodes of the state snapshot tree record the status version number; Calculate the state difference set based on the state snapshot tree. Sort the state changes in the state difference set according to the difference weight to generate a priority queue. The difference weight is calculated based on the state change amount, state priority, and hierarchical depth influence factor; Execute the two-phase commit of the state difference set in the order of the priority queue. Calculate the feasibility score of state merging for each state change item in the pre-commit phase. The feasibility score is calculated based on the conflict resolution rate and data consistency degree. When the feasibility score meets the preset security threshold, execute the confirm commit; Generate a status version number and construct a version link when executing the confirm commit. Roll back the status through the version link when a status synchronization exception is detected.

7. The method according to claim 1, characterized in that, Read the component information in the replacement queue, and replace the original industry components one by one with the dedicated components of the target industry in the order preset by the component dependency graph. During the replacement process, maintain the call link between components, record the current system state after each successful component replacement, and mark the current system state as a rollback point; When a component replacement exception is detected, the steps to restore the system to the system state corresponding to the nearest rollback point include: Read the component identifier to be replaced from the replacement queue, calculate the component replacement priority score based on the component dependency graph. The replacement priority score is calculated by weighted averaging the dependency depth, call frequency, and resource occupancy rate between components, and sort the components in the replacement queue according to the replacement priority score; Extract the components to be replaced in sequence based on the sorted replacement queue, load the target industry components corresponding to the components to be replaced into the component state buffer, and collect the runtime state of the components to be replaced. The runtime state includes memory data, call parameters, and execution progress; Establish a component call mapping table in the component state buffer. The component call mapping table records the corresponding relationship between the call methods of the original industry components and the target industry components. Based on the component call mapping table, migrate the runtime state to the target industry components, complete the component replacement, and update the call link; Collect the system operation metrics after replacement. The system operation metrics include response time, resource occupancy rate, and business success rate. When the system operation metrics meet the stability requirements, record the current system state as a rollback point and continue to execute the replacement of the next component in the replacement queue; When the system operation metrics do not meet the stability requirements, restore the system to the nearest rollback point, mark the currently replaced component as an item to be optimized and write it into the optimization task queue. The components in the optimization task queue are re-added to the replacement queue after being reconstructed by the component adapter.

8. An electronic device, characterized in that, Include: A processor; A memory for storing instructions executable by the processor; Wherein, the processor is configured to call the instructions stored in the memory to execute the method according to any one of claims 1 to 7.

9. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When the computer program instructions are executed by the processor, the method according to any one of claims 1 to 7 is implemented.

Images