Method and system for deploying micro-services in batches and storage medium

Abstract

The invention provides a method and a system for deploying micro-services in batches and a storage medium. The method comprises the following steps: acquiring attribute dimension information corresponding to each micro-service to be deployed; the attribute dimension information comprises a service importance level, a calling dependency coefficient and a deployment risk level; selecting a core dependency service, and selecting a preorder service from the core dependency service based on the dependency relationship between the micro-services to carry out first batch deployment; after the core dependency service is completely deployed, for the micro-services belonging to the same business importance level in the non-core dependency service, respectively clustering the micro-services of a high deployment risk level and a low deployment risk level to obtain a high risk cluster and a low risk cluster corresponding to each business importance level; and if the deployment of the current batch is completed and the propulsion condition is satisfied, selecting one cluster combination from the obtained high-risk clusters and low-risk clusters by using a multi-target weighted Bayesian optimization algorithm as the deployment of the next batch. According to the invention, micro-services can be dynamically and automatically deployed in batches.

Description

Technical Field

[0001] This invention relates to the field of software engineering technology, and in particular to a method and system for deploying microservices in batches. Background Technology

[0002] With the widespread adoption of microservice architecture, modern applications typically consist of dozens or even hundreds of independent microservices. Deploying all services securely and efficiently when releasing a new version becomes a significant challenge.

[0003] A common implementation approach is static batch deployment of microservices. This approach first requires operations personnel to manually group the microservices to be deployed from the microservice list into fixed deployment batches (e.g., dividing all microservices into three batches). During deployment, each batch is deployed sequentially according to a predefined order. After each batch is deployed, the service monitoring dashboard needs to be manually checked to confirm that core metrics (such as service error rate and response time) are normal before manually triggering the next batch deployment. If an anomaly occurs after a batch deployment, a full rollback is typically required, reverting all deployed services to the previous version.

[0004] However, existing microservice deployment solutions heavily rely on manual judgment and operation in batching and service deployment, resulting in low efficiency, high error rates, and a lack of dynamic adjustment. Specifically, ① there is a lack of flexible adjustment: although batching reduces the scope of a single version change, batching is static and predefined, making it impossible to dynamically adjust based on the real-time operating status of the deployed system (such as resource load and service dependency changes); ② manual batching is unstable: manually defined batches may be unreasonable. For example, manual deployment may result in high-risk services being grouped into the same batch and deployed centrally, leading to a large impact if it fails; ③ the judgment of advancement conditions is inaccurate: whether core indicators meet the advancement conditions depends on manual judgment, which may result in delays or misjudgments.

[0005] Therefore, there is an urgent need for a method for dynamically deploying microservices in batches, which can realize the dynamic and automated division of deployment batches and the intelligent advancement of the deployment process. Summary of the Invention

[0006] In view of this, embodiments of the present invention provide a method and system for deploying microservices in batches, which can overcome the shortcomings of manual deployment and realize the dynamic and automated division of deployment batches and the intelligent advancement of the deployment process.

[0007] One aspect of the present invention provides a method for deploying microservices in batches, the method comprising the following steps: Retrieve the attribute dimension information and the corresponding new version image for each microservice in the list of services to be deployed; the attribute dimension information for each microservice includes the business importance level, call dependency coefficient, and deployment risk level of the microservice. Select core dependency services from the microservices with the highest business importance that meet the set dependency conditions, and select predecessor services from the core dependency services based on the dependency relationships between microservices. Use the new version image of the predecessor service to deploy the first batch of services to be deployed. If the core dependent services are not fully deployed, based on the dependencies between microservices, the new version images corresponding to each undeployed microservice in the core dependent services are deployed in separate batches. If the core dependent services are fully deployed, for microservices in non-core dependent services that belong to the same business importance level, microservices with high deployment risk level and microservices with low deployment risk level are clustered separately to obtain high-risk clusters and low-risk clusters corresponding to each business importance level. After the current batch deployment is completed, cluster resource status information and deployment feedback information are obtained in real time from the deployed service system. If the conditions for advancement are met based on the cluster resource status information and / or deployment feedback information, multiple cluster combinations are selected from the obtained high-risk and low-risk clusters according to the preset cluster combination strategy. Then, a multi-objective weighted Bayesian optimization algorithm is used to select one cluster combination as the next batch for deployment. This process continues until all microservices in the list of services to be deployed are deployed. The objective function value of the multi-objective weighted Bayesian optimization algorithm is determined based on attribute status information and cluster resource status information.

[0008] In some embodiments of the present invention, the dependency condition is set such that the call dependency coefficient corresponding to the microservice is not less than a set dependency threshold. From the microservices with the highest business importance, select the core dependency services whose call dependency coefficients meet the defined dependency conditions, including: The Tarjan algorithm is used to identify strongly connected components from the dependencies between microservices with the highest business importance, and microservices with call dependency coefficients not less than a set dependency threshold are selected as core dependent services from the strongly connected components.

[0009] In some embodiments of the present invention, microservices with high deployment risk levels and microservices with low deployment risk levels are clustered, including: Density peak clustering is performed on microservices with high deployment risk levels, and hierarchical clustering is performed on microservices with low deployment risk levels. After clustering is completed, the method further includes: For each microservice within a high-risk or low-risk cluster, the contour coefficient corresponding to the microservice is determined based on the distance between the microservice and other microservices within its own cluster, as well as the distance between the microservice and all microservices within its nearest neighbor cluster. Based on the silhouette coefficients of microservices using the same clustering algorithm, the silhouette coefficients corresponding to the clustering algorithm are obtained. If the silhouette coefficients corresponding to the clustering algorithm meet the set clustering constraints, the clustering is verified to be effective; otherwise, the clustering parameters are adjusted and the clustering is re-clustered.

[0010] In some embodiments of the present invention, the preset cluster combination strategy includes: A high-risk cluster is deployed as a batch; low-risk clusters to which microservices of high business importance belong are deployed as a batch; and for low-risk clusters to which microservices of low business importance belong, a single cluster or any combination thereof is deployed as a batch.

[0011] In some embodiments of the present invention, the objective function value of the multi-objective weighted Bayesian optimization algorithm is determined based on attribute dimension information and cluster resource status dimension information, including: the objective function value of the multi-objective weighted Bayesian optimization algorithm is obtained by weighting the business adaptability score, deployment risk score, and resource usage score; wherein, the business adaptability score is determined based on the business importance level and call dependency coefficient of the microservice in the next batch of deployment, the deployment risk score is determined based on the deployment risk level of the microservice in the next batch of deployment and the failure probability value predicted by using historical deployment failure data of microservices, and the resource usage score is determined based on cluster resource status dimension information.

[0012] In some embodiments of the present invention, the weights corresponding to the service compatibility score, deployment risk score, and resource usage score for the next batch of deployment are obtained in the following manner: Based on real-time acquired cluster resource status and deployment feedback information, resource time-series data and feedback time-series data are generated respectively; the correlation between resource time-series data and feedback time-series data is calculated, and the weights corresponding to resource usage scores are adjusted based on the correlation. The entropy weight method is used to calculate the weights corresponding to the business adaptability score and the deployment risk score.

[0013] In some embodiments of the present invention, for each batch deployment, the number of microservices distributed to the deployed service system in a single deployment is determined based on the baseline service scale, cluster resource status dimension information, and deployment feedback dimension information; wherein, the baseline service scale is a range value determined based on the business importance level.

[0014] In some embodiments of the present invention, the order in which new version images of microservices are distributed for each batch deployment is determined in the following manner: By using the Kahn algorithm and the dependencies between microservices in this batch of deployments, the dependency hierarchy order of microservices in this batch of deployments is determined; For the same dependency level, microservices are arranged in ascending order of deployment risk score to obtain a deployment priority queue for microservices, which is used as the deployment order for the new version image of the corresponding microservice. The deployment risk score is determined based on the deployment risk level of the microservice in the next batch of deployments and the failure probability value predicted by using historical deployment failure data of the microservice.

[0015] Another aspect of the present invention provides a batch deployment microservice system, including a processor, a memory, and a computer program / instructions stored in the memory, wherein the processor is used to execute the computer program / instructions, and when the computer program / instructions are executed, the system implements the steps of the method described in any of the above embodiments.

[0016] Another aspect of the present invention provides a computer-readable storage medium having a computer program / instructions stored thereon, which, when executed by a processor, implement the steps of the method described in any of the above embodiments.

[0017] The method and system for batch deployment of microservices proposed in this invention determine the core dependency services to be deployed first based on the attribute dimension information corresponding to the microservices. When deploying non-core dependency services, the system uses real-time cluster resource status and deployment feedback information obtained from the systems of the deployed services to determine the deployment batches using a multi-objective weighted Bayesian optimization algorithm. This application achieves dynamic and automated batch division and intelligent advancement of the deployment process by collecting the real-time operating status of the systems of the deployed services, reducing manual intervention and improving deployment efficiency and security.

[0018] Additional advantages, objects, and features of the invention will be set forth in part in the description which follows, and will also become apparent in part to those skilled in the art upon studying the text, or may be learned by practice of the invention. The objects and other advantages of the invention can be realized and obtained by means of the structures specifically pointed out in the description and drawings.

[0019] Those skilled in the art will understand that the objectives and advantages achievable with the present invention are not limited to those specifically described above, and that the above and other objectives achievable with the present invention will become clearer from the following detailed description. Attached Figure Description

[0020] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, are not intended to limit the scope of the invention. In the drawings: Figure 1 This is a schematic diagram of the process of deploying microservices in batches according to one embodiment of the present invention.

[0021] Figure 2 This is a schematic diagram of the process of deploying microservices in batches according to another embodiment of the present invention. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the embodiments and accompanying drawings. Here, the illustrative embodiments and descriptions of this invention are used to explain the invention, but are not intended to limit the invention.

[0023] It should also be noted that, in order to avoid obscuring the invention with unnecessary details, only the structures and / or processing steps closely related to the solution according to the invention are shown in the accompanying drawings, while other details that are not closely related to the invention are omitted.

[0024] It should be emphasized that the term "including / comprises" as used herein refers to the presence of a feature, element, step, or component, but does not exclude the presence or addition of one or more other features, elements, steps, or components.

[0025] In the following description, embodiments of the invention will be illustrated with reference to the accompanying drawings. In the drawings, the same reference numerals represent the same or similar parts, or the same or similar steps.

[0026] Existing microservice deployment schemes use static, predefined batches, which cannot dynamically adjust based on the real-time operational status of the deployed system (such as changes in resource load and service dependencies), and risk control is rudimentary. Therefore, this application proposes a method for dynamically batching microservice deployment. This method can collect the operational status of the deployed services in real time and use a multi-objective weighted Bayesian optimization algorithm to select the optimal cluster combination as the next batch for deployment. This application enables dynamic and automated batch partitioning and intelligent advancement of the deployment process, reducing manual intervention and improving deployment efficiency and security.

[0027] This application designs a deployment controller to execute a dynamic deployment method. Through real-time feedback and a dynamic allocation strategy, a closed-loop automated deployment control scheme is formed. The deployment controller consists of three modules for information collection: a service awareness module, a resource monitoring module, and a health feedback module; a dynamic decision-making module for executing the dynamic allocation strategy; and a deployment execution module for executing microservice deployment. These modules work together to achieve dynamic batch deployment of microservices. Specifically, the service awareness module obtains attribute dimension information for all microservices in the list of services to be deployed; the resource monitoring module obtains resource status dimension information of cluster nodes from the system of the deployed services (hereinafter referred to as the deployed system); and the health feedback module obtains feedback parameters (i.e., deployment feedback dimension information) of deployed microservices. The dynamic decision-making module is the core of the deployment controller, determining the next batch of microservices to be deployed through a dynamic deployment strategy path optimized by core dependencies, clustering, and Bayesian methods. The deployment execution module then deploys microservices sequentially according to the number of microservices deployed in a single batch and the order in which the new version images of the corresponding microservices are distributed.

[0028] The flowchart of the batch deployment method for microservices proposed in this application is shown below. Figure 1 As shown, it includes steps S110 to S140.

[0029] Step S110: Obtain the attribute dimension information (hereinafter referred to as microservice attribute dimension information) and the corresponding new version image for each microservice in the list of services to be deployed.

[0030] The service awareness module and the resource monitoring module work in parallel. After the first batch of services in the list to be deployed is completed, the resource monitoring module will continuously collect information on the status of cluster resources. After each batch of services is deployed to the deployed system through the deployment controller, the health feedback module can be started and collect deployment feedback information from the deployed system in real time.

[0031] In some embodiments of the present invention, the microservice attribute dimension information, cluster resource status dimension information, and deployment feedback dimension information specifically include the following indicators: Microservice attribute dimensions include metrics such as the microservice's business importance level, call dependency coefficient, and deployment risk level. The business importance level is a static parameter configured when configuring the microservice (it can also be dynamically updated using Nacos parameterization, synchronizing with the business configuration center within 50ms after a change). It indicates the core importance level of the corresponding business within the microservice and can be quantified based on the rule that higher core importance levels correspond to higher business importance levels. For example, the core importance level of a business can be divided into four levels: Category A (core business), Category B (important business), Category C (general business), and Category D (general business), thus ranking them by core importance level as: Category A (core business) > Category B (important business) > Category C (general business) > Category D (general business). The call dependency coefficient is used to indicate the number and depth of downstream microservices that a microservice depends on. It can be obtained from the service call chain topology diagram (located in the service registry) formed when the service dependency analysis tool parses the microservice configuration. The call dependency coefficient can be quantified as follows: the call dependency coefficient is quantized into an integer from 1 to 10. For every 3 additional downstream microservices that depend on the microservice or for every 1 additional layer of dependency depth, the call dependency coefficient of the microservice (the initial value can be set to 1) increases by 1, and the call dependency coefficient will not increase further after reaching the maximum value of 10. The service dependency analysis tool can be built based on SkyWalking and K8s ServiceMap, or it can be built using service mapping and visualization tools (such as Ivanti Neurons for Service Mapping). This invention is not limited to these. The deployment risk level is a risk assessment result based on the service's historical deployment failure records (also known as service historical deployment failure data). These records are extracted from the deployment ELK logs (i.e., the ELK Stack formed by Elasticsearch, Logstash, and Kibana). The deployment risk level can be quantified as follows: Deployment risk levels are divided into 1 to 5. If the microservice has no failure records in the past 3 months, its deployment risk level is level 1. If a failure occurs in the past 3 months, the deployment risk level increases by 1 level, and will not increase further after reaching level 5. The quantification methods for each indicator in the microservice attribute dimension information mentioned above are merely examples, and this invention is not limited to them.

[0032] Cluster resource status information includes metrics such as CPU idle rate, memory usage, and inter-node communication bandwidth utilization for the cluster nodes where microservices will be deployed. CPU idle rate indicates the average percentage of idle CPU resources in the target cluster, memory usage indicates the average percentage of memory used, and bandwidth utilization indicates the real-time utilization of inter-node communication bandwidth. For example, it can be used to monitor the bandwidth of links pulling new image versions, and Grafana tools can be used for data visualization.

[0033] Deployment feedback includes metrics such as the startup success rate of the previous batch of deployments, the health of deployed microservices, and the call success rate (i.e., business interface availability) of the corresponding business interfaces of the microservices. The startup success rate indicates the ratio of the number of successfully started microservice instances (referring to the new version image of the microservice running on the deployed system) to the total number of deployments for the previous batch. This can be obtained immediately after each batch of deployments is completed. Service health indicates the health of deployed microservices and can be quantified as follows: if the microservice is alive or ready at each check, the service health score increases by 20 points; otherwise, it decreases by 20 points, thus quantifying it into an evaluation result of 0-100 points. Business interface availability indicates the success rate of calls to the interfaces corresponding to the microservices, and is statistically analyzed through the traffic-controlled API gateway (located on the deployed system; all access requests must pass through the traffic-controlled API gateway to reach the backend microservices). Furthermore, to reduce computational complexity, data can be collected only for Category A core business and Category B important business.

[0034] As an example, the dynamic deployment method proposed in this application can be executed using a DevOps platform. Since the monitoring tools and microservice instances are on the same intranet segment, the resource monitoring module can directly collect cluster resource status parameters in real time from the DevOps platform's monitoring system (such as the monitoring component Prometheus) (the sampling period can be set to 200ms), offering advantages of low latency and high security. The health feedback module can also utilize the DevOps platform's Liveness Probe and Readiness Probe to detect (the detection period can be set to 100ms) the survival duration and readiness level of microservices, thereby obtaining the health status of deployed microservices; it can utilize self-developed gateway services or open-source tools (Gateway, Zuul) for real-time statistics, and the data collection period from the traffic control API gateway can be set to 500ms. For example, the service awareness module can be developed based on Java, deployed as a K8s Deployment (with 3 replicas ensuring high availability), obtain service registration information and call chain data by calling the Nacos Open API, parse it, and generate service attribute parameters; it synchronizes the business importance configuration with the business configuration center (Apollo) via an HTTP interface. For example, the resource monitoring module can integrate Prometheus and Grafana. Prometheus is deployed as a StatefulSet (2 replicas), collecting cluster node CPU and memory data through the Node Exporter, container resource usage through the Kubernetes API, and network bandwidth data through a network monitoring agent deployed on each node, with a data retention period of 7 days. Another example is the health feedback module, which can be integrated into each microservice instance by developing a custom Kubernetes probe plugin, reporting service health in real time via an HTTP interface; the availability of core service interfaces is statistically analyzed through the API gateway (Kong), aggregating data every 500ms. Furthermore, modules communicate internally through Kubernetes Services, and core parameters and decision results are asynchronously synchronized via a message queue (RocketMQ), ensuring decoupling between modules and reliable communication.

[0035] In addition, all data collected by the service awareness module, resource monitoring module, and health feedback module can be aggregated into the parameter cache pool of the dynamic decision-making module, and the cache update delay is set to no more than 200ms to ensure the timeliness and accuracy of the decision-making basis.

[0036] The dynamic allocation strategy does not rely on fixed rules. Instead, it is based on real-time perception of three dimensions: microservice attribute information, cluster resource status information, and deployment feedback information. It uses a multi-objective weighted Bayesian optimization algorithm to generate the next batch of deployments, ensuring that batch decisions align with actual deployment scenarios. The dynamic allocation strategy includes the execution flow of steps S120–S140.

[0037] Step S120: Select the core dependency services from the microservices with the highest business importance level that meet the set dependency conditions, and select the predecessor services from the core dependency services based on the dependency relationship between microservices. Use the new version image of the predecessor service to deploy the first batch of services to be deployed.

[0038] In some embodiments of the present invention, the dependency condition can be set as follows: the call dependency coefficient corresponding to the microservice is not less than a set dependency threshold (e.g., call dependency coefficient ≥ 8). Selecting core dependent services whose call dependency coefficients meet the set dependency condition from the microservices with the highest business importance includes: using the Tarjan algorithm to identify strongly connected components from the dependency relationships between the microservices with the highest business importance, and selecting microservices with call dependency coefficients not less than the set dependency threshold from the strongly connected components as core dependent services. The dependency relationships between the microservices with the highest business importance can be obtained by constructing a dependency topology graph (e.g., a directed acyclic graph) based on the service call chain topology graph and the parsing results.

[0039] More specifically, the preceding service selected from the core dependent services based on the dependency relationships between microservices in the core dependent services (which can be obtained through the service call chain topology diagram) refers to an independent service that does not depend on other microservices (there may be other downstream microservices that depend on this independent service). The new version image corresponding to the preceding service is deployed to the deployed system as an independent base batch.

[0040] As an example, this application can be designed to make the preceding service the first service batch in the list of services to be deployed. The trigger condition is that the first batch of deployments is executed immediately when the deployment task starts. For other batches after the first batch of deployments, a condition-triggered approach can be adopted: if the previous batch of deployments is completed, and the advancement conditions are met based on one or more indicators in the real-time cluster resource status dimension information and / or one or more indicators in the deployment feedback dimension information (such as stable health, CPU idle rate fluctuation exceeding 15%, and / or service health score below 60 points, and / or business interface availability dropping below 95%), then the current batch of deployments will be executed, thereby avoiding deployment delays or blind advancements and ensuring timely response to abnormal scenarios. In addition, if the deployed system has sufficient resources, each microservice in the preceding service can also be treated as a separate batch and deployed batch by batch according to dependencies.

[0041] Step S130: When the core dependency service is not fully deployed (at this time, the number of microservices contained in the preceding services is less than the number of microservices contained in the core dependency service), based on the dependency relationships between the undeployed microservices in the core dependency service, deploy the new version images corresponding to each undeployed microservice in the core dependency service as separate batches (e.g., deploy batch by batch according to dependency relationships); when the core dependency service is fully deployed, for microservices belonging to the same business importance level in the non-core dependency service, cluster the microservices with high deployment risk level and the microservices with low deployment risk level respectively, so as to obtain high-risk clusters and low-risk clusters corresponding to each business importance level.

[0042] More specifically, this application divides the list of services to be deployed into two categories: core dependent services and non-core dependent services. With all core dependent services deployed, the dynamic decision-making module can, based on the collected three-dimensional information, divide the non-core dependent services in the microservice list into multiple clusters using a clustering method, and calculate the optimal deployment decision combination based on a multi-objective weighted Bayesian optimization algorithm. Here, the high and low deployment risk levels of microservices are relative, and this application does not specifically limit the method of classifying these levels. For example, if the deployment risk level is quantified into 1 to 5 levels, then microservices with a deployment risk level ≥ 3 can be considered high-risk microservices, and microservices with a deployment risk level ≤ 2 can be considered low-risk microservices.

[0043] Assuming that the non-core dependent services in this application include microservices corresponding to core business (Category A), important business (Category B), general business (Category C), and general business (Category D, which can be referred to as Category A services, Category B services, Category C services, and Category D services, respectively), then clustering is performed on the microservices with high deployment risk levels (e.g., microservices with deployment risk level ≥ 3) and microservices with low deployment risk levels (e.g., microservices with deployment risk level ≤ 2) within Category A services to obtain high-risk clusters and low-risk clusters corresponding to Category A services; similarly, high-risk clusters and low-risk clusters corresponding to Category B, Category C, and Category D services can be obtained.

[0044] In some embodiments of the present invention, different clustering methods can be used for microservices with different deployment risk levels. For example, density peak clustering (DPC) can be used to achieve separate batching for microservices with high deployment risk levels, while hierarchical clustering (HC) can be used to achieve merged clustering for microservices with low deployment risk levels. Moreover, after the clustering is completed, the method further includes: for each microservice in each high-risk cluster or low-risk cluster, determining the silhouette coefficient corresponding to the microservice based on the distance between the microservice and other microservices in its own cluster and the distance between the microservice and all microservices in its nearest neighbor cluster; obtaining the silhouette coefficient corresponding to the clustering algorithm based on the silhouette coefficients corresponding to microservices using the same clustering algorithm (such as DPC or HC); if the silhouette coefficient corresponding to the clustering algorithm satisfies the set clustering constraints, the clustering is verified to be effective; otherwise, the clustering parameters are adjusted and the clustering is re-dense to obtain the corresponding high-risk clusters or low-risk clusters again.

[0045] As an example, the clustering constraint is set such that the silhouette coefficient corresponding to the clustering algorithm is not less than a set silhouette threshold (the clustering constraint can be...). (This invention is not limited to this). The process of verifying the rationality of group division using contour coefficients is as follows: For the Each microservice sample, and its corresponding silhouette coefficient The following formula is used for calculation: ; in, Indicates the first The average distance from a microservice sample to other microservice samples in the same cluster is used to measure the compactness within the cluster. Indicates the first The average distance from a microservice sample to all microservice samples in its nearest cluster is used to measure the separation within the cluster. The range of values ​​for can be: , The closer to 1, the better the clustering effect.

[0046] Calculate all microservice samples clustered using the same clustering algorithm (assuming the number is ). The average of the silhouette coefficients corresponding to the clustering constraints is used as the validation metric. If the validation metric satisfies the clustering constraints, the clustering is considered effective; otherwise, the parameters of the clustering algorithm are readjusted, and these microservice samples are re-clustered until the validation metric satisfies the clustering constraints. The formula for calculating the validation metric is: .

[0047] Step S140: After the current batch deployment is completed, and the conditions for advancement are met based on the cluster resource status dimension information and / or deployment feedback dimension information, select multiple cluster combinations from the obtained high-risk and low-risk clusters according to the preset cluster combination strategy, and use a multi-objective weighted Bayesian optimization algorithm to select one cluster combination from the selected cluster combinations as the next batch deployment; until all microservices in the service list to be deployed are deployed.

[0048] From the start of the first batch of deployments until all microservices in the list of services to be deployed are deployed, cluster resource status information and deployment feedback information can be obtained in real time from the systems of the deployed services after the current batch of deployments is completed. When the current batch of deployments is determined to be completed based on conditional triggering and the advancement conditions are met, multiple cluster combinations can be obtained based on preset cluster combination strategies, and the optimal cluster combination can be selected as the next batch of deployments using a Bayesian optimization algorithm.

[0049] As an example, to ensure the stable deployment of microservices, this application designs a pre-defined cluster combination strategy, which includes: deploying a high-risk cluster as a batch; deploying low-risk clusters to which microservices with high business importance (such as Class A services and Class B services) belong as a batch; and deploying individual or arbitrary combinations of low-risk clusters to which microservices with low business importance (such as Class C services and Class D services) belong as a batch.

[0050] In some embodiments of the present invention, the objective of Bayesian optimization is to find the optimal deployment decision combination based on the objective function under the constraint of the cluster combination strategy. The objective function value of the multi-objective weighted Bayesian optimization algorithm is determined based on attribute dimension information and cluster resource state dimension information, including: the objective function value of the multi-objective weighted Bayesian optimization algorithm is obtained by weighting the business adaptability score, deployment risk score, and resource usage score; wherein, the business adaptability score is determined based on the business importance level and call dependency coefficient of the microservice in the next batch of deployment, the deployment risk score is determined based on the deployment risk level of the microservice in the next batch of deployment and the failure probability value predicted by using historical deployment failure data of microservices, and the resource usage score is determined based on the cluster resource state dimension information. Specifically, the objective function of multi-objective Bayesian optimization can be expressed as: ; in, , and These represent the target priority coefficients for business compatibility score, resource utilization score, and deployment risk score, respectively, and can be set. Or adjust according to the core business level. , and These represent the weights corresponding to the business compatibility score, resource usage score, and deployment risk score, respectively. , and These represent the business compatibility score, resource usage score, and deployment risk score, respectively. The business importance level and service call dependency coefficient of microservices will be determined based on the next batch of deployments. It can be determined based on the failure probability value and the deployment risk level. The failure probability value is determined based on the collected CPU idle rate, memory usage, and bandwidth utilization. It can be obtained as follows: Input historical deployment failure records into a pre-trained failure probability prediction model (e.g., trained via logistic regression), and output the failure probability value for each service; then, after normalizing the deployment risk level and the failure probability value, perform a weighted calculation to obtain the final failure probability value. For example, business compatibility scores, resource usage scores, and deployment risk scores can all be quantified into values ​​within the range of [0,1] using a uniform method, such as... These are the membership function values ​​for CPU idle rate, memory utilization, and bandwidth utilization.

[0051] Furthermore, for the next batch of deployments, the weights corresponding to the business adaptability score, deployment risk score, and resource usage score are obtained through the following methods: Based on real-time acquired cluster resource status dimension information and deployment feedback dimension information, resource time-series data and feedback time-series data are formed respectively; the correlation (such as calculating the Pearson correlation coefficient of the two sets of time-series data) and correlation strength between the resource time-series data and feedback time-series data are calculated, and the weights corresponding to the resource usage score are adjusted based on the correlation and correlation strength; the weights corresponding to the business adaptability score and deployment risk score are calculated using the entropy weight method (since the higher the weight of a dimension, the greater its impact on the objective function, this application can design an entropy weight method to adaptively adjust the weight ratio to adapt to dynamic changes in the system), and this application will not elaborate on the existing entropy weight method calculation process here. Among them, adjusting the weights corresponding to the resource usage score based on the correlation and correlation strength includes: if it is negatively correlated, the current weight corresponding to the resource usage score is reduced according to the set scaling factor; if it is positively correlated, the current weight corresponding to the resource usage score is increased according to the set scaling factor. For example, by filtering feedback and resource status information from the last 30 deployments of a specific microservice (such as a payment service), two sets of time-series data can be extracted: a health time-series array V and a memory utilization time-series array M. The Pearson correlation coefficient ρ(V,M) between the two sets of data can be calculated. If ρ(V,M) ≤ -0.7, it can be determined to be a strong negative correlation (i.e., the higher the memory utilization, the lower the service health), and therefore the weight corresponding to the resource utilization score can be appropriately reduced. Different scaling factors can be selected for different correlation strengths.

[0052] In some embodiments of the present invention, each batch deployment typically includes multiple microservices. Since these microservices may not be deployed together during the batch deployment, the number of microservices deployed to the system in a single batch needs to be limited. For each batch deployment, the number of microservices deployed to the system in a single batch can be determined based on a baseline service size, cluster resource status information, and deployment feedback information; wherein the baseline service size is a range determined based on the importance level of the business.

[0053] As an example, this application designs a nonlinear scaling function based on a two-factor dynamic scaling model to achieve intelligent control of single-batch deployment scale. The function uses the baseline proportion corresponding to the business importance level as the base factor, combined with the resource elasticity coefficient and deployment feedback confidence level as adjustment factors. ; in, The number of microservices deployed to the system in a single distribution. Based on the baseline deployment scale, and These are the resource adjustment coefficient (which can be -0.5 to 0.2) and the feedback adjustment coefficient (which can be -0.4 to 0.1). Assess the current resource elasticity score. To deploy feedback confidence.

[0054] Baseline deployment scale These are range values ​​set based on the importance level of the business. The higher the importance level of the business, the smaller the baseline deployment scale. For example, if a batch of microservices deployed corresponds to a Class A core business, then 5% to 10% of the service instances will be deployed in a single baseline deployment. If a batch of microservices deployed corresponds to a Class B important business, then 15% to 25% of the service instances will be deployed in a single baseline deployment. If a batch of microservices deployed corresponds to a Class C or D general business, then 30% to 50% of the service instances will be deployed in a single baseline deployment.

[0055] Resource resilience score It can be determined based on cluster resource status parameters. The value of determines the deployment speed. A three-dimensional threshold matrix is ​​constructed based on CPU idle rate, memory utilization, and network bandwidth utilization, and fuzzy logic reasoning (such as Mamdani fuzzy reasoning) is used to calculate the resource elasticity score R. For example, regarding the CPU idle rate dimension in the threshold matrix, a CPU idle rate ≥70% is considered sufficient resources, triggering an increase in scale; a CPU idle rate ≤30% is considered strained resources, triggering a decrease in scale; and a CPU idle rate of 30%~70% is considered balanced resources with no basic elasticity. Regarding the memory utilization dimension in the threshold matrix, a memory utilization rate ≤50% is considered sufficient resources, triggering an increase in scale; a memory utilization rate ≥80% is considered strained resources, triggering a decrease in scale; and a memory utilization rate of 50%~80% is considered balanced resources with no basic elasticity. Regarding the network bandwidth utilization dimension in the threshold matrix, a network bandwidth utilization rate ≥90% is considered congested, forcing a decrease in scale (prioritizing the pull of new version images); and a network bandwidth utilization rate ≤60% is considered smooth, with no restriction on elasticity increases.

[0056] The priority of fuzzy logic reasoning can be bandwidth congestion > CPU / memory shortage > sufficient resources. Based on this priority, the following resource elasticity score R selection strategy can be obtained: if CPU ≥ 70% and memory ≤ 50%, then R = 0.2 (i.e., the cluster resource status parameter control scale is increased by 20%); if CPU ≤ 30% or memory ≥ 80%, then R = -0.3 (i.e., the cluster resource status parameter control scale is decreased by 30%); if bandwidth ≥ 90%, then R = -0.5 (i.e., the cluster resource status parameter control scale is decreased by 50%); if resources are balanced, then R = 0 (i.e., the cluster resource status parameters have no elasticity).

[0057] Deployment feedback confidence It constructs a discrete probability distribution model (such as a binomial distribution model) based on the startup success rate, service health, and business interface availability of the previous batch deployment, and then determines the feedback confidence level under the 95% confidence interval based on the confidence level determination strategy. The confidence level determination strategy is as follows: when the startup success rate of the previous batch is 100%, the service health score is ≥90, and the business interface availability is ≥95%, The value is 0.1 (meaning the deployment process feedback parameter control scale is increased by 10%); when the success rate of the previous batch startup is <80% or the health score is <70, The value is -0.4 (meaning the deployment process feedback parameter control scale is reduced by 40%), and an exponential backoff mechanism is triggered (initially a 1-minute pause, with the pause duration doubling upon continuous anomalies); when the business interface availability is <95%, -1.0 (Immediately halt deployment and trigger rollback assessment).

[0058] As an example, in determining The validation process can then be performed using a constraint optimization algorithm. If the following conditions are met: the minimum number of service instances for Class A services is ≥2 (or the number of service instances for Class B, C, or D services is ≥1), and the size of a single deployment is ≤30% of the total number of services in the batch (to avoid risk concentration), then the validation is successful. Otherwise, the microservices in the batch are deployed according to the pre-set size conditions to ensure a balance between scheduling overhead and risk control. The pre-set size condition can be that the number of microservices deployed in a single deployment is fixed at 2.

[0059] If using a DevOps platform, the dynamic decision-making module can be developed using Java and the Spring Boot framework, deployed as a K8s Deployment (2 replicas), with a built-in decision model algorithm library, real-time parameter data cached through Redis, and decision results stored in a MySQL database (master-slave architecture), supporting traceability of the decision-making process.

[0060] In some embodiments of the present invention, after calculating the optimal deployment decision combination, the deployment execution module can calculate the deployment priority of microservices within the batch, store and schedule them through a priority queue (an abstract data structure, such as Java's PriorityQueue), and the deployment execution module can trigger the deployment within the batch in sequence according to the priority queue order to ensure that critical services are deployed first and risks are controllable.

[0061] Deployment priority is determined based on the attribute parameters of each microservice within the optimal deployment decision combination. For example, a weighted calculation method can be used to determine the deployment priority of each microservice within a batch, as shown in the following formula: ; in, This indicates the deployment priority of each microservice. For dependency level scoring, This is a deployment risk score based on the failure probability value and deployment risk level. Score the importance of the business. , and The corresponding weights are assigned. The stronger the dependence, the higher the weight. The larger the value, the more likely it is that the upstream core dependent services... Take version 1.0, downstream business services Use a value between 0.5 and 0.9; the higher the importance level of the business, the better. The larger the value, such as the core business of category A, the better. For version 1.0, Category B important business It is 0.8, for Class C general business. The value is 0.6, for Class D general business. It is 0.4.

[0062] By integrating three-dimensional ranking factors—dependency links, risk level, and business importance—a priority calculation model with a weighted directed graph can be constructed. Calculating the deployment priority of each microservice using the above method requires significant computing resources. This application also proposes that for each batch of deployments, the deployment priority of each microservice within a batch can be determined using the following method: Utilizing the Kahn algorithm and the dependencies between microservices in that batch, the dependency hierarchy order of microservices in that batch is determined. Specifically, the Kahn algorithm is used to perform topological sorting of microservices with different business importance levels in the service call chain topology graph, determining the execution order of upstream core dependent services and downstream dependent services (e.g., deploying basic dependencies such as database access services and caching services first, then deploying business layer services such as order services and payment services). The inverse of the topological sorting... The order refers to the dependency hierarchy. For the same dependency hierarchy, microservices are arranged in ascending order of deployment risk score (lower-risk services are deployed first), resulting in a deployment priority queue for the microservices. This queue serves as the deployment order for the corresponding new version images of the microservices. The deployment risk score is determined based on the deployment risk level of the microservice in the next batch of deployments and the failure probability value predicted using historical deployment failure data. For example, historically fault-free services (failure probability 0.02, risk level 1, RiskScore=0.028) are prioritized over frequently failing services (failure probability 0.3, risk level 4, RiskScore=0.26).

[0063] As an example, batch deployment operations can support both rolling updates and blue-green deployment modes simultaneously. For instance, services corresponding to type A businesses can use blue-green deployment by default (starting a new instance first and then destroying the old one), while microservices corresponding to type B, C, and D businesses can use rolling updates. When using a DevOps platform, the deployment execution module performs batch deployment operations through a container orchestration platform (such as Kubernetes) based on the optimal deployment decision combination, and synchronizes the service instance startup status to the health feedback module in real time during the deployment process. For example, the deployment execution module is developed based on Kubernetes and uses the Kubernetes API to automate the execution of rolling updates and blue-green deployments. It supports switching deployment modes via configuration files, and deployment logs are collected by Fluentd and sent to Elasticsearch for easy troubleshooting. In addition, instances that time out (exceeding a preset threshold of 5 seconds) are immediately marked as exceptions and a retry mechanism is triggered. If deployment still fails after multiple retries, the instance is removed from the batch and recorded in the deployment ELK log.

[0064] It should be noted that when the deployment of microservices within a batch fails, existing technologies typically employ a full rollback strategy. However, this can inadvertently affect other batches of services that have been successfully deployed and are running normally, causing unnecessary service interruptions and resource waste, and failing to minimize the impact of the failure. To address this issue, this application provides a precise, fine-grained rollback mechanism: such as... Figure 2 As shown, when there are microservices that fail to deploy in a certain batch (if the conditions for advancement are not met based on the real-time collected cluster resource status dimension information and deployment feedback dimension information, the deployment is considered to have failed), by setting the minimum explosion radius parameter, only the failed batch is rolled back, thereby preserving the successful deployment results to the maximum extent and ensuring the overall availability of the deployed system.

[0065] In some embodiments of the present invention, services with different business importance levels adopt a differentiated time-slice scheduling mechanism: ① If the microservices deployed in the current batch are Class A services (i.e., core services), then the batch interval between them and the microservices deployed in the previous batch is... The calculation formula is: ; in, Set the basic batch interval (default 1 minute) for ordinary services (i.e., microservices corresponding to Class B, Class C, and Class D services). The fault handling time for the previous batch of deployments (unit: minutes). Stable startup time for the previous batch of services (unit: minutes). Duration for adjusting resource status (unit: minutes). Weighting based on business importance (the higher the level of business importance, the higher the weighting). (The larger). This application design The purpose is to reserve a window for fault circuit interruption and emergency handling.

[0066] As an example, It can be dynamically calculated from the cluster resource load: .

[0067] ② The microservices deployed in the current batch are ordinary services, and the batch interval between them and the microservices deployed in the previous batch is... The calculation formula is: ; in, The deployment feedback adjustment time (in minutes) can be calculated based on the success rate of the previous batch of startups: .

[0068] If a differentiated time-slice scheduling mechanism is not used, the default interval between batches for core services is 2 minutes, and the default interval between batches for ordinary services is 1 minute.

[0069] The dynamic batch deployment method proposed in this application has the following significant advantages: ① Dynamic batching enables intelligent and automated deployment, improving efficiency and security. By employing a deployment controller that automatically and in real-time makes dynamic decisions based on dynamic batching strategies and real-time data (such as service dependencies and business importance), the entire deployment process eliminates the need for manual batching and manual execution, significantly reducing human error and delays, achieving a higher degree of automation, and improving deployment efficiency. Furthermore, compared to existing statically defined deployment batches, decisions based on objective data are more reliable than manual judgment, enhancing security.

[0070] ② Provides a more refined and adaptive risk control solution. The batch division is dynamic, and the preset advancement conditions rely on strict, quantifiable, and continuous monitoring indicators. Therefore, the deployed system can avoid blindly advancing in an unhealthy state, can adapt to the real-time load of the system, achieve the effect of canary release, greatly reduce the release risk, and thus form an intelligent closed loop of perception-decision-execution.

[0071] ③ Achieve precise rollback to maximize service availability. By setting a minimum explosion radius and introducing a single-batch rollback mechanism, when a batch deployment fails, only that batch of services can be rolled back without affecting other batches that have been successfully deployed. This avoids the service jitter and resource waste caused by full rollback, ensuring maximum availability of the deployed system and achieving precise fault isolation and minimizing the scope of impact.

[0072] ④ Compared to traditional static batching strategies, this application differs significantly in parameter awareness, batch size determination, batching triggering conditions, priority adaptability (deployment priority within a batch), self-optimization capability (weights of the iterative Bayesian optimization algorithm), and applicable scenarios. For example, it collects core dimension parameters from both the data acquisition end and the system end in real time, dynamically calculates based on multi-dimensional real-time parameters, and adaptively adjusts according to changes in the scenario. This makes it suitable for complex scenarios with high concurrency, large data fluctuations, dynamic changes in system resources, and business priority requirements.

[0073] Corresponding to the above method, the present invention also provides a batch deployment microservice system, the system including a computer device, the computer device including a processor and a memory, the memory storing computer programs / instructions, the processor being used to execute the computer programs / instructions stored in the memory, and when the computer programs / instructions are executed by the processor, the system implements the steps of the method described above.

[0074] This invention also provides a computer-readable storage medium storing a computer program / instructions thereon, which, when executed by a processor, implements the steps of the aforementioned edge computing server deployment method. The computer-readable storage medium can be a tangible storage medium, such as random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, floppy disks, hard disks, removable storage disks, CD-ROMs, or any other form of storage medium known in the art.

[0075] Those skilled in the art will understand that the exemplary components, systems, and methods described in conjunction with the embodiments disclosed herein can be implemented in hardware, software, or a combination of both. Whether 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 implementation should not be considered beyond the scope of this invention. When implemented in hardware, it can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this invention are programs or code segments used to perform the desired tasks. The programs or code segments can be stored in a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried in a carrier wave.

[0076] It should be clarified that the present invention is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present invention is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of the present invention.

[0077] In this invention, features described and / or illustrated for one embodiment may be used in the same or similar manner in one or more other embodiments, and / or combined with or in place of features of other embodiments.

[0078] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, various modifications and variations of the embodiments of the present invention are possible. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for deploying microservices in batches, characterized in that, The method includes the following steps: Obtain the attribute dimension information and the corresponding new version image for each microservice in the list of services to be deployed; the attribute dimension information for each microservice includes the business importance level, call dependency coefficient, and deployment risk level of the microservice. Select the core dependency services that meet the set dependency conditions from the microservices with the highest business importance, and select the predecessor services from the core dependency services based on the dependency relationship between microservices. Use the new version image corresponding to the predecessor service to deploy the first batch of the service list to be deployed. If the core dependent services are not fully deployed, based on the dependencies between microservices, the new version images corresponding to each undeployed microservice in the core dependent services are deployed in separate batches. If the core dependent services are fully deployed, for microservices in non-core dependent services that belong to the same business importance level, microservices with high deployment risk level and microservices with low deployment risk level are clustered separately to obtain high-risk clusters and low-risk clusters corresponding to each business importance level. After the current batch deployment is completed, cluster resource status information and deployment feedback information are obtained in real time from the system of the deployed services. If the conditions for advancement are met based on the cluster resource status information and / or deployment feedback information, multiple cluster combinations are selected from the obtained high-risk and low-risk clusters according to the preset cluster combination strategy. Then, a multi-objective weighted Bayesian optimization algorithm is used to select one cluster combination as the next batch for deployment. This process continues until all microservices in the list of services to be deployed are deployed. The objective function value of the multi-objective weighted Bayesian optimization algorithm is determined based on attribute status information and cluster resource status information.

2. The method according to claim 1, characterized in that, The set dependency condition is that the call dependency coefficient of the microservice is not less than the set dependency threshold. The process of selecting core dependency services from the microservices with the highest business importance that meet the set dependency conditions includes: The Tarjan algorithm is used to identify strongly connected components from the dependencies between microservices with the highest business importance, and microservices with call dependency coefficients not less than a set dependency threshold are selected as core dependent services from these strongly connected components.

3. The method according to claim 1, characterized in that, The clustering of microservices with high deployment risk and microservices with low deployment risk includes: Density peak clustering is performed on microservices with high deployment risk levels, and hierarchical clustering is performed on microservices with low deployment risk levels. After clustering is completed, the method further includes: For each microservice within a high-risk or low-risk cluster, the contour coefficient corresponding to the microservice is determined based on the distance between the microservice and other microservices within its own cluster, as well as the distance between the microservice and all microservices within its nearest neighbor cluster. Based on the silhouette coefficients of microservices using the same clustering algorithm, the silhouette coefficients corresponding to the clustering algorithm are obtained. If the silhouette coefficients corresponding to the clustering algorithm meet the set clustering constraints, the clustering is verified to be effective; otherwise, the clustering parameters are adjusted and the clustering is re-clustered.

4. The method according to claim 1, characterized in that, The preset cluster combination strategies include: A high-risk cluster is deployed as a batch; low-risk clusters to which microservices of high business importance belong are deployed as a batch; and for low-risk clusters to which microservices of low business importance belong, a single cluster or any combination thereof is deployed as a batch.

5. The method according to claim 1, characterized in that, The objective function value of the multi-objective weighted Bayesian optimization algorithm is determined based on attribute dimension information and cluster resource state dimension information. Specifically, the objective function value is obtained by weighting the business adaptability score, deployment risk score, and resource usage score. The business adaptability score is determined based on the business importance level and call dependency coefficient of the microservice in the next batch of deployments; the deployment risk score is determined based on the deployment risk level of the microservice in the next batch of deployments and the failure probability value predicted using historical deployment failure data of the microservice; and the resource usage score is determined based on cluster resource state dimension information.

6. The method according to claim 5, characterized in that, For the next batch of deployments, the weights for the business compatibility score, deployment risk score, and resource usage score are obtained through the following methods: Based on the real-time acquired cluster resource status and deployment feedback information, resource time-series data and feedback time-series data are generated respectively. Calculate the correlation between resource time-series data and feedback time-series data, and adjust the weights corresponding to resource usage scores based on the correlation; The entropy weight method is used to calculate the weights corresponding to the business adaptability score and the deployment risk score.

7. The method according to claim 1, characterized in that, For each batch of deployments, the number of microservices distributed to the deployed system in a single deployment is determined based on the baseline service scale, the cluster resource status dimension information, and the deployment feedback dimension information; wherein, the baseline service scale is a range value determined based on the business importance level.

8. The method according to claim 1, characterized in that, For each batch of deployments, the order in which the new version images for the corresponding microservices are distributed is determined as follows: By using the Kahn algorithm and the dependencies between microservices in this batch of deployments, the dependency hierarchy order of microservices in this batch of deployments is determined; For the same dependency level, microservices are arranged in ascending order of deployment risk score to obtain a deployment priority queue for microservices, which is used as the deployment order for the new version image of the corresponding microservice. The deployment risk score is determined based on the deployment risk level of the microservice in the next batch of deployments and the failure probability value predicted by using historical deployment failure data of microservices.

9. A batch deployment microservice system, comprising a processor, a memory, and computer programs / instructions stored in the memory, characterized in that, The processor is configured to execute the computer program / instructions, and when the computer program / instructions are executed, the system implements the steps of the method as described in any one of claims 1 to 8.

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

Images