Enterprise-level data operation capability scheduling method and system based on microservices

Abstract

The application provides an enterprise-level data operation capability scheduling method and system based on microservices, relates to the technical field of microservices, and comprises the following steps: extracting resource requirements and quality constraints from a data operation task, analyzing a capability requirement vector, matching the capability requirement vector with microservice registration information to obtain a candidate set, selecting a target instance based on multi-objective optimization and generating a scheduling decision, and issuing a calling instruction and then adaptively correcting service boundary conditions according to feedback. The application realizes efficient scheduling of enterprise-level data operation tasks, improves resource utilization, reduces response time delay, and enhances system load balancing.

Description

Technical Field

[0001] This invention relates to the field of microservices technology, and in particular to a method and system for scheduling enterprise-level data operation capabilities based on microservices. Background Technology

[0002] With the deepening of digital transformation, enterprise-level data operations have become a key capability for organizations to gain a competitive advantage. Enterprise-level data operations involve multiple stages, including data collection, storage, processing, analysis, and application, requiring efficient scheduling of various computing resources and data service capabilities. Microservice architecture, as a mainstream distributed system design pattern, provides flexibility and scalability for enterprise-level data operations by breaking down complex applications into small, loosely coupled sets of services. In a microservice environment, the effective scheduling of enterprise-level data operation capabilities is crucial for ensuring data processing efficiency, optimizing resource utilization, and improving service quality.

[0003] Traditional microservice scheduling methods primarily focus on resource allocation and load balancing, lacking a deep understanding and precise matching mechanism for the specific needs of enterprise-level data operation tasks. This makes it difficult to accurately select service instances based on the specific capability requirements of complex data operation tasks, reducing overall scheduling efficiency and task execution quality.

[0004] Existing scheduling systems typically use statically configured service boundary conditions, which cannot adapt to dynamically changing workloads and performance requirements in data operation environments. In practical applications, when the load status and execution efficiency of microservice instances change, fixed boundary conditions can lead to unreasonable resource allocation and affect the overall system performance.

[0005] Current microservice scheduling technologies lack multi-dimensional collaborative optimization capabilities, making it difficult to achieve a balance between multiple objectives such as resource utilization, service response latency, and load balancing. This prevents enterprises from simultaneously ensuring efficient resource utilization and service quality when facing high-concurrency, high-volume data operation tasks, thus reducing the overall efficiency of data operations. Summary of the Invention

[0006] This invention provides a method and system for scheduling enterprise-level data operation capabilities based on microservices, which can solve the problems in the prior art.

[0007] A first aspect of this invention provides a microservice-based enterprise-level data operation capability scheduling method, comprising: Extract resource requirement descriptions and service quality constraints from enterprise-level data operation task requests; Based on the resource requirement description, the capability requirement of the enterprise-level data operation task request is parsed to obtain a capability requirement vector. The current load status and service boundary conditions are obtained and combined into microservice capability registration information. The capability requirement vector is matched with the microservice capability registration information to obtain a set of candidate microservices. Based on the current load status and the service quality constraints, resource utilization, service response latency and load balancing are taken as optimization objectives. Based on the service boundary conditions, the target microservice instances in the candidate microservice set are combined and optimized to obtain a capacity allocation scheme. The target microservice instances and the capacity allocation scheme are combined to form a scheduling decision result. Based on the scheduling decision result, a capability invocation instruction is issued to the target microservice instance, and the execution feedback information returned by the target microservice instance is obtained; Based on the deviation measurement result between the execution feedback information and the capability requirement vector, the service boundary conditions are adaptively corrected, and the corrected service boundary conditions are used for new scheduling decisions.

[0008] Based on the resource requirement description, the capability requirement of the enterprise-level data operation task request is parsed to obtain the capability requirement vector, which includes: Extract task type identifiers and resource quantification requirements from the resource requirement description; Analyze the association patterns between task type identifiers of historical enterprise-level data operation task requests and the types of microservice capabilities actually invoked, extract association rules, and establish a mapping relationship table between task types and microservice capability types based on the association rules; query the mapping relationship table according to the task type identifier to obtain the set of microservice capability types required by the enterprise-level data operation task request; Based on the demand intensity of each microservice capability type in the enterprise-level data operation task request and the resource quantification requirements, the computing capability requirement component, storage capability requirement component and network capability requirement component corresponding to the microservice capability type are determined respectively, and combined to construct the capability requirement quantification value. The set of microservice capability types and the corresponding quantified capability requirement values ​​are combined to construct the capability requirement vector.

[0009] The current load status and service boundary conditions are obtained and combined into microservice capability registration information. The capability requirement vector is then matched with the microservice capability registration information to obtain a candidate microservice set, including: Collect the current resource utilization rate and request processing queue length, and combine them to form the current load state; obtain the maximum concurrent processing capacity and the supported microservice capability types, and combine them to form the service boundary conditions; associate the current load state, the service boundary conditions, and the instance identifier of the corresponding microservice instance to obtain the microservice capability registration information; Extract the set of microservice capability types from the capability requirement vector, traverse the microservice capability registration information, and filter out microservice instances whose supported microservice capability types intersect with the set of microservice capability types to form a basic matching microservice set; For each microservice instance in the basic matching microservice set, the load margin is calculated based on the current load status, and the available processing capacity is calculated based on the maximum concurrent processing capacity. When the load margin is greater than the preset load threshold and the available processing capacity meets the corresponding capability requirement quantification value in the capability requirement vector, the microservice instance is included in the candidate microservice set.

[0010] Based on the current load status and the service quality constraints, the optimization objectives include resource utilization, service response latency, and load balancing. Extract the maximum allowable response latency and the minimum resource utilization requirement from the service quality constraints. Use the maximum allowable response latency as the upper bound of the response latency optimization objective and the minimum resource utilization requirement as the lower bound of the resource utilization optimization objective. For each microservice instance in the candidate microservice set, a predicted resource utilization value is calculated based on the resource occupancy rate in the current load state, and a predicted service response latency value is calculated based on the request processing queue length in the current load state. The deviation between the predicted resource utilization rate and the midpoint value of the resource utilization optimization target is calculated as a resource utilization optimization component. The ratio between the predicted service response latency and the maximum allowable response latency is calculated as a service response latency optimization component. The load distribution variance is calculated based on the current load status of each microservice instance in the candidate microservice set as a load balancing optimization component. The resource utilization optimization component, the service response latency optimization component, and the load balancing optimization component are used as optimization objectives.

[0011] Based on the service boundary conditions, the target microservice instances in the candidate microservice set are combined and optimized to obtain a capability allocation scheme including: Using the selection status and capacity allocation ratio of microservice instances in the candidate microservice set as decision variables, the maximum concurrent processing capacity in the service boundary conditions as the capacity constraint of each microservice instance, and the capacity requirement satisfaction constraint based on the capacity requirement quantification value in the capacity requirement vector, a combinatorial optimization problem is constructed. The remaining processing capacity is calculated based on the current load status. The ratio of the remaining processing capacity to the maximum concurrent processing capacity is used as the available capacity coefficient. Based on the available capacity coefficient and the matching degree of the microservice capability types supported by the microservice instance and the set of microservice capability types in the capability requirement vector, the overall adaptability of the microservice instance is calculated. Based on the comprehensive fit, the decision variables are solved under the constraints of the combinatorial optimization problem to obtain the capability allocation ratio of each microservice instance in the selected microservice instance combination, and the selected microservice instance combination is determined as the target microservice instance. Based on the quantified value of capability requirements in the capability requirement vector and the capability allocation ratio in the target microservice instance, the capability call volume that each microservice instance should undertake is calculated to form the capability allocation scheme.

[0012] Based on the scheduling decision result, a capability invocation instruction is issued to the target microservice instance, and the execution feedback information returned by the target microservice instance is obtained, including: Based on the scheduling decision result, a capacity call quantity is generated according to the capacity call share corresponding to each microservice instance, and the identification information, execution parameters and capacity call quantity of the microservice instance are encapsulated into the capacity call instruction, while a scheduling tracing identifier is embedded in the capacity call instruction; Based on the execution feedback information received from the scheduling tracking identifier, the actual number of processes in the execution feedback information is compared with the number of capability calls in the capability call instruction to determine the execution completion rate of the microservice instance, and the execution success status of the microservice instance is determined based on the execution status identifier of the execution feedback information.

[0013] Based on the deviation measurement result between the execution feedback information and the capability requirement vector, adaptive correction of the service boundary conditions includes: The actual processing quantity and execution time of each microservice instance are extracted from the execution feedback information. Based on the actual processing quantity and the quantified value of the capacity requirement undertaken, the capacity supply and demand deviation is calculated. Based on the ratio of the execution time to the preset execution time standard, the execution efficiency deviation coefficient is calculated. The capacity supply and demand deviation and the execution efficiency deviation coefficient are combined to obtain the service capacity deviation metric; the capacity correction is calculated based on the absolute value of the service capacity deviation metric. When the service capacity deviation metric is negative, the capacity correction is subtracted from the maximum concurrent processing capacity corresponding to the service boundary conditions. When the service capacity deviation metric is positive, the capacity correction is added to the maximum concurrent processing capacity corresponding to the service boundary conditions. The modified maximum concurrent processing capacity is updated to the service boundary conditions to complete the adaptive correction.

[0014] A second aspect of this invention provides an enterprise-level data operation capability scheduling system based on microservices, comprising: The first unit is used to extract resource requirement descriptions and service quality constraints from enterprise-level data operation task requests; The second unit is used to parse the capability requirements of the enterprise-level data operation task request based on the resource requirement description, and obtain the capability requirement vector. The third unit is used to obtain the current load status and service boundary conditions and combine them into microservice capability registration information, and to match the capability requirement vector with the microservice capability registration information to obtain a set of candidate microservices. The fourth unit is used to optimize resource utilization, service response latency and load balancing based on the current load status and the service quality constraints, and to combine and optimize the target microservice instances in the candidate microservice set based on the service boundary conditions to obtain a capacity allocation scheme. The target microservice instances and the capacity allocation scheme are combined into a scheduling decision result. The fifth unit is used to issue a capability invocation instruction to the target microservice instance based on the scheduling decision result, and to obtain the execution feedback information returned by the target microservice instance. The sixth unit is used to adaptively correct the service boundary conditions based on the deviation measurement result between the execution feedback information and the capability requirement vector, and to use the corrected service boundary conditions for new scheduling decisions.

[0015] A third aspect of the present invention, An electronic device is provided, comprising: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the aforementioned method.

[0016] Fourth aspect of the embodiments of the present invention, A computer-readable storage medium is provided, having stored thereon computer program instructions that, when executed by a processor, implement the aforementioned method.

[0017] The beneficial effects of this application are as follows: This invention achieves precise scheduling of target microservice instances by parsing the capability requirements of enterprise-level data operation task requests and matching them with microservice capability registration information, effectively improving resource utilization efficiency and service response speed.

[0018] By taking resource utilization, service response latency, and load balancing as optimization objectives and combining them based on service boundary conditions, the resulting capacity allocation scheme can achieve balanced distribution of system load while ensuring service quality, reducing waste of system resources and improving overall operating performance.

[0019] Based on the deviation measurement results between the execution feedback information and the capacity demand vector, the service boundary conditions are adaptively corrected, and a closed-loop optimization mechanism is constructed. This enables the system to continuously optimize the scheduling strategy according to the actual operation, thereby enhancing the system's adaptability and stability to complex business scenarios. Attached Figure Description

[0020] Figure 1 This is a flowchart illustrating the enterprise-level data operation capability scheduling method based on microservices according to an embodiment of the present invention. Figure 2 This is a schematic diagram of the microservice capability matching and candidate set selection process. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, 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.

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

[0023] Figure 1 This is a flowchart illustrating the enterprise-level data operation capability scheduling method based on microservices according to an embodiment of the present invention. Figure 1 As shown, the method includes: Extract resource requirement descriptions and service quality constraints from enterprise-level data operation task requests; Based on the resource requirement description, the capability requirement of the enterprise-level data operation task request is parsed to obtain a capability requirement vector. The current load status and service boundary conditions are obtained and combined into microservice capability registration information. The capability requirement vector is matched with the microservice capability registration information to obtain a set of candidate microservices. Based on the current load status and the service quality constraints, resource utilization, service response latency and load balancing are taken as optimization objectives. Based on the service boundary conditions, the target microservice instances in the candidate microservice set are combined and optimized to obtain a capacity allocation scheme. The target microservice instances and the capacity allocation scheme are combined to form a scheduling decision result. Based on the scheduling decision result, a capability invocation instruction is issued to the target microservice instance, and the execution feedback information returned by the target microservice instance is obtained; Based on the deviation measurement result between the execution feedback information and the capability requirement vector, the service boundary conditions are adaptively corrected, and the corrected service boundary conditions are used for new scheduling decisions.

[0024] In one optional implementation, the enterprise-level data operation task request is parsed based on the resource requirement description to obtain a capability requirement vector including: Extract task type identifiers and resource quantification requirements from the resource requirement description; Analyze the association patterns between task type identifiers of historical enterprise-level data operation task requests and the types of microservice capabilities actually invoked, extract association rules, and establish a mapping relationship table between task types and microservice capability types based on the association rules; query the mapping relationship table according to the task type identifier to obtain the set of microservice capability types required by the enterprise-level data operation task request; Based on the demand intensity of each microservice capability type in the enterprise-level data operation task request and the resource quantification requirements, the computing capability requirement component, storage capability requirement component and network capability requirement component corresponding to the microservice capability type are determined respectively, and combined to construct the capability requirement quantification value. The set of microservice capability types and the corresponding quantified capability requirement values ​​are combined to construct the capability requirement vector.

[0025] The task type identifier and resource quantification requirements are extracted from the resource requirement description. For example, for an enterprise-level data operation task request "Real-time analysis of product sales data, requiring 16-core CPU, 64GB memory, 5TB storage space, and 100Mbps network bandwidth," natural language processing technology extracts the task type identifier as "real-time analysis" and the resource quantification requirements as "16-core CPU, 64GB memory, 5TB storage space, and 100Mbps network bandwidth." In practice, a pre-trained text classification model is used to identify the task type, and regular expression matching is used to extract the resource quantification parameters.

[0026] This study analyzes the association patterns between task type identifiers and the actual microservice capability types invoked in historical enterprise-level data operation task requests. Association rules are extracted, and a mapping table between task types and microservice capability types is established based on these rules. All successfully executed task records from the past six months are extracted from the historical task execution record database, including task type identifiers and a list of microservice capability types actually invoked by that task. A frequent pattern mining algorithm identifies task types and microservice capability types that occur more frequently than a preset threshold, such as 80% of the time. For example, it was found that "real-time analysis" tasks invoke the "data acquisition," "stream processing," and "visualization" microservice capability types in 90% of cases. Based on the mining results, a mapping table is constructed, mapping each task type to its frequently associated set of microservice capability types. This mapping table is in key-value pair format, where the key is the task type identifier, and the value is the set of microservice capability types and their invocation probability.

[0027] Based on the task type identifier of the current enterprise-level data operation task request, the mapping table above is queried to obtain the set of microservice capability types required for the task request. For example, for the "real-time analysis" task type, the mapping table is queried to obtain the set of required microservice capability types as {"data acquisition", "stream processing", "visualization"}. If the current task type identifier does not exist in the mapping table, the most similar task type is found using similarity calculation, or the default set of microservice capability types is activated.

[0028] Based on the demand intensity and resource quantification requirements for each microservice capability type according to enterprise-level data operation task requests, the computing power requirement component, storage power requirement component, and network power requirement component corresponding to each microservice capability type are determined and combined to construct a quantified capability requirement value. Through historical data analysis, a resource occupancy ratio model for each microservice capability type is pre-established. For example, the "stream processing" microservice typically consumes 60% of computing resources, 30% of storage resources, and 50% of network resources in real-time analysis tasks. Based on this model, the quantified resource requirements are allocated to each microservice capability type. In the above example, the computing power requirement component for the "stream processing" microservice is 16 cores × 60% = 9.6 CPU cores, the storage power requirement component is 5TB × 30% = 1.5TB, and the network power requirement component is 100Mbps × 50% = 50Mbps. Similar calculations are performed for each microservice capability type to obtain its respective quantified capability requirement value, in the form of a triple (computing power value, storage power value, network power value).

[0029] A capability requirement vector is constructed by combining the set of microservice capability types with their corresponding quantified capability requirements. For each microservice capability type, a four-tuple is created: (microservice capability type identifier, compute capability value, storage capability value, network capability value). All four-tuples of microservice capability types are combined in a predefined order to form the capability requirement vector. For example, for the real-time analytics task mentioned above, its capability requirement vector is [("Data Acquisition", 3.2 cores, 1TB, 30Mbps), ("Stream Processing", 9.6 cores, 1.5TB, 50Mbps), ("Visualization", 3.2 cores, 2.5TB, 20Mbps)]. This capability requirement vector comprehensively describes the microservice capability requirements and resource quantification requirements of an enterprise-level data operation task request, providing a precise basis for subsequent resource scheduling and task execution.

[0030] To ensure the accuracy of capability requirement analysis, the mapping table between task types and microservice capability types is updated regularly, such as monthly, and the resource consumption ratio model for microservice capability types is adjusted based on actual execution results. Simultaneously, the differences between each capability requirement analysis result and the actual execution are recorded, and the analysis accuracy is continuously optimized through feedback learning. This dynamic adaptive mechanism enables capability requirement analysis to adapt to changes and developments in enterprise business, continuously providing accurate resource requirement predictions.

[0031] In one optional implementation, the current load status and service boundary conditions are obtained and combined into microservice capability registration information. The capability requirement vector is then matched with the microservice capability registration information to obtain a candidate microservice set, including: Collect the current resource utilization rate and request processing queue length, and combine them to form the current load state; obtain the maximum concurrent processing capacity and the supported microservice capability types, and combine them to form the service boundary conditions; associate the current load state, the service boundary conditions, and the instance identifier of the corresponding microservice instance to obtain the microservice capability registration information; Extract the set of microservice capability types from the capability requirement vector, traverse the microservice capability registration information, and filter out microservice instances whose supported microservice capability types intersect with the set of microservice capability types to form a basic matching microservice set; For each microservice instance in the basic matching microservice set, the load margin is calculated based on the current load status, and the available processing capacity is calculated based on the maximum concurrent processing capacity. When the load margin is greater than the preset load threshold and the available processing capacity meets the corresponding capability requirement quantification value in the capability requirement vector, the microservice instance is included in the candidate microservice set.

[0032] like Figure 2 As shown, the method includes: The system collects current resource utilization and request processing queue length, combining them to form the current load status, including resource metrics such as CPU utilization and network bandwidth usage. For example, for a microservice instance A, its current CPU utilization is 65%, memory utilization is 72%, and network bandwidth utilization is 45%. Simultaneously, the system monitors the request processing queue of this microservice instance, recording the number of currently unprocessed requests, such as the current request queue length for microservice instance A being 28. These metrics are combined into a structured load status information, represented as {CPU: 65%, Memory: 72%, Bandwidth: 45%, QueueLength: 28}.

[0033] The maximum concurrent processing capacity and supported microservice capability types are combined to form service boundary conditions. The maximum concurrent processing capacity of a microservice refers to the maximum number of requests a microservice instance can handle simultaneously while ensuring service quality. This value is typically pre-configured by the system administrator based on microservice performance test results or obtained through adaptive learning. For example, the maximum concurrent processing capacity of microservice instance A is 200. The microservice capability type refers to the functional categories that the microservice instance can provide, such as data query, data processing, and image recognition. For example, the capability types supported by microservice instance A are {data query, data aggregation, data validation}. Combining the maximum concurrent processing capacity and supported microservice capability types into service boundary conditions is represented as {MaxConcurrency: 200, SupportedCapabilities: {data query, data aggregation, data validation}}.

[0034] The current load status, service boundary conditions, and the instance identifier of the corresponding microservice instance are associated to obtain microservice capability registration information. The instance identifier is a unique identifier for a microservice instance in the system, such as "service-A-instance-01". The load status, service boundary conditions, and instance identifier are combined into complete capability registration information and registered with the service registry for subsequent service discovery and capability matching. Example of complete capability registration information: {InstanceId: "service-A-instance-01", LoadStatus: {CPU: 65%, Memory: 72%, Bandwidth: 45%, QueueLength: 28}, ServiceBoundary: {MaxConcurrency: 200, SupportedCapabilities: {Data Query, Data Aggregation, Data Validation}}}.

[0035] Upon receiving a service request, a set of microservice capability types is extracted from the capability requirement vector. The capability requirement vector is structured data describing the service capabilities and corresponding quantities required by the user's request. For example, a user's capability requirement vector might be {Data Query: 50, Data Aggregation: 30}, indicating a need for data query capability with an estimated processing volume of 50; and a need for data aggregation capability with an estimated processing volume of 30. The capability type set {Data Query, Data Aggregation} is then extracted from this vector.

[0036] The process iterates through the microservice capability registration information, filtering out microservice instances whose supported microservice capability types intersect with the requested set of microservice capability types. This forms a basic matching microservice set. Specifically, the service registry is accessed to retrieve all registered microservice capability information, and each microservice instance's supported capability types are checked one by one to see if they intersect with the requested set of capability types. For example, microservice instance A supports {data query, data aggregation, data validation}, which intersects with the requested set of capability types {data query, data aggregation}, and is therefore included in the basic matching set; microservice instance B supports {data storage, data backup}, which does not intersect with the requested set of capability types, and is therefore not included in the basic matching set.

[0037] For each microservice instance in the basic matching microservice set, the load margin is calculated based on the current load status, and the available processing capacity is calculated based on the maximum concurrent processing capacity. Load margin refers to the proportion of additional load that a microservice instance can currently handle, which can be calculated by the difference between the current resource utilization rate and a preset threshold. For example, if the preset CPU utilization threshold is 85%, and microservice instance A currently has a CPU utilization rate of 65%, then the CPU-based load margin is 20%. Similarly, the memory and bandwidth-based load margins are calculated, and the minimum of the three is taken as the overall load margin. Available processing capacity refers to the number of additional requests that a microservice instance can currently handle, which can be calculated by the difference between the maximum concurrent processing capacity and the current request queue length. For example, if microservice instance A has a maximum concurrent processing capacity of 200 and a current request queue length of 28, then the available processing capacity is 172.

[0038] The system determines whether the load margin exceeds a preset load threshold and whether the available processing capacity meets the corresponding quantified capacity requirement value in the capacity requirement vector. If both conditions are met, the microservice instance is included in the candidate microservice set. The preset load threshold is a safety margin value configured by the system administrator, such as 15%, to prevent microservice instances from being overloaded. The quantified capacity requirement value is the estimated processing volume corresponding to each capability in the capacity requirement vector. For example, microservice instance A has a load margin of 20%, which is greater than the preset load threshold of 15%; its available processing capacity is 172, which is greater than the total demand of data query and data aggregation in the capacity requirement vector (50 + 30 = 80). Therefore, microservice instance A is included in the candidate microservice set.

[0039] Through the above implementation methods, the set of microservice instances most suitable for handling the current request can be accurately matched based on the real-time load status and service boundary conditions of the microservice, combined with the user's specific capability requirements, thereby improving the utilization efficiency of service resources and the processing quality of user requests.

[0040] In one optional implementation, based on the current load state and the service quality constraints, resource utilization, service response latency, and load balancing are used as optimization objectives, including: Extract the maximum allowable response latency and the minimum resource utilization requirement from the service quality constraints. Use the maximum allowable response latency as the upper bound of the response latency optimization objective and the minimum resource utilization requirement as the lower bound of the resource utilization optimization objective. For each microservice instance in the candidate microservice set, a predicted resource utilization value is calculated based on the resource occupancy rate in the current load state, and a predicted service response latency value is calculated based on the request processing queue length in the current load state. The deviation between the predicted resource utilization rate and the midpoint value of the resource utilization optimization target is calculated as a resource utilization optimization component. The ratio between the predicted service response latency and the maximum allowable response latency is calculated as a service response latency optimization component. The load distribution variance is calculated based on the current load status of each microservice instance in the candidate microservice set as a load balancing optimization component. The resource utilization optimization component, the service response latency optimization component, and the load balancing optimization component are used as optimization objectives.

[0041] Extract the maximum allowable response latency and minimum resource utilization requirements from the service quality constraints. For example, suppose the service quality constraints in the system stipulate that the maximum allowable response latency is 200 milliseconds and the minimum resource utilization requirement is 40%. Here, 200 milliseconds is used as the upper bound of the response latency optimization objective, and 40% is used as the lower bound of the resource utilization optimization objective. In practical applications, these constraint values ​​can be adjusted according to specific business needs.

[0042] For each microservice instance in the candidate microservice set, the predicted resource utilization and service response latency need to be calculated based on the current load status. Assume a microservice instance A has a current CPU utilization of 60%, memory utilization of 50%, and network bandwidth utilization of 30%. The predicted resource utilization can be calculated using a weighted average method. For example, if the weights for CPU, memory, and network bandwidth are 0.5, 0.3, and 0.2 respectively, then the predicted resource utilization for microservice instance A is 60% × 0.5 + 50% × 0.3 + 30% × 0.2 = 52%. The predicted service response latency can be calculated based on the current request processing queue length. Assuming the current request processing queue length for microservice instance A is 10, and the average processing time per request is 15 milliseconds, then the predicted service response latency is 10 × 15 = 150 milliseconds.

[0043] The deviation between the predicted resource utilization rate and the midpoint of the resource utilization optimization target is calculated as a component of resource utilization optimization. The midpoint of the resource utilization optimization target can be determined based on a lower bound of the resource utilization constraint and an empirical upper bound. Assuming the empirical upper bound is 80%, the midpoint of the resource utilization optimization target is (40% + 80%) / 2 = 60%. For microservice instance A, its predicted resource utilization rate is 52%, and the deviation from the midpoint of 60% is |52% - 60%| / 60% = 13.3%. This deviation can be used as a component of resource utilization optimization.

[0044] The ratio between the predicted service response latency and the maximum allowable response latency is used as the service response latency optimization component. For microservice instance A, its predicted service response latency is 150 milliseconds, and its maximum allowable response latency is 200 milliseconds. Therefore, the service response latency optimization component is 150 / 200 = 0.75. The smaller this ratio, the better the response latency performance of the microservice instance.

[0045] The load distribution variance is calculated as a component for load balancing optimization based on the current load status of each microservice instance in the candidate microservice set. Assume the candidate microservice set contains three microservice instances A, B, and C, with predicted resource utilization rates of 52%, 65%, and 48%, respectively. The mean of these values ​​is calculated as (52% + 65% + 48%) / 3 = 55%. The squared deviation of each microservice instance's predicted resource utilization rate from the mean is calculated as (52% - 55%). 2 +(65%-55%) 2 +(48%-55%) 2=9 + 100 + 49 = 158. The load distribution variance is 158 / 3 = 52.67. The smaller this value, the more balanced the system load distribution. To facilitate optimization calculations, this value can be normalized, for example, by dividing it by a baseline variance value of 100, resulting in the optimized load balance component as 52.67 / 100 = 0.5267.

[0046] By using resource utilization optimization, service response latency optimization, and load balancing optimization as optimization objectives, weights can be assigned to these three components to form a comprehensive optimization goal. For example, assuming the weight of resource utilization optimization is 0.3, the weight of service response latency optimization is 0.5, and the weight of load balancing optimization is 0.2, then for microservice instance A, its comprehensive optimization objective value is 0.3 × 13.3% + 0.5 × 0.75 + 0.2 × 0.5267 = 0.0399 + 0.375 + 0.10534 = 0.52024. In actual optimization, the microservice instance with the optimal comprehensive optimization objective value can be selected as the request allocation target.

[0047] By implementing the above methods, multi-objective optimization of resource utilization, service response latency, and load balancing can be achieved while meeting quality of service constraints. This approach is applicable to various microservice architecture systems, improving system resource utilization efficiency, reducing service response latency, and achieving good load balancing. In actual deployment, various parameters and weights can be adjusted according to specific business scenarios to achieve optimal system performance.

[0048] In one optional implementation, the capability allocation scheme is obtained by combining and optimizing the target microservice instances in the candidate microservice set based on the service boundary conditions, including: Using the selection status and capacity allocation ratio of microservice instances in the candidate microservice set as decision variables, the maximum concurrent processing capacity in the service boundary conditions as the capacity constraint of each microservice instance, and the capacity requirement satisfaction constraint based on the capacity requirement quantification value in the capacity requirement vector, a combinatorial optimization problem is constructed. The remaining processing capacity is calculated based on the current load status. The ratio of the remaining processing capacity to the maximum concurrent processing capacity is used as the available capacity coefficient. Based on the available capacity coefficient and the matching degree of the microservice capability types supported by the microservice instance and the set of microservice capability types in the capability requirement vector, the overall adaptability of the microservice instance is calculated. Based on the comprehensive fit, the decision variables are solved under the constraints of the combinatorial optimization problem to obtain the capability allocation ratio of each microservice instance in the selected microservice instance combination, and the selected microservice instance combination is determined as the target microservice instance. Based on the quantified value of capability requirements in the capability requirement vector and the capability allocation ratio in the target microservice instance, the capability call volume that each microservice instance should undertake is calculated to form the capability allocation scheme.

[0049] During the initialization phase, relevant information about the candidate microservice set is obtained, including the maximum concurrent processing capacity of each microservice instance, the types of microservice capabilities it supports, and its current load status. Simultaneously, a capability requirement vector is obtained, containing quantified values ​​for the required capabilities of various microservices. This information serves as the foundation for subsequent optimization decisions.

[0050] The selection status of a microservice instance is defined as a binary variable, where 0 indicates that the instance is not selected and 1 indicates that the instance is selected. Simultaneously, a capacity allocation ratio variable is defined, representing the proportion of capacity demand allocated to each microservice instance. For example, in a candidate set of 3 microservice instances, if instance 1 has a selection status of 1 and a capacity allocation ratio of 0.4, it means that this instance is selected and will bear 40% of the corresponding capacity demand.

[0051] Using the maximum concurrent processing capacity in the service boundary conditions as a constraint, let's take a specific example. Suppose the maximum concurrent processing capacity of microservice instance A is 100 requests / second. Then, the capacity requirement allocated to this instance cannot exceed this threshold. To satisfy the capacity requirement constraint, ensure that the sum of the capacity allocation ratios of all selected instances equals 1, that is, fully satisfy the demand in the capacity requirement vector.

[0052] The current load status of each microservice instance is obtained based on real-time monitoring data. For example, if microservice instance B is currently processing 30 requests / second and its maximum concurrent processing capacity is 80 requests / second, then the current remaining processing capacity is 50 requests / second. The available capacity coefficient is calculated as 50 / 80 = 0.625, indicating that this instance still has 62.5% of its capacity available for new capacity allocation.

[0053] When assessing the match between microservice instances and capability requirements, it is checked whether the microservice capability types supported by each instance include the capability types in the capability requirement vector. For example, if the capability requirement vector includes two capability types, "data processing" and "image recognition", and microservice instance C supports three capability types, namely "data processing", "image recognition" and "speech recognition", then the match degree is 1.0 (complete match); while microservice instance D only supports one capability type, "data processing", and the match degree is 0.5 (partial match).

[0054] The overall adaptability score is calculated by combining the available capacity coefficient and the degree of matching between capability types. For example, the two can be multiplied together to obtain the overall adaptability score. In the above example, if the available capacity coefficient of microservice instance C is 0.8, then its overall adaptability score is 0.8 × 1.0 = 0.8; while the available capacity coefficient of microservice instance D is 0.9, and its overall adaptability score is 0.9 × 0.5 = 0.45.

[0055] When solving combinatorial optimization problems, heuristic algorithms or exact solution methods are used to maximize the total comprehensive fitness under constraints. In specific implementation, a greedy algorithm can be used: first, all microservice instances are sorted in descending order of comprehensive fitness, and then instances are selected one by one and capabilities are assigned until all capability requirements are met.

[0056] Let's illustrate the process with a specific example: Assume there's a candidate set containing four microservice instances (W1, W2, W3, W4). The capability requirement vector includes two capability types, A and B, with quantified values ​​of 60 and 40 (unit: requests / second), respectively. The attributes of each microservice instance are as follows: W1 supports capability type A, with a maximum processing capacity of 100 and a current remaining capacity of 80; W2 supports capability types A and B, with a maximum processing capacity of 120 and a current remaining capacity of 60; W3 supports capability type B, with a maximum processing capacity of 80 and a current remaining capacity of 40; W4 supports capability types A and B, with a maximum processing capacity of 150 and a current remaining capacity of 45.

[0057] Calculate the available capacity coefficient for each instance: W1 = 0.8, W2 = 0.5, W3 = 0.5, W4 = 0.3. Calculate the capability type matching degree: W1 = 0.5 (matching capability A only), W2 = 1.0, W3 = 0.5 (matching capability B only), W4 = 1.0. Obtain the overall fit: W1 = 0.4, W2 = 0.5, W3 = 0.25, W4 = 0.3.

[0058] The solution results show that the selected microservice instance combination is W1, W2 and W3, and the capacity allocation ratios are as follows: W1 undertakes 0.6 of capacity A (i.e., 36 requests / second), W2 undertakes 0.4 of capacity A (i.e., 24 requests / second) and 0.5 of capacity B (i.e., 20 requests / second), and W3 undertakes 0.5 of capacity B (i.e., 20 requests / second).

[0059] Based on the aforementioned capacity allocation ratios and quantified capacity requirements, the specific capacity call volume undertaken by each microservice instance is calculated: W1 handles 36 type A requests / second, W2 handles 24 type A and 20 type B requests / second, and W3 handles 20 type B requests / second. This information constitutes the final capacity allocation scheme, serving as the basis for the system to execute microservice scheduling.

[0060] In one optional implementation, issuing a capability invocation instruction to the target microservice instance based on the scheduling decision result, and obtaining the execution feedback information returned by the target microservice instance include: Based on the scheduling decision result, a capacity call quantity is generated according to the capacity call share corresponding to each microservice instance, and the identification information, execution parameters and capacity call quantity of the microservice instance are encapsulated into the capacity call instruction, while a scheduling tracing identifier is embedded in the capacity call instruction; Based on the execution feedback information received from the scheduling tracking identifier, the actual number of processes in the execution feedback information is compared with the number of capability calls in the capability call instruction to determine the execution completion rate of the microservice instance, and the execution success status of the microservice instance is determined based on the execution status identifier of the execution feedback information.

[0061] After obtaining the scheduling decision result, the scheduling system needs to issue capability invocation instructions to the target microservice instances based on the result, parse the scheduling decision result, and extract the capability invocation share for each microservice instance. These shares are usually expressed as percentages; for example, microservice instance A is allocated 60% of the invocation share, and microservice instance B is allocated 40%. Assuming that a total of 1000 request tasks need to be processed, these requests will be allocated according to the share ratio, that is, microservice instance A will handle 600 requests, and microservice instance B will handle 400 requests.

[0062] A dedicated invocation command is created for each microservice instance. This command contains three core components: the microservice instance's identification information, the parameters required for execution, and the number of capability calls. The microservice instance's identification information typically includes the instance ID, IP address, and port number, used to accurately locate the target instance. For example, the identification information for microservice instance A is {instanceId: "service-a-01", host: "192.168.1.100", port: 8080}. The execution parameters are the specific data and configuration information required for the microservice instance to execute the task, such as {operation: "dataProcess", dataType: "json", timeout: 500}. The number of capability calls explicitly specifies the number of requests the instance needs to handle, such as 600 in the previous example.

[0063] A scheduling trace identifier is embedded in the instruction. This identifier is a globally unique string generated in UUID format, such as "7b46fd82-9c8f-4a6e-a378-f9d671e54b29". The purpose of the scheduling trace identifier is to associate requests and responses, ensuring accurate tracking of the execution of each call instruction. The call instructions are ultimately assembled into a complete data structure, for example: {target: {instanceId: "service-a-01", host: "192.168.1.100", port: 8080}, params: {operation: "dataProcess", dataType: "json", timeout: 500}, callCount: 600, traceId: "7b46fd82-9c8f-4a6e-a378-f9d671e54b29"}.

[0064] The command is sent over the network to the target microservice instance. Upon receiving the command, the microservice instance processes the specified number of requests according to the execution parameters in the command and returns execution feedback information after completion. This feedback information includes the status of the processing result and the actual number of requests processed. For example, microservice instance A returns {traceId: "7b46fd82-9c8f-4a6e-a378-f9d671e54b29", status: "SUCCESS", processedCount: 580, errorCode: null, message: "Request processed successfully"}, indicating that 580 out of 600 requests were successfully processed.

[0065] By comparing the scheduling trace identifier in the feedback information with the identifier in the issued call command, it is ensured that the feedback information corresponds one-to-one with the original command. For each feedback information, the actual number of processes (processedCount) is extracted and compared with the number of capability calls (callCount) in the original command. By calculating the ratio of the actual number of processes to the expected number of calls, the execution completion rate of the microservice instance can be obtained. Taking the above example, the execution completion rate of microservice instance A is 580 / 600 = 96.67%.

[0066] In addition to calculating the execution completion rate, the execution status indicators in the execution feedback information are analyzed to determine the success status of the microservice instance. Execution status indicators typically include values ​​such as "SUCCESS," "PARTIAL_SUCCESS," and "FAILED." When the execution status is "SUCCESS" and the actual number of requests processed equals the number of capability calls, it indicates that the microservice instance has successfully executed all requests. When the execution status is "SUCCESS" but the actual number of requests processed is less than the number of capability calls, it indicates partial success. When the execution status is "FAILED," it indicates execution failure.

[0067] In a practical application scenario, consider a distributed image processing system comprising three microservice instances, each responsible for handling different types of image conversion requests. Based on historical performance data, it is decided to allocate 1200 image processing requests to these three instances in a 50%, 30%, and 20% ratio: instance 1 handles 600 requests, instance 2 handles 360, and instance 3 handles 240. The scheduling system generates corresponding call instructions, embeds a unique tracking identifier, and sends them to each instance. After processing, instance 1 reports success in processing 590 requests, instance 2 reports success in processing 358 requests, and instance 3 reports success in processing 240 requests. The execution completion rate is calculated as 98.33% for instance 1, 99.44% for instance 2, and 100% for instance 3. Based on this, the performance metrics of each instance are updated to provide a reference for future scheduling decisions.

[0068] The above implementation method enables precise control over the allocation of capability calls for microservice instances and allows for real-time evaluation of the execution status of each instance through execution feedback information, thereby optimizing subsequent scheduling decisions and improving the overall system performance and stability.

[0069] In one optional implementation, adaptively correcting the service boundary conditions based on the deviation measurement result between the execution feedback information and the capability requirement vector includes: The actual processing quantity and execution time of each microservice instance are extracted from the execution feedback information. Based on the actual processing quantity and the quantified value of the capacity requirement undertaken, the capacity supply and demand deviation is calculated. Based on the ratio of the execution time to the preset execution time standard, the execution efficiency deviation coefficient is calculated. The capacity supply and demand deviation and the execution efficiency deviation coefficient are combined to obtain the service capacity deviation metric; the capacity correction is calculated based on the absolute value of the service capacity deviation metric. When the service capacity deviation metric is negative, the capacity correction is subtracted from the maximum concurrent processing capacity corresponding to the service boundary conditions. When the service capacity deviation metric is positive, the capacity correction is added to the maximum concurrent processing capacity corresponding to the service boundary conditions. The modified maximum concurrent processing capacity is updated to the service boundary conditions to complete the adaptive correction.

[0070] The monitoring module extracts the actual processing volume and execution time data for each microservice instance from the execution feedback information. For example, for the order processing microservice, the monitoring module recorded that in the past 5 minutes, this microservice instance actually processed 1200 order requests, with a total execution time of 240 seconds. Simultaneously, it obtains the quantified capacity demand of this microservice instance, assumed to be 1000 orders / 5 minutes. Based on the comparison between the actual processing volume and the quantified capacity demand, the calculated capacity supply-demand deviation is 200 orders, indicating that the actual processing capacity of this instance exceeds the expected demand.

[0071] To calculate the execution efficiency deviation, the execution time is compared with the preset execution time standard. Assuming that the preset execution time standard for this microservice to process 1200 orders is 300 seconds, while the actual execution time is 240 seconds, the execution efficiency deviation coefficient is 240 / 300=0.8, which is less than 1, indicating that the execution efficiency is higher than expected.

[0072] The service capacity deviation metric is obtained by combining the capacity supply-demand deviation and the execution efficiency deviation coefficient. The combination method can be a weighted average, i.e., Service Capacity Deviation Metric = α × Normalized Capacity Supply-Demand Deviation + β × (1 - Execution Efficiency Deviation Coefficient), where α and β are weighting coefficients and α + β = 1. Assuming α = 0.6, β = 0.4, and the normalized capacity supply-demand deviation is 0.2 (200 / 1000), then the service capacity deviation metric = 0.6 × 0.2 + 0.4 × (1 - 0.8) = 0.12 + 0.08 = 0.2, a positive value indicating that the overall service capacity is better than expected.

[0073] The capacity adjustment amount is calculated based on the absolute value of the service capacity deviation metric. The calculation of the capacity adjustment amount considers both the current maximum concurrent processing capacity and the absolute value of the deviation metric, and can be calculated as follows: Capacity Adjustment Amount = Current Maximum Concurrent Processing Capacity × Absolute Value of Deviation Metric × Adjustment Coefficient. The adjustment coefficient is used to control the magnitude of the adjustment, preventing over-adjustment due to short-term fluctuations. Assuming the current microservice instance's maximum concurrent processing capacity is 300 concurrent requests, and the adjustment coefficient is set to 0.5, then the capacity adjustment amount = 300 × 0.2 × 0.5 = 30 concurrent requests.

[0074] Given that the service capacity deviation metric is positive (0.2), indicating that the actual capacity of the service instance exceeds expectations, the maximum concurrent processing capacity corresponding to the service boundary conditions is increased by the capacity correction amount. Therefore, the corrected maximum concurrent processing capacity is 300 + 30 = 330 concurrent requests. If the deviation metric is negative, for example -0.15, the corresponding capacity correction amount of 300 × 0.15 × 0.5 = 22.5 is subtracted. Therefore, the corrected maximum concurrent processing capacity is 300 - 22.5 = 277.5, rounded down to 277 concurrent requests.

[0075] After the calculation is complete, the revised maximum concurrent processing capacity of 330 concurrent requests is updated to the service boundary conditions, achieving adaptive adjustment of the service boundary. This adjustment mechanism enables the microservice system to dynamically adjust the processing capacity boundaries of each service instance based on actual operating conditions, thereby improving resource utilization.

[0076] To ensure the stability of the corrections, upper and lower limits are set for the correction magnitude to avoid excessive adjustments due to short-term fluctuations. For example, the magnitude of a single correction should not exceed 15% of the current capacity. Simultaneously, data from each correction is recorded, correction trends are analyzed, and smoothing is implemented for repeated fluctuations.

[0077] The adaptive correction process is continuous, recalculating the deviation metric and performing corrections at set time intervals, such as every 15 minutes. During peak business periods, the correction interval can be shortened to improve the system's responsiveness to load changes; during stable business periods, the correction interval can be appropriately extended to reduce unnecessary adjustments.

[0078] Through the aforementioned adaptive correction mechanism, microservice systems can intelligently adjust service boundary conditions based on actual operating conditions, improving the overall system elasticity and resource utilization efficiency, thereby better responding to ever-changing business needs.

[0079] This invention relates to an enterprise-level data operation capability scheduling system based on microservices, the system comprising: The first unit is used to extract resource requirement descriptions and service quality constraints from enterprise-level data operation task requests; The second unit is used to parse the capability requirements of the enterprise-level data operation task request based on the resource requirement description, and obtain the capability requirement vector. The third unit is used to obtain the current load status and service boundary conditions and combine them into microservice capability registration information, and to match the capability requirement vector with the microservice capability registration information to obtain a set of candidate microservices. The fourth unit is used to optimize resource utilization, service response latency and load balancing based on the current load status and the service quality constraints, and to combine and optimize the target microservice instances in the candidate microservice set based on the service boundary conditions to obtain a capacity allocation scheme. The target microservice instances and the capacity allocation scheme are combined into a scheduling decision result. The fifth unit is used to issue a capability invocation instruction to the target microservice instance based on the scheduling decision result, and to obtain the execution feedback information returned by the target microservice instance. The sixth unit is used to adaptively correct the service boundary conditions based on the deviation measurement result between the execution feedback information and the capability requirement vector, and to use the corrected service boundary conditions for new scheduling decisions.

[0080] A third aspect of the present invention provides an electronic device, comprising: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the aforementioned method.

[0081] A fourth aspect of the present invention provides a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the aforementioned method.

[0082] This invention can be a method, apparatus, system, and / or computer program product. The computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for performing various aspects of the invention.

[0083] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A microservice-based enterprise-level data operation capability scheduling method, characterized in that, include: Extract resource requirement descriptions and service quality constraints from enterprise-level data operation task requests; Based on the resource requirement description, the capability requirement of the enterprise-level data operation task request is parsed to obtain a capability requirement vector. The current load status and service boundary conditions are obtained and combined into microservice capability registration information. The capability requirement vector is matched with the microservice capability registration information to obtain a set of candidate microservices. Based on the current load status and the service quality constraints, resource utilization, service response latency and load balancing are taken as optimization objectives. Based on the service boundary conditions, the target microservice instances in the candidate microservice set are combined and optimized to obtain a capacity allocation scheme. The target microservice instances and the capacity allocation scheme are combined to form a scheduling decision result. Based on the scheduling decision result, a capability invocation instruction is issued to the target microservice instance, and the execution feedback information returned by the target microservice instance is obtained; Based on the deviation measurement result between the execution feedback information and the capability requirement vector, the service boundary conditions are adaptively corrected, and the corrected service boundary conditions are used for new scheduling decisions.

2. The method according to claim 1, characterized in that, Based on the resource requirement description, the capability requirement of the enterprise-level data operation task request is parsed to obtain the capability requirement vector, which includes: Extract task type identifiers and resource quantification requirements from the resource requirement description; Analyze the association patterns between task type identifiers of historical enterprise-level data operation task requests and the types of microservice capabilities actually invoked, extract association rules, and establish a mapping relationship table between task types and microservice capability types based on the association rules; query the mapping relationship table according to the task type identifier to obtain the set of microservice capability types required by the enterprise-level data operation task request; Based on the demand intensity of each microservice capability type in the enterprise-level data operation task request and the resource quantification requirements, the computing capability requirement component, storage capability requirement component and network capability requirement component corresponding to the microservice capability type are determined respectively, and combined to construct the capability requirement quantification value. The set of microservice capability types and the corresponding quantified capability requirement values ​​are combined to construct the capability requirement vector.

3. The method according to claim 1, characterized in that, The current load status and service boundary conditions are obtained and combined into microservice capability registration information. The capability requirement vector is then matched with the microservice capability registration information to obtain a candidate microservice set, including: Collect the current resource utilization rate and request processing queue length, and combine them to form the current load state; obtain the maximum concurrent processing capacity and the supported microservice capability types, and combine them to form the service boundary conditions; associate the current load state, the service boundary conditions, and the instance identifier of the corresponding microservice instance to obtain the microservice capability registration information; Extract the set of microservice capability types from the capability requirement vector, traverse the microservice capability registration information, and filter out microservice instances whose supported microservice capability types intersect with the set of microservice capability types to form a basic matching microservice set; For each microservice instance in the basic matching microservice set, the load margin is calculated based on the current load status, and the available processing capacity is calculated based on the maximum concurrent processing capacity. When the load margin is greater than the preset load threshold and the available processing capacity meets the corresponding capability requirement quantification value in the capability requirement vector, the microservice instance is included in the candidate microservice set.

4. The method according to claim 1, characterized in that, Based on the current load status and the service quality constraints, the optimization objectives include resource utilization, service response latency, and load balancing. Extract the maximum allowable response latency and the minimum resource utilization requirement from the service quality constraints. Use the maximum allowable response latency as the upper bound of the response latency optimization objective and the minimum resource utilization requirement as the lower bound of the resource utilization optimization objective. For each microservice instance in the candidate microservice set, a predicted resource utilization value is calculated based on the resource occupancy rate in the current load state, and a predicted service response latency value is calculated based on the request processing queue length in the current load state. The deviation between the predicted resource utilization rate and the midpoint value of the resource utilization optimization target is calculated as a resource utilization optimization component. The ratio between the predicted service response latency and the maximum allowable response latency is calculated as a service response latency optimization component. The load distribution variance is calculated based on the current load status of each microservice instance in the candidate microservice set as a load balancing optimization component. The resource utilization optimization component, the service response latency optimization component, and the load balancing optimization component are used as optimization objectives.

5. The method according to claim 1, characterized in that, Based on the service boundary conditions, the target microservice instances in the candidate microservice set are combined and optimized to obtain a capability allocation scheme including: Using the selection status and capacity allocation ratio of microservice instances in the candidate microservice set as decision variables, the maximum concurrent processing capacity in the service boundary conditions as the capacity constraint of each microservice instance, and the capacity requirement satisfaction constraint based on the capacity requirement quantification value in the capacity requirement vector, a combinatorial optimization problem is constructed. The remaining processing capacity is calculated based on the current load status. The ratio of the remaining processing capacity to the maximum concurrent processing capacity is used as the available capacity coefficient. Based on the available capacity coefficient and the matching degree of the microservice capability types supported by the microservice instance and the set of microservice capability types in the capability requirement vector, the overall adaptability of the microservice instance is calculated. Based on the comprehensive fit, the decision variables are solved under the constraints of the combinatorial optimization problem to obtain the capability allocation ratio of each microservice instance in the selected microservice instance combination, and the selected microservice instance combination is determined as the target microservice instance. Based on the quantified value of capability requirements in the capability requirement vector and the capability allocation ratio in the target microservice instance, the capability call volume that each microservice instance should undertake is calculated to form the capability allocation scheme.

6. The method according to claim 1, characterized in that, Based on the scheduling decision result, a capability invocation instruction is issued to the target microservice instance, and the execution feedback information returned by the target microservice instance is obtained, including: Based on the scheduling decision result, a capacity call quantity is generated according to the capacity call share corresponding to each microservice instance, and the identification information, execution parameters and capacity call quantity of the microservice instance are encapsulated into the capacity call instruction, while a scheduling tracing identifier is embedded in the capacity call instruction; Based on the execution feedback information received from the scheduling tracking identifier, the actual number of processes in the execution feedback information is compared with the number of capability calls in the capability call instruction to determine the execution completion rate of the microservice instance, and the execution success status of the microservice instance is determined based on the execution status identifier of the execution feedback information.

7. The method according to claim 1, characterized in that, Based on the deviation measurement result between the execution feedback information and the capability requirement vector, adaptive correction of the service boundary conditions includes: The actual processing quantity and execution time of each microservice instance are extracted from the execution feedback information. Based on the actual processing quantity and the quantified value of the capacity requirement undertaken, the capacity supply and demand deviation is calculated. Based on the ratio of the execution time to the preset execution time standard, the execution efficiency deviation coefficient is calculated. The capacity supply and demand deviation and the execution efficiency deviation coefficient are combined to obtain the service capacity deviation metric; the capacity correction is calculated based on the absolute value of the service capacity deviation metric. When the service capacity deviation metric is negative, the capacity correction is subtracted from the maximum concurrent processing capacity corresponding to the service boundary conditions. When the service capacity deviation metric is positive, the capacity correction is added to the maximum concurrent processing capacity corresponding to the service boundary conditions. The modified maximum concurrent processing capacity is updated to the service boundary conditions to complete the adaptive correction.

8. A microservice-based enterprise-level data operation capability scheduling system, used to implement the method as described in any one of claims 1-7, characterized in that, include: The first unit is used to extract resource requirement descriptions and service quality constraints from enterprise-level data operation task requests; The second unit is used to parse the capability requirements of the enterprise-level data operation task request based on the resource requirement description, and obtain the capability requirement vector. The third unit is used to obtain the current load status and service boundary conditions and combine them into microservice capability registration information, and to match the capability requirement vector with the microservice capability registration information to obtain a set of candidate microservices. The fourth unit is used to optimize resource utilization, service response latency and load balancing based on the current load status and the service quality constraints, and to combine and optimize the target microservice instances in the candidate microservice set based on the service boundary conditions to obtain a capacity allocation scheme. The target microservice instances and the capacity allocation scheme are combined into a scheduling decision result. The fifth unit is used to issue a capability invocation instruction to the target microservice instance based on the scheduling decision result, and to obtain the execution feedback information returned by the target microservice instance. The sixth unit is used to adaptively correct the service boundary conditions based on the deviation measurement result between the execution feedback information and the capability requirement vector, and to use the corrected service boundary conditions for new scheduling decisions.

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

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

Images