Multi-industry dynamic switching and routing adaptation supply chain front-end architecture method

Abstract

The application provides a multi-industry dynamic switching and routing adaptation supply chain front-end architecture method, relates to the technical field of front-end architecture, and comprises the following steps: a layered model is established by scanning component dependency relationships, a progressive switching strategy is set, a routing adaptation layer is constructed to realize multi-dimensional decision, a state is listened to and difference synchronization is performed, components are replaced in a preset order and a rollback point is set. The application realizes smooth switching of components of different industries, reduces the coupling degree between components, improves the adaptability and reliability of the front-end architecture, and enables the system to maintain stable operation in a multi-industry scene.

Description

TECHNICAL FIELD

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

[0002] With the rapid development of e-commerce and supply chain management, the supply chain front-end system needs to support multiple industry business scenarios at the same time. The supply chain front-end architecture refers to the software architecture that provides user interface and interaction functions for the supply chain management system, which needs to adapt to different industry business rules, processes and data structures. The existing technology has the following defects and deficiencies 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 relationship management mechanism during inter-industry switching, leading to problems such as component dependency confusion, call link interruption, etc. when switching industry scenarios, which cannot guarantee the stability and continuity of the system during switching.

[0004] The existing technology lacks a systematic component layer marking strategy, which cannot effectively distinguish and manage business components of 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 switching efficiency and increasing system risk.

[0005] The existing routing adaptation mechanism generally uses a static configuration method, which cannot dynamically adjust routing rules according to industry switching needs, lacks routing decision-making mechanisms and abnormal recovery capabilities for multi-industry scenarios, and it is difficult to achieve fast rollback and state recovery when switching exceptions occur, which seriously affects the availability and business continuity of the system in a multi-industry environment. SUMMARY

[0006] The embodiments of the present application provide a supply chain front-end architecture method for multi-industry dynamic switching and routing adaptation, which can solve the problems in the prior art.

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

[0008] Scanning the dependency relationship of the front-end components, extracting the call link, data flow and life cycle hook between the components, and generating a component dependency relationship graph;

[0009] Based on the component dependency relationship graph, the front-end components are marked in layers, the basic components, industry general components and industry specific components are marked as the first level, the second level and the third level respectively, and a component layering model is established;

[0010] According to the component layered model, a progressive switching strategy is set, on the basis of keeping the stable operation of the first-level basic components, the second-level industry general components are injected into the switching buffer, the switching buffer isolates the component running environment of different industries through a virtual component container, and meanwhile, the third-level industry special components are included in the replacement queue; a routing adaptation layer is constructed based on the component layered model, the routing adaptation layer updates routing rules through a multi-dimensional routing decision mechanism and layered storage management; the state changes of the original industry components and the target industry components in the switching buffer are listened to, and differential synchronization is performed;

[0011] Component information in the replacement queue is read, and the special components of the target industry are replaced with the original industry components one by one in the order preset by the component dependency graph, the calling link between components is maintained during the replacement process, the current system state is recorded after each successful replacement of components, and the current system state is marked as a rollback point; when a component replacement exception is detected, the system is restored to the system state corresponding to the nearest rollback point.

[0012] In an optional implementation,

[0013] The dependency relationship of the front-end component is scanned, the calling link, data flow direction and life cycle hook between components are extracted, and the component dependency graph is generated.

[0014] Component instance running data is collected, method calling relationship between components, event triggering record, data flow path and life cycle state change are recorded, and a component behavior log is formed;

[0015] A component communication graph is constructed based on the component behavior log, the component communication graph records the method calling frequency, event triggering times, state manager data transmission amount and message bus communication amount between components;

[0016] The component communication graph is subjected to timing analysis, the initialization hook calling order, update hook triggering chain, data dependency relationship and destruction hook calling order of the component are identified, and the identified component life cycle dependency relationship is organized into a component life cycle dependency tree;

[0017] The calling weight in the component communication graph and the life cycle weight in the component life cycle dependency tree are calculated, the calling weight and the life cycle weight are subjected to normalization processing, and then the dependency strength is obtained by weighted summation;

[0018] A component dependency graph is generated based on the calling weight and the life cycle weight, wherein a node represents a component, an edge represents a dependency relationship, and the weight of the edge is the normalized dependency strength, and when the dependency strength is greater than a preset strength threshold, a directed edge is established between the corresponding nodes.

[0019] In an alternative embodiment,

[0020] The step of hierarchically marking the front-end components comprises:

[0021] A component dependency matrix is constructed, and a matrix element of the component dependency matrix represents a degree of dependency between components; a component feature vector is extracted based on the component dependency matrix, and the component feature vector comprises component reuse degree, component coupling degree, component timing weight, and component state complexity, wherein the component reuse degree is calculated according to a frequency of use of the component in different industry scenarios, the component coupling degree is derived based on a row and a column of the component dependency matrix, the component timing weight reflects a position of the component in a business process, and the component state complexity represents a number of states maintained by the component;

[0022] The component reuse degree, a reverse value of the component coupling degree, the component timing weight, and a reverse value of the component state complexity are weighted and calculated to obtain a component hierarchical score;

[0023] A dynamic hierarchical threshold is calculated based on the component hierarchical score, and the dynamic hierarchical threshold comprises a first threshold and a second threshold, the first threshold is a sum of a mean value and a standard deviation of the component hierarchical score, and the second threshold is a difference between the mean value and the standard deviation of the component hierarchical score;

[0024] The components are hierarchically marked according to the dynamic hierarchical threshold, and the components are divided into different levels;

[0025] A layer isolation degree is obtained by calculating a ratio between a dependency degree between components in the same layer and a dependency degree between components across layers, and re-hierarchy is triggered when the layer isolation degree is greater than a preset isolation threshold.

[0026] In an alternative embodiment,

[0027] The step of isolating running environments of components of different industries through a virtual component container comprises:

[0028] An outer resource isolation container is constructed, and the outer resource isolation container performs memory isolation, document object model isolation, and style isolation on the components, the memory isolation is implemented by allocating independent heap memory space for the components and limiting access boundaries, the document object model isolation is implemented by creating independent Shadow DOM and setting access interception rules, and the style isolation is implemented by generating a unique namespace identifier and rewriting selector rules;

[0029] An inner-layer runtime isolation container is constructed, which performs environment isolation, loading isolation and network request isolation on the components, the environment isolation is implemented by creating an independent JavaScript execution context, the loading isolation is implemented by constructing an independent component registry, and the network request isolation is implemented by setting an independent request queue;

[0030] A container-to-container communication channel is constructed between the outer-layer resource isolation container and the inner-layer runtime isolation container, which 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 priority, and the resource access control determines resource access rules based on an access permission table and a resource locking state.

[0031] In an optional implementation,

[0032] A routing adaptation layer is constructed based on the component hierarchical model, and the steps of updating routing rules by the multi-dimensional routing decision mechanism and the hierarchical storage management of the routing adaptation layer include:

[0033] The interaction characteristics of the components at each level in the component hierarchical model are analyzed, the component communication boundary is extracted, and the basic framework of the routing adaptation layer is constructed, which is responsible for coordinating request forwarding and response processing between different industry components;

[0034] Routing weights are calculated based on industry dimension, user role dimension, business process dimension and system load dimension, the routing weights are weighted according to component call frequency, data flow volume and business importance, initial routing rules are generated through the routing weights, and the initial routing rules record the call relationship and data transmission rules between components;

[0035] The initial routing rules are divided into a memory fast layer and a persistent layer according to the routing weights, a routing migration index is obtained by calculating routing access heat, rules are migrated between layers based on the routing migration index, and a backup copy is established for the routing rules in the memory fast layer;

[0036] Request parameter characteristics, call chain characteristics and business scenario characteristics are extracted, a request fingerprint identifier is generated, the request fingerprint identifier is matched and verified with an industry identifier, when the verification result is inconsistent, the routing weights are recalculated and the routing rules are updated;

[0037] Routing hit rate, routing delay, abnormal rate and business completion rate are collected, routing health scores are calculated, when the routing health scores are lower than a third threshold, the backup copy is enabled to forward requests, and when the routing health scores are lower than a fourth threshold, routing rules are rebuilt based on the request fingerprint identifier;

[0038] The route rule compatibility degree is calculated based on the historical request matching rate and the route health score, atomic replacement is performed on the route rule with the compatibility degree higher than a preset compatibility threshold, and a bidirectional mapping relationship is established for the route rule with the compatibility degree lower than the preset compatibility threshold and the route rule is deployed for dual-active operation, and the bidirectional mapping relationship maintains the data conversion rule between the new and old rules.

[0039] In an optional implementation,

[0040] The step of monitoring the state changes of the original industry component and the target industry component in the switching buffer and performing differential synchronization comprises:

[0041] The attribute access trajectory graph is generated by intercepting the read and write operations of the component attributes through the proxy mode, the attribute change weight is calculated based on the attribute access trajectory graph, the attribute change weight is obtained by weighting the change frequency and the access frequency, the collection frequency of the state collection point is dynamically adjusted based on the attribute change weight, and the state transition path is recorded;

[0042] The state dependency graph is constructed based on the state transition path, the state dependency graph determines the influence range of state change through depth-first traversal, the states of the original industry component and the target industry component in the state dependency graph are organized into a state snapshot tree in time sequence, and the node of the state snapshot tree records the state version number;

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

[0044] The two-phase commit of the state difference set is sequentially performed based on the priority queue, the feasibility score of state merging is calculated 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, and the confirmation commit is performed when the feasibility score meets a preset safety threshold;

[0045] The state version number is generated and the version link is constructed when the confirmation commit is performed, and the state is rolled back through the version link when a state synchronization exception is detected.

[0046] In an optional implementation,

[0047] The component information in the replacement queue is read, the special components of the target industry are replaced with the original industry components one by one in the order preset by the component dependency graph, the calling link between the components is maintained during the replacement process, the current system state is recorded after each successful replacement of the components, and the current system state is marked as a rollback point, and the step of recovering the system to the system state corresponding to the nearest rollback point when a component replacement exception is detected comprises:

[0048] reading a component identifier to be replaced from the replacement queue, calculating a component replacement priority score based on the component dependency graph, the replacement priority score being calculated according to a dependency depth between components, a calling frequency and a resource occupancy rate, and sorting the components in the replacement queue according to the replacement priority score;

[0049] extracting the component to be replaced from the sorted replacement queue, loading a target industry component corresponding to the component to be replaced into a component state buffer, collecting a runtime state of the component to be replaced, the runtime state including memory data, calling parameters and execution progress;

[0050] establishing a component calling mapping table in the component state buffer, the component calling mapping table recording a calling method correspondence relationship between the original industry component and the target industry component, migrating the runtime state to the target industry component based on the component calling mapping table, completing component replacement and updating a calling link;

[0051] collecting system running indicators after replacement, the system running indicators including response time, resource occupancy rate and business success rate, recording a rollback point when the system running indicators meet stability requirements, and continuing to execute the next component replacement in the replacement queue;

[0052] when the system running indicators do not meet the stability requirements, restoring the system to the nearest rollback point, marking the currently replaced component as an optimization item and writing it into an optimization task queue, and rejoining the replaced component in the optimization task queue to the replacement queue after the component is reconstructed by a component adapter.

[0053] In a second aspect of the embodiment of the application, an electronic device is provided, comprising:

[0054] a processor;

[0055] a memory for storing processor-executable instructions;

[0056] The processor is configured to invoke the instructions stored in the memory to execute the method described above.

[0057] In a fourth aspect of the embodiment of the application, a computer-readable storage medium is provided, which stores computer program instructions, and the computer program instructions are executed by a processor to implement the method described above.

[0058] The application realizes systematic management of front-end components through component dependency relationship scanning and hierarchical marking, makes the component structure in different industry scenarios clear and visible, facilitates targeted optimization and maintenance, and improves the maintainability and scalability of the system.

[0059] The application realizes smooth switching between different industry scenes, reduces system instability in the switching process, and improves user experience, and the multi-dimensional decision mechanism of the routing adaptation layer improves the adaptability of the system to different industry business rules, so that the front-end architecture can flexibly cope with complex and variable industry demands.

[0060] The application sets a rollback point mechanism in the component replacement process, and combines the ordered replacement strategy guided by the component dependency graph to greatly improve the fault recovery capability and fault tolerance capability of the system in the industry switching process, reduce the risk of system crash caused by component replacement failure, and ensure the stable operation of the supply chain front-end system in a multi-industry environment. BRIEF DESCRIPTION OF DRAWINGS

[0061] Figure 1 A flowchart of a supply chain front-end architecture method for multi-industry dynamic switching and routing adaptation of the embodiment of the application is shown in

[0062] Figure 2 A front-end component dependency relationship scanning architecture diagram is shown in

[0063] Figure 3 A virtual component container isolation different industry component running simulation diagram is shown in

[0064] Figure 4 A differential state synchronization method performance index comparison diagram is shown in DETAILED DESCRIPTION

[0065] In order to make the purpose, technical scheme and advantages of the embodiment of the application clearer, the technical scheme in the embodiment of the application will be described clearly and completely in combination with the drawings in the embodiment of the application. Obviously, the described embodiments are only part of the embodiments of the application, not all the embodiments. Based on the embodiments in the application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the application.

[0066] The technical scheme of the application will be described in detail in the following specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described in some embodiments.

[0067] Figure 1 A flowchart of a supply chain front-end architecture method for multi-industry dynamic switching and routing adaptation of the embodiment of the application is shown in Figure 1 As shown in the figure, the method comprises:

[0068] Scanning the dependency relationship of the front-end component, extracting the calling link, data flow and life cycle hook between components, and generating a component dependency graph;

[0069] Based on the component dependency graph, the front-end components are hierarchically labeled, and the basic components, industry general components, and industry specific components are labeled as the first level, the second level, and the third level respectively, and a component hierarchical model is established;

[0070] According to the component hierarchical model, a progressive switching strategy is set, the second level industry general components are injected into the switching buffer on the basis of maintaining the stable operation of the first level basic components, the switching buffer isolates the component running environment of different industries through a virtual component container, and the third level industry specific components are included in the replacement queue; a routing adaptation layer is constructed 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; the state changes of the original industry components and the target industry components in the switching buffer are listened to, and differential synchronization is performed;

[0071] The component information in the replacement queue is read, the specific components of the target industry are replaced with the original industry components one by one in the order preset by the component dependency graph, the calling link between components is maintained during the replacement process, the current system state is recorded after each successful component replacement, and the current system state is marked as a rollback point; when a component replacement exception is detected, the system is restored to the system state corresponding to the nearest rollback point.

[0072] For example, by combining static analysis and dynamic monitoring, the front-end component dependency relationship is comprehensively scanned. In the static analysis stage, the system parses the source code, extracts import / export statements, event binding, and attribute reference; in the dynamic monitoring stage, the system collects component interaction data during application runtime, and the two are combined to generate an accurate component dependency graph, which includes method calls between nodes, event transmission, data flow conversion, and life cycle association.

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

[0074] After the layering is completed, the system designs a progressive switching strategy, and the switching process adopts the strategy of "stable core, buffer transition, and gradual replacement". The first level of basic components is kept stable, the second level of industry general components is injected into the switching buffer, and the third level of special components is included in the replacement queue. The switching buffer isolates the running environments of different industries through virtual component container technology to prevent mutual interference between components. The virtual container adopts a double-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 realized between the two layers through a secure channel.

[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 the communication boundary, and establishes a rule system for request forwarding and response processing. Routing decisions are based on industry, user role, business process, and system load, etc. The access efficiency is improved through the hierarchical storage of the in-memory fast layer and the persistent layer, and adaptive optimization is realized.

[0076] During the component switching process, the system continuously monitors the state changes of the original industry components and the target industry components in the switching buffer. Through the proxy mode to intercept attribute reading and writing, a state dependency graph is constructed and the state difference set is calculated. Two-phase commit is executed according to priority to ensure the consistency of state synchronization, and version linkage is constructed to support state rollback in abnormal conditions.

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

[0078] Through the above-mentioned steps of cooperative work, the present application realizes the dynamic switching and adaptation of front-end components in multiple industry scenarios, guarantees business continuity and system stability, and improves the flexibility and adaptability of the supply chain front-end system.

[0079] In an optional implementation, the step of scanning the dependency relationship of the front-end component, extracting the call link, data flow direction, and life cycle hook between components, and generating a component dependency relationship graph includes:

[0080] Collecting component instance running data, recording method call relationship between components, event trigger record, data flow path, and life cycle state change, and forming component behavior log;

[0081] construct a component communication graph based on the component behavior logs, the component communication graph recording method invocation frequency, event trigger times, state manager data transfer volume and message bus communication volume among components;

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

[0083] calculate invocation weight in the component communication graph and lifecycle weight in the component lifecycle dependency tree, and obtain dependency strength by weighted summation after normalization processing of the invocation weight and the lifecycle weight;

[0084] generate a component dependency relationship graph based on the invocation weight and the lifecycle weight, wherein nodes represent components and edges represent dependency relationships, and the weight of the edge is the normalized dependency strength, and a directed edge is established between the corresponding nodes when the dependency strength is greater than a preset strength threshold.

[0085] Figure 2 A front-end component dependency relationship scanning architecture diagram is shown. For example, in the component instance running data collection stage, the system monitors the components in the front-end application through the instrumentation technology, and the system will inject log recording code at the method call entry and exit of the component, which is used to record the method name, call time, caller component identifier, callee component identifier and transmitted parameter value. 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 transmitted data object. Similarly, the system will listen to the event trigger between components, record the event name, trigger component, receiving component and event data. For data flow path, the system will track component attribute changes and state update operations, and record the flow direction of data from the source component to the target component. For the lifecycle hook, the system will record the invocation time, execution time and context state 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 the component communication graph based on the component behavior logs, the system extracts the 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, if component A calls component B's method a total of 15 times within a session period, 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 will also be reflected on the weight of the edge. For data transmitted through state managers (such as Redux or Vuex), the system will calculate the number of data changes and the size of the data. For example, component A transmits a total of 500KB of data to component C through the state manager, which is updated 20 times, this information will be recorded as the state management communication volume from A to C. Message bus communication volume is also recorded, such as component D sends 8 messages to component E through the event bus, with a total data volume of 120KB. Through these statistical data, the system generates a complete component communication graph, reflecting the interaction intensity and frequency between components.

[0087] In the timing analysis phase, the system analyzes the execution order and dependency relationships of component lifecycle hooks. The system first extracts all lifecycle hook call records from the component behavior logs, sorts them by timestamp, and identifies the hook call sequence in 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 detects that the updated hook of component H triggers the beforeUpdate and updated hook calls of components I and J, it can determine that there is an update dependency relationship between H, I, and J. By analyzing the component destruction sequence, the system can identify the destruction dependencies between components, such as the beforeDestroy hook call of component K causing the destroy method of component L to be triggered, indicating that the destruction of L depends on the destruction process of K. These dependencies are organized into a component lifecycle dependency tree, where nodes are components, and edges represent lifecycle dependencies, with dependency types (such as initialization dependency, update dependency, or destruction dependency) marked on the edges.

[0088] In the dependency strength calculation stage, the system quantifies the call weight in the component communication graph and the lifecycle weight in the component lifecycle dependency tree. The call weight is calculated based on factors such as method call frequency, event trigger times, and data transfer volume. For example, the method call frequency weight can be set to 1 for each call, and if a component calls another component's method 30 times, the weight is 30. The event trigger weight can be set to 1.5 for each event, and if there are 20 event triggers, the weight is 30. The data transfer volume weight can be calculated at 5 per 100KB of data, and if 300KB of data is transferred, the weight is 15. The lifecycle weight is assigned different weights according to the importance of initialization dependency, update dependency, and destruction dependency, such as initialization dependency weight 10, update dependency weight 5, and destruction dependency weight 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 2x10+3x5+1x3=38. In order to make the weights of different dimensions comparable, the system will normalize the call weight and the lifecycle weight respectively, mapping them to between 0 and 1. The final dependency strength is obtained by weighted sum of the normalized call weight and the lifecycle weight, for example, the call weight can be set to 0.6, and the lifecycle weight can be set to 0.4.

[0089] In the component dependency graph generation stage, the information of the component communication graph and the component lifecycle dependency tree is integrated. Firstly, 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), the calling weight value (such as the weighted sum of method call frequency, event triggering and data transmission volume) of the two nodes is extracted from the component communication graph, and the lifecycle weight value (such as the weighted sum of initialization, update and destruction dependencies) of the two nodes is extracted from the lifecycle dependency tree. The two kinds of weight values are respectively applied to Min-Max normalization to map them to the interval [0, 1]. The system calculates the comprehensive dependency strength between components by applying a configurable weighted formula (such as 0.6 × normalized calling weight + 0.4 × normalized lifecycle weight). The nodes represent the front-end components, and the edges represent the comprehensive dependency relationships between the components. 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 the threshold, the system establishes a directed edge between the two nodes to ensure that only the 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 calling), and the normalized weight of the lifecycle is 0.78 (indicating the existence of a key lifecycle dependency). Applying the weighted formula 0.6 × 0.85 + 0.4 × 0.78 = 0.822, the comprehensive dependency strength is 0.82, which exceeds the threshold of 0.5. The system establishes a directed edge from P to Q in the dependency relationship graph and marks the weight 0.82. The finally generated component dependency relationship graph reflects not only the communication frequency and data flow between components, but also the coupling degree of the lifecycle, comprehensively displaying the dependency network between front-end components and providing a key basis for industry switching decisions.

[0090] The present application constructs a component communication graph and performs timing analysis by collecting component behavior logs, accurately identifies and quantifies component dependency relationships, enables the system to automatically discover implicit dependencies and key call paths between components, provides a reliable dependency relationship basis for multi-industry dynamic switching, reduces component conflicts and exceptions during industry switching, and improves system stability and industry adaptation efficiency.

[0091] In an optional embodiment, the step of hierarchically marking the front-end components comprises:

[0092] A component dependency matrix is constructed, and the matrix elements of the component dependency matrix represent the dependency degree between components. A component feature vector is extracted based on the component dependency matrix, and the component feature vector includes component reuse degree, component coupling degree, component timing 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 derived based on the row and column sum 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.

[0093] The reverse values of the component multiplexing degree, component coupling degree, component timing weight, and component state complexity are weighted to obtain a component level score;

[0094] A dynamic hierarchical threshold is calculated based on the component level score, the dynamic hierarchical threshold including a first threshold and a second threshold, the first threshold being a sum of a mean value and a standard deviation of the component level score, and the second threshold being a difference between the mean value and the standard deviation of the component level score;

[0095] Components are hierarchically marked according to the dynamic hierarchical threshold, and the components are divided into different levels;

[0096] The ratio of the intra-layer dependency and the cross-layer dependency is calculated to obtain an inter-layer isolation degree, and re-hierarchy is triggered when the inter-layer isolation degree is greater than a preset isolation threshold.

[0097] For example, in the component hierarchical marking process, a component dependency matrix is constructed, the matrix being scanned by a static code analysis tool on project code to extract import and export relationships between components, forming an n x n matrix A, where n is the total number of components, and 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 of referring to component j in component i, for example, if component A refers to the properties or methods of component B three times, then a[A][B]=3. For example, in a system containing 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;

[0103] Based on the component dependency matrix, a component feature vector is extracted, including the component multiplexing degree, the component coupling degree, the component timing weight, and the component state complexity. The component multiplexing degree is calculated by analyzing the usage frequency of the component in different industry scenarios. For example, a form component is used 8 times in e-commerce, 5 times in finance, and 3 times in education, so its multiplexing degree is 16. The component coupling degree is obtained based on the row sum and column sum of the component dependency matrix, that is, the coupling degree of component i is equal to the sum of the element sum of the ith row and the element sum of the ith column of matrix A, representing the dependency relationship strength of the component with other components.

[0104] The component timing weight reflects the position of the component in the business process and is obtained by analyzing the business process diagram. The component timing weight of the front end of the business process is lower, and the component timing weight of the back end is higher. For example, in the process of login-browsing-purchase-payment, the login component timing weight can be set to 0.2, the browsing 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 inside the component, which is obtained by code analysis tool statistics. For example, a component maintains three states of user information, shopping cart data, and order status inside, and the state complexity is 3.

[0105] The extracted feature vector is weighted and calculated to obtain the component level score. The calculation formula is: component level score = w1 x component reuse degree + w2 x (1 / component coupling degree) + w3 x component timing weight + w4 x (1 / component state complexity), wherein w1, w2, w3, and w4 are weight coefficients, and w1 + w2 + w3 + w4 = 1. Different weights can be set according to the characteristics of the project, for example, w1 = 0.3, w2 = 0.3, w3 = 0.2, and 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 in a higher level, so the inverse value of the coupling degree and the state complexity is taken.

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

[0107] The hierarchical scores of all components are counted, and the mean μ and standard deviation σ are calculated. The first threshold T1 is μ+σ, and the second threshold T2 is μ-σ. For example, the mean of the hierarchical scores of the above 5 components is 2.817, and the standard deviation is 0.683, so T1=3.5 and T2=2.134. The components are marked according to the dynamic hierarchical threshold. After the hierarchical marking is completed, the inter-layer isolation degree is calculated, which is the ratio of the intra-layer dependency and the cross-layer dependency. The intra-layer dependency is the sum of the dependency relationships between the components in the same layer, and the cross-layer dependency is the sum of the dependency relationships between the components in different layers. For example, in the above hierarchical result, the sum of the intra-layer dependency is 11, and the sum of the cross-layer dependency is 14, so the inter-layer isolation degree is 11 / 14≈0.786. When the inter-layer isolation degree is greater than a preset isolation threshold (such as 0.8), it indicates that the component hierarchy is not ideal, and a re-hierarchy is triggered. The re-hierarchy can be achieved by adjusting the feature vector weight or modifying the hierarchical threshold. For example, if the inter-layer isolation degree is 0.786, which is close to but does not exceed the threshold 0.8, no re-hierarchy is needed; if it exceeds the threshold, the multiplexing weight can be increased or the coupling weight can be reduced to promote the component hierarchy to be more reasonable.

[0108] After the division of the component hierarchical score based on the dynamic hierarchical threshold, the system will mark the components as three types of basic components, industry general components and industry specific components according to the business attributes and hierarchical scores of the components. Specifically, the components with a hierarchical score higher than a first threshold T1 are marked as first-level basic components, which usually have high reusability, low coupling, moderate timing weight and low state complexity, such as UI basic controls, tool function libraries, general data processing components, etc., which have less association with specific industry business logic; the components with a hierarchical score between the first threshold T1 and a second threshold T2 are marked as second-level industry general components, which have certain reusability in multiple industries but contain specific business logic, such as general form verification, data visualization, file upload, etc. functional components; the components with a hierarchical score lower than the second threshold T2 are marked as third-level industry specific components, which usually have low reusability, high coupling, high timing weight and high state complexity, such as specific industry business process components, professional computing modules, etc. 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 marking, the system establishes a component hierarchical model, which not only contains the hierarchical attributes of the components, but also records the dependency relationship between the hierarchical levels, the industry application range of the components, the calling rules between the components, etc. to form a complete component dependency and hierarchical knowledge base, providing decision basis for subsequent dynamic switching and routing adaptation. The hierarchical model is stored in a graph database, which supports fast query and dynamic update to adapt to the evolution of the component library and changes in industry demand.

[0109] The present application uses dynamic hierarchical threshold for component hierarchical marking, which enables the system to intelligently identify and classify industry components, forms a clear hierarchical structure, reduces unnecessary dependencies between cross-layer components, improves component reusability, and ensures the rationality of hierarchical isolation through inter-layer isolation monitoring, providing a stable and reliable component hierarchical architecture foundation for industry dynamic switching; can effectively identify the hierarchical attributes of the components, guide the developers to develop components according to the reasonable dependency direction, avoid circular dependencies, and improve the code quality and maintainability.

[0110] In an optional embodiment, the step of isolating the component running environments of different industries through a virtual component container includes:

[0111] An outer resource isolation container is constructed, which performs memory isolation, document object model isolation, and style isolation on the component, the memory isolation is implemented by allocating independent heap memory space for the component and limiting access boundaries, the document object model isolation is implemented by creating independent Shadow DOM and setting access interception rules, and the style isolation is implemented by generating a unique namespace identifier and rewriting selector rules;

[0112] An inner runtime isolation container is constructed, which performs runtime environment isolation, loading isolation, and network request isolation on the component, the runtime environment isolation is implemented by creating an independent JavaScript execution context, the loading isolation is implemented by constructing an independent component registry, and the network request isolation is implemented by setting an independent request queue;

[0113] A container-to-container communication channel is constructed between the outer resource isolation container and the inner runtime isolation container, the container-to-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 priority, and the resource access control determines resource access rules based on an access authority table and a resource lock state.

[0114] For example, when constructing the outer resource isolation container, memory isolation is implemented by allocating independent heap memory space for each component and limiting access boundaries. Specifically, the system creates a virtual memory manager that maintains a component memory allocation table, which records each component ID and its corresponding memory region start address and size. For example, the system allocates 8MB of memory space for component A, with a start address of 0x80000000 and an end address of 0x80800000; and allocates 12MB of memory space for component B, with a start address of 0x81000000 and an end address of 0x81C00000. When a component attempts to access memory, the virtual memory manager checks whether the access address is within the range allocated to it, and if it is outside the range, the access request is intercepted and an access denial error is returned. Memory access interception is implemented by rewriting the memory allocation function of the JavaScript engine, using a Proxy object to wrap the native object, and adding boundary check logic in the get and set operations.

[0115] The document object model isolation is achieved by creating 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 child nodes of the 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 rewriting the 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'), it actually executes shadowRoot.querySelector('div.class1'), where shadowRoot is the Shadow DOM root node of the component. For cross-component DOM operation cases, the system maintains a DOM access permission table to record the DOM access permission relationship between components, and only allows cross-component access with explicit authorization.

[0116] Style isolation is achieved by generating unique namespace identifiers and rewriting selector rules. The system generates a 32-bit hash value for each component as a unique identifier, such as component A's identifier "comp-7a8b9c0d" and component B's identifier "comp-1e2f3g4h". When parsing the CSS style sheet of a component, the system will add a namespace prefix to 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 to calculate the final 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 apply based on component priority, and the style of the component with higher priority is retained.

[0117] When building the inner-layer runtime isolated container, the runtime environment isolation is achieved by creating independent JavaScript execution contexts. The system creates a sandbox environment for each component, including independent global objects, scope chains, and execution contexts. The implementation method is to create an isolated environment using iframe elements or the with statement of JavaScript. For example, the system creates an invisible iframe and loads the component code in it, making the component run in the window object context of the iframe, isolated from the window object of the main application. For 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 the component calls the setTimeout function, the actual call is made to the proxy function provided by the system, which limits the minimum delay time to 100 ms to prevent malicious code from consuming system resources through high-frequency timers.

[0118] Loading isolation is achieved by building an independent component registry. The system maintains a component registration center that records detailed information about loaded components, including component ID, version number, dependency list, loading status, and other information. When a component needs to be loaded, the system first checks whether the component has been loaded. If it has not been loaded, it starts the loading process. If it has been loaded, it reuses the existing instance. For example, for multiple components that depend on the library React, the system only loads the React library once and injects it into the required components. Component loading is done asynchronously through dynamically created script tags or using the import() function. After loading is complete, the component status is updated to "loaded".

[0119] Network request isolation is achieved by setting up independent request queues. The system creates independent network request queues for each component to manage and limit XHR, fetch, and other network requests initiated by the component. Request queue configurations include maximum concurrent requests, request timeout, retry strategy, and other configurations. For example, component A has a maximum of 5 concurrent requests and a request timeout of 30 seconds; component B has a maximum of 3 concurrent requests and a request timeout of 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 URL whitelist checks based on the component's network permissions to deny access to unauthorized domain names.

[0120] A container-to-container communication channel is built between the outer resource isolation container and the inner runtime isolation container. Point-to-point message transmission is implemented through a message event mechanism. Components can send messages to other components through 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 sent by component A 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 verifies the message to ensure that the sender has the right to send the type of message to the receiver, and schedules it according to the priority.

[0121] 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, and education groups divided by industry. Broadcast messages contain fields such as sender ID, target group ID, message type, message content, timestamp, and priority. The system schedules messages according to message priority and the state of receiving components, with high-priority messages being processed first and idle components receiving messages first.

[0122] Resource access control is based on access permission tables and resource lock states to determine resource access rules. The system maintains a resource permission table that records the access permission level of components for various resources (such as DOM, storage, network, etc.). For example, component A has a permission level of "read and write" for localStorage and a permission level of "prohibited" for the camera; component B has a permission level of "read only" for localStorage and a permission level of "ask when using" for the camera. When a component requests access to a resource, the system checks the permission table and the current lock state of the resource to determine whether access is allowed. 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 resources simultaneously but only allowing one component to write resources.

[0123] The prior art is difficult to balance the isolation strength and communication efficiency when dealing with different industry components coexistence scenarios, resulting in resource conflict, state pollution and performance loss problems. The present application proposes a double-layer isolation container architecture, which separates the resource isolation and runtime isolation. The outer resource isolation container realizes precise memory boundary control through the virtual memory manager, realizes DOM isolation through the Shadow DOM technology and access interception rules, and solves the style conflict using namespace and priority dynamic calculation. The inner runtime isolation container realizes execution context isolation through the configurable sandbox environment, designs the component registration center to realize dependency sharing and version control, and builds the request queue and permission system to realize network isolation. A priority-based communication channel is designed between the two layers of containers to solve the contradiction between isolation and interaction. The running environment of different industry components is completely isolated, avoiding resource conflict and interference between components, so that multi-industry components can run in parallel in the same system without affecting each other. At the same time, the communication channel between the containers ensures the necessary data exchange between the components, ensuring the stability and security of the system during industry switching.

[0124] Figure 3 The simulation diagram of the virtual component container isolating the components of different industries shows that from the isolation strength curve, as the isolation level increases, the isolation strength shows a stepwise rising trend, reaching an ideal level of 100% after achieving full outer isolation, indicating that the combination of Shadow DOM and namespace style isolation technology can effectively block cross-component pollution. The memory consumption curve shows that although increasing the isolation layer will bring additional overhead, through the boundary control of the virtual memory manager and the resource sharing mechanism, the memory occupation under the complete double-layer isolation is only 20%, which is much lower than the expected level.

[0125] In terms of communication efficiency, it gradually decreases from 100% for pure memory isolation to 60% for complete double-layer isolation. This moderate reduction is the result of the communication channel design between containers, which maintains acceptable communication performance while ensuring isolation through point-to-point message transmission and priority scheduling mechanism. The resource conflict rate data line is the most convincing, which decreases significantly from 80% to 0% under complete double-layer isolation, proving the outstanding performance of this technology in resource conflict prevention and control.

[0126] In an optional implementation, a routing adaptation layer is constructed based on the component hierarchical model, and the steps of updating routing rules through a multi-dimensional routing decision mechanism and hierarchical storage management of the routing adaptation layer include:

[0127] The interaction characteristics of each level of components in the component hierarchical model are analyzed, the component communication boundary is extracted, and the basic framework of the routing adaptation layer is constructed. The routing adaptation layer is responsible for coordinating the request forwarding and response processing between different industry components;

[0128] The routing weight is calculated based on an industry dimension, a user role dimension, a business process dimension, and a system load dimension, the routing weight is weighted according to a component call frequency, a data flow volume, and a business importance degree, an initial routing rule is generated through the routing weight, and the initial routing rule records a call relationship and a data transmission rule between components;

[0129] The initial routing rule is divided into a memory fast layer and a persistent layer according to the routing weight, a routing migration index is obtained by calculating a routing access heat, and the rule is migrated between layers based on the routing migration index, and a backup copy is established for the routing rule in the memory fast layer;

[0130] Request parameter features, call chain features, and business scenario features are extracted, a request fingerprint identifier is generated, the request fingerprint identifier is matched and verified with an industry identifier, when the verification result is inconsistent, the routing weight is recalculated and the routing rule is updated;

[0131] The routing health score is calculated by collecting the routing hit rate, the routing delay, the abnormal rate, and the business completion rate, when the routing health score is lower than a third threshold, the backup copy is enabled to forward the request, and when the routing health score is lower than a fourth threshold, the routing rule is rebuilt based on the request fingerprint identifier;

[0132] The routing rule compatibility is calculated based on the historical request matching rate and the routing health score, the routing rule with a compatibility higher than a preset compatibility threshold is executed for atomic replacement, the routing rule with a compatibility lower than the preset compatibility threshold is established for a bidirectional mapping relationship and deployed for double-live operation, and the bidirectional mapping relationship maintains the data conversion rule between the new and old rules.

[0133] For example, the interaction features of each level component in the component hierarchical model are comprehensively analyzed. By deeply mining the data exchange mode between financial industry components and medical industry components, the component communication boundary is extracted. For example, when the financial payment component needs to interact with the medical appointment component, the system identifies the interface difference, data format difference, and security policy difference between the two, thereby constructing an adaptive conversion rule. The routing adaptation layer serves as an intermediate coordination layer, establishes a unified request format conversion mechanism, converts the JSON format request from the financial component into the XML format that can be received by the medical component, and realizes seamless connection between heterogeneous systems.

[0134] The routing weight calculation process involves comprehensive evaluation of multiple dimensions. 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 administrator operation path weight is 90 points, and the ordinary user operation path weight 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 based on real-time CPU occupancy and memory usage. When the system load exceeds 80%, the related routing weight is reduced by 15%. Based on component call statistics, the system records that component A is called 200 times per second, the data flow volume is 50 MB / s, and the business importance is "critical". According to these weight data, the system generates initial routing rules. The system extracts call relationships based on component call logs, such as discovering that the financial component frequently calls the report component. The routing weight is applied to these call relationships, and the path with high weight is preferentially selected. Combined with business conditions, the system forms rules in the "condition-action" format. For example, when it is found that "financial administrator" has high-frequency calls from the financial component to the report component when performing "monthly settlement", the system automatically generates the rule: "when the user role is 'financial administrator' and the business process is'monthly settlement', request routing from the financial component to the report component". Each rule also records data format requirements, parameter mapping, and timeout settings to ensure correct data transmission between components.

[0135] The hierarchical storage management of routing rules achieves a balance between efficient access and reliability. The system places rules with routing weights higher than 85 points in the memory fast layer, such as financial transaction routing rules and user authentication routing rules. Rules with weights lower than 85 points are stored in the persistent layer, such as log query routing rules and data statistics routing rules. The system calculates routing access heat every hour. When the access frequency of the medical appointment routing rule increases from 10 times per minute to 100 times per minute, the routing migration index increases from 40 to 90, triggering the rule to migrate 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 a distributed cache cluster, achieving fast recovery in fault conditions.

[0136] The request fingerprint identification generation 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), chain features (the request comes from a mobile terminal, passes through identity verification service, hospital selection service), business scenario features (regular outpatient appointment), and generates a unique request fingerprint identification "MED-REG-APP-2023110501". The system matches this identification with the medical industry identification for verification. If it finds that the request carries bank payment information but does not contain a medical security verification code, it determines that the verification is inconsistent, recalculates the routing weight (from the original 78 points to 65 points), and updates the routing rules, adding a security verification check node.

[0137] The routing health monitoring system ensures stability. The system regularly collects various routing indicators, such as financial component routing hit rate of 98%, routing delay of 15ms, abnormal rate of 0.5%, and business completion rate of 99.5%, and calculates the routing health score as 92 points. When the education resource routing health score drops to 65 points (lower than the third threshold of 70 points), the system automatically enables backup copies to handle request forwarding. When the medical data routing health score further drops to 45 points (lower than 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.

[0138] The routing rule update adopts a smooth transition strategy. The system calculates that the compatibility of the financial payment routing rule V2 version and the V1 version is 92% (higher than the preset compatibility threshold of 85%), performs atomic replacement operation, and completes rule switching within 100 milliseconds. The compatibility of the medical image routing rule V3 version and the V2 version is 75% (lower than the preset compatibility threshold), and the system establishes a bidirectional mapping relationship to dynamically convert the V2 version of DICOM format data into the V3 version of compressed DICOM+ format. Both versions of rules run simultaneously for 30 days to ensure business continuity. The bidirectional mapping table stores the field correspondence, such as "patientInfo" in the V2 version mapping to "patientProfile" in the V3 version, ensuring lossless data conversion.

[0139] Traditional front-end routing is mainly based on URL path matching, lacking multi-dimensional decision-making ability; API gateway supports complex routing rules, but focuses on inter-service communication rather than component-level routing. The application innovatively proposes a routing adaptation layer combining multi-dimensional routing decision mechanism and hierarchical storage management. In terms of decision mechanism, an integrated weight calculation model of industry dimension, user role dimension, business process dimension and system load dimension is introduced to realize context-aware accurate routing. In terms of storage management, a double-layer structure of memory fast layer and persistent layer is designed, and the access efficiency is optimized through a routing hotness dynamic migration mechanism. The special innovation is the request fingerprint identification and health monitoring mechanism, the former realizes accurate classification of requests through multi-feature fusion, and the latter realizes fault self-healing through multi-index monitoring. The double-active deployment strategy and bidirectional mapping relationship solve the version compatibility problem.

[0140] In an optional implementation, the step of monitoring the state changes of the original industry component and the target industry component in the switching buffer and performing differentiated synchronization includes:

[0141] An attribute access trajectory graph is generated by intercepting read and write operations of component attributes through a proxy mode, an attribute change weight is calculated based on the attribute access trajectory graph, the attribute change weight is obtained by weighting a change frequency and an access frequency, a collection frequency of a state collection point is dynamically adjusted based on the attribute change weight, and a state transition path is recorded;

[0142] A state dependency graph is constructed based on the state transition path, the state dependency graph determines the influence range of state changes through depth-first traversal, states of the original industry component and the target industry component in the state dependency graph are organized into a state snapshot tree in a time sequence, and a node of the state snapshot tree records a state version number;

[0143] A state difference set is calculated based on the state snapshot tree, state changes in the state difference set are sorted according to a difference weight to generate a priority queue, and the difference weight is calculated according to a state change amount, a state priority and a hierarchical depth influence factor;

[0144] Two-phase commit of the state difference set is sequentially executed based on the priority queue, a feasibility score of state merging is calculated for each state change item in a pre-commit phase, the feasibility score is calculated based on a conflict resolution rate and a data consistency degree, and a confirmation commit is executed when the feasibility score meets a preset safety threshold;

[0145] A state version number is generated and a version link is constructed when the confirmation commit is executed, and the state is rolled back through the version link when a state synchronization exception is detected.

[0146] For example, 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 of JavaScript to intercept the get and set operations of the component object. When the component attributes are read or modified, the proxy layer records the access path, timestamp, operation type, and attribute value, thereby generating an attribute access trajectory graph. For example, when the user operates the shopping cart function in the e-commerce component, the proxy layer records the operation sequence of "ShoppingCart.items.add" and "ShoppingCart.totalPrice.update". The system calculates the change frequency according to the recorded attribute access time interval, and simultaneously calculates the access frequency by counting the number of times the attribute is accessed within a unit time. In the calculation of 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 goods in the shopping cart attribute is 10 times per minute, and the access frequency is 30 times per minute, then the change weight is 10 x 0.7 + 30 x 0.3 = 16. Based on the calculated attribute change weight, 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 every 2 seconds, attributes with a change weight between 5 and 15 are collected every 5 seconds, and attributes with a change weight less than 5 are collected every 10 seconds. At the same time, the system records the conversion path of the component state from one value to another, forming a complete tracking record of state migration.

[0147] Based on the recorded state conversion path, the system constructs a state dependency graph. The state dependency graph adopts a directed graph structure, with nodes representing component states and edges representing the dependency relationship between states. The system uses a depth-first search algorithm to traverse the state dependency graph and determine the influence range of a 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 "account balance" state change 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 into a state snapshot tree in chronological order. Each node of the state snapshot tree saves the component state snapshot at a specific time point and marks a unique state version number. The version number format is "YYYYMMDD-HHMMSS-component ID-random code". For example, the version number "20231015-143025-finance001-8a7b" represents the state snapshot generated for the financial component at 14:30:25 on October 15, 2023.

[0148] The system calculates the state difference set based on the state snapshot tree. By comparing the state snapshots of the original industry component and the target industry component at the corresponding time points, the system generates a list of state change items that need to be synchronized. The difference calculation uses a structured comparison algorithm to identify three types of differences: attribute value changes, attribute additions, and attribute deletions. The system calculates a difference weight for each state change item, taking into account three factors: state change volume, state priority, and hierarchical depth impact factor. The state change volume represents the magnitude of attribute value changes, such as the relative percentage change for numerical attributes. The state priority is pre-set according to business rules, such as a transaction-related state priority of 5 and a user preference-related state priority of 3. The hierarchical depth impact factor reflects the position of the state in the component hierarchy, with a top-level state impact factor of 1.0 and a decrease of 0.1 for each level deeper. The difference weight calculation result ranges from 0 to 100. The system sorts the state change items according to the difference weight to form a priority queue. For example, the difference weight of the total amount change in the shopping cart is 85, which is displayed at the front of the queue, while the difference weight of the page background color change is 20, which is placed at the back of the queue.

[0149] 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 a feasibility score for state merging for each state change item. The feasibility score is calculated based on conflict resolution rate and data consistency level. The conflict resolution rate represents the proportion of successful resolution in the presence of conflicts, and the data consistency level represents the degree to which the merged data meets business rules. The system first attempts to apply the state change to the memory copy of the target component, detects whether a conflict occurs, and applies a pre-defined conflict resolution strategy. 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 their union. The system performs data validation rules to check the consistency of the merging results, such as verifying whether the total amount is equal to the sum of the amounts of each item. When the score exceeds the pre-set safety threshold of 75 points, the system performs a confirmation commit to apply the state change to the target component formally; otherwise, the system marks the state change item as requiring manual intervention.

[0150] In the confirmation commit phase, the system generates a new state version number for each state update and associates it with the previous version to construct a version link. The version link uses a double-linked list structure to facilitate tracing the state change history forward or backward. When the system detects state synchronization exceptions, such as data inconsistency or business rule violations, it locates the latest stable state version through the version link and performs a rollback operation. During the rollback process, the system restores the target component to the specified version state and records the rollback event for subsequent analysis. For example, when a price calculation error is detected in the e-commerce component, the system can roll back to the previous state version with correct prices to ensure business continuity.

[0151] Traditional front-end state management adopts one-way data flow or reactive design, but lacks precise mechanisms for cross-component state synchronization; existing snapshot and time travel debugging functions can record state changes, but are not optimized for component replacement scenarios. These technologies face problems such as state loss, conflict handling difficulties, and resource waste when dealing with state migration between components in different industries, especially in real-time switching scenarios that maintain business continuity. They cannot achieve precise state difference synchronization and abnormal recovery, leading to data inconsistency and user experience interruption. The invention innovatively introduces the concept of database transaction processing into the field of front-end state synchronization, designing an attribute access trajectory graph based on the proxy pattern and an adaptive collection mechanism. Through weighted analysis of change frequency and access frequency, it achieves precise capture of key states and efficient use of resources. The unique state dependency graph and impact range analysis solve the problem of complex dependencies between states, while the state snapshot tree provides timing guarantees. The invention achieves precise state migration between original industry components and target industry components by proxy pattern listening to state changes and performing differential synchronization, and the system can intelligently identify key state changes and prioritize synchronization, reducing resource consumption for state synchronization. The two-phase commit mechanism and version linking ensure the consistency and rollback of state synchronization, improving data integrity and system resilience during industry switching.

[0152] Figure 4 For the performance index comparison diagram of the differential state synchronization method, from the state synchronization speed index, the method reaches 60.0 MB / s, which is significantly better than the traditional state replication (30.0 MB / s) and the snapshot comparison method (40.0 MB / s), close to the ideal benchmark value (75.0 MB / s), reflecting the optimization effect based on the attribute access trajectory graph and the state dependency graph. In terms of memory usage, the method (45.0 MB) is more efficient than the traditional method (75.0 MB) and the snapshot comparison method (60.0 MB), indicating that the strategy of dynamically adjusting the state collection frequency effectively reduces resource consumption.

[0153] It is particularly noteworthy that the state loss rate index is only 20.0%, which is much lower than the traditional method (67.5%) and the snapshot comparison method (50.0%), close to the ideal value (5.0%), proving the advantages of the state snapshot tree and the difference weight ordering mechanism in ensuring data integrity. In terms of conflict resolution rate and rollback success rate, the method reaches 80.0% and 85.0% respectively, which is significantly better than the traditional method and the snapshot comparison method, close to the ideal value (90.0% respectively), fully verifying the effectiveness of the two-phase commit mechanism and the version linking technology in handling state synchronization exceptions.

[0154] In an alternative embodiment, the component information in the replacement queue is read, and the components of the target industry are replaced one by one in the order preset by the component dependency graph, the call link between components is maintained during the replacement process, the current system state is recorded after each successful component replacement, and the current system state is marked as a rollback point; when a component replacement exception is detected, the system is restored to the system state corresponding to the nearest rollback point, and the steps include:

[0155] The identification of the component to be replaced is read from the replacement queue, and the component replacement priority score is calculated based on the component dependency graph, the replacement priority score being calculated according to the dependency depth, call frequency and resource occupancy rate between components, and the components in the replacement queue are sorted according to the replacement priority score;

[0156] The component to be replaced is extracted from the sorted replacement queue, the target industry component corresponding to the component to be replaced is loaded into the component state buffer, the runtime state of the component to be replaced is collected, and the runtime state includes memory data, call parameters and execution progress;

[0157] A component call mapping table is established in the component state buffer, the component call mapping table records the correspondence between the call methods of the original industry component and the target industry component, the runtime state is migrated to the target industry component based on the component call mapping table, the component replacement is completed and the call link is updated;

[0158] The system running indicators after replacement are collected, the system running indicators include response time, resource occupancy rate and business success rate, the current system state is recorded as a rollback point when the system running indicators meet the stability requirements, and the next component replacement in the replacement queue is continued;

[0159] When the system running indicators do not meet the stability requirements, the system is restored to the nearest rollback point, the currently replaced component is marked as an optimization item and written into an 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.

[0160] For example, the identification of the component to be replaced is read from the replacement queue. The system calls the queue management module to obtain the component information stored in the replacement queue through the queue interface, which includes component ID, component type, function description, interface definition and dependency relationship, etc. For example, for a component named "payment processing module", the system obtains its ID "PAY001", type "payment processing", and dependency on "user authentication module" and "order management module" information.

[0161] After obtaining the component information, the system calculates the replacement priority score of each component based on the component dependency graph. The system calculates the replacement priority score of each component by traversing the component dependency graph. The specific calculation method is to weight the dependency depth, call frequency and resource occupancy rate between components. Dependency depth represents the hierarchical position of the component in the dependency graph, the lower the hierarchical position of the component, the higher the priority; call frequency represents the number of times the component is called in the system, the lower the call frequency of the component, the higher the priority; resource occupancy rate represents the occupancy degree of the component to the system resources, the lower the occupancy rate of the component, the higher the 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 score, and the components with higher scores will be replaced first.

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

[0163] To ensure the integrity of the call link during component replacement, the system establishes a component call mapping table in the component state buffer. The component call mapping table records the correspondence between the calling 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 state 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 can be recognized and processed by the target component, and adjusts the call parameters and execution flow according to the mapping relationship. After completing the state migration, the system updates the call link to ensure that other components can correctly call the replaced component.

[0164] After the replacement is completed, the system collects the replaced system running indicators, including response time, resource occupancy rate, and business success rate. The response time represents the time for the system to process a request, for example, the average response time is reduced from 50 milliseconds to 40 milliseconds; the resource occupancy rate represents the use 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 success rate of business processing, for example, the success rate is increased from 99.5% to 99.8%. The system compares these indicators 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%).

[0165] When the system running indicators 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 relationship of all current components. The system serializes these information and stores it in the persistent storage, and generates a unique identifier, such as "Rollback_20230515_142530". The system continues to execute the next component replacement in the replacement queue, and repeats the above process until the replacement queue is empty or an exception occurs.

[0166] When the system running indicators do not meet the stability requirements, such as the response time exceeding 200 milliseconds or the business success rate falling to 95%, the system triggers the rollback mechanism. The system reads the rollback point information recorded last time from the persistent storage, and restores the system state to the state corresponding to the rollback point. The restoration process includes reloading components, restoring component state, and rebuilding call links. The system marks the currently replaced component as an optimization item, and writes it into the optimization task queue. The optimization task queue is a queue specially storing component information that needs to be optimized, and the system will periodically process the tasks in this queue. After entering the optimization task queue, the component will be reconstructed by the component adapter. The adapter will analyze the problem points of the component, such as performance bottlenecks or compatibility problems, and make corresponding optimizations and adjustments to the component. After optimization, the component will rejoin the replacement queue and wait for the next round of replacement.

[0167] Through the above process, the system can realize smooth replacement of original industry components to target industry components while ensuring stability, ensuring business continuity and system reliability.

[0168] The present application realizes the orderly and smooth replacement of target industry special components through component replacement priority sorting and runtime state migration, the component call mapping table ensures the correct conversion of the calling relationship between components, the system running indicator monitoring and rollback point mechanism provides safety guarantee for the replacement process, and the optimization task queue mechanism enables abnormal components to participate in replacement again after being reconstructed by the adapter, improving the success rate and adaptability of industry switching.

[0169] In a second aspect, the present application provides an electronic device, comprising:

[0170] a processor;

[0171] a memory for storing processor-executable instructions;

[0172] wherein the processor is configured to invoke the instructions stored in the memory to perform the method described above.

[0173] In a third aspect, the present application provides a computer-readable storage medium having stored thereon computer program instructions, which when executed by a processor, implement the method described above.

[0174] The present application can be a method, apparatus, system, and / or computer program product. Computer program products can include computer-readable storage media having computer-readable program instructions loaded thereon for performing various aspects of the present application.

[0175] Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present application, and not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand: it can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement for part or all of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A supply chain front-end architecture method for dynamic switching and routing adaptation across multiple industries, characterized in that: include: Scan the dependencies of front-end components, extract the call chain, data flow and lifecycle hooks between components, and generate a component dependency graph; Based on the component dependency graph, the front-end components are hierarchically labeled, with basic components, industry-general components, and industry-specific components labeled as the first level, second level, and third level, respectively, to establish a component hierarchical model; Based on the component layering model, a progressive switching strategy is implemented. While maintaining the stable operation of the first-level basic components, second-level industry-wide components are injected into a switching buffer. This switching buffer isolates the component runtime environments of different industries through a virtual component container. Simultaneously, third-level industry-specific components are included in the replacement queue. A routing adaptation layer is constructed based on the component layering model. This layer updates routing rules through a multi-dimensional routing decision mechanism and layered storage management. Specifically, it includes: analyzing the interaction characteristics of components at each level in the component layering model, extracting component communication boundaries, and constructing the basic framework of the routing adaptation layer. The routing adaptation layer is responsible for coordinating different... Request forwarding and response processing between components in the same industry; calculating routing weights based on industry, user role, business process, and system load dimensions, with the routing weights weighted according to component call frequency, data flow volume, and business importance; generating initial routing rules based on the routing weights, with the initial routing rules recording the call relationships and data transmission rules between components; dividing the initial routing rules into a memory fast layer and a persistent layer according to the routing weights; obtaining a routing migration index by calculating route access heat; triggering rules to migrate between layers based on the routing migration index; and simultaneously creating backup copies of the routing rules in the memory fast layer. 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. If the verification results are inconsistent, recalculate the routing weight and update the routing rules. Collect route hit rate, route latency, anomaly rate, and business completion rate to calculate the route health score. When the route health score is lower than the third threshold, activate the backup copy for request forwarding. When the route health score is lower than the fourth threshold, rebuild the routing rules based on the request fingerprint identifier. Calculate the routing rule compatibility based on the historical request matching rate and the route health score. Perform atomic replacement on routing rules with compatibility higher than a preset compatibility threshold. Establish a bidirectional mapping relationship for routing rules with compatibility lower than the preset compatibility threshold and deploy dual-active operation. The bidirectional mapping relationship maintains the data conversion rules between the old and new rules. Monitor the state changes of the original industry component and the target industry component in the switching buffer and perform differentiated synchronization. Read the component information in the replacement queue, replace the original industry components one by one with the special components of the target industry according to the preset order of the component dependency graph, maintain the call chain 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 a component replacement anomaly is detected, restore the system to the system state corresponding to the most recent rollback point.

2. The method according to claim 1, characterized in that, The steps for scanning the dependencies of front-end components, extracting the call chain, data flow, and lifecycle hooks between components, and generating a component dependency graph include: Collect component instance runtime data, record method call relationships between components, event trigger records, data flow paths, and lifecycle state changes to form component behavior logs; A component communication graph is constructed based on the component behavior log. The component communication graph records the frequency of method calls, the number of event triggers, the amount of data transferred by the state manager, and the amount of communication on the message bus between components. Perform timing analysis on the component communication graph to identify the component's initialization hook call order, update hook trigger chain, data dependency relationship and destruction hook call order, and organize the identified component lifecycle dependency relationship into a component lifecycle dependency tree; Calculate the call weight in the component communication graph and the life cycle weight in the component life cycle dependency tree. After normalizing the call weight and the life cycle weight, obtain the dependency strength by weighted summation. A component dependency graph is generated based on the call weight and the lifecycle weight, where nodes represent components, edges represent dependencies, 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.

3. The method according to claim 1, characterized in that, The steps for layering and marking front-end components include: Construct a component dependency matrix, where the matrix elements represent the degree of dependency between components; extract component feature vectors based on the component dependency matrix, where the component feature vectors include component reusability, component coupling, component temporal weight, and component state complexity, wherein component reusability is calculated based on the frequency of use of the component in different industry scenarios, component coupling is derived based on the row and column sum of the component dependency matrix, component temporal weight reflects the position of the component in the business process, and component state complexity represents the number of states maintained by the component; The component level score is obtained by weighting the inverse values ​​of component reusability, component coupling, component timing weight, and component state complexity. A dynamic stratification threshold is calculated based on the component-level scores. 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-level scores, and the second threshold is the difference between the mean and standard deviation of the component-level scores. The components are classified into different levels based on the dynamic hierarchical threshold. The inter-layer isolation degree is obtained by calculating the ratio of the dependency between components in the same layer to the dependency between components across layers. When the inter-layer isolation degree is greater than a preset isolation degree threshold, re-layering is triggered.

4. The method according to claim 1, characterized in that, The steps involved in isolating component runtime environments from different industries using virtual component containers include: An outer resource isolation container is constructed, which isolates components in terms of memory, document object model, and style. The memory isolation is achieved by allocating independent heap memory space for components and limiting access boundaries. 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 selector rules. An inner runtime isolation container is constructed, which isolates components in terms of runtime environment, loading, and network requests. The runtime environment isolation is achieved by creating an independent JavaScript execution context, the loading isolation is achieved by constructing an independent component registry, and the network request isolation is achieved by setting an independent request queue. An inter-container communication channel is established between the outer resource isolation container and the inner 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 priority, and the resource access control determines resource access rules based on the access permission table and resource locking status.

5. The method according to claim 1, characterized in that, The steps of monitoring the state changes of the original industry component and the target industry component in the switching buffer and performing differentiated synchronization include: By intercepting read and write operations of component attributes through the proxy pattern, an attribute access trajectory map is generated. The attribute change weight is calculated based on the attribute access trajectory map. The attribute change weight is obtained by weighting the change frequency and access frequency. The collection frequency of state collection points is dynamically adjusted based on the attribute change weight, and the state transition path is recorded. A state dependency graph is constructed based on the state transition path. The state dependency graph determines the scope of influence of state changes through depth-first traversal. The states of the original industry component and the target industry component in the state dependency graph are organized into a state snapshot tree according to the time sequence. The nodes of the state snapshot tree record the state version number. Based on the state snapshot tree, a state difference set is calculated, and the state changes in the state difference set are sorted 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. Based on the priority queue, the two-phase commit of the state difference set is executed sequentially. For each state change item, the feasibility score of state merging is calculated in the pre-commit phase. The feasibility score is calculated based on the conflict resolution rate and the degree of data consistency. When the feasibility score meets the preset security threshold, the confirmation commit is executed. When performing a confirmation submission, a status version number is generated and a version link is constructed. When a status synchronization anomaly is detected, the status is rolled back through the version link.

6. The method according to claim 1, characterized in that, Read the component information in the replacement queue, replace the original industry components one by one with the special components of the target industry according to the preset order of the component dependency graph, maintain the call chain 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 a component replacement anomaly is detected, the steps to restore the system to the system state corresponding to the most recent rollback point include: Read the identifier of the component 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 weighting the component dependency depth, call frequency and resource utilization, and sort the components in the replacement queue according to the replacement priority score; Based on the sorted replacement queue, the components to be replaced are extracted sequentially, the target industry components corresponding to the components to be replaced are loaded into the component state buffer, and the runtime state of the components to be replaced is collected, including memory data, calling parameters and execution progress. A component call mapping table is established in the component state buffer. The component call mapping table records the correspondence between the call methods of the original industry component and the target industry component. Based on the component call mapping table, the runtime state is migrated to the target industry component, completing the component replacement and updating the call chain. Collect system operation metrics after replacement, including response time, resource utilization, 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 replace the next component in the replacement queue. When the system's operating metrics do not meet stability requirements, the system is restored to the most recent rollback point. The currently replaced component is marked as an item to be optimized and written 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.

7. An electronic device, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the method according to any one of claims 1 to 6.

8. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the method described in any one of claims 1 to 6.

Images