Service orchestration method and device and related equipment
By acquiring the state and action space of services, using policy networks and genetic algorithms to generate interface call sequences, and combining LSTM models and graph neural networks for dynamic resource management and anomaly monitoring, the system solves the problems of insufficient flexibility and optimization in existing service orchestration technologies, and achieves efficient and intelligent service orchestration.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-30
- Publication Date
- 2026-04-03
AI Technical Summary
Existing service orchestration technologies lack flexibility, dynamic learning, and optimization capabilities, resulting in an inability to quickly adapt to changes in business needs, unreasonable resource allocation, and insufficient anomaly monitoring capabilities, which affect system performance and security.
By acquiring the state space and action space of the services to be orchestrated, generating interface call information using a policy network, generating target interface call sequences by combining reinforcement learning and genetic algorithms, dynamically adjusting the interface call chain, predicting resource requirements using an LSTM model, and using graph neural networks for anomaly monitoring, dynamic resource management and intelligent orchestration are achieved.
It improves the flexibility and efficiency of the service orchestration process, dynamically optimizes interface calls, enhances response speed and resource utilization, strengthens anomaly monitoring capabilities, and reduces operation and maintenance costs and system risks.
Smart Images

Figure CN121785686A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of information technology, and in particular to a service orchestration method, apparatus and related equipment. Background Technology
[0002] In inter-system service interface calls, there are various application scenarios. For example, Scenario 1: To cope with temporary promotional activities and adapt service interfaces between systems to quickly respond to user needs, the calls between system interfaces often involve excessively long call chains and frequent changes. Scenario 2: Sudden events causing a surge in traffic and uneven distribution of system traffic can lead to system crashes. For example, trending searches may make search engines inaccessible, or excessive requests during business promotional activities may render the system inaccessible.
[0003] Currently, service development in these scenarios can be achieved using service orchestration and integration platforms. However, current service orchestration technologies mainly rely on static configuration and simple rule engines, managing service calls through predefined interface rule orchestration or configuration files. The service orchestration process lacks flexibility and dynamic learning and optimization capabilities. Summary of the Invention
[0004] This application provides a service orchestration method, apparatus, and related equipment, which can solve the technical problems of lack of flexibility and lack of dynamic learning and optimization capabilities in the service orchestration process in related technologies.
[0005] In a first aspect, embodiments of this application provide a service orchestration method, the method comprising:
[0006] Obtain the first state space and the first action space of the service to be orchestrated. The first state space is used to represent the state of the servers and interfaces involved in the service to be orchestrated, and the first action space is used to represent the interface functions and calling relationships of the interfaces involved in the service to be orchestrated.
[0007] Based on the first state space and the first action space, the first call information of the interfaces involved in the service to be orchestrated is generated;
[0008] Based on the first action space, M candidate interface call sequences for the service to be orchestrated are generated, where M is a positive integer;
[0009] Select the target interface call sequence that matches the first call information from the M candidate interface call sequences;
[0010] Based on the target interface call sequence, the link configuration is performed on the service to be orchestrated.
[0011] Secondly, embodiments of this application provide a service orchestration apparatus, the apparatus comprising:
[0012] The first acquisition module is used to acquire the first state space and the first action space of the service to be orchestrated. The first state space is used to represent the state of the servers and interfaces involved in the service to be orchestrated, and the first action space is used to represent the interface functions and calling relationships of the interfaces involved in the service to be orchestrated.
[0013] The first generation module is used to generate the first call information of the interfaces involved in the service to be orchestrated based on the first state space and the first action space.
[0014] The second generation module is used to generate M candidate interface call sequences for the service to be orchestrated based on the first action space, where M is a positive integer;
[0015] The selection module is used to select a target interface call sequence that matches the first call information from the M candidate interface call sequences;
[0016] The configuration module is used to configure the links of the service to be orchestrated based on the target interface call sequence.
[0017] Thirdly, embodiments of this application provide an electronic device, including: a processor, a memory, and a program stored in the memory and executable on the processor, wherein when the program is executed by the processor, it implements the steps of the service orchestration method as described in the first aspect.
[0018] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the service orchestration method as described in the first aspect.
[0019] Fifthly, embodiments of this application provide a computer program product including computer instructions that, when executed by a processor, implement the steps of the service orchestration method as described in the first aspect.
[0020] In this embodiment, a first state space and a first action space of the service to be orchestrated are obtained. The first state space represents the state of the servers and interfaces involved in the service to be orchestrated, and the first action space represents the interface functions and call relationships of the interfaces involved in the service to be orchestrated. Based on the first state space and the first action space, first call information of the interfaces involved in the service to be orchestrated is generated. Based on the first action space, M candidate interface call sequences of the service to be orchestrated are generated, where M is a positive integer. A target interface call sequence matching the first call information is selected from the M candidate interface call sequences. Based on the target interface call sequence, the link configuration of the service to be orchestrated is performed. In this way, the target interface call sequence of the service to be orchestrated can be automatically generated based on the first state space and the first action space of the service to be orchestrated, and the link configuration of the service to be orchestrated can be performed based on the target interface call sequence. Therefore, the automatic orchestration of the service to be orchestrated can be performed by combining the first state space and the first action space of the service to be orchestrated, thereby improving the flexibility of the service orchestration process. Furthermore, since the first state space and the first action space of the service to be orchestrated are different, the target interface call sequence of the service to be orchestrated automatically generated is also different. In this way, the target interface call sequence of the service to be orchestrated can be dynamically adjusted according to the changes in the first state space and the first action space of the service to be orchestrated during the service orchestration process, thereby realizing the dynamic learning and optimization capabilities of the service to be orchestrated during the service orchestration process. Attached Figure Description
[0021] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0022] Figure 1 This is a flowchart of a service orchestration method provided in an embodiment of this application;
[0023] Figure 2 This is a schematic diagram of the architecture for implementing the service orchestration method in the embodiments of this application;
[0024] Figure 3 This is a schematic diagram of the structure of a service orchestration apparatus provided in an embodiment of this application;
[0025] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation
[0026] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0027] In inter-system service interface calls, the following scenarios are common:
[0028] Scenario 1: To cope with temporary promotional activities, adapt service interfaces between systems, and quickly respond to user needs, the calls between system interfaces often involve excessively long call chains and frequent changes. A common solution is to gather developers to perform secondary development based on existing call chains or interfaces, providing interface call logic and interfaces. Over time, this leads to an overabundance of interfaces.
[0029] Scenario 2: Sudden events causing a surge in traffic and uneven system traffic distribution can lead to system crashes. For example, trending topics might make search engines inaccessible, or excessive requests during promotional activities might render the system unusable. Common solutions include configuring traffic splitting through static files and pre-emptively expanding server resources to handle the situation.
[0030] To address the issues described above, service orchestration integration platforms are typically used. Current service orchestration technologies primarily rely on static configuration and simple rule engines. Common solutions include container orchestration platforms (Kubernetes), open-source platforms (Apache Airflow), and serverless workflow orchestration (AWS Step Functions). These solutions usually manage service calls through predefined interface rule orchestration or configuration files, lacking dynamic learning and optimization capabilities.
[0031] It can be seen that the relevant technologies have the following technical defects:
[0032] 1. Static configuration leads to insufficient flexibility.
[0033] Most related technologies rely on static configuration files (such as XML or YAML), requiring users to manually write and maintain these configurations. This approach lacks flexibility in the face of changing business needs and cannot quickly adapt to new service call sequences or logic. Each modification requires redeployment, increasing the complexity of development and operations.
[0034] 2. Lack of dynamic learning and optimization capabilities.
[0035] Existing service orchestration methods are typically based on predefined workflows or rule engines, which cannot be dynamically adjusted according to real-time data. This means that during peak periods or when service request volumes change, the system cannot automatically optimize resource allocation and API call order, leading to performance degradation and resource waste.
[0036] 3. Unreasonable allocation of resources:
[0037] Related technologies typically rely on static load balancing strategies for resource management, failing to provide intelligent predictions based on historical data and real-time request volumes. This can lead to resource shortages during peak demand periods and idle resources during periods of low demand, increasing operational costs.
[0038] 4. Insufficient anomaly monitoring capabilities:
[0039] Existing anomaly monitoring methods often rely on simple rules or thresholds, failing to identify complex anomaly patterns in real time. This results in a slow response from the system to potential security risks, hindering timely action and increasing transaction security vulnerabilities.
[0040] In summary, existing technologies suffer from drawbacks in service orchestration, including a lack of flexibility, lack of dynamic learning, difficulty in managing complexity, unreasonable resource allocation, insufficient anomaly monitoring capabilities, and integration and scalability issues. These problems limit the flexibility and efficiency of service orchestration, necessitating a new service orchestration method to achieve intelligent and dynamic service orchestration to meet the needs of modern distributed business systems.
[0041] The service orchestration method proposed in this application aims to solve the above problems and achieve intelligent, efficient, and dynamic service orchestration.
[0042] It should be noted that the service orchestration method in this application is applied to the service orchestration backend and mainly involves technical fields such as information technology (IT) support, software systems, and machine learning.
[0043] See Figure 1 , Figure 1 This is a flowchart of a service orchestration method provided in an embodiment of this application, such as... Figure 1 As shown, the method includes the following steps:
[0044] Step 101: Obtain the first state space and the first action space of the service to be orchestrated. The first state space is used to represent the state of the servers and interfaces involved in the service to be orchestrated, and the first action space is used to represent the interface functions and calling relationships of the interfaces involved in the service to be orchestrated.
[0045] Step 102: Based on the first state space and the first action space, generate the first call information of the interfaces involved in the service to be orchestrated;
[0046] Step 103: Based on the first action space, generate M candidate interface call sequences for the service to be orchestrated, where M is a positive integer;
[0047] Step 104: Select the target interface call sequence that matches the first call information from the M candidate interface call sequences;
[0048] Step 105: Configure the link for the service to be orchestrated based on the target interface call sequence.
[0049] In step 101, the service to be orchestrated refers to the service that needs to be orchestrated. For example, to cope with promotional activities, a flash sale service can be orchestrated; to support trending searches, an access service can be orchestrated, so that the server can effectively handle a large number of user accesses.
[0050] The first state space refers to the state space of the service to be orchestrated during orchestration, while the first action space refers to the action space of the service to be orchestrated during orchestration. However, the state space and action space of the service to be orchestrated may differ during orchestration due to the expansion or reduction of service instances and the monitoring of abnormal service instances.
[0051] For example, if an additional service instance is deployed due to the expansion of the service instance, the interfaces involved in orchestrating the service to be orchestrated will be different, which will cause changes in the state space and action space.
[0052] For example, as the service to be orchestrated runs, the load and resource utilization of the service instance will change, and the state space of the service to be orchestrated may also change accordingly.
[0053] In other words, the orchestration process of the service to be orchestrated not only includes the initial orchestration, but also, after the initial orchestration of the service to be orchestrated is completed and applied, the changes in the state space and action space may trigger the re-orchestration of the service to be orchestrated in order to adjust the interface call chain of the service to be orchestrated.
[0054] The first state space is used to represent the state of the servers and interfaces involved in the service to be orchestrated, and the construction of the state space is the foundation of service orchestration.
[0055] In some embodiments, the state space can be defined from the following dimensions:
[0056] From the server perspective, the state space can include the server's status, including server load and available resources, as shown in Table 1 below.
[0057] Table 1 Server Status Table
[0058]
[0059] From the perspective of the interface's historical call dimension, the state space can include the interface's historical call records, that is, the previous successful and failed interface calls and response times. Among them, the historical call records are the historical call records of the interfaces involved in the service to be orchestrated, as shown in Table 2 below.
[0060] Table 2 Historical Call Records of the Interface
[0061]
[0062] From the perspective of interface performance status, the state space can include interface response time, such as the current response time and historical response time of each interface, reflecting the interface performance, as shown in Table 3 below.
[0063] Table 3 Interface Performance Status Table
[0064]
[0065] In other words, in some embodiments, the first state space may include the state of the server, the historical call state of the interface, and the performance state of the interface.
[0066] The first action space is used to represent the interface functions and calling relationships of the interfaces involved in the service to be orchestrated. For example, the calling relationship of the interfaces is that interface A1 calls interface B1, interface A1 calls interface B1, and interface B1 can be called by interface A1. The interface function of interface A1 is to obtain business parameter c1 based on parameter a1 and parameter b1.
[0067] In some embodiments, the action space can include all interface functions and the next possible interface call to satisfy the business call. For each interface, all available interfaces can be evaluated to form an action set, which reflects the call relationship between this interface and other interfaces, ensuring flexible selection in a real environment. Table 4 shows a schematic of a defined action space.
[0068] Table 4 Action Space Table
[0069]
[0070] In step 102, the first call information of the interfaces involved in the service to be orchestrated can represent an interface call. For example, the next action of interface A is to call interface B1. The first call information of each interface involved in the service to be orchestrated can be generated.
[0071] In some embodiments, based on the server state and interface performance state in the first state space, the interface call with the best simulated call performance can be selected by monitoring the simulated calls, thereby generating the first call information of the interfaces involved in the service to be orchestrated. This interface call needs to satisfy the interface functions and interface call relationships in the first action space.
[0072] In some embodiments, the first state space and the first action space can be input to the policy network to generate the first invocation information of the interfaces involved in the service to be orchestrated, that is, step 102 specifically includes:
[0073] Based on the first state space and the first action space, the first call information of the interfaces involved in the service to be orchestrated is generated using the policy network;
[0074] The policy network includes policy parameters that indicate desired interface calls in different state spaces. Furthermore, these desired interface calls satisfy the interface functions and interface call relationships in the first action space.
[0075] Among them, Q-learning and Deep Q Network (DQN) can be used to construct the policy network. The state space is different and the expected interface call indicated by the policy parameters is different. The policy parameters are the optimal policy parameters after reinforcement learning. The policy parameters can include the Q-value maximizing motion vector obtained after reinforcement learning. The Q-value maximizing motion vector can indicate the expected interface call of an interface. The expected interface call can maximize the expected reward. The expected reward can be quantified by the call effect evaluation information.
[0076] In some embodiments, before generating the first call information of the interfaces involved in the service to be orchestrated using a policy network based on the first state space and the first action space, the method further includes:
[0077] Acquire training data, which includes the second state space and the second action space of the service samples;
[0078] Based on the second state space and the second action space, the second invocation information of the interfaces involved in the service sample is generated using the policy network;
[0079] Based on the second call information, the call effect evaluation information of the interfaces involved in the service sample is determined;
[0080] Based on the interface transfer relationship under the second call information and the call effect evaluation information, the parameters of the policy network are updated.
[0081] That is, the policy network is trained through reinforcement learning so that the policy network can form the optimal policy, and the interface call output based on the state space can maximize the evaluation information of the call effect.
[0082] In the reinforcement learning process, reward mechanisms can be established, which can be based on the use of performance evaluation information.
[0083] The reward mechanism is crucial to the reinforcement learning process and is designed as follows:
[0084] A reward function can be set, which can calculate the reward based on the call effect evaluation information. The call effect evaluation information can be set as follows:
[0085] Service response time: The shorter the response time, the higher the reward;
[0086] Success rate: The higher the success rate of the call, the higher the reward;
[0087] Resource utilization rate: The efficiency of system resource utilization. The more reasonable the utilization rate, the higher the reward.
[0088] In some embodiments, the reward function can be expressed in the following form:
[0089]
[0090] Where w1, w2, and w3 are weight coefficients, which can be adjusted according to the actual test and verification results; RT(a) is the service response time; SuccessRate(a) is the success rate; ResourceUtilization(a) is the resource utilization rate; s is the service to be orchestrated; and a is the interface call.
[0091] In some embodiments, reinforcement learning techniques can be used to learn by continuously interacting with the environment. The specific steps are as follows:
[0092] Initialization: Construct the policy network, such as using Q-learning and deep Q-networks;
[0093] Action selection (i.e., interface call): In each state space, an action is selected through an ε-greedy strategy (such as a greedy strategy) to obtain the second call information of the interface. ε decays linearly with the number of iterations to ensure a balance between exploration and exploitation.
[0094] Update Q-value: Based on the interface transfer relationship under the second call information and the reward under the second call information (the reward is determined based on the call effect evaluation information under the second call information), update the Q-value function to form the optimal strategy.
[0095] It should be noted that when the reward value of the reward function is relatively large, it indicates that the interface transition relationship generated under the second call information is accurate, and the Q-value function can be updated so that the policy network can generate more accurate interface transition relationships. When the penalty value of the reward function is large, it indicates that the interface transition relationship generated under the second call information is incorrect, and the Q-value function can be updated so that the policy network can correct its interface transition relationship, ultimately forming the optimal policy and obtaining the Q-value maximized motion vector of the Q-value function. This Q-value maximized motion vector can generate the most likely action in the current state space for different state spaces, that is, the most likely interface call. In other words, the Q-value maximized motion vector is used to indicate the expected interface call in different state spaces.
[0096] It should be noted that the second action space serves as a constraint condition for the policy network, ensuring that the generated second call information conforms to the interface functions and interface call relationships in the second action space.
[0097] In step 103, M candidate interface call sequences for the service to be orchestrated can be generated based on the first action space.
[0098] In some embodiments, multiple interface call sequences can be generated based on the first action space, and the interface call sequence with good service effect evaluation information can be selected as the candidate interface call sequence from among these multiple interface call sequences.
[0099] In some embodiments, genetic algorithms can be used to find the optimal solution from multiple interface call sequences, as follows:
[0100] 1) Population initialization.
[0101] Multiple first interface call sequences can be randomly generated based on the first action space (such as interface functions and interface call relationships) to represent different interface combinations. The initial population size can be set according to system requirements.
[0102] 2) Fitness assessment.
[0103] Each genetic individual (i.e., the sequence of interface calls in each iteration) is evaluated to obtain its service performance evaluation information, such as average response time and success rate, in order to determine its fitness value.
[0104] In some embodiments, fitness = w1 * (1 / average response time) + w2 * success rate, where w1 and w2 are weighting coefficients that can be adjusted based on actual test results.
[0105] 3) Select operation.
[0106] Tournament selection can be used to select highly fit individuals from the current population to generate the next generation. The selected individuals will then participate in crossover and mutation operations, maintaining population diversity.
[0107] 4) Crossover and mutation operations.
[0108] Crossover operation: Randomly select parent individuals, crossover to generate new individuals, and generate new interface combinations.
[0109] Mutation operations: Randomly adjust the new individual, such as swapping the order of interface calls, adding new interfaces, and ensuring the exploration of new call configurations.
[0110] 5) Iterative optimization.
[0111] The population is updated through multiple generations of evolution until a preset fitness target or the maximum number of iterations is reached. In each iteration, the individual with the best fitness is selected and fed back to the system so that the interface call sequence can be updated to obtain a candidate interface call sequence.
[0112] Given M candidate interface call sequences, a comprehensive decision can be made to generate a target interface call sequence, which can be the optimal interface call sequence.
[0113] In some embodiments, after processing with reinforcement learning and genetic algorithms, the target interface call order is output. The specific steps are as follows:
[0114] 1) By combining the Q-value obtained from reinforcement learning to maximize the motion vector, the first call information of the interfaces involved in the service to be orchestrated can be obtained.
[0115] 2) Combining genetic algorithms can yield multiple candidate interface call sequences.
[0116] 3) Select the target interface call sequence that matches the first call information from the M candidate interface call sequences.
[0117] In this context, "matching with the first call information" can refer to the existence of an interface call relationship in the candidate interface call sequence that is the same as the first call information. In some embodiments, the interface call sequence that overlaps the most with the interface call relationship in the first call information from the M candidate interface call sequences can be selected as the target interface call sequence.
[0118] This embodiment can generate the target interface call sequence of the service to be orchestrated and configure the link based on the target interface call sequence by configuring the driver module. In step 105, after obtaining the target interface call sequence, the Activiti rule model can be automatically generated to define each approval node, condition branch and interface call link. Based on this information, the operation and maintenance personnel can configure the optimal interface call link with one click on the page.
[0119] In this embodiment, an optimal interface orchestration algorithm is designed, combining reinforcement learning and genetic algorithms to automatically generate a fast and efficient interface call sequence. Combined with the Activiti rule model, it automatically defines each approval node, conditional branch, and interface call chain. Operations personnel can configure the optimal interface call chain with a single click on the page. Furthermore, the configuration of the interface call chain has dynamic learning and adaptive capabilities, enabling real-time optimization of service performance, thereby improving the overall service response speed and resource utilization efficiency. This dynamic learning and optimization capability reduces maintenance costs.
[0120] In some embodiments, after the orchestration service is running, changes in the state space can be dynamically monitored and fed back, and reinforcement learning can be used to adjust the strategy in real time in order to achieve optimal interface link orchestration in a constantly changing environment.
[0121] In some embodiments, after step 105, the method further includes:
[0122] Based on the historical service data of the service to be orchestrated in the past time period, predict the service request volume of the service to be orchestrated in the future time period.
[0123] Based on the monitored operational status data of the service to be orchestrated, the load status of the service instance of the service to be orchestrated is determined;
[0124] Based on the service request volume and the load conditions, the number of service instances of the service to be orchestrated is adjusted, and the service instances include the interfaces involved in the service to be orchestrated.
[0125] Step 101 specifically includes:
[0126] Obtain the first state space and the first action space after adjusting the number of service instances of the service to be orchestrated.
[0127] This embodiment can be implemented through a resource management module, aiming to achieve dynamic resource adjustment through a Long Short-Term Memory (LSTM) network model, the Sidecar pattern, containerization technology, and an agent. Specifically, the LSTM model is used to predict the second service request volume of the service to be orchestrated in a future time period based on the first service request volume of the service in the past time period; the Sidecar pattern is used to collect the runtime status data of the service to be orchestrated; and the containerization technology and the agent are used to adjust the number of service instances of the service to be orchestrated based on the second service request volume and the load conditions.
[0128] The LSTM model needs to be trained before it can be used.
[0129] First, the LSTM model can be used to analyze historical service data. The specific process is as follows:
[0130] Historical service data collection includes information such as service request volume, service response time, and failure rate for each time period.
[0131] Data preprocessing can be used to preprocess historical service data, including noise reduction, normalization, and handling of missing values, to ensure data quality.
[0132] LSTM model construction and design: LSTM models can be used for time series forecasting. LSTM is an improved neural network suitable for problems with long-term dependencies, and can effectively learn the time-series characteristics of service request volume.
[0133] Training and optimization involve dividing historical service data into training and testing sets, training an LSTM model, and evaluating its performance using metrics such as Mean Squared Error (MSE). Model parameters are then adjusted based on the evaluation results to ensure model accuracy.
[0134] The network structure consists of three stacked LSTM layers, each containing 128 hidden units. The LSTM layers use the tanh activation function. Dropout layers with a dropout rate of 0.2 are added between the LSTM layers. A fully connected layer with 64 neurons and the ReLU activation function is connected after each LSTM layer. The output layer contains one neuron and uses a linear activation function.
[0135] The input data for the LSTM model is historical service data, as shown in Table 5 below.
[0136] Table 5 Input data for the LSTM model
[0137]
[0138] The output data of the LSTM model includes the number of service requests for future time periods, such as the number of service requests per hour in the future.
[0139] Predicting future service request volume can be achieved using a trained LSTM model. The output vector containing the service request volume for each hour in the future can then be used as the basis for resource allocation.
[0140] Resources can be dynamically adjusted based on forecast results.
[0141] For example, the prediction results of the LSTM model can be used to determine the service request volume in the future and decide on resource allocation strategies. For instance, if peak demand is predicted, resources can be prepared and allocated in advance. During peak periods, system resources can be dynamically adjusted, such as increasing the number of service instances, to ensure resource availability, improve responsiveness, and guarantee service quality.
[0142] In some embodiments, a Sidecar proxy can be injected alongside each service instance to monitor the performance and request volume of that service instance in real time. This pattern effectively isolates monitoring logic from business logic, improving system maintainability.
[0143] The Sidecar agent continuously collects runtime status data of services to be orchestrated, including metrics such as CPU utilization, memory usage, and current request volume. This data will serve as the basis for subsequent resource adjustments.
[0144] The orchestration service and its Sidecar agent both run within containers to enable rapid deployment, scaling, and management. Containerization technology provides highly flexible and lightweight resource scheduling capabilities.
[0145] Based on monitoring data from the Sidecar agent, the load status of the current service instance can be determined. When the load exceeds a preset threshold, a new service instance will be automatically started to perform horizontal scaling.
[0146] Alternatively, a resource reclamation mechanism can be used. When the number of service requests decreases and the Sidecar agent detects a drop in service load, it can automatically reduce the number of service instances to release unnecessary resources and achieve efficient resource utilization.
[0147] In some embodiments, Agent technology can be used to proactively invoke the Application Programming Interface (API) of the container management platform to achieve container scaling up and down. The Agent can interact with container orchestration tools (such as Kubernetes) through the Representational State Transition (RESTful) API.
[0148] The agent can scale up proportionally to the predicted values, as shown below.
[0149] desired_pods = current_pods * (predicted_requests / current_requests)
[0150] Here, predicted_requests represents the number of future requests predicted by the LSTM model, and current_requests represents the number of current requests.
[0151] The agent can also be scaled up based on a threshold of the predicted value, as shown below.
[0152] if predicted_requests > threshold then
[0153] Increase the number of Pods
[0154] end if
[0155] The threshold is set based on the service capacity and the Service Level Agreement (SLA).
[0156] Capacity can be expanded in advance. The midpoint between the two expansion values mentioned above can be used to expand the capacity 30 minutes before the predicted peak of service requests.
[0157] To ensure the safety of capacity expansion, a safety factor can be selected. The safety factor can be set to 1.2, which multiplies the predicted service request volume by the safety factor to compensate for prediction errors and ensure the accuracy of capacity expansion.
[0158] During peak demand periods, the Agent makes resource adjustment decisions using scaling strategies based on predictions from the LSTM model and real-time monitoring data from the Sidecar agent, thereby achieving dynamic resource adjustment.
[0159] The process for implementing dynamic resource adjustment is as follows:
[0160] 1) Data collection: Collect historical service data and monitor current service request status in real time.
[0161] 2) Monitoring data analysis: Sidecar agent monitors the performance and load of existing services in real time and collects relevant metrics.
[0162] 3) LSTM model prediction: Use the LSTM model to predict future request volume.
[0163] 4) Dynamically adjust decision-making: The agent formulates dynamic resource adjustment strategies based on prediction results and monitoring data.
[0164] 5) Resource scheduling execution: The Agent calls the container management API to expand or shrink service instances to meet current needs.
[0165] 6) Feedback and optimization: Collect dynamically adjusted performance data to form a feedback loop, continuously optimize the LSTM model and monitoring strategy, and improve the accuracy and efficiency of resource management.
[0166] This embodiment combines LSTM model, Sidecar pattern, containerization technology and Agent technology. This resource management module can achieve accurate resource prediction and dynamic adjustment, ensuring that the system can maintain a high level of service and resource utilization even under constantly changing demands.
[0167] Correspondingly, due to the expansion and reduction of service instances, the state space and action space of the service to be orchestrated have changed. The first state space and first action space after the adjustment of the number of service instances of the service to be orchestrated can be obtained, and the configuration driver module can be started to re-orchestrate the service to be orchestrated, so as to adapt to the current resource state.
[0168] In this embodiment, a resource management module is designed. It analyzes historical service data using an LSTM model and employs a sidecar pattern to monitor the performance and request volume of the service instance in real time. This pattern effectively isolates monitoring logic from business logic, improving system maintainability. Using agent technology, based on prediction results from the LSTM model, real-time monitoring data from the sidecar agent, and the highly flexible and lightweight resource scheduling capabilities of containerization, dynamic resource adjustments are achieved. Furthermore, accurate dynamic resource adjustments can be made, and by predicting service request volume using LSTM, peak demand can be effectively addressed, reducing operating costs.
[0169] In some embodiments, the servers to be orchestrated can be monitored in real time to detect anomalies. Following step 105, the method further includes:
[0170] Using the service instances of the service to be orchestrated as nodes and the dependencies between different service instances as edges, a service dependency graph of the service to be orchestrated is constructed. The service instances include the interfaces involved in the service to be orchestrated.
[0171] Based on the service dependency graph and the node running status of the service instance, a graph neural network is used to monitor the service instance of the service to be orchestrated.
[0172] The acquisition of the first state space and first action space of the service to be orchestrated includes:
[0173] Obtain a first state space and a first action space related to the target service instance of the service to be orchestrated, wherein the target service instance is a service instance other than the monitored abnormal service instance among the service instances of the service to be orchestrated.
[0174] This embodiment can be implemented through a monitoring module.
[0175] This monitoring module combines genetic algorithms and graph neural networks (GNNs) to monitor anomalies in services to be orchestrated. By optimizing the anomaly detection model and analyzing dependencies between services, this module enhances the intelligence of anomaly detection.
[0176] Genetic algorithms can be used to optimize the parameters of anomaly detection models. Specifically, anomaly detection models can be constructed using graph neural networks. The basic principle of genetic algorithms is based on the theory of biological evolution. Through operations such as roulette wheel selection, crossover, and mutation, they continuously optimize individuals with high fitness to find the optimal solution.
[0177] Anomaly detection model parameter optimization can be achieved by using the parameters to be optimized in the anomaly detection model (such as thresholds, weights, etc.) as chromosome representations in a genetic algorithm, constructing an initial population, and defining its fitness function by evaluating its performance in anomaly detection.
[0178] Iterative evolution involves selecting individuals with high fitness for crossover and mutation to generate a new generation of the population. Through continuous iteration, the parameters of the anomaly detection model are optimized. By finding the optimal parameters, genetic algorithms can improve the accuracy and precision of anomaly detection.
[0179] Genetic algorithms can efficiently process large-scale data and multi-dimensional parameters, providing a good solution when facing complex anomaly detection models.
[0180] Graph neural networks can be used to model the dependencies between service instances.
[0181] Network architecture construction involves viewing service instances as nodes in a graph and the dependencies between service instances as edges, thus building a service dependency graph. GNNs are then used to capture this graph structure information, thereby understanding the complex interactions between services.
[0182] Through information propagation mechanisms, GNNs can learn the relationships between services and potential anomaly patterns. For example, when the response time of a service increases significantly, GNNs can infer whether the services it depends on are affected.
[0183] The anomaly detection model can identify and predict anomalies in real time. In anomaly behavior identification, GNN analyzes the running status of nodes in the service dependency graph (such as load, response time, etc.) to identify possible abnormal behaviors and supports real-time monitoring. When GNN detects an anomaly in a service's metrics, it can immediately issue an alert.
[0184] Anomaly detection models can learn complex patterns. Through in-depth learning of service interactions using graph neural networks, they can identify complex abnormal transaction patterns, such as chain failures caused by frequent calls to a certain service, thereby enabling multi-level anomaly monitoring.
[0185] In anomaly monitoring, genetic algorithms can be combined with graph neural networks (GNNs) to optimize and learn anomaly detection. Model fusion is possible; the anomaly detection model optimized by the genetic algorithm can be integrated with a GNN-based monitoring system to form a dynamic monitoring system. By optimizing model parameters through genetic algorithms, anomaly behavior can be identified and analyzed in real time based on GNN data.
[0186] The parameter optimization capability of genetic algorithms enhances the accuracy of GNNs in anomaly detection, while deep learning of GNNs provides genetic algorithms with richer training data and scenarios, improving their adaptability.
[0187] By combining genetic algorithms and GNNs, and continuously optimizing parameters and service dependencies, intelligent alerts for abnormal events are achieved. When monitoring detects potential abnormal behavior, the system can accurately identify and respond, notifying operations and maintenance users and improving the efficiency of anomaly handling.
[0188] The process for implementing anomaly monitoring is as follows:
[0189] 1) Data collection: Collect node running status (such as response time, error rate, etc.) as feature data from the service runtime.
[0190] 2) Service dependency modeling: construct a service dependency graph and establish a GNN model.
[0191] 3) Anomaly detection model training: Use a genetic algorithm to optimize the parameter settings of the GNN model to improve the accuracy of anomaly detection.
[0192] 4) Real-time monitoring and identification: GNN analyzes the dependencies between services in real time, monitors feature data, and identifies abnormal trends.
[0193] 5) Alarm generation: Once GNN identifies potential abnormal behavior, it notifies the system administrator through the intelligent alarm mechanism to handle the anomaly in a timely manner.
[0194] 6) Feedback and optimization: The monitoring results are fed back to the genetic algorithm to continue optimizing the parameters, improve the model accuracy, and form a closed loop.
[0195] In this embodiment, by combining genetic algorithms and graph neural networks, the monitoring module achieves an effective fusion of deep learning and optimization in anomaly detection, possessing efficient and timely anomaly identification capabilities and a flexible adjustment mechanism, ensuring that the system can operate stably in complex scenarios.
[0196] Correspondingly, when abnormal service instances are detected, they can be removed during service orchestration to improve its accuracy. This involves obtaining the first state space and first action space related to the target service instance to be orchestrated. The target service instance is any service instance in the service list excluding the detected abnormal service instance. Then, the configuration driver module is started to re-orchestrate the service to be orchestrated, selecting healthy service instances to configure the interface call chain, thus ensuring the accuracy of service orchestration.
[0197] In this embodiment, a monitoring module is designed. By optimizing the parameters of the anomaly detection model and modeling the dependencies between services, a genetic algorithm and a graph neural network are combined to achieve real-time monitoring and identification of system anomalies, ensuring stable system operation in complex scenarios. Furthermore, it enhances security; the anomaly monitoring scheme combining genetic algorithms and graph neural networks can identify complex anomaly patterns in real time, thereby strengthening system security.
[0198] The following is a detailed explanation of the service orchestration method provided in the embodiments of this application using a specific example.
[0199] This application proposes an intelligent service orchestration method, aiming to achieve efficient orchestration, dynamic resource management, and real-time monitoring of various services and interfaces in financial business scenarios involving multi-system interaction through intelligent modular design. The service orchestration method of this application is mainly implemented by three modules, such as... Figure 2 As shown, these are the configuration driver module, resource management module, and monitoring module. These modules collaborate to form an efficient, flexible, and intelligent service orchestration solution.
[0200] The functions of each module are summarized in Table 6 below.
[0201] Table 6: Functional Overview of Each Module
[0202]
[0203] The interaction between modules in the implementation process of the intelligent service orchestration method in this application embodiment is as follows:
[0204] like Figure 2 As shown, label 1 represents the interaction between the operations and maintenance user and the configuration driver module. The user injects all the interface information into the configuration driver module and initializes the configuration interface call chain on the page through the Activiti rule engine. During the operation of the business system, the configuration driver module will use the optimal interface orchestration algorithm to calculate the optimal interface call sequence according to the actual situation, automatically generate the Activiti rule configuration and notify the user. The user can configure the optimal interface call chain with one click on the page.
[0205] Label 2 represents the interaction between the operations and maintenance user and the resource management module. The user configures basic server resources in the container through the resource management module. During the operation of the business system, the resource management module analyzes resource consumption based on actual traffic and automatically expands the capacity by calling the container API through the Agent.
[0206] Labels 3 and 4 represent the interaction between the monitoring module and the configuration driver module and resource management module, respectively. The monitoring module checks the status of the configuration driver module and resource management module in real time, and combines genetic algorithms and graph neural networks to realize the abnormal monitoring of service orchestration calls.
[0207] Label 5 represents the interaction between the monitoring module and the operations and maintenance user. The monitoring module will report any abnormal situations it detects to the operations and maintenance user, who will then handle the abnormalities according to the actual situation.
[0208] The embodiments of this application have broad commercial value.
[0209] For example, by improving operational efficiency through intelligent service orchestration and dynamic resource management, enterprises can significantly improve system response speed and processing capacity, and reduce service call latency. This high-efficiency operational capability can directly improve customer satisfaction and enhance the enterprise's market competitiveness.
[0210] By optimizing resource utilization and dynamic scaling capabilities, businesses can reduce operating costs and automatically adjust resource allocation during peak periods, avoiding resource waste. Effective resource management can reduce infrastructure costs and improve return on investment.
[0211] Enhancing system reliability through real-time monitoring and anomaly detection mechanisms enables the timely identification and handling of potential abnormal behaviors, reducing the risk of system failures and service interruptions. This high reliability strengthens customer trust in the company's services and fosters long-term customer partnerships.
[0212] See Figure 3 , Figure 3 This is a schematic diagram of the structure of a service orchestration apparatus provided in an embodiment of this application, such as... Figure 3 As shown, the service orchestration apparatus 300 includes:
[0213] The first acquisition module 301 is used to acquire the first state space and the first action space of the service to be orchestrated. The first state space is used to represent the state of the servers and interfaces involved in the service to be orchestrated, and the first action space is used to represent the interface functions and calling relationships of the interfaces involved in the service to be orchestrated.
[0214] The first generation module 302 is used to generate first call information of the interfaces involved in the service to be orchestrated based on the first state space and the first action space;
[0215] The second generation module 303 is used to generate M candidate interface call sequences for the service to be orchestrated based on the first action space, where M is a positive integer;
[0216] Selection module 304 is used to select a target interface call sequence that matches the first call information from the M candidate interface call sequences;
[0217] The configuration module 305 is used to configure the link of the service to be orchestrated based on the target interface call sequence.
[0218] Optionally, the first generation module 302 is specifically used for:
[0219] Based on the first state space and the first action space, the first call information of the interfaces involved in the service to be orchestrated is generated using the policy network;
[0220] The policy network includes policy parameters, which are used to indicate the desired interface calls in different state spaces.
[0221] Optionally, the device further includes:
[0222] The second acquisition module is used to acquire training data, which includes the second state space and the second action space of the service samples.
[0223] The third generation module is used to generate second call information of the interfaces involved in the service sample based on the second state space and the second action space using a policy network.
[0224] The first determining module is used to determine the call effect evaluation information of the interface involved in the service sample based on the second call information;
[0225] The update module is used to update the parameters of the policy network based on the interface transfer relationship under the second call information and the call effect evaluation information.
[0226] Optionally, the second generation module 303 is specifically used for:
[0227] Based on the first action space, generate K first interface call sequences, where K is an integer greater than 1;
[0228] Based on the service performance evaluation information of the service to be orchestrated under each first interface call sequence, a fitness evaluation is performed on each first interface call sequence to obtain a fitness value for each first interface call sequence.
[0229] Crossover and mutation operations are performed on the second interface call sequence among the K first interface call sequences, where the fitness value of the second interface call sequence is greater than or equal to that of the other interface call sequences among the K first interface call sequences excluding the second interface call sequence.
[0230] The third interface call sequence obtained after each crossover and mutation operation is determined as a candidate interface call sequence, resulting in the M candidate interface call sequences. The third interface call sequence is the interface call sequence with the largest fitness value among the multiple interface call sequences obtained after the crossover and mutation operation.
[0231] Optionally, the device further includes:
[0232] The prediction module is used to predict the service request volume of the service to be orchestrated in a future time period based on the historical service data of the service in the past time period.
[0233] The second determining module is used to determine the load status of the service instance of the service to be orchestrated based on the monitored running status data of the service to be orchestrated.
[0234] An adjustment module is used to adjust the number of service instances of the service to be orchestrated based on the service request volume and the load conditions. The service instances include the interfaces involved in the service to be orchestrated.
[0235] The first acquisition module 301 is specifically used for:
[0236] Obtain the first state space and the first action space after adjusting the number of service instances of the service to be orchestrated.
[0237] Optionally, the device further includes:
[0238] The building module is used to construct a service dependency graph of the service to be orchestrated, with service instances of the service to be orchestrated as nodes and dependencies between different service instances as edges. The service instances include the interfaces involved in the service to be orchestrated.
[0239] The monitoring module is used to monitor the service instances of the service to be orchestrated based on the node running status of the service dependency graph and service instances using a graph neural network.
[0240] The first acquisition module 301 is specifically used for:
[0241] Obtain a first state space and a first action space related to the target service instance of the service to be orchestrated, wherein the target service instance is a service instance other than the monitored abnormal service instance among the service instances of the service to be orchestrated.
[0242] The service orchestration apparatus 300 can implement all the processes implemented in the above service orchestration method embodiments and achieve the same technical effect. To avoid repetition, it will not be described again here.
[0243] See Figure 4 The figure shows a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Figure 4 As shown, the electronic device 400 includes: a processor 401, a memory 402, a user interface 403, and a bus interface 404.
[0244] Processor 401 is used to read the program from memory 402 and execute the following procedures:
[0245] Obtain the first state space and the first action space of the service to be orchestrated. The first state space is used to represent the state of the servers and interfaces involved in the service to be orchestrated, and the first action space is used to represent the interface functions and calling relationships of the interfaces involved in the service to be orchestrated.
[0246] Based on the first state space and the first action space, the first call information of the interfaces involved in the service to be orchestrated is generated;
[0247] Based on the first action space, M candidate interface call sequences for the service to be orchestrated are generated, where M is a positive integer;
[0248] Select the target interface call sequence that matches the first call information from the M candidate interface call sequences;
[0249] Based on the target interface call sequence, the link configuration is performed on the service to be orchestrated.
[0250] exist Figure 4 In this context, the bus architecture can include any number of interconnected buses and bridges, specifically linking various circuits of one or more processors represented by processor 401 and memory represented by memory 402 together. The bus architecture can also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. Bus interface 404 provides an interface. For different user devices, user interface 403 can also be an interface capable of connecting external or internal devices, including but not limited to keypads, displays, speakers, microphones, joysticks, etc.
[0251] The processor 401 is responsible for managing the bus architecture and general processing, while the memory 402 can store the data used by the processor 401 when performing operations.
[0252] In some embodiments, the processor 401 is further configured to:
[0253] Based on the first state space and the first action space, the first call information of the interfaces involved in the service to be orchestrated is generated using the policy network;
[0254] The policy network includes policy parameters, which are used to indicate the desired interface calls in different state spaces.
[0255] In some embodiments, the processor 401 is further configured to:
[0256] Acquire training data, which includes the second state space and the second action space of the service samples;
[0257] Based on the second state space and the second action space, the second invocation information of the interfaces involved in the service sample is generated using the policy network;
[0258] Based on the second call information, the call effect evaluation information of the interfaces involved in the service sample is determined;
[0259] Based on the interface transfer relationship under the second call information and the call effect evaluation information, the parameters of the policy network are updated.
[0260] In some embodiments, the processor 401 is further configured to:
[0261] Based on the first action space, generate K first interface call sequences, where K is an integer greater than 1;
[0262] Based on the service performance evaluation information of the service to be orchestrated under each first interface call sequence, a fitness evaluation is performed on each first interface call sequence to obtain a fitness value for each first interface call sequence.
[0263] Crossover and mutation operations are performed on the second interface call sequence among the K first interface call sequences, where the fitness value of the second interface call sequence is greater than or equal to that of the other interface call sequences among the K first interface call sequences excluding the second interface call sequence.
[0264] The third interface call sequence obtained after each crossover and mutation operation is determined as a candidate interface call sequence, resulting in the M candidate interface call sequences. The third interface call sequence is the interface call sequence with the largest fitness value among the multiple interface call sequences obtained after the crossover and mutation operation.
[0265] In some embodiments, the processor 401 is further configured to:
[0266] Based on the historical service data of the service to be orchestrated in the past time period, predict the service request volume of the service to be orchestrated in the future time period.
[0267] Based on the monitored operational status data of the service to be orchestrated, the load status of the service instance of the service to be orchestrated is determined;
[0268] Based on the service request volume and the load conditions, the number of service instances of the service to be orchestrated is adjusted, and the service instances include the interfaces involved in the service to be orchestrated.
[0269] Obtain the first state space and the first action space after adjusting the number of service instances of the service to be orchestrated.
[0270] In some embodiments, the processor 401 is further configured to:
[0271] Using the service instances of the service to be orchestrated as nodes and the dependencies between different service instances as edges, a service dependency graph of the service to be orchestrated is constructed. The service instances include the interfaces involved in the service to be orchestrated.
[0272] Based on the service dependency graph and the node running status of the service instance, a graph neural network is used to monitor the service instance of the service to be orchestrated.
[0273] Obtain a first state space and a first action space related to the target service instance of the service to be orchestrated, wherein the target service instance is a service instance other than the monitored abnormal service instance among the service instances of the service to be orchestrated.
[0274] Preferably, the present invention also provides an electronic device 400, including a processor 401, a memory 402, and a computer program stored in the memory 402 and executable on the processor 401. When the computer program is executed by the processor 401, it implements the various processes of the above-described service orchestration method embodiments and achieves the same technical effect. To avoid repetition, it will not be described again here.
[0275] This invention also provides a readable storage medium storing a computer program. When executed by a processor, this computer program implements the various processes of the above-described service orchestration method embodiments and achieves the same technical effects. To avoid repetition, it will not be described again here. The readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.
[0276] This application also provides a computer program product, including computer instructions. When executed by a processor, these computer instructions implement the various processes of the above-described service orchestration method embodiments and achieve the same technical effects. To avoid repetition, they will not be described again here.
[0277] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.
[0278] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.
[0279] In the embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units 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 an indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.
[0280] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of the embodiments of the present invention, depending on actual needs.
[0281] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.
[0282] If the aforementioned functions are implemented as software functional units 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 invention, essentially, 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 invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.
[0283] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.
Claims
1. A service orchestration method, characterized in that, The method includes: Obtain the first state space and the first action space of the service to be orchestrated. The first state space is used to represent the state of the servers and interfaces involved in the service to be orchestrated, and the first action space is used to represent the interface functions and calling relationships of the interfaces involved in the service to be orchestrated. Based on the first state space and the first action space, the first call information of the interfaces involved in the service to be orchestrated is generated; Based on the first action space, M candidate interface call sequences for the service to be orchestrated are generated, where M is a positive integer; Select the target interface call sequence that matches the first call information from the M candidate interface call sequences; Based on the target interface call sequence, the link configuration is performed on the service to be orchestrated.
2. The method according to claim 1, characterized in that, The step of generating the first call information of the interfaces involved in the service to be orchestrated, based on the first state space and the first action space, includes: Based on the first state space and the first action space, the first call information of the interfaces involved in the service to be orchestrated is generated using the policy network; The policy network includes policy parameters, which are used to indicate the desired interface calls in different state spaces.
3. The method according to claim 2, characterized in that, Before generating the first call information of the interfaces involved in the service to be orchestrated using a policy network based on the first state space and the first action space, the method further includes: Acquire training data, which includes the second state space and the second action space of the service samples; Based on the second state space and the second action space, the second invocation information of the interfaces involved in the service sample is generated using the policy network; Based on the second call information, the call effect evaluation information of the interfaces involved in the service sample is determined; Based on the interface transfer relationship under the second call information and the call effect evaluation information, the parameters of the policy network are updated.
4. The method according to claim 1, characterized in that, The step of generating M candidate interface call sequences for the service to be orchestrated based on the first action space includes: Based on the first action space, generate K first interface call sequences, where K is an integer greater than 1; Based on the service performance evaluation information of the service to be orchestrated under each first interface call sequence, a fitness evaluation is performed on each first interface call sequence to obtain a fitness value for each first interface call sequence. Crossover and mutation operations are performed on the second interface call sequence among the K first interface call sequences, where the fitness value of the second interface call sequence is greater than or equal to that of the other interface call sequences among the K first interface call sequences excluding the second interface call sequence. The third interface call sequence obtained after each crossover and mutation operation is determined as a candidate interface call sequence, resulting in the M candidate interface call sequences. The third interface call sequence is the interface call sequence with the largest fitness value among the multiple interface call sequences obtained after the crossover and mutation operation.
5. The method according to claim 1, characterized in that, After configuring the link of the service to be orchestrated based on the target interface call sequence, the method further includes: Based on the historical service data of the service to be orchestrated in the past time period, predict the service request volume of the service to be orchestrated in the future time period. Based on the monitored operational status data of the service to be orchestrated, the load status of the service instance of the service to be orchestrated is determined; Based on the service request volume and the load conditions, the number of service instances of the service to be orchestrated is adjusted, and the service instances include the interfaces involved in the service to be orchestrated. The acquisition of the first state space and first action space of the service to be orchestrated includes: Obtain the first state space and the first action space after adjusting the number of service instances of the service to be orchestrated.
6. The method according to claim 1, characterized in that, After configuring the link of the service to be orchestrated based on the target interface call sequence, the method further includes: Using the service instances of the service to be orchestrated as nodes and the dependencies between different service instances as edges, a service dependency graph of the service to be orchestrated is constructed. The service instances include the interfaces involved in the service to be orchestrated. Based on the service dependency graph and the node running status of the service instance, a graph neural network is used to monitor the service instance of the service to be orchestrated. The acquisition of the first state space and first action space of the service to be orchestrated includes: Obtain a first state space and a first action space related to the target service instance of the service to be orchestrated, wherein the target service instance is a service instance other than the monitored abnormal service instance among the service instances of the service to be orchestrated.
7. A service orchestration apparatus, characterized in that, The device includes: The first acquisition module is used to acquire the first state space and the first action space of the service to be orchestrated. The first state space is used to represent the state of the servers and interfaces involved in the service to be orchestrated, and the first action space is used to represent the interface functions and calling relationships of the interfaces involved in the service to be orchestrated. The first generation module is used to generate the first call information of the interfaces involved in the service to be orchestrated based on the first state space and the first action space. The second generation module is used to generate M candidate interface call sequences for the service to be orchestrated based on the first action space, where M is a positive integer; The selection module is used to select a target interface call sequence that matches the first call information from the M candidate interface call sequences; The configuration module is used to configure the links of the service to be orchestrated based on the target interface call sequence.
8. An electronic device, characterized in that, include: A processor, a memory, and a program stored in the memory and executable on the processor, wherein the program, when executed by the processor, implements the steps of the service orchestration method as described in any one of claims 1 to 6.
9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the service orchestration method as described in any one of claims 1 to 6.
10. A computer program product, characterized in that, It includes computer instructions that, when executed by a processor, implement the steps of the service orchestration method as described in any one of claims 1 to 6.
Citation Information
Cited By
Service processing method and apparatus
CN122204669A