Multi-dimensional service process perception and dynamic optimization method based on intelligent algorithm

Abstract

The invention discloses a multi-dimensional service process perception and dynamic optimization method based on an intelligent algorithm, particularly relates to the technical field of resource allocation and workflow optimization, and is used for solving the problem that an existing dynamic optimization method falls into local optimum due to the influence of historical decisions in an industrial micro-service system. The method comprises the following steps of: acquiring multi-dimensional perception data in a micro-service instance operation process, analyzing convergence of a historical decision sequence to identify a path dependence characteristic, and analyzing a calling relationship among micro-service instances when path dependence exists to identify a high-frequency collaborative service combination. The method comprises the steps of evaluating the decoupling property of a resource competition relationship in a service combination to identify a service interaction bottleneck, evaluating the structure reconstruction potential of a system based on the service interaction bottleneck, determining the exploration priority of an unexplored area in a solution space, and finally dynamically adjusting the resource allocation proportion and the workflow scheduling sequence of micro-service instances according to the exploration priority. And continuous optimization and performance improvement of the industrial micro-service system are realized.

Description

Technical Field

[0001] This invention relates to the field of resource allocation and workflow optimization technology, and more specifically, to a multi-dimensional service process perception and dynamic optimization method based on intelligent algorithms. Background Technology

[0002] In the field of intelligent manufacturing, industrial internet platforms generally adopt a microservice architecture to decouple complex production and manufacturing systems into multiple single-function industrial microservices, such as order parsing, process planning, and equipment monitoring. Through dynamic combination and collaboration, the entire business process from order placement to product delivery is completed. In this environment, dynamic optimization technology based on intelligent algorithms can be used to continuously adjust the resource allocation and workflow scheduling of microservice instances based on real-time perceived system status data, so as to improve overall production efficiency and resource utilization.

[0003] However, existing dynamic optimization methods still have inherent limitations when dealing with complex systems composed of industrial microservices. During the continuous decision-making process, the optimization trajectory of dynamic optimization methods is easily influenced by historical decision states, forming path dependence. This causes the system, when seeking the global optimum, to often get trapped in local optima due to being confined to the neighborhood of the solution space constituted by past choices. Consequently, it struggles to adapt to the long-term and dynamically changing global performance goals in the manufacturing environment, thus hindering further improvements in the overall performance of the production system. Summary of the Invention

[0004] To overcome the aforementioned deficiencies of the prior art, this invention provides a multi-dimensional service process perception and dynamic optimization method based on intelligent algorithms to solve the problems mentioned in the background art.

[0005] To achieve the above objectives, the present invention provides the following technical solution: A multi-dimensional service process perception and dynamic optimization method based on intelligent algorithms includes: S1. Obtain multi-dimensional perception data generated by multiple microservice instances in the industrial microservice system during operation; S2. Based on multi-dimensional sensing data, use intelligent algorithms to analyze the convergence of historical decision sequences and determine whether the current optimization process exhibits path dependence characteristics caused by historical decision sequences. S3. When path dependency features are presented due to historical decision sequences, analyze the calling relationships between microservice instances in the historical decision sequences to identify service compositions that form high-frequency collaborations. S4. Based on high-frequency collaborative service composition, assess the decoupling of resource competition relationships between microservice instances within the service composition and identify service interaction bottlenecks caused by the difficulty in decoupling resource competition relationships. S5. Based on the assessment of the service interaction bottleneck, evaluate the potential for system structure reconstruction that can be triggered after the service interaction bottleneck is removed, and determine the exploration priority of the unexplored region in the solution space associated with the service interaction bottleneck according to the size of the structural reconstruction potential. S6. Dynamically adjust the resource allocation ratio and workflow scheduling order of microservice instances based on exploration priority.

[0006] Furthermore, the multi-dimensional perception data obtained in step S1 includes resource load indicators of microservice instances, service call chain relationship data, and business process execution status indicators.

[0007] Furthermore, the resource load metrics include CPU utilization and memory usage; Service call chain relationship data records the call frequency and dependency relationships between microservice instances; Business process execution status indicators include order processing progress and process planning completion status.

[0008] Furthermore, step S2, which uses intelligent algorithms to analyze the convergence of historical decision sequences, includes: Based on the fluctuation of resource load indicators in multidimensional perception data and the trend of call frequency changes in service call chain relationship data, the distribution concentration of historical decision sequences in the solution space is calculated. Evaluate and optimize the stability of target achievement rate by combining business process execution status indicators; Based on the correlation between distribution concentration and the stability of the achievement rate of optimization objectives, it can be determined whether the current optimization process exhibits path dependence characteristics caused by historical decision sequences.

[0009] Furthermore, judging whether the current optimization process exhibits path dependence characteristics caused by historical decision sequences based on the correlation between distribution concentration and the stability of the optimization target achievement rate includes: when the distribution concentration is high and the stability of the optimization target achievement rate is low, it is judged to exhibit path dependence characteristics caused by historical decision sequences.

[0010] Furthermore, step S3, analyzing the call relationships between microservice instances in the historical decision sequence to identify service compositions that form high-frequency collaborations, includes: Based on the call frequency and dependency relationships between microservice instances recorded in the service call chain relationship data, we statistically analyze the combinations of microservice instances that co-occur in the historical decision sequence. Based on the frequency and duration of microservice instance combinations in the historical decision sequence, microservice instance combinations with call frequency higher than a set threshold and stable duration are identified as high-frequency collaborative service combinations.

[0011] Furthermore, step S4, which assesses the decoupling of resource contention relationships between microservice instances within the service composition, includes: Based on the CPU utilization and memory usage in the resource load indicators, we analyze the resource usage conflicts of microservice instances in the historical decision sequence in high-frequency collaborative service combinations. Assess the decoupling potential of resource competition by considering the persistence of resource use conflicts in the historical decision-making sequence and the success rate of resource allocation attempts. Resource competition relationships with high persistence of resource usage conflicts and low success rate of resource allocation attempts are identified as service interaction bottlenecks that are difficult to decouple.

[0012] Furthermore, assessing the decoupling of resource competition relationships based on the persistence of resource use conflicts in the historical decision-making sequence and the success rate of resource allocation attempts includes: when the persistence of resource use conflicts is high and the success rate of resource allocation attempts is low, the decoupling of resource competition relationships is assessed as low.

[0013] Furthermore, step S5 assesses the potential for system architecture refactoring that can be triggered by removing service interaction bottlenecks, including: Analyze the structural position of microservice instances involved in service interaction bottlenecks in the service call chain relationship data and the scope of their impact on business process execution status indicators; Based on the historical trends of CPU utilization and memory usage in resource load indicators, the degree of relief of resource competition after removing service interaction bottlenecks is predicted. The potential for system restructuring is determined by a comprehensive evaluation of the scope of changes in the service call chain structure and the degree of relief of resource competition. The exploration priority of unexplored regions in the solution space associated with service interaction bottlenecks is determined based on the potential for system structure reconstruction.

[0014] Furthermore, step S6, which dynamically adjusts the resource allocation ratio and workflow scheduling order of microservice instances based on exploration priority, includes: Based on the order of exploration priority from high to low, resources are allocated to the microservice instances that constitute service interaction bottlenecks in turn; The adjustment range of the resource allocation ratio is determined based on the CPU utilization and memory usage in the resource load indicators. Based on the call dependencies between microservice instances recorded in the service call chain relationship data, the workflow scheduling order is adjusted accordingly.

[0015] Compared with the prior art, the present invention has the following beneficial effects: 1. By constructing a complete closed loop of perception, identification, evaluation, and optimization, it effectively overcomes the technical limitations of traditional dynamic optimization methods that are prone to getting trapped in local optima in industrial microservice environments. Based on the intelligent analysis of the convergence of historical decision sequences using multi-dimensional perception data, it can accurately identify path dependency characteristics in the optimization process. Furthermore, by analyzing the call relationships between microservice instances, it can locate high-frequency collaborative service combinations. The correlation analysis mechanism based on actual operating data can accurately capture the implicit functional coupling relationships in the microservice system, providing accurate target objects for subsequent optimization.

[0016] 2. By assessing the decoupling of resource competition relationships within the service portfolio, the system can identify key bottlenecks affecting overall performance. Based on the potential for system restructuring that may result from removing bottlenecks, the system scientifically determines the exploration priority of unexplored regions in the solution space. The priority determination method based on restructuring potential ensures that resource allocation and workflow scheduling adjustments always proceed in the direction that best improves the overall system performance. This enables continuous and adaptive global optimization in complex industrial microservice environments, significantly improving the operating efficiency and resource utilization of production systems. Attached Figure Description

[0017] Figure 1 This is a flowchart of a multi-dimensional service process perception and dynamic optimization method based on intelligent algorithms according to the present invention. Detailed Implementation

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

[0019] Example: Figure 1 This invention presents a multi-dimensional service process perception and dynamic optimization method based on intelligent algorithms, comprising: S1. Obtain multi-dimensional perception data generated by multiple microservice instances in the industrial microservice system during operation; S2. Based on multi-dimensional sensing data, use intelligent algorithms to analyze the convergence of historical decision sequences and determine whether the current optimization process exhibits path dependence characteristics caused by historical decision sequences. S3. When path dependency features are presented due to historical decision sequences, analyze the calling relationships between microservice instances in the historical decision sequences to identify service compositions that form high-frequency collaborations. S4. Based on high-frequency collaborative service composition, assess the decoupling of resource competition relationships between microservice instances within the service composition and identify service interaction bottlenecks caused by the difficulty in decoupling resource competition relationships. S5. Based on the assessment of the service interaction bottleneck, evaluate the potential for system structure reconstruction that can be triggered after the service interaction bottleneck is removed, and determine the exploration priority of the unexplored region in the solution space associated with the service interaction bottleneck according to the size of the structural reconstruction potential. S6. Dynamically adjust the resource allocation ratio and workflow scheduling order of microservice instances based on exploration priority.

[0020] When implementing step S1, it is first necessary to acquire multi-dimensional perception data generated by multiple microservice instances in the industrial microservice system during operation. This multi-dimensional perception data includes resource load metrics, service call chain relationship data, and business process execution status metrics for the microservice instances. Resource load metrics cover CPU utilization and memory usage; service call chain relationship data records the call frequency and dependencies between microservice instances; and business process execution status metrics include order processing progress and process planning completion status. The data acquisition process is implemented through monitoring components deployed on the microservice instances and integrated business system interfaces, ensuring the real-time nature and integrity of the data.

[0021] Resource load metrics are obtained through a monitoring agent deployed on the microservice instances. This agent runs as an independent process, periodically collecting CPU utilization and memory usage data. CPU utilization is expressed as a percentage, obtained by reading performance counters provided by the operating system kernel. For example, in Linux systems, this is achieved by parsing the cpuinfo and stat files in the proc filesystem to obtain the system-level and process-level CPU time allocation ratios. Memory usage is measured in megabytes, obtained by querying the system memory management interface to determine the current physical memory used by the microservice instance, such as using the sysinfo system call or programming interfaces like malloc_info provided by the operating system. For example, the data collection frequency is set to once every 10 seconds to ensure data real-time performance and continuity while avoiding significant impact on system performance. The monitoring agent formats the collected data into key-value pairs and sends it to a central data repository via lightweight communication protocols such as HTTP POST or message queues. The repository uses a time-series database for data persistence, such as InfluxDB, to store timestamped metric data. The threshold settings for resource load indicators are based on historical data statistical analysis. For example, the high load threshold is determined by calculating the 95th percentile of historical CPU utilization. When the CPU utilization exceeds this threshold, it indicates a state of resource stress. Similarly, the memory utilization threshold is set by the 90th percentile of historical memory usage data to reflect memory pressure.

[0022] The acquisition of service call chain relationship data relies on the deployment of a distributed tracing system. A tracing library is integrated into each microservice instance, automatically generating and propagating tracing identifiers during inter-microservice calls. Call frequency is obtained by counting the number of calls between microservice instances per unit of time, such as the number of times microservice A calls microservice B per minute. This data is extracted from call logs and aggregated into a time window. Dependencies are constructed using a directed graph model built from call chain logs. Nodes in the graph represent microservice instances, edges represent call relationships, and edge weights reflect call frequency. Call chain logs record the source microservice, target microservice, timestamp, and response status for each call. Data is aggregated to an analytics engine via a log collector, such as using Fluentd to collect logs and outputting them to Elasticsearch for indexing. The high-frequency call threshold is set to the historical average call frequency plus a standard deviation. This threshold is used to identify combinations of frequently interacting microservices; for example, if the historical average call frequency is 100 times per minute and the standard deviation is 20 times, the threshold is set to 120 times per minute. Data storage utilizes a graph database to support efficient dependency queries and traversals. For example, Neo4j is used to store graph structure data, and indexes are built to optimize query performance.

[0023] Business process execution status metrics are obtained through integrated business system interfaces. Order processing progress is extracted from the order status table in the order management database. Progress is calculated by dividing the number of completed order processing steps by the total number of steps, with the result expressed as a percentage. For example, order processing steps may include order receipt, inventory check, payment processing, and shipment confirmation. Progress is calculated in real-time based on the percentage of completed steps. Process planning completion status is obtained from the planning task table in the manufacturing execution system. Statuses include not started, in progress, and completed. Completion status is determined by comparing the task completion timestamp with the planned completion time. For example, if the task completion time is earlier than the planned completion time, the status is marked as early completion. Data collection is accomplished through periodic polling of the business database's API interface, such as using a RESTful API call to retrieve order status. The polling interval is set to 30 seconds to ensure timely updates of status data. An order processing progress threshold is set to indicate a delay when the progress value is 10 percentage points lower than the planned progress. This threshold is dynamically adjusted based on the business plan timeline. For example, if the planned progress is 80% and the actual progress is 70%, a delay is indicated. All state data is stored in a relational database, and indexes are created to optimize query performance. For example, a MySQL database is used to store state records, and foreign key associations are used to ensure data consistency.

[0024] During data acquisition, the integrity and consistency of all metrics are ensured. Resource load metrics are associated with service call chain relationships through microservice instance identifiers, such as using a unique instance ID as the association key. Business process execution status metrics are associated with microservice instances through business transaction identifiers, such as mapping an order ID to the microservice instance that processed the order. Monitoring agents and tracing libraries are implemented using open source, such as using Prometheus to collect resource data and Jaeger for distributed tracing. Business data interfaces are designed based on RESTful specifications to ensure system interoperability. Data collection frequency and threshold parameters are managed through configuration files, allowing dynamic adjustment based on system load; for example, during periods of high load, the collection frequency can be reduced to once every 30 seconds to alleviate system pressure. The integration of multi-dimensional sensing data is completed during the data preprocessing stage, ensuring data quality through time window alignment and missing value imputation; for example, linear interpolation methods are used to handle missing time point data, and timestamps are used to synchronize different data sources. To handle abnormal situations, an error retry mechanism is implemented, such as automatically retransmitting data in case of network failure, and setting data validation rules to discard invalid records, providing reliable input for subsequent analysis.

[0025] In step S2, based on the multidimensional sensing data obtained in step S1, intelligent algorithms are used to analyze the convergence of historical decision sequences, thereby determining whether the current optimization process exhibits path dependence characteristics caused by historical decision sequences. Historical decision sequences refer to the chronologically ordered records of microservice instance resource allocation and workflow scheduling decisions, with each decision point containing specific parameter values ​​for resource allocation ratios and workflow scheduling order. The solution space represents a multidimensional space composed of all possible resource allocation ratios and workflow scheduling orders, where each dimension corresponds to a decision variable, such as the CPU allocation ratio dimension, memory allocation ratio dimension, and service call order dimension. The analysis process first calculates the distribution concentration of historical decision sequences in the solution space based on the fluctuation of resource load indicators in the multidimensional sensing data and the call frequency change trend in the service call chain relationship data. The fluctuation of resource load indicators is obtained by calculating the standard deviation of CPU utilization and memory usage within a sliding time window. For example, the window size is set to 100 data points, with each data point corresponding to the data collection interval defined in step S1. The fluctuation reflects the dispersion of resource usage, and the standard deviation is calculated using the sample standard deviation formula. The call frequency trend in the service call chain relationship data is obtained by statistically analyzing the number of calls between microservice instances per unit time and calculating the slope of its moving average. For example, the call frequency data can be directly obtained from the service call chain relationship data recorded in step S1. The moving average window size is set to 20 time points, and the slope is calculated using least squares linear regression.

[0026] Distribution concentration is calculated by measuring the degree of clustering of decision points in the solution space within a historical decision sequence, specifically using the inverse average of Euclidean distances as the concentration index. Decision points are represented as vectors composed of normalized resource load indicators and call frequency data. For example, CPU utilization, memory usage, and call frequency are scaled to the range of 0 to 1. The normalization method uses a min-max scaling algorithm, where each indicator value is subtracted from its historical minimum and then divided by the difference between its historical maximum and minimum. The pairwise Euclidean distances between all decision points are calculated using the formula: the square root of the sum of the squares of the differences in each dimension's coordinates. The average of these distances is then calculated, and the distribution concentration is defined as the inverse of this average distance. The threshold for high or low distribution concentration is set based on the statistical quantiles of historical distribution concentration values. For example, a historical dataset is created by collecting distribution concentration data from the past 30 working days. After sorting the dataset, the 75th percentile is used as the distribution concentration threshold. When the current distribution concentration exceeds this threshold, it is identified as a high distribution concentration state. Threshold adjustments are made based on changes in the system operating environment. For example, when the number of microservice instances increases, historical data is recalculated to update the threshold.

[0027] Next, the stability of the optimization target achievement rate is evaluated by combining business process execution status indicators. The optimization target achievement rate is extracted from business process execution status indicators; for example, the weighted average of order processing progress and process planning completion status is used as the overall achievement rate. Weighting is based on business priorities; for example, business experts determine that order processing progress has a weight of 0.6 and process planning completion status has a weight of 0.4. Weight allocation is based on the impact of each indicator on the business objective, or the weights are automatically adjusted through historical data correlation analysis. The achievement rate is calculated as the ratio of actual progress to planned progress. For example, order processing progress is the number of completed orders divided by the total number of orders; process planning completion status is the number of completed planned tasks divided by the total number of tasks; and the overall achievement rate is the sum of the products of each indicator value and its corresponding weight. Stability assessment is achieved by calculating the coefficient of variation (COP) of the optimization target achievement rate over historical time series. The COP is defined as the ratio of the standard deviation to the mean. For example, using a time window of 50 decision points, the mean and standard deviation of the achievement rate within the window are calculated. A larger COP indicates lower stability. The threshold setting for optimizing target achievement rate stability is based on the distribution characteristics of historical coefficient of variation values. For example, by analyzing the coefficient of variation data from the past 100 time points, the 60th percentile value after sorting the data is taken as the stability threshold for optimizing target achievement rate. When the current coefficient of variation exceeds this threshold, it is marked as a low-stability state. The threshold setting takes into account the tolerance for business fluctuations; for example, the threshold can be appropriately increased during peak business periods.

[0028] Then, based on the correlation between distribution concentration and the stability of the optimization target achievement rate, it is determined whether the current optimization process exhibits path dependence characteristics caused by historical decision sequences. Correlation analysis is achieved by comparing whether the distribution concentration is higher than its threshold and whether the stability of the optimization target achievement rate is lower than its threshold. Specifically, when the distribution concentration is high and the stability of the optimization target achievement rate is low, it is judged to exhibit path dependence characteristics caused by historical decision sequences. For example, high distribution concentration indicates that the decision sequence is clustered in a narrow region in the solution space, indicating that the optimization process tends to repeat historical decision patterns. Low stability of the optimization target achievement rate indicates large fluctuations in system performance, indicating that the current decision has failed to effectively maintain the level of business target achievement. The combination of these two factors indicates that the optimization process is limited by historical decisions and cannot explore better solution space regions. The judgment process uses logical AND operations to simultaneously check the two threshold conditions. All input parameters come from the stored values ​​of the multi-dimensional perception data and historical calculation results from step S1. To handle data anomalies, a missing value handling mechanism is set up. For example, when data is missing at a certain point in time, a linear interpolation method is used to fill in the missing data. The interpolation is based on the data trend of adjacent time points, and the distribution concentration value and the stability value of the optimization target achievement rate are recorded through the log system.

[0029] When implementing step S3, after step S2 determines that the current optimization process exhibits path dependency characteristics caused by historical decision sequences, the call relationships between microservice instances in the historical decision sequences are analyzed to identify service combinations that form high-frequency collaboration. The historical decision sequences are derived from the analysis results of step S2 and include records of microservice instance resource allocation and workflow scheduling decisions arranged chronologically. Each decision point corresponds to the system state and resource configuration at a given time. The service call chain relationship data directly uses the multi-dimensional perception data obtained in step S1, which records the call frequency and dependency relationships between microservice instances. The call frequency is expressed as the number of calls per unit time, such as the number of calls per minute. The dependency relationships are stored in the form of a directed graph, where nodes represent microservice instances, edges represent call relationships, and edge weights represent call frequencies. High-frequency collaborative service combinations refer to groups of microservice instances that frequently co-occur in the historical decision sequences and have stable call relationships. These combinations may represent microservice clusters in the system that have close collaboration and significant performance impact.

[0030] Based on the call frequency and dependencies between microservice instances recorded in the service call chain relationship data, the system statistically analyzes the combinations of microservice instances that co-occur in historical decision sequences. Specifically, it first extracts the microservice instance call events corresponding to each decision point from the historical decision sequence. These call events include the source microservice instance, the target microservice instance, and a timestamp; the data originates from the service call chain relationship database in step S1. A combination of co-occurring microservice instances is defined as a set of microservice instances called by the same business transaction or workflow within a preset time window, for example, a 5-minute window. Microservice instances active simultaneously within the window constitute a candidate combination. The time window is set based on the average duration of the business transaction, for example, by analyzing the completion time of historical transactions to determine the window size. The statistical process employs frequent itemset mining methods, such as using the Apriori algorithm to scan all call events in the historical decision sequence and generate all microservice instance combinations that meet the minimum support requirement. The minimum support is set to, for example, 10% of the total number of occurrences in the historical decision sequence, representing the relative frequency of the combination in the sequence. The Apriori algorithm iteratively generates frequent itemsets, first identifying frequent itemsets for all individual microservice instances, then combining them to generate larger itemsets, until no new itemsets are generated. Data preprocessing includes time window alignment and event deduplication. For example, call events are sorted by timestamp and divided into fixed-length windows, and duplicate call records within the same window are merged. To handle data anomalies, a missing value handling mechanism is implemented. For instance, when a call event timestamp is missing, linear interpolation is used to fill it based on the timestamps of adjacent events, or records for that time window are discarded when the data is incomplete. Statistical results are output as the frequency of occurrence for each microservice instance combination. The frequency is calculated as the total number of times the combination appears in the historical decision sequence, and the start and end timestamps of each occurrence are recorded. The output data is stored as a structured table containing a list of combination identifiers, frequencies, and durations.

[0031] Based on the frequency and duration of microservice instance combinations in historical decision sequences, combinations of microservice instances with call frequencies exceeding a set threshold and stable durations are identified as high-frequency collaborative service combinations. The frequency is directly calculated using the frequency value obtained in the previous step, expressed as counts. The duration is obtained by calculating the time span of each combination occurrence; for example, the time span is the end timestamp minus the start timestamp, with the result in seconds. The call frequency threshold is set based on the statistical distribution of historical frequency values. For example, by analyzing the frequency data of all microservice instance combinations, a historical frequency dataset is formed. After sorting the dataset, the 80th percentile value is used as the call frequency threshold. When the frequency of a combination exceeds this threshold, it is identified as a high-frequency state. Duration stability is assessed by calculating the coefficient of variation (COP) of the duration. The COP is defined as the ratio of the standard deviation to the mean of the duration series. For example, a sliding window is used to analyze the duration data of the most recent 50 occurrences, and the COP is calculated. A smaller COP indicates higher stability. The duration stability threshold is set based on the distribution characteristics of historical coefficient of variation values. For example, by statistically analyzing the coefficient of variation of all combinations over a past period, the 70th percentile value after sorting is taken as the duration stability threshold. When the current coefficient of variation is lower than this threshold, it is identified as having high stability. The identification condition is that both the call frequency and the duration stability are higher than the duration stability threshold. For example, if a service combination occurs 100 times per minute and the duration coefficient of variation is 0.1, and the call frequency threshold is 80 times per minute and the duration stability threshold is 0.2, this combination is identified as a high-frequency collaborative service combination. Parameter adjustments are based on the system's operating scale. For example, when the number of microservice instances increases, historical data is recalculated to update the thresholds. For instance, the call frequency threshold is adjusted to the 85th percentile of historical occurrence frequency values, and the duration stability threshold is adjusted to the 65th percentile of historical coefficient of variation values. To handle boundary conditions, a minimum duration limit is set. For example, combinations with a duration of less than 1 second are ignored to avoid noisy data.

[0032] In step S4, based on the high-frequency collaborative service combinations identified in step S3, the decoupling capability of resource contention relationships among microservice instances within the service combinations is assessed, and service interaction bottlenecks caused by the difficulty in decoupling resource contention relationships are identified. High-frequency collaborative service combinations, derived from the analysis results of step S3, refer to groups of microservice instances that frequently co-occur in historical decision sequences and have stable call relationships. Resource contention relationships refer to the conflicts that arise when multiple microservice instances simultaneously access shared resources; decoupling capability indicates the ease with which such conflicts can be eliminated through resource allocation. Service interaction bottlenecks refer to critical nodes where system performance degrades due to the difficulty in decoupling resource contention relationships. The assessment process aims to identify microservice instance combinations with severe resource contention that is difficult to alleviate through adjustments, providing target objects for subsequent optimization steps.

[0033] Based on CPU utilization and memory usage in the resource load metrics, this study analyzes resource usage conflicts among microservice instances in a high-frequency collaborative service portfolio across historical decision sequences. The resource load metrics directly utilize the multidimensional sensing data obtained in step S1, where CPU utilization is expressed as a percentage and memory usage is expressed in megabytes. Resource usage conflict analysis is achieved by calculating the correlation of resource usage between microservice instances. For example, the Pearson correlation coefficient is used to calculate the degree of synchronous change in CPU utilization; a correlation coefficient close to 1 indicates a strong positive correlation, suggesting resource competition. Specifically, the time series of CPU utilization for all microservice instances in the high-frequency collaborative service portfolio across historical decision sequences are selected, and the correlation coefficient between each pair of microservice instances is calculated. The correlation coefficient is calculated as the product of the covariance and the respective standard deviations. Memory usage conflict analysis employs the same method, assessing memory resource competition by calculating the correlation coefficient of the memory usage time series. The degree of resource usage conflict is defined as the average of the correlation coefficients between all pairs of microservice instances. For example, for a service portfolio containing three microservice instances, the arithmetic mean of the correlation coefficients for all three pairs of instances is the degree of resource usage conflict for that service portfolio. Data preprocessing includes time series alignment and outlier handling. For example, when resource load metrics are missing at a certain point in time, linear interpolation from previous and subsequent time points is used to fill the gap, or moving averages are used for smoothing when data is out of place. To handle data inconsistencies, data quality check rules are set up, such as skipping the analysis of a service combination when the time series length is insufficient, ensuring the reliability of the calculation results.

[0034] The decoupling capability of resource competition is assessed by evaluating the persistence of resource usage conflicts in historical decision sequences and the success rate of resource allocation attempts. The persistence of resource usage conflicts is evaluated by analyzing the stability of the conflict intensity over time. For example, the coefficient of variation (COP) of the conflict intensity within a sliding time window is calculated, defined as the ratio of the standard deviation to the mean, with a window size of, for example, 50 decision points. The threshold for the persistence of resource usage conflicts is set based on the statistical distribution of historical COP values. For instance, by analyzing the COP data of all service combinations to form a historical dataset, the 70th percentile value is used as the threshold after sorting the dataset; a COP below this threshold is considered high persistence. The success rate of resource allocation attempts is calculated by statistically analyzing the proportion of performance improvements achieved in historical resource allocation records. For example, past resource allocation operations performed on this service combination, including adjustments to CPU and memory allocation ratios, are extracted from system logs, and the proportion of operations that successfully improved resource usage conflicts out of the total number of operations is calculated. The success rate threshold for resource allocation attempts is set based on the statistical characteristics of historical success rates. For example, by analyzing the historical allocation success rates of all service portfolios, the 30th percentile value after sorting is taken as the threshold. When the current success rate is lower than this threshold, it is marked as a low success rate. The decoupling assessment condition is that when the persistence of resource usage conflicts is high and the success rate of resource allocation attempts is low, the decoupling capability of the resource competition relationship is assessed as low; otherwise, it is assessed as high. For example, if the coefficient of variation for the persistence of resource usage conflicts in a service portfolio is, for example, 0.15, and the success rate of resource allocation attempts is, for example, 20%, then when the threshold for the persistence of resource usage conflicts is, for example, 0.2, and the threshold for the success rate of resource allocation attempts is, for example, 25%, the decoupling capability of the resource competition relationship for this service portfolio is assessed as low.

[0035] Resource contention relationships characterized by high persistence of resource usage conflicts and low success rates of resource allocation attempts are identified as service interaction bottlenecks that are difficult to decouple. The identification process is based on the aforementioned decouplingability assessment results; when the decouplingability assessment of a resource contention relationship is low, that relationship is marked as a service interaction bottleneck. For example, in a service composition containing microservice instance A and microservice instance B, if the persistence of resource usage conflicts is high and the success rate of resource allocation attempts is low, the resource contention relationship between microservice instance A and microservice instance B is identified as a service interaction bottleneck. Parameter adjustments are based on system operating status. For example, when system load changes, historical data is recalculated to update the resource usage conflict persistence threshold and the resource allocation attempt success rate threshold. For instance, the resource usage conflict persistence threshold is adjusted to the 75th percentile of the historical coefficient of variation, and the resource allocation attempt success rate threshold is adjusted to the 25th percentile of the historical success rate. To handle boundary cases, a minimum statistical sample requirement is set; for example, service compositions with fewer than 5 resource allocation attempts are excluded from the evaluation to avoid statistical bias.

[0036] In step S5, based on the service interaction bottlenecks identified in step S4, the potential for system architecture reconfiguration after removing the bottlenecks is assessed. The exploration priority of unexplored regions in the solution space associated with the service interaction bottlenecks is determined according to the magnitude of this reconfiguration potential. The service interaction bottleneck, derived from the analysis results of step S4, refers to a critical node where system performance degrades due to the difficulty in decoupling resource contention. The system architecture reconfiguration potential represents the degree of system architecture optimization that can be achieved by removing the service interaction bottlenecks. The solution space represents a multi-dimensional space composed of all possible resource allocation ratios and workflow scheduling sequences. Unexplored regions refer to configuration areas in the solution space that have not yet been covered by historical decision sequences. The assessment process aims to quantify the potential impact of bottleneck removal on the overall system architecture and provide a basis for subsequent resource allocation decisions.

[0037] This analysis examines the structural position of microservice instances involved in service interaction bottlenecks within the service call chain relationship data and their impact on business process execution status indicators. The service call chain relationship data directly utilizes the multi-dimensional perception data obtained in step S1, which records the call frequency and dependencies between microservice instances. Structural position analysis is achieved by calculating the centrality of microservice instances in the service call chain graph. For example, betweenness centrality measures the importance of a node in the call path; it is calculated as the proportion of the number of shortest paths passing through that node to the total number of shortest paths. Impact assessment is achieved by analyzing the degree of influence of the microservice instances involved in the service interaction bottleneck on business process execution status indicators. For example, it calculates the delay in relevant business process execution status indicators, such as order processing progress, when the performance of the microservice instance degrades. In practice, a directed graph of the service call chain is first constructed, where nodes represent microservice instances and edges represent call relationships. Then, the betweenness centrality of each node is calculated. Impact is quantified by statistically analyzing the number of affected business process instances. For example, this involves querying business transaction records related to the bottleneck microservice instance and calculating the average rate of change of business process execution status indicators in these transactions. Data preprocessing includes graph structure construction and transaction record association, such as mapping microservice instance identifiers to business transaction identifiers to ensure data consistency. To handle boundary cases, a minimum sample size requirement is set; for example, if the number of affected business process instances is less than 10, an impact assessment is not performed.

[0038] Based on the historical trends of CPU utilization and memory usage in resource load metrics, the degree of relief in resource contention after removing service interaction bottlenecks is predicted. Resource load metrics directly utilize the multi-dimensional sensing data obtained in step S1, where CPU utilization is expressed as a percentage and memory usage as megabytes. The prediction process employs time series analysis methods, such as using an autoregressive integral moving average model to analyze historical resource load metric data and establish a resource usage trend model. In practice, the CPU utilization and memory usage time series of the microservice instances involved in the service interaction bottleneck are selected from the historical decision sequence, and a sliding window method is used to fit the trend curve, with the window size set to, for example, 100 time points. The degree of relief is predicted by comparing the current resource usage level with the predicted resource usage level after removing the bottleneck, for example, by calculating the relative reduction ratio between the predicted and current values. The degree of relief in resource contention is defined as the weighted average of the predicted reduction ratio of CPU utilization and memory usage. The weights are set based on the importance of the resource type; for example, the weight of CPU utilization is determined to be 0.6 and the weight of memory usage is 0.4 through expert evaluation, or the weights are automatically adjusted through historical data analysis. The model parameters are obtained by training on historical data, and the prediction accuracy is evaluated using cross-validation.

[0039] The potential for system restructuring is determined based on a comprehensive evaluation of the range of changes in the service call chain structure and the degree of mitigation of resource contention. The range of changes in the service call chain structure is assessed by analyzing the structural changes in the call chain graph after bottleneck removal, for example, by calculating the rate of change in the average path length of the remaining nodes in the graph after the bottleneck node is removed. The degree of mitigation of resource contention is directly calculated using the prediction results from the previous step. The comprehensive evaluation uses a weighted summation method. The formula for calculating the system restructuring potential is: the weight of the structural change range multiplied by the structural change range score, plus the weight of the resource mitigation degree multiplied by the resource mitigation degree score. Weights are set based on business objective priorities; for example, by analyzing historical optimization effects, the weight of the structural change range is determined to be 0.4, and the weight of the resource mitigation degree is determined to be 0.6. The structural change range score is obtained by normalizing the change range value to the 0-1 range, for example, using a minimum-maximum scaling method. The resource mitigation degree score is directly used using the mitigation degree value. The threshold for the system restructuring potential is set based on the statistical distribution of historical potential values; for example, by analyzing the potential value data of all service interaction bottlenecks, the 60th percentile value after sorting is taken as the high-potential threshold. When the current potential value exceeds this threshold, it is marked as a high-potential state. Parameter adjustments are made based on changes in the system's operating environment. For example, when business objectives are adjusted, the weight allocation is recalculated.

[0040] The exploration priority of unexplored regions associated with service interaction bottlenecks in the solution space is determined based on the system architecture reconfiguration potential. The exploration priority is determined by ranking the system architecture reconfiguration potential values; service interaction bottlenecks with higher potential values ​​are assigned higher priority. In practice, the system architecture reconfiguration potential values ​​are first normalized to the range of 0 to 1, and then all unexplored regions corresponding to service interaction bottlenecks are sorted in descending order. The exploration priority threshold is set based on business resource constraints; for example, by analyzing available resources, it is determined that only unexplored regions with potential values ​​higher than 0.7 will be prioritized for exploration. Unexplored regions are defined based on the distribution of historical decision sequences in the solution space, and cluster analysis is used to identify regions in the solution space not covered by historical decisions. Parameter adjustments are based on the system's operating status; for example, when the system architecture changes, historical data is recalculated to update weights and thresholds. To handle boundary cases, a minimum data requirement is set; for example, service interaction bottlenecks with fewer than 50 historical data points are not included in the evaluation.

[0041] When implementing step S6, the resource allocation ratio and workflow scheduling order of microservice instances are dynamically adjusted based on the exploration priority determined in step S5. The exploration priority, derived from the analysis results of step S5, refers to the ranking of unexplored regions in the solution space based on the potential for system architecture refactoring. Service interaction bottlenecks, derived from the analysis results of step S4, refer to critical nodes where system performance degrades due to the difficulty in decoupling resource contention. The resource allocation ratio refers to the ratio of the number of CPU cores to the memory capacity, and the workflow scheduling order refers to the execution order of microservice instances within the business process. The dynamic adjustment process aims to eliminate service interaction bottlenecks and improve overall system performance by optimizing resource configuration and workflow execution order.

[0042] Based on the exploration priority from high to low, resource allocation is performed sequentially on the microservice instances constituting service interaction bottlenecks. Specifically, the exploration priority ranking list is first obtained from the output of step S5, arranged from highest to lowest system architecture refactoring potential. The resource allocation process processes each microservice instance involved in each service interaction bottleneck in this order. For example, the microservice instance corresponding to the service interaction bottleneck with the highest system architecture refactoring potential is prioritized for resource allocation. The allocation operation is implemented through the resource management interface of the container orchestration platform, including adjusting the number of CPU cores and memory allocation capacity. A resource locking mechanism is set during the process to prevent multiple allocation operations from simultaneously modifying the resource configuration of the same microservice instance. The allocation order is determined based on the size of the system architecture refactoring potential, which is obtained through comprehensive evaluation in step S5. To handle abnormal situations, a timeout retry mechanism is set up; for example, if the resource allocation operation of a microservice instance is not completed within a set time, the instance is automatically skipped and the abnormal information is recorded.

[0043] Based on the CPU utilization and memory occupancy rates in the resource load metrics, the adjustment range of the resource allocation ratio is determined. The resource load metrics directly utilize the multi-dimensional sensing data obtained in step S1, where CPU utilization is expressed as a percentage and memory occupancy is expressed in megabytes. The adjustment range is determined by analyzing the difference between the current resource utilization level and the target utilization level. The target utilization rate is set based on the statistical characteristics of historical resource utilization data; for example, the target CPU utilization rate is set to the 80th percentile of historical CPU utilization, and the target memory utilization rate is set to the 85th percentile of historical memory occupancy. The adjustment range is calculated using a difference-weighted method: the CPU adjustment range equals the difference between the current utilization rate and the target utilization rate multiplied by the CPU adjustment coefficient, and the memory adjustment range equals the difference between the current occupancy rate and the target occupancy rate multiplied by the memory adjustment coefficient. The adjustment coefficient is dynamically set according to system load characteristics, for example, calculated using an exponentially weighted moving average method based on historical load fluctuations. Weight allocation is based on the importance of resource types; for example, the CPU weight is set to 0.6, and the memory weight is set to 0.4. The weight settings are determined based on the analysis of the resource's impact on business performance. The upper and lower limits of the adjustment range are set based on system stability requirements. For example, the adjustment range of the central processing unit shall not exceed 20% of the initial allocation ratio, and the adjustment range of memory shall not exceed 15% of the initial allocation capacity.

[0044] Based on the call dependencies between microservice instances recorded in the service call chain relationship data, the workflow scheduling order is adjusted accordingly. The service call chain relationship data directly uses the multi-dimensional perception data obtained in step S1, which records the call frequency and dependencies between microservice instances. The adjustment process is based on call dependency graph analysis. First, a directed graph of the service call chain is constructed, where nodes represent microservice instances and edges represent call relationships. The workflow scheduling order adjustment is achieved through a topological sorting algorithm, determining a reasonable execution sequence based on dependencies. In specific implementation, the position of the microservice instance involved in the service interaction bottleneck in the call chain is identified, and then the scheduling priority of its upstream and downstream instances is adjusted. For example, if the output of microservice instance A is the input of microservice instance B, then instance A is ensured to be scheduled before instance B. Adjustment strategies include increasing the scheduling frequency of bottleneck instances or reducing the scheduling latency of their dependent instances, for example, by modifying the scheduling strategy parameters of the workflow engine. Scheduling order optimization considers resource contention, for example, scheduling microservice instances with resource contention to execute in different time windows. Parameter adjustments are based on system operating status; for example, when call dependencies change, the call chain graph is re-analyzed and the scheduling order is updated. To handle circular dependencies, set dependency resolution rules, such as by introducing intermediate services or setting timeout mechanisms to break circular dependencies.

[0045] The calculations involved in the embodiments are all dimensionless numerical calculations, and the preset parameters and thresholds in the calculations are set by those skilled in the art according to the actual situation.

[0046] It should be noted that this invention can be deployed on the device itself to realize embedded applications, or it can run on a PC or other terminal with a user interface, thereby meeting various hardware environments and usage requirements.

[0047] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wireless or wired transmission; wired transmission methods include optical fiber, twisted pair, coaxial cable, etc.; wireless transmission includes infrared, microwave, etc. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center containing one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0048] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and modules described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0049] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0050] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0051] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0052] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0053] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

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

Claims

1. A method for multi-dimensional service process perception and dynamic optimization based on intelligent algorithms, characterized in that, include: S1. Obtain multi-dimensional perception data generated by multiple microservice instances in the industrial microservice system during operation; S2. Based on multi-dimensional sensing data, use intelligent algorithms to analyze the convergence of historical decision sequences and determine whether the current optimization process exhibits path dependence characteristics caused by historical decision sequences. S3. When path dependency features are presented due to historical decision sequences, analyze the calling relationships between microservice instances in the historical decision sequences to identify service compositions that form high-frequency collaborations. S4. Based on high-frequency collaborative service composition, assess the decoupling of resource competition relationships between microservice instances within the service composition and identify service interaction bottlenecks caused by the difficulty in decoupling resource competition relationships. S5. Based on the assessment of the service interaction bottleneck, evaluate the potential for system structure reconstruction that can be triggered after the service interaction bottleneck is removed, and determine the exploration priority of the unexplored region in the solution space associated with the service interaction bottleneck according to the size of the structural reconstruction potential. S6. Dynamically adjust the resource allocation ratio and workflow scheduling order of microservice instances based on exploration priority.

2. The method for multi-dimensional service process perception and dynamic optimization based on intelligent algorithms according to claim 1, characterized in that, The multidimensional perception data obtained in step S1 includes resource load indicators of microservice instances, service call chain relationship data, and business process execution status indicators.

3. The method for multi-dimensional service process perception and dynamic optimization based on intelligent algorithms according to claim 2, characterized in that, The resource load metrics include CPU utilization and memory usage. Service call chain relationship data records the call frequency and dependency relationships between microservice instances; Business process execution status indicators include order processing progress and process planning completion status.

4. The method for multi-dimensional service process perception and dynamic optimization based on intelligent algorithms according to claim 1, characterized in that, Step S2, which uses intelligent algorithms to analyze the convergence of historical decision sequences, includes: Based on the fluctuation of resource load indicators in multidimensional perception data and the trend of call frequency changes in service call chain relationship data, the distribution concentration of historical decision sequences in the solution space is calculated. Evaluate and optimize the stability of target achievement rate by combining business process execution status indicators; Based on the correlation between distribution concentration and the stability of the achievement rate of optimization objectives, it can be determined whether the current optimization process exhibits path dependence characteristics caused by historical decision sequences.

5. The method for multi-dimensional service process perception and dynamic optimization based on intelligent algorithms according to claim 4, characterized in that, Determining whether the current optimization process exhibits path dependence characteristics caused by historical decision sequences based on the correlation between distribution concentration and the stability of the optimization target achievement rate includes: when the distribution concentration is high and the stability of the optimization target achievement rate is low, it is determined that the current optimization process exhibits path dependence characteristics caused by historical decision sequences.

6. The method for multi-dimensional service process perception and dynamic optimization based on intelligent algorithms according to claim 1, characterized in that, Step S3 involves analyzing the call relationships between microservice instances in the historical decision sequence to identify and form high-frequency collaborative service compositions, including: Based on the call frequency and dependency relationships between microservice instances recorded in the service call chain relationship data, we statistically analyze the combinations of microservice instances that co-occur in the historical decision sequence. Based on the frequency and duration of microservice instance combinations in the historical decision sequence, microservice instance combinations with call frequency higher than a set threshold and stable duration are identified as high-frequency collaborative service combinations.

7. The method for multi-dimensional service process perception and dynamic optimization based on intelligent algorithms according to claim 1, characterized in that, Step S4, which assesses the decoupling of resource contention relationships between microservice instances within the service composition, includes: Based on the CPU utilization and memory usage in the resource load indicators, we analyze the resource usage conflicts of microservice instances in the historical decision sequence in high-frequency collaborative service combinations. Assess the decoupling potential of resource competition by considering the persistence of resource use conflicts in the historical decision-making sequence and the success rate of resource allocation attempts. Resource competition relationships with high persistence of resource usage conflicts and low success rate of resource allocation attempts are identified as service interaction bottlenecks that are difficult to decouple.

8. The method for multi-dimensional service process perception and dynamic optimization based on intelligent algorithms according to claim 7, characterized in that, Assessing the decoupling of resource competition based on the persistence of resource use conflicts in the historical decision-making sequence and the success rate of resource allocation attempts includes: when the persistence of resource use conflicts is high and the success rate of resource allocation attempts is low, the decoupling of resource competition is assessed as low.

9. The method for multi-dimensional service process perception and dynamic optimization based on intelligent algorithms according to claim 1, characterized in that, Step S5 assesses the potential for system architecture refactoring following the removal of service interaction bottlenecks, including: Analyze the structural position of microservice instances involved in service interaction bottlenecks in the service call chain relationship data and the scope of their impact on business process execution status indicators; Based on the historical trends of CPU utilization and memory usage in resource load indicators, the degree of relief of resource competition after removing service interaction bottlenecks is predicted. The potential for system restructuring is determined by a comprehensive evaluation of the scope of changes in the service call chain structure and the degree of relief of resource competition. The exploration priority of unexplored regions in the solution space associated with service interaction bottlenecks is determined based on the potential for system structure reconstruction.

10. The method for multi-dimensional service process perception and dynamic optimization based on intelligent algorithms according to claim 1, characterized in that, Step S6, which dynamically adjusts the resource allocation ratio and workflow scheduling order of microservice instances based on exploration priority, includes: Based on the order of exploration priority from high to low, resources are allocated to the microservice instances that constitute service interaction bottlenecks in turn; The adjustment range of the resource allocation ratio is determined based on the CPU utilization and memory usage in the resource load indicators. Based on the call dependencies between microservice instances recorded in the service call chain relationship data, the workflow scheduling order is adjusted accordingly.

Images