E-commerce platform architecture optimization method and system based on Handle technology

Abstract

The invention discloses an E-commerce platform architecture optimization method and system based on a Handle technology, and relates to the technical field of architecture optimization, and the method comprises the steps: constructing a platform operation state architecture dependency graph, carrying out the multi-dimensional structure analysis, recognizing at least one architecture imbalance mode, and carrying out the multi-dimensional structure analysis; generating an architecture optimization trigger condition set according to the duration, the influence range and the business value association degree of the architecture imbalance mode; when it is detected that the framework optimization triggering condition set is met, a triggering label is called, and a corresponding framework optimization target space is constructed; and executing structure transformation optimization of the platform operation state architecture dependency graph based on the architecture optimization target space, and executing architecture optimization management according to an optimization result. According to the invention, the technical problem that the e-commerce platform in the prior art cannot timely identify the architecture imbalance and perform effective optimization in the operation state is solved, and the technical effects of real-time discovery and automatic optimization of the architecture imbalance and improvement of the stability and sustainable evolution capability of the platform architecture are achieved.

Description

Technical Field

[0001] This invention relates to the field of architecture optimization technology, specifically to a method and system for optimizing the architecture of an e-commerce platform based on Handle technology. Background Technology

[0002] As e-commerce platforms continue to operate, their business scale and interaction chains grow, leading to increasingly complex call relationships, data read / write paths, and transaction chains. During operation, phenomena such as the concentration of various call chains, the amplification of cascading links, and the diffusion of data consistency can easily accumulate and lead to architectural imbalances. However, these changes are often hidden and evolve rapidly, making them difficult to detect in a timely manner through conventional monitoring methods. Due to the lack of real-time mapping and proactive identification capabilities for runtime structural relationships, platforms often only respond passively after performance degradation or abnormal expansion, resulting in delayed optimization and increased risks. Summary of the Invention

[0003] This application provides a method and system for optimizing the architecture of e-commerce platforms based on Handle technology, which is used to address the technical problem that existing e-commerce platforms cannot identify and effectively optimize their architecture in a timely manner during runtime.

[0004] In view of the above problems, this application provides a method and system for optimizing the architecture of e-commerce platforms based on Handle technology.

[0005] The first aspect of this application provides a method for optimizing the architecture of an e-commerce platform based on Handle technology, the method comprising: During the operation of the e-commerce platform, real-time call behavior, data read / write paths, cross-domain transaction relationships, and performance response indicators across business modules are continuously collected using Handle technology. Based on the collected results, a platform runtime architecture dependency graph is constructed. Multi-dimensional structural analysis is performed on this graph to identify at least one architecture imbalance mode, including highly concentrated dependency imbalance, cross-link cascading large-scale imbalance, and data consistency diffusion imbalance. An architecture optimization trigger condition set is generated based on the duration, scope of impact, and business value relevance of each imbalance mode. When the architecture optimization trigger condition set is met, a trigger tag is invoked, and a corresponding architecture optimization target space is constructed. This target space includes at least two of the following: architecture decoupling optimization target, transaction convergence radius optimization target, and architecture adjustment risk constraint target, used to limit the allowed direction and magnitude of architecture adjustments. Based on the architecture optimization target space, structural transformation optimization of the platform runtime architecture dependency graph is performed, and architecture optimization management is executed based on the optimization results.

[0006] A second aspect of this application provides an e-commerce platform architecture optimization system based on Handle technology, the system comprising: The data collection module continuously collects real-time call behavior, data read / write paths, cross-domain transaction relationships, and performance response indicators across business modules during the operation of the e-commerce platform, based on Handle technology. It then constructs a platform runtime architecture dependency graph based on the collection results. The structure analysis module performs multi-dimensional structure analysis on the platform runtime architecture dependency graph, identifying at least one architecture imbalance mode. These imbalance modes include highly concentrated dependency imbalance, cross-link cascading amplification imbalance, and data consistency diffusion imbalance. It generates a set of architecture optimization trigger conditions based on the duration, scope of impact, and business value relevance of the imbalance modes. The optimization space construction module invokes trigger tags and constructs a corresponding architecture optimization target space when the set of architecture optimization trigger conditions is detected. This target space includes at least two of the following: architecture decoupling optimization target, transaction convergence radius optimization target, and architecture adjustment risk constraint target, limiting the allowed direction and magnitude of architecture adjustments. The optimization management module performs structural transformation optimization of the platform runtime architecture dependency graph based on the architecture optimization target space and performs architecture optimization management based on the optimization results.

[0007] One or more technical solutions provided in this application have at least the following technical effects or advantages: This application, during the operation of an e-commerce platform, continuously collects real-time call behavior, data read / write paths, cross-domain transaction relationships, and performance response indicators across business modules using Handle technology. Based on the collected results, a platform runtime architecture dependency graph is constructed. Multi-dimensional structural analysis is performed on the platform runtime architecture dependency graph to identify at least one architecture imbalance mode, including highly concentrated dependency imbalance, cross-link cascading large-scale imbalance, and data consistency diffusion imbalance. An architecture optimization trigger condition set is generated based on the duration, scope of impact, and business value relevance of the architecture imbalance mode. When the architecture optimization trigger condition set is detected, a trigger tag is invoked to construct a corresponding architecture optimization target space. The architecture optimization target space includes at least two of the following: architecture decoupling optimization target, transaction convergence radius optimization target, and architecture adjustment risk constraint target, used to limit the allowed direction and magnitude of architecture adjustments. Based on the architecture optimization target space, structural transformation optimization of the platform runtime architecture dependency graph is performed, and architecture optimization management is executed based on the optimization results. This invention addresses the technical problem in existing technologies where e-commerce platforms cannot promptly identify and effectively optimize architectural imbalances during runtime. By constructing a runtime architectural dependency graph and triggering controlled structural optimization based on imbalance patterns, it achieves real-time detection and automated optimization of architectural imbalances, thereby improving the platform's architectural stability and sustainable evolution capabilities. Attached Figure Description

[0008] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0009] Figure 1 A schematic diagram of the e-commerce platform architecture optimization method based on Handle technology provided in this application embodiment; Figure 2 This is a schematic diagram of the system architecture optimization of the e-commerce platform based on Handle technology provided in the embodiments of this application.

[0010] Figure labeling: Acquisition module 11, structural analysis module 12, optimization space construction module 13, optimization management module 14. Detailed Implementation

[0011] This application provides an e-commerce platform architecture optimization method and system based on Handle technology. It addresses the technical problem in existing technologies that e-commerce platforms cannot promptly identify and effectively optimize architectural imbalances during runtime. By constructing a runtime architecture dependency graph and triggering controlled structural optimization based on imbalance patterns, it achieves real-time detection and automated optimization of architectural imbalances, thereby improving the platform's architectural stability and sustainable evolution capabilities.

[0012] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0013] It should be noted that any variation of the terms "comprising" and "having" is intended to cover non-exclusive inclusion, for example, a process, method, system, product, or server that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or modules that are not explicitly listed or that are inherent to such processes, methods, products, or devices.

[0014] Example 1, as Figure 1 As shown, this application provides a method for optimizing the architecture of an e-commerce platform based on Handle technology, the method comprising: Step S100: During the operation of the e-commerce platform, based on Handle technology, real-time call behavior, data read and write paths, cross-domain transaction relationships and performance response indicators of cross-business modules are continuously collected, and the platform runtime architecture dependency graph is constructed based on the collection results.

[0015] In this embodiment, during the operation of the e-commerce platform, the call status across business modules is continuously observed based on Handle technology. By recording the request trigger point, call order, call duration, and call result, real-time call behavior reflecting the interaction methods and dependency strength between business units is obtained. The aforementioned real-time call behavior includes features such as call direction, call sequence, and call frequency, which can be used to characterize the call relationship structure in the runtime state.

[0016] To obtain data read / write paths, Handle technology is used to continuously record data access actions between different business units. By analyzing the source, purpose, and access order of various data read and write actions, the complete trajectory of data flow during business processing is obtained. The data read / write paths obtained through this process reflect data dependencies and the actual data transfer methods between different business units.

[0017] When identifying cross-domain relationships in transactions, the Handle technology is used to continuously track the propagation process of the same business transaction across multiple domains. By recording the flow order, processing scope, and transmission depth of the transaction in different execution stages, a complete cross-domain relationship structure of the transaction is obtained. The obtained cross-domain relationship of the transaction can show the diffusion process of a business transaction between different business units and its impact chain.

[0018] In collecting performance response metrics, Handle technology is used to continuously monitor the response latency, processing scale, and anomalies of each call and access behavior. By statistically analyzing and extracting features from multiple sampled values, performance response metrics reflecting changes in runtime pressure, latency fluctuations, and anomaly trends are obtained. These performance response metrics ensure that call relationships, data relationships, and transaction relationships are all accompanied by accurate runtime performance information.

[0019] The aforementioned real-time call behavior, data read / write paths, cross-domain transaction relationships, and performance response metrics collectively constitute the collected results. Based on these results, by performing time alignment, content association, and structural unification on different types of data, the call relationships, data relationships, and transaction relationships between business units are organized into a node-edge structure. This allows call intensity, data flow, transaction propagation scope, and performance characteristics to be expressed within the same structure, ultimately constructing a platform runtime architecture dependency graph that reflects the runtime coupling state.

[0020] Furthermore, the method provided in the application embodiments also includes: The platform runtime architecture dependency graph uses business capability units as nodes and edges jointly represented by call strength and state coupling degree as connections to depict the actual runtime coupling state under the current platform architecture.

[0021] In this embodiment of the application, when constructing the platform runtime architecture dependency graph, the business capability units that can independently undertake specific business processing responsibilities are first identified as nodes in the graph based on the functional division presented by the e-commerce platform during operation, so that each node corresponds to a clear and distinguishable business processing function.

[0022] Subsequently, the actual call relationships between the business capability units are extracted, and the number of requests per unit time is counted. This statistic is used as the call intensity to characterize the load correlation between two business capability units.

[0023] Simultaneously, the transaction latency, data read / write dependencies, and state propagation range that occur in the call chain are measured. These quantitative values, which reflect the degree of state influence between nodes, are used as the state coupling degree to characterize the degree of diffusion of the running state between nodes.

[0024] Next, the call strength and state coupling degree are jointly represented in a preset way and used as attributes of the edges connecting the corresponding business capability units, so that the edges can reflect the dual relationship between operating load and state diffusion.

[0025] The platform runtime architecture dependency graph obtained through the above steps has nodes corresponding to business capability units, and its edges are characterized by both call strength and state coupling degree, which are used to depict the real coupling structure relationship of the e-commerce platform in the current runtime state.

[0026] Step S200: Perform multi-dimensional structural analysis on the platform runtime architecture dependency graph to identify at least one architecture imbalance mode. The architecture imbalance mode includes highly centralized dependency imbalance, cross-link cascading amplification large-scale imbalance, and data consistency diffusion imbalance. Generate a set of architecture optimization trigger conditions based on the duration, scope of impact, and business value relevance of the architecture imbalance mode.

[0027] In this embodiment of the application, when performing multidimensional structural analysis on the platform runtime architecture dependency graph, a set of structural metrics is first defined and calculated on the platform runtime architecture dependency graph. The set of structural metrics includes node centrality metrics, subgraph clustering coefficients, path redundancy index, transaction propagation amplification coefficient, write amplification radius, and cross-domain coupling strength index.

[0028] Subsequently, based on the set of structural metrics, a sliding time window mechanism is used to calculate the statistical distribution of each structural metric in the short-term time window and the baseline distribution in the long-term time window, and to construct a metric deviation vector based on the difference between the short-term statistical distribution and the long-term baseline distribution.

[0029] Then, using the deviation vector as input, a combined decision mechanism is adopted to identify the platform runtime architecture dependency graph. The combined decision mechanism identifies imbalanced candidate regions in the platform runtime architecture dependency graph that may have abnormal structures by fusing rule threshold judgment and unsupervised clustering judgment.

[0030] Next, for the identified imbalance candidate regions, persistence indicators and impact diffusion scores are calculated to characterize the duration of the imbalance and the potential scope of its impact. Based on this, at least one architectural imbalance mode is constructed in the platform runtime architecture dependency graph. The architectural imbalance modes include highly centralized dependency imbalance, cross-link cascading amplification of large-scale imbalance, and data consistency diffusion imbalance.

[0031] Finally, a set of architectural optimization trigger conditions is generated based on the duration, scope of impact, and business value relevance of the architectural imbalance pattern. In this process, the duration of the architectural imbalance pattern is first calculated. A fixed-length sliding time window method is used to statistically analyze the deviation of the deviation vector within consecutive time windows. When the deviation remains above the long-term baseline in multiple adjacent windows, these adjacent windows are merged into a continuous segment, and the total duration of this continuous segment is used as the duration indicator. For example, if an imbalance pattern remains deviated for six consecutive one-minute windows, its duration is recorded as six minutes.

[0032] The impact range of the architectural imbalance mode is then calculated. A range expansion method based on multi-hop propagation is adopted, expanding from the imbalance candidate region to the associated edges of the outer edge of the platform's runtime architectural dependency graph by a preset number of hops. The number of nodes reached during the expansion process is counted, and the proportion of this number to the total number of related nodes is used as the impact range indicator. For example, if the number of nodes reached within three hops accounts for 20% of the total number of related nodes, the impact range is recorded as 20%.

[0033] Next, the business value relevance of the architectural imbalance pattern is calculated. A path overlap calculation method is used to compare the imbalance candidate region with pre-marked key business paths, calculating the overlap ratio between nodes within the imbalance region and nodes on the key business paths, and using this ratio as the business value relevance. For example, if the imbalance region involves 30% of the nodes in the key business path, the business value relevance is recorded as 30%.

[0034] After obtaining the duration, impact, and business value relevance metrics, a set of architecture optimization trigger conditions is generated using preset combination rules. A threshold combination method is employed to match the three types of metrics with different types of architecture imbalance patterns. For example, when the duration exceeds a set threshold, the impact exceeds a set range, and the business value relevance reaches a critical level, this imbalance pattern is marked as a condition requiring architecture optimization. Finally, the set of architecture optimization trigger conditions comprises all conditions that meet the triggering requirements.

[0035] Furthermore, the method provided in the application embodiments, which performs multi-dimensional structural analysis on the platform runtime architecture dependency graph to identify at least one architecture imbalance mode, further includes: A set of structural metrics is defined and calculated on the platform's runtime architecture dependency graph. These structural metrics include: node centrality metric, subgraph clustering coefficient, path redundancy index, transaction propagation amplification coefficient, write amplification radius, and cross-domain coupling strength index. Based on this set of structural metrics, a sliding time window mechanism is used to calculate the short-term statistical distribution and long-term baseline distribution of each metric, and a metric deviation vector is constructed based on the distance between the short-term and long-term distributions. Using the metric deviation vector as input, a combined decision mechanism is used to identify imbalance candidate regions. Based on the identified imbalance candidate regions, a persistence index and impact diffusion score are calculated to construct an architecture imbalance pattern.

[0036] In this embodiment of the application, when defining and calculating the set of structural metrics on the platform runtime architecture dependency graph, a graph calculation method based on adjacency and shortest path relationships is used to complete one traversal and on-demand shortest path calculation, resulting in six results: node centrality metric, subgraph clustering coefficient, path redundancy index, transaction propagation amplification coefficient, write amplification radius, and cross-domain coupling strength index. The node centrality metric uses the node degree value as a direct quantification of the degree of call concentration; the subgraph clustering coefficient is obtained by dividing the number of existing triangular relationships in the neighborhood by the theoretical number of triangular relationships, and is used to characterize the tightness of local connections; the path redundancy index is obtained by enumerating the number of simple paths with limited length between two given points and comparing it with the shortest path length, and is used to reflect the path substitution capability; the transaction propagation amplification coefficient is obtained by constructing the directed propagation structure of the same transaction and calculating the product of the average number of branches and the maximum propagation level, and is used to reflect the propagation expansion magnitude; the write amplification radius is obtained by taking the quantile value (e.g., the 90th tenth) of the set of shortest distances from the source node to the affected node in a single write, and is used to reflect the write diffusion range; the cross-domain coupling strength index is obtained by the ratio of the sum of the weights of cross-domain directed edges to the sum of the weights of intra-domain directed edges, and is used to reflect the cross-domain association strength.

[0037] Next, based on the set of structural metrics, a sliding time window mechanism is used to calculate the short-term statistical distribution and long-term baseline distribution for each structural metric. The short-term statistical distribution reflects the real-time state of the current period, using a 5-minute window; for example, it comprises all node centrality metrics and path redundancy indices collected between 10:00 and 10:05. The long-term baseline distribution describes the stability level over a long period, using a 60-minute window; for example, it comprises six structural metrics collected between 9:00 and 10:00. At the end of each window, a representative value, such as the short-term average, is calculated for the short-term statistical distribution, and the long-term average is calculated for the long-term baseline distribution. The difference between the short-term average and the long-term average is used as the deviation. The deviations of the six structural metrics are combined in a fixed order to form a metric deviation vector.

[0038] Subsequently, using the metric deviation vector as input, a combined decision mechanism is employed to identify imbalance candidate regions. In this process, the combined decision mechanism works collaboratively through a rule-based threshold determination submodule, an unsupervised graph embedding clustering submodule, and a combined decision fusion module. First, the rule-based threshold determination submodule sets structural thresholds for each component of the metric deviation vector. When any component exceeds its structural threshold, the corresponding node or related subgraph region is marked as a rule-abnormal candidate. Then, in the unsupervised graph embedding clustering submodule, the metric deviation vector is jointly embedded with its topological information in the platform's runtime architecture dependency graph to obtain a low-dimensional vector representation. Density clustering or hierarchical clustering is then performed based on this low-dimensional vector representation to identify clustering anomalous regions caused by both deviation concentration and topological association, thus obtaining latent imbalance candidates. Finally, the combined decision fusion module performs a fusion analysis on the rule-abnormal candidates and latent imbalance candidates, comprehensively judging their intersection or combination relationships to output the final imbalance candidate regions.

[0039] Finally, based on the identified imbalance candidate regions, persistence indices and impact diffusion scores are calculated to construct the architectural imbalance pattern. When calculating the persistence indices, the time axis is first divided into continuous time windows of fixed duration, for example, each window is 1 minute long. Next, within each time window, it is determined whether the imbalance candidate region is in an abnormal state, and this is recorded sequentially to form a label sequence consisting of 1s and 0s, where 1 represents abnormality and 0 represents normality. The label sequence is then scanned again, and consecutive occurrences of 1s are considered as a continuous abnormal segment, with the number of 1s in that segment counted. Finally, the number of continuous abnormal segments is multiplied by the duration of each time window to obtain the persistence value of that segment, and the maximum persistence value from all segments is selected as the persistence index. For example, if, within the 10 windows from 10:00 to 10:10, an imbalance candidate region is marked as 1 for 8 consecutive windows between 10:02 and 10:09, then the persistence index is equal to 8 minutes, representing the specific duration for which the imbalance candidate region remains continuously abnormal.

[0040] When calculating the impact diffusion score, the imbalanced candidate region is first used as the starting point, and the platform's runtime architecture dependency graph is expanded according to a limited number of hops, for example, performing a 3-hop expansion. Next, the set of nodes reachable by the first hop is counted, then the set of nodes reachable by the second hop is counted, and finally the set of nodes reachable by the third hop is counted. During the expansion process, only related edges with edge weights not lower than a set threshold are retained. Then, all reachable nodes within the 3-hop expansion range are deduplicated and counted to obtain the number of reachable nodes N1, and the total number of related nodes N2 is counted. The coverage ratio N1 is then divided by N2. Subsequently, the length L of the deepest expansion path in the 3-hop expansion is recorded, and L is divided by a baseline value used for normalization to obtain the path depth normalized value. Finally, the coverage ratio and the path depth normalized value are linearly summed according to preset weights to obtain the impact diffusion score. For example, in a 3-hop expansion, there are 36 reached nodes, 120 related nodes, a coverage ratio of 0.30, a deepest expansion path length of 5, and a path depth normalization value of 0.5. After multiplying the coverage ratio by 0.6 and adding the path depth normalization value multiplied by 0.4, the impact diffusion score is 0.38.

[0041] After obtaining the persistence metric and impact diffusion score, and combining the key deviation components in the metric deviation vector, an architectural imbalance pattern is constructed using fixed mapping rules. When the deviation value of the node centrality metric increases significantly and the impact diffusion score is mainly concentrated in a small number of nodes, a highly concentrated dependency imbalance is constructed in the platform runtime architectural dependency graph. When the deviation value of the transaction propagation amplification coefficient increases significantly and the deepest extension path grows from a shorter level to a longer level within a limited number of hops, a large-scale cross-link cascading amplification imbalance is constructed. When the deviation values ​​of the write amplification radius and the cross-domain coupling strength metric both increase in the metric deviation vector, and the coverage ratio continues to increase in multi-hop extension, a data consistency diffusion imbalance is constructed. The calculation results formed by the persistence metric, impact diffusion score, and deviation components in the metric deviation vector can clearly construct at least one architectural imbalance pattern in the platform runtime architectural dependency graph.

[0042] Furthermore, in the method provided in the application embodiments, using the metric deviation vector as input and employing a combined decision mechanism to identify imbalance candidate regions, it further includes: The combined decision mechanism includes a rule threshold determination submodule, an unsupervised graph embedding clustering submodule, and a combined decision fusion module. The rule threshold determination submodule sets structural thresholds for each component of the metric deviation vector. When any component exceeds the corresponding structural threshold, the corresponding node or subgraph region is marked as a rule anomaly candidate. The metric deviation vector is jointly embedded with the topological information of the corresponding node in the platform's runtime architecture dependency graph to generate a low-dimensional vector representation. The unsupervised graph embedding clustering submodule performs density or hierarchical clustering of the low-dimensional vector representation to identify clustering anomaly regions of nodes or subgraphs and establish latent imbalance candidates. The combined decision fusion module performs a fusion analysis of rule anomaly candidates and latent imbalance candidates, outputting imbalance candidate regions.

[0043] In this embodiment, the combined decision mechanism includes a rule threshold determination submodule, an unsupervised graph embedding clustering submodule, and a combined decision fusion module. In the rule threshold determination submodule, a structural threshold is set for each component of the metric deviation vector. The structural threshold is determined based on the statistical results of the long-term baseline distribution. For example, if the mean of the node centrality metric in the long-term baseline distribution is 30 and the standard deviation is 6, then the structural threshold can be 42, which is the mean plus twice the standard deviation. Then, the metric deviation vector is calculated in each short-term time window. For example, if the short-term value of the node centrality metric of a node is 48, and the difference from the mean of the long-term baseline distribution is 18, which is greater than the structural threshold of 12, the node can be immediately marked as a candidate for rule anomaly. To improve stability, it can be required that the threshold condition is met for three consecutive windows. For example, if the metric deviations at 10:00, 10:01, and 10:02 are 18, 20, and 17 respectively, all higher than the structural threshold of 12, then the node is marked as a candidate for rule anomaly.

[0044] In the unsupervised graph embedding clustering submodule, the metric deviation vector is jointly embedded with the topological information of the corresponding node in the platform runtime architecture dependency graph. The joint embedding is calculated by generating a vector for each node, consisting of structural deviation information and topological connectivity features. The structural deviation information comes from the normalization result of the metric deviation vector, while the topological connectivity features come from the local connectivity of the node in the platform runtime architecture dependency graph, such as the number of neighboring nodes and the strength of local connections. These two types of information are concatenated to obtain a low-dimensional vector representation for clustering. Clustering operations are then performed based on this low-dimensional vector representation, using density clustering or hierarchical clustering methods. Clusters of vectors are identified by analyzing the distance relationships between nodes in the low-dimensional space. When some nodes are close to each other in the low-dimensional space and their deviation features are similar, this area is identified as an anomalous clustering region and used as a latent imbalance candidate to characterize potential imbalances caused by both structural changes and topological structures.

[0045] In the combined decision fusion module, a fusion analysis is performed on rule-abnormal candidates and latent imbalance candidates. First, the intersection of the two types of candidates in the platform's runtime architecture dependency graph is calculated. For example, if there are 8 nodes in the rule-abnormal candidate group and 10 nodes in the latent imbalance candidate group, the intersection number is 5 nodes. Then, the coverage is calculated, which equals the number of intersection nodes divided by the number of union nodes. For example, if the union has 13 nodes, the coverage is 5 divided by 13, which equals 0.38. Next, the comprehensive deviation strength is calculated. For example, if the average deviation value of the rule-abnormal candidate nodes is 15 and the average deviation value of the latent imbalance candidate nodes is 12, the comprehensive deviation strength is 27. When the coverage is greater than 0.35 and the comprehensive deviation strength is greater than 25, the intersection region can be directly identified as an imbalance candidate region. If the coverage is 0.25 but the comprehensive deviation strength reaches 35, the union of the two is considered an imbalance candidate region.

[0046] Step S300: When the set of architecture optimization trigger conditions is detected, the trigger tag is invoked to construct the corresponding architecture optimization target space. The architecture optimization target space includes at least two of the following: architecture decoupling optimization target, transaction convergence radius optimization target, and architecture adjustment risk constraint target, which are used to limit the allowed direction and magnitude of architecture adjustments.

[0047] In this embodiment, when a set of architectural optimization trigger conditions is detected, the corresponding structural imbalance mode type is determined by calling a trigger tag, and an architectural optimization target space is constructed accordingly. The architectural optimization target space consists of at least two of the following: architectural decoupling optimization target, transaction convergence radius optimization target, and architectural adjustment risk constraint target. These targets are used to limit the allowed direction and magnitude of architectural adjustments. Specifically, the architectural decoupling optimization target limits the adjustment direction to reducing the coupling relationship between nodes and controls the magnitude of coupling reduction; the transaction convergence radius optimization target limits the adjustment direction to shortening the propagation path of transactions in the platform's runtime architectural dependency graph and controls the magnitude of path reduction; and the architectural adjustment risk constraint target limits the adjustment direction to reducing the performance and stability risks caused by structural changes and controls the magnitude of the change. The architectural optimization target space, constructed by these targets, limits the feasible scope of operations such as node merging, node splitting, call path adjustment, and data access path rearrangement in the platform's runtime architectural dependency graph. This ensures that subsequent architectural adjustments are executed within a clear direction and controlled scope, thereby ensuring that the overall architectural optimization process is manageable, constrained, and meets the optimization requirements corresponding to the structural imbalance mode.

[0048] Furthermore, in the method provided in the application embodiments, when the set of architecture optimization triggering conditions is detected, a trigger tag is invoked to construct a corresponding architecture optimization target space, which further includes: Based on the trigger tags, the structural imbalance mode type is obtained. Using the structural imbalance mode type as the matching condition, a target subset is matched from the predefined set of architecture optimization target dimensions. Different architecture imbalance modes correspond to target subsets with different weight combinations to reduce irrelevant architectural interventions on non-primary imbalance factors. For each architecture optimization target dimension in the target subset, the corresponding target constraint interval is calculated based on the duration, scope of impact, and business value relevance of the structural imbalance mode. The architecture decoupling optimization target, transaction convergence radius optimization target, and architecture adjustment risk constraint target are mapped to structural constraints on the platform's runtime architecture dependency graph. The structural constraints are used to limit the executable scope of structural transformation operations such as node merging, splitting, call path adjustment, and data access path rearrangement. Based on the target constraint intervals and structural constraints, a multi-objective constrained architecture optimization target space is jointly constructed.

[0049] In this embodiment, after detecting a set of conditions that meet the architecture optimization triggering criteria, the structural imbalance mode type is obtained based on the trigger tag. Using the structural imbalance mode type as the matching condition, a target subset is matched from a predefined set of architecture optimization target dimensions. A mapping table method is used to map the structural imbalance mode type to the architecture decoupling optimization target, the transaction convergence radius optimization target, and the architecture adjustment risk constraint target, and different weight combinations are given to reduce irrelevant architectural interventions on non-primary imbalance factors. For example, highly concentrated dependency imbalance corresponds to the architecture decoupling optimization target and the architecture adjustment risk constraint target with a weight ratio of 6:4; cross-link cascading amplification imbalance corresponds to the transaction convergence radius optimization target and the architecture adjustment risk constraint target with a weight ratio of 7:3; and data consistency diffusion imbalance corresponds to the architecture decoupling optimization target and the transaction convergence radius optimization target with a weight ratio of 5:5. Through this process, the target subset and its weight combination matching the current structural imbalance mode type are obtained.

[0050] Next, for each architecture optimization dimension in the target subset, the corresponding target constraint interval is calculated based on the duration, impact range, and business value relevance of the structural imbalance mode. In this process, a linear interval calibration method is used to normalize the three inputs to a range of 0 to 1 and combine them into upper and lower limits according to a fixed ratio. These limits are then truncated to an executable interval based on safety boundaries. For example, when the duration is 8 minutes, the impact range coverage ratio is 0.30, and the business value relevance is 0.7, the architecture decoupling optimization target achieves a decoupling reduction of approximately 0.28 to 0.48, the transaction convergence radius optimization target achieves a reduction in the deepest path of approximately 2 to 4 layers, and the architecture adjustment risk constraint target achieves an upper limit of the proportion of nodes involved in a single change of approximately 0.036 and a performance regression window of approximately 8 minutes. Through this process, target constraint intervals covering all activated target dimensions are obtained.

[0051] Subsequently, the optimization objectives for architectural decoupling, transaction convergence radius, and architectural adjustment risk constraints are mapped to structural constraints on the platform's runtime architectural dependency graph. A direct translation method is used to transform each objective constraint interval into hard restrictions at the graph level. These include the allowed range of changes in node in-degree and out-degree, the maximum decrease in edge weight, the upper limit of the deepest level of a transaction path, the upper limit of cross-domain coupling strength, the maximum scale limit for node merging and splitting, call path adjustment, and data access path reordering in a single batch, and the requirement that critical link performance must revert to the adjacent interval of the long-term baseline distribution. For example, when the decoupling reduction limit is 0.48, the weight reduction of any adjusted edge must not exceed 0.48 of its original value; when the deepest path shortening limit is 4 levels, the new deepest level of the transaction path must not be higher than the original level minus 4; and when the node ratio limit is 0.036, the number of nodes involved in a single batch must not exceed 3.6% of the total number of nodes. This process yields structural constraints that can be directly applied to the platform's runtime architectural dependency graph.

[0052] Finally, based on the target constraint interval and structural constraints, a multi-objective constrained architecture optimization target space is jointly constructed. In this process, the feasible region intersection method is used to verify each candidate structural change scheme. First, it is determined whether all scheme parameters fall within the corresponding target constraint interval; then, it is verified whether all structural constraints are met. Finally, the comprehensive priority is calculated according to the weight combination of the target subsets, and the scheme is selected and added to the database. For example, if a scheme has a decoupling reduction of 0.32, a deepest path shortening to 3, involves 3 nodes with a proportion not exceeding 0.036, and simultaneously satisfies all constraints on edge weight reduction, cross-domain coupling strength, and performance regression, then this scheme is included in the solution set and sorted according to the weight combination. Through this process, a multi-objective constrained architecture optimization target space that meets the constraints and can be used for subsequent structural transformation optimization is obtained.

[0053] Step S400: Based on the architecture optimization target space, perform structural transformation optimization of the platform runtime architecture dependency graph, and perform architecture optimization management based on the optimization results.

[0054] In this embodiment, when optimizing the structural transformation of the platform runtime architecture dependency graph based on the architecture optimization target space, the platform runtime architecture dependency graph is first parsed, and the optimization potential index of each node or subgraph is calculated based on the topological features, node centrality, cross-domain transaction paths, and data access paths in the parsing results. Then, based on the metric deviation vector corresponding to the trigger label and the persistence index, the coupling growth trend or transaction diffusion trend within multiple future time windows is predicted, and this prediction result is combined with the optimization potential index to generate multiple candidate structural transformation schemes. Next, the architecture decoupling optimization objective, the transaction convergence radius optimization objective, and the architecture adjustment risk constraint objective in the architecture optimization target space are treated as multiple agents with independent evaluation criteria. Through collaborative game theory, all candidate structural transformation schemes are evaluated for optimization, so that each objective, within the constraints, jointly promotes the selection of the structural transformation direction. Finally, an optimization result that comprehensively meets the requirements of the architecture optimization target space is obtained.

[0055] Next, when performing architecture optimization management based on the optimization results, the optimization results are executed step by step in a phased sequence. Before the start of each phase, the optimization potential index and imbalance prediction results are recalculated based on the latest updated platform runtime architecture dependency graph, thereby obtaining the key areas of structural change and potential diffusion trends for the current phase. Subsequently, the constraints and action strategies in the architecture optimization target space are dynamically updated to ensure that the structural changes in subsequent phases remain consistent with the real-time state of the platform runtime architecture dependency graph. By continuously executing in phases and dynamically correcting constraints and strategies, the architecture optimization management is finally completed.

[0056] Furthermore, in the method provided in the application embodiments, the structural transformation optimization of the target space execution platform runtime architecture dependency graph based on the architecture optimization further includes: The platform's runtime architecture dependency graph is analyzed. Based on the topological features, node centrality, cross-domain transaction paths, and data access paths in the analysis results, the optimization potential index of each node or subgraph is calculated. Based on the metric deviation vector and persistence index of the trigger label, the coupling growth or transaction diffusion trend within multiple future time windows is predicted. N candidate structural transformation schemes are generated by combining the optimization potential index. Each objective in the architecture optimization target space is regarded as an intelligent agent, and the optimization evaluation of the N candidate structural transformation schemes is carried out through collaborative game to complete the structural transformation optimization.

[0057] In this embodiment, when parsing the platform runtime architecture dependency graph, the topological features are first extracted using a graph traversal method, and the shortest path analysis method is used to calculate the cross-domain transaction path and data access path. Then, the node centrality is quantified using betweenness centrality or degree centrality. Subsequently, the topological features, node centrality, cross-domain transaction path strength, and data access path strength are mapped to the 0~1 interval using min-max normalization, and linearly combined in a fixed ratio to obtain the optimization potential index for each node or subgraph. For example, if a node has a topological feature of 0.60, a node centrality of 0.50, a cross-domain transaction path strength of 0.40, and a data access path strength of 0.30, and is calculated in a 3:3:2:2 ratio, the optimization potential index is 0.47. This process yields an optimization potential index covering all nodes or subgraphs.

[0058] In the trend prediction phase, linear extrapolation predictions are performed for multiple future time windows based on the deviation vector and persistence index corresponding to the trigger tags. The average deviation increment of the most recent three windows is calculated using the sliding time window method as the growth slope, and the persistence index is used as the trend amplification ratio. For example, if the node centrality deviation of a node is 12, 16, and 19 in the most recent three windows, then the slope = [(19−16)+(16−12)]÷2 = 3.5; the persistence index is 6 minutes, then the amplification ratio = 1+6÷10 = 1.6; the predicted deviation for the next window = 19×(1+3.5÷20)×1.6≈35.68. This calculation is repeated for cross-domain transaction paths and data access paths to obtain the coupled growth trend and transaction diffusion trend. The trend values ​​are then multiplied by the optimization potential index and sorted. Several structural change starting points are selected from high to low, and N candidate structural transformation schemes are generated based on these starting points, including structural actions such as node merging, node splitting, call path adjustment, and data access path rearrangement.

[0059] When generating candidate solutions, based on the target constraint range given by the architecture optimization target space, multiple action levels that meet the range requirements are generated for each structural action. For example, if the decoupling reduction range is 0.28–0.48, then three reduction levels of 0.30, 0.40, and 0.48 are tried for each related edge; if the deepest path shortening range of the transaction convergence radius is 2–4 layers, then the path is adjusted to shorten it by 2, 3, or 4 layers; if the node ratio upper limit is 0.036, then the number of nodes selected in a single operation is ≤ the total number of nodes × 0.036. By combining these levels with the starting point, N candidate structural transformation schemes are obtained.

[0060] In the optimization and evaluation phase, the optimization objectives of architectural decoupling, transaction convergence radius, and architectural adjustment risk constraints are treated as three agents, and a collaborative game evaluation is conducted on N candidate solutions. Using a multi-objective collaborative evaluation method, each agent independently scores the candidate solutions based on its own optimization direction. For example, if the global coupling index of a candidate solution decreases by 0.22, the decoupling score is 0.22; if the transaction path is reduced from 7 layers to 4 layers (a reduction of 3 layers), the convergence score is 3 ÷ 4 = 0.75; if the proportion of nodes involved in the change is 0.024 ≤ 0.036, and the performance of the critical link returns to the vicinity of the long-term baseline distribution within 8 minutes, the risk score is 1. Based on these, the comprehensive score is calculated in a 5:3:2 ratio: Comprehensive score = 0.22 × 0.5 + 0.75 × 0.3 + 1 × 0.2 = 0.11 + 0.225 + 0.2 = 0.535. Furthermore, if a solution violates any structural constraints, it is directly eliminated. The remaining candidates are sorted by their overall scores, and the candidate with the highest score that meets all the requirements is selected as the optimal candidate.

[0061] Furthermore, the method provided in the application embodiments, which performs architecture optimization management based on the optimization results, further includes: The optimization results are executed in stages. Before each stage, the optimization potential index and imbalance prediction results are recalculated based on the latest updated platform runtime architecture dependency graph, and the target space constraints and action strategies are dynamically updated.

[0062] In this embodiment, before the start of a phase, the optimization potential index is recalculated based on the latest updated platform runtime architecture dependency graph. The updated topological features, node centrality, cross-domain transaction paths, and data access paths are obtained through graph traversal and shortest path calculation. These four values ​​are normalized to 0 to 1 and linearly added at a fixed ratio to form the optimization potential index for the current phase.

[0063] Simultaneously, based on the metric deviation vector of the trigger tag and the persistence index, multiple subsequent time windows are linearly extrapolated to calculate the growth slope of node centrality deviation, transaction cross-domain path deviation, and data access path deviation, respectively. The persistence index is used as the amplification ratio to synthesize the imbalance prediction result of the current stage.

[0064] After obtaining the imbalance prediction results for the current stage, the optimization targets for architectural decoupling, transaction convergence radius, and architectural adjustment risk constraints are updated within intervals based on the duration, scope of impact, and relevance to business value of the structural imbalance pattern. A linear interval calibration method maps the duration, scope of impact, and relevance to business value to new upper and lower limits, allowing the adjustment range to converge or widen synchronously with the degree of structural imbalance. For example, when the duration shortens, the scope of impact decreases, or the relevance to business value decreases, the upper and lower limits of the decoupling reduction shrink accordingly, the range of levels from which transaction paths can be shortened decreases, and the proportion of nodes involved in a single transaction decreases synchronously, thus forming a new target constraint interval for this stage.

[0065] After obtaining the new target constraint intervals, these intervals are directly converted into structural constraints on the platform runtime architecture dependency graph. This limits the allowable range of changes in node in-degree and node out-degree, restricts the maximum value of edge weight decrease, limits the upper limit of the deepest level of the transaction path, and limits the upper limit of cross-domain coupling strength. At the same time, it determines the upper limit of the number of nodes that can be involved in a single batch, so that all structural transformations are constrained by the current stage's constraints.

[0066] After updating the structural constraints, candidate actions are ranked according to the new optimization potential index and the new imbalance prediction results, and each action is examined to see if it meets the new target constraint range and structural constraints. For actions that meet all conditions, an executable range is set within their allowable range. For example, the decoupling reduction is limited to the new upper and lower limits, the transaction path shortening is limited to the new level range, and the number of nodes involved is strictly controlled within the new upper limit. By ranking, filtering, and limiting the range of actions such as node merging, node splitting, call path adjustment, and data access path rearrangement, the action strategy for the current stage is formed.

[0067] After setting the action strategy, it is used for structural adjustment execution in this phase, ensuring that structural changes always remain within the latest target and structural constraints. Through the above phased execution and real-time updates before each phase, the architecture optimization process can always remain consistent with the platform's runtime architecture dependency graph, thereby achieving dynamic updates of target space constraints and action strategies.

[0068] Furthermore, the method provided in the application embodiments also includes: If new potential imbalances or risks are detected that exceed constraints during the phased execution process, the system will automatically roll back to the previous safe state node and perform optimization and reconstruction.

[0069] In this embodiment of the application, during the phased execution process, the deviation vector and persistence index are recalculated based on the latest platform runtime architecture dependency graph before and after each structural adjustment operation, and the imbalance prediction result is obtained by using the linear extrapolation method of sliding time window. The imbalance prediction result is then compared with the target constraint interval and structural constraint conditions.

[0070] When the comparison results indicate the emergence of new potential imbalances, or if any risk value exceeds the structural constraints, it is determined that the current adjustment has exceeded the allowable range. At this point, based on the saved runtime records, the most recent runtime state that simultaneously met the architecture decoupling optimization objective, the transaction convergence radius optimization objective, and the architecture adjustment risk constraint objective is located. This state is taken as the previous safe state node, and by reversing the executed node merging, node splitting, call path adjustment, and data access path rearrangement actions, the platform's runtime architecture dependency graph is restored to the previous safe state node.

[0071] Once the restoration is complete, the structure will be readjusted to ensure that the architecture optimization process is always performed within constraints.

[0072] Furthermore, the method provided in the application embodiments also includes: Record the execution time and adjustment results of each structural adjustment to the platform runtime architecture dependency graph, and store the recorded results in the architecture optimization history database.

[0073] In this embodiment of the application, when recording each structural adjustment of the platform runtime architecture dependency graph, the execution time of the adjustment is first obtained after the structural adjustment action is completed, and it is used as a timestamp to identify the specific time when the architecture change occurs during the operation.

[0074] Subsequently, the node merging, node splitting, call path adjustment, and data access path rearrangement involved in this structural adjustment were extracted, and the actual changes they caused to the platform's runtime architecture dependency graph were recorded, including changes in node in-degree and out-degree, increases or decreases in edge weights, changes in transaction path depth, and changes in cross-domain coupling strength. These contents were taken as the results of the structural adjustment.

[0075] Next, the timestamp and structural adjustment results are combined into a complete record according to a fixed format, reflecting the specific performance of the architecture decoupling optimization goal, transaction convergence radius optimization goal, and architecture adjustment risk constraint goal in this adjustment. Finally, the record is written to the architecture optimization history database.

[0076] In summary, the embodiments of this application have at least the following technical effects: This application, during the operation of an e-commerce platform, continuously collects real-time call behavior, data read / write paths, cross-domain transaction relationships, and performance response indicators across business modules using Handle technology. Based on the collected results, a platform runtime architecture dependency graph is constructed. Multi-dimensional structural analysis is performed on the platform runtime architecture dependency graph to identify at least one architecture imbalance mode, including highly concentrated dependency imbalance, cross-link cascading large-scale imbalance, and data consistency diffusion imbalance. An architecture optimization trigger condition set is generated based on the duration, scope of impact, and business value relevance of the architecture imbalance mode. When the architecture optimization trigger condition set is detected, a trigger tag is invoked to construct a corresponding architecture optimization target space. The architecture optimization target space includes at least two of the following: architecture decoupling optimization target, transaction convergence radius optimization target, and architecture adjustment risk constraint target, used to limit the allowed direction and magnitude of architecture adjustments. Based on the architecture optimization target space, structural transformation optimization of the platform runtime architecture dependency graph is performed, and architecture optimization management is executed based on the optimization results. This invention addresses the technical problem in existing technologies where e-commerce platforms cannot promptly identify and effectively optimize architectural imbalances during runtime. By constructing a runtime architectural dependency graph and triggering controlled structural optimization based on imbalance patterns, it achieves real-time detection and automated optimization of architectural imbalances, thereby improving the platform's architectural stability and sustainable evolution capabilities.

[0077] Example 2, based on the same inventive concept as the e-commerce platform architecture optimization method based on Handle technology in the previous examples, such as... Figure 2 As shown, this application provides an e-commerce platform architecture optimization system based on Handle technology. The system and method embodiments in this application are based on the same inventive concept. The system includes: The data collection module 11 is used to continuously collect real-time call behavior, data read / write paths, cross-domain transaction relationships, and performance response indicators across business modules during the operation of the e-commerce platform, based on Handle technology, and construct a platform runtime architecture dependency graph based on the collection results. The structure analysis module 12 is used to perform multi-dimensional structure analysis on the platform runtime architecture dependency graph, identify at least one architecture imbalance mode, including highly concentrated dependency imbalance, cross-link cascading large-scale imbalance, and data consistency diffusion imbalance, and generate a set of architecture optimization trigger conditions based on the duration, scope of impact, and business value relevance of the architecture imbalance mode. The optimization space construction module 13 is used to call trigger tags and construct a corresponding architecture optimization target space when the set of architecture optimization trigger conditions is detected. The architecture optimization target space includes at least two of the following: architecture decoupling optimization target, transaction convergence radius optimization target, and architecture adjustment risk constraint target, which are used to limit the allowed direction and magnitude of architecture adjustments. The optimization management module 14 is used to perform structural transformation optimization of the platform runtime architecture dependency graph based on the architecture optimization target space, and perform architecture optimization management based on the optimization results.

[0078] Furthermore, the system is also used to implement the following functions: A set of structural metrics is defined and calculated on the platform's runtime architecture dependency graph. These structural metrics include: node centrality metric, subgraph clustering coefficient, path redundancy index, transaction propagation amplification coefficient, write amplification radius, and cross-domain coupling strength index. Based on this set of structural metrics, a sliding time window mechanism is used to calculate the short-term statistical distribution and long-term baseline distribution of each metric, and a metric deviation vector is constructed based on the distance between the short-term and long-term distributions. Using the metric deviation vector as input, a combined decision mechanism is used to identify imbalance candidate regions. Based on the identified imbalance candidate regions, a persistence index and impact diffusion score are calculated to construct an architecture imbalance pattern.

[0079] Furthermore, the system is also used to implement the following functions: The combined decision mechanism includes a rule threshold determination submodule, an unsupervised graph embedding clustering submodule, and a combined decision fusion module. The rule threshold determination submodule sets structural thresholds for each component of the metric deviation vector. When any component exceeds the corresponding structural threshold, the corresponding node or subgraph region is marked as a rule anomaly candidate. The metric deviation vector is jointly embedded with the topological information of the corresponding node in the platform's runtime architecture dependency graph to generate a low-dimensional vector representation. The unsupervised graph embedding clustering submodule performs density or hierarchical clustering of the low-dimensional vector representation to identify clustering anomaly regions of nodes or subgraphs and establish latent imbalance candidates. The combined decision fusion module performs a fusion analysis of rule anomaly candidates and latent imbalance candidates, outputting imbalance candidate regions.

[0080] Furthermore, the system is also used to implement the following functions: Based on the trigger tags, the structural imbalance mode type is obtained. Using the structural imbalance mode type as the matching condition, a target subset is matched from the predefined set of architecture optimization target dimensions. Different architecture imbalance modes correspond to target subsets with different weight combinations to reduce irrelevant architectural interventions on non-primary imbalance factors. For each architecture optimization target dimension in the target subset, the corresponding target constraint interval is calculated based on the duration, scope of impact, and business value relevance of the structural imbalance mode. The architecture decoupling optimization target, transaction convergence radius optimization target, and architecture adjustment risk constraint target are mapped to structural constraints on the platform's runtime architecture dependency graph. The structural constraints are used to limit the executable scope of structural transformation operations such as node merging, splitting, call path adjustment, and data access path rearrangement. Based on the target constraint intervals and structural constraints, a multi-objective constrained architecture optimization target space is jointly constructed.

[0081] Furthermore, the system is also used to implement the following functions: The platform's runtime architecture dependency graph is analyzed. Based on the topological features, node centrality, cross-domain transaction paths, and data access paths in the analysis results, the optimization potential index of each node or subgraph is calculated. Based on the metric deviation vector and persistence index of the trigger label, the coupling growth or transaction diffusion trend within multiple future time windows is predicted. N candidate structural transformation schemes are generated by combining the optimization potential index. Each objective in the architecture optimization target space is regarded as an intelligent agent, and the optimization evaluation of the N candidate structural transformation schemes is carried out through collaborative game to complete the structural transformation optimization.

[0082] Furthermore, the system is also used to implement the following functions: The optimization results are executed in stages. Before each stage, the optimization potential index and imbalance prediction results are recalculated based on the latest updated platform runtime architecture dependency graph, and the target space constraints and action strategies are dynamically updated.

[0083] Furthermore, the system is also used to implement the following functions: If new potential imbalances or risks are detected that exceed constraints during the phased execution process, the system will automatically roll back to the previous safe state node and perform optimization and reconstruction.

[0084] Furthermore, the system is also used to implement the following functions: Record the execution time and adjustment results of each structural adjustment to the platform runtime architecture dependency graph, and store the recorded results in the architecture optimization history database.

[0085] Furthermore, the system is also used to implement the following functions: The platform runtime architecture dependency graph uses business capability units as nodes and edges jointly represented by call strength and state coupling degree as connections to depict the actual runtime coupling state under the current platform architecture.

[0086] It should be noted that the order of the embodiments described above is for descriptive purposes only and does not represent the superiority or inferiority of the embodiments. Furthermore, the above description focuses on specific embodiments of this specification. The processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired results. In some implementations, multitasking and parallel processing are possible or may be advantageous.

[0087] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any modifications, equivalent changes, and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. An e-commerce platform architecture optimization method based on Handle technology, characterized in that, The method includes: During the operation of the e-commerce platform, the Handle technology is used to continuously collect real-time call behavior, data read and write paths, cross-domain transaction relationships and performance response indicators across business modules, and to build a platform runtime architecture dependency graph based on the collection results; A multi-dimensional structural analysis is performed on the platform's runtime architecture dependency graph to identify at least one architecture imbalance mode. The architecture imbalance modes include highly centralized dependency imbalance, cross-link cascading amplification imbalance, and data consistency diffusion imbalance. A set of architecture optimization trigger conditions is generated based on the duration, scope of impact, and business value relevance of the architecture imbalance modes. When the set of architecture optimization triggering conditions is detected, the trigger tag is invoked to construct the corresponding architecture optimization target space. The architecture optimization target space includes at least two of the following: architecture decoupling optimization target, transaction convergence radius optimization target, and architecture adjustment risk constraint target, which are used to limit the direction and magnitude of the allowed architecture adjustments. Based on the aforementioned architecture, the target space is optimized to perform structural transformation optimization of the runtime architecture dependency graph, and architecture optimization management is performed based on the optimization results.

2. The e-commerce platform architecture optimization method based on Handle technology as described in claim 1, characterized in that, A multi-dimensional structural analysis of the platform's runtime architecture dependency graph is performed to identify at least one architectural imbalance pattern, including: A set of structural metrics is defined and calculated on the platform runtime architecture dependency graph. The set of structural metrics includes: node centrality metric, subgraph clustering coefficient, path redundancy index, transaction propagation amplification coefficient, write amplification radius, and cross-domain coupling strength index. Based on the aforementioned set of structural metrics, a sliding time window mechanism is used to calculate the short-term statistical distribution and long-term baseline distribution of each metric, and a metric deviation vector is constructed based on the distance between the short-term and long-term distributions. Using the aforementioned deviation vector as input, a combined decision mechanism is employed to identify imbalance candidate regions. Based on the identified candidate imbalance regions, persistence indicators and impact diffusion scores are calculated to construct architectural imbalance patterns.

3. The e-commerce platform architecture optimization method based on Handle technology as described in claim 2, characterized in that, Using the metric deviation vector as input, a combined decision mechanism is employed to identify imbalance candidate regions, including: The combined decision mechanism includes a rule-based threshold determination submodule, an unsupervised graph embedding clustering submodule, and a combined decision fusion module. The rule threshold determination submodule sets structural thresholds for each component of the deviation vector. When any component exceeds the corresponding structural threshold, the corresponding node or subgraph region is marked as a candidate for rule anomaly. The deviation vector is jointly embedded with the topological information of the corresponding node in the platform runtime architecture dependency graph to generate a low-dimensional vector representation. Density or hierarchical clustering of the low-dimensional vector representation is performed through the unsupervised graph embedding clustering submodule to identify anomalous clustering regions of nodes or subgraphs and establish latent imbalance candidates. The combined decision fusion module is used to perform fusion analysis of rule-abnormal candidates and latent imbalance candidates, and output the imbalance candidate region.

4. The e-commerce platform architecture optimization method based on Handle technology as described in claim 1, characterized in that, When the set of architecture optimization triggering conditions is detected, the trigger tag is invoked to construct the corresponding architecture optimization target space, including: Based on the trigger tag, the structural imbalance mode type is obtained. Using the structural imbalance mode type as the matching condition, a target subset is matched from the predefined set of architecture optimization target dimensions. Different architecture imbalance modes correspond to target subsets with different weight combinations to reduce irrelevant architectural interventions on non-major imbalance factors. For each architecture in the target subset, optimize the target dimension and calculate the corresponding target constraint interval based on the duration, scope of impact, and business value relevance of the structural imbalance mode; The optimization objectives of architecture decoupling, transaction convergence radius, and architecture adjustment risk constraint are respectively mapped to structural constraints on the platform's runtime architecture dependency graph. The structural constraints are used to limit the executable range of structural transformation operations such as node merging, splitting, call path adjustment, and data access path rearrangement. Based on the aforementioned target constraint interval and structural constraints, a multi-objective constrained architecture optimization target space is jointly constructed.

5. The e-commerce platform architecture optimization method based on Handle technology as described in claim 1, characterized in that, Based on the aforementioned architecture, optimization of the structural transformation of the runtime architecture dependency graph of the target space execution platform includes: The platform runtime architecture dependency graph is analyzed, and the optimization potential index of each node or subgraph is calculated based on the topological characteristics, node centrality, cross-domain transaction path and data access path in the analysis results. Based on the metric deviation vector and persistence index of the trigger tag, the coupling growth or transaction diffusion trend in multiple future time windows is predicted, and N candidate structure transformation schemes are generated in combination with the optimization potential index. Each objective within the target space of the architecture optimization is regarded as an intelligent agent, and the optimization evaluation of N candidate structural transformation schemes is carried out through collaborative game to complete the structural transformation optimization.

6. The e-commerce platform architecture optimization method based on Handle technology as described in claim 5, characterized in that, Based on the optimization results, perform architecture optimization management, including: The optimization results are executed in stages. Before each stage, the optimization potential index and imbalance prediction results are recalculated based on the latest updated platform runtime architecture dependency graph, and the target space constraints and action strategies are dynamically updated.

7. The e-commerce platform architecture optimization method based on Handle technology as described in claim 6, characterized in that, If new potential imbalances or risks are detected that exceed constraints during the phased execution process, the system will automatically roll back to the previous safe state node and perform optimization and reconstruction.

8. The e-commerce platform architecture optimization method based on Handle technology as described in claim 1, characterized in that, Record the execution time and adjustment results of each structural adjustment to the platform runtime architecture dependency graph, and store the recorded results in the architecture optimization history database.

9. The e-commerce platform architecture optimization method based on Handle technology as described in claim 1, characterized in that, The platform runtime architecture dependency graph uses business capability units as nodes and edges jointly represented by call strength and state coupling degree as connections to depict the actual runtime coupling state under the current platform architecture.

10. An e-commerce platform architecture optimization system based on Handle technology, characterized in that: The system is used to execute the e-commerce platform architecture optimization method based on Handle technology as described in any one of claims 1-9, and the system includes: The data collection module is used to continuously collect real-time call behavior, data read and write paths, cross-domain transaction relationships and performance response indicators across business modules during the operation of the e-commerce platform based on Handle technology, and to build a platform runtime architecture dependency graph based on the collection results. The structural analysis module is used to perform multi-dimensional structural analysis on the platform's runtime architecture dependency graph, identify at least one architecture imbalance mode, including highly centralized dependency imbalance, cross-link cascading amplification imbalance, and data consistency diffusion imbalance. Based on the duration, scope of impact, and business value relevance of the architecture imbalance mode, a set of architecture optimization triggering conditions is generated. An optimization space construction module is used to call a trigger tag and construct a corresponding architecture optimization target space when the set of architecture optimization trigger conditions is detected. The architecture optimization target space includes at least two of the following: architecture decoupling optimization target, transaction convergence radius optimization target, and architecture adjustment risk constraint target, which are used to limit the allowed direction and magnitude of architecture adjustments. The optimization management module is used to optimize the structural transformation of the platform runtime architecture dependency graph based on the architecture optimization target space, and to perform architecture optimization management based on the optimization results.

Images