WO2022028157A1

WO2022028157A1 - Elastic scaling method and system for microservice system in cloud environment, medium and device

Info

Publication number: WO2022028157A1
Application number: PCT/CN2021/103502
Authority: WO
Inventors: 蒋昌俊; 闫春钢; 丁志军; 张亚英; 王晟
Original assignee: 同济大学
Priority date: 2020-08-03
Filing date: 2021-06-30
Publication date: 2022-02-10
Also published as: CN112084002B; CN112084002A

Abstract

The present invention provides an elastic scaling method and system for a microservice system in a cloud environment, a medium and a device. The elastic scaling method comprises: monitoring work attribute information of each microservice instance in the microservice system in the cloud environment; before and during the operation of the microservice system, determining an optimal cost-effective container type of each type of microservice instances; forming a scheduling scheme of a task on the basis of the workflow of the task and the optimal cost-effective container type of each type of microservice instances; reading the scheduling scheme of the task to obtain the type and quantity of newly added microservice instances therefrom, and deploying the newly added microservice instances on a rented or newly added virtual machine. The present invention comprehensively considers a task scheduling algorithm and a resource scaling algorithm, accurately determines by means of the task scheduling algorithm the quantity of resources that need to be expanded, and then solves a cost-optimized scaling scheme by means of the resource scaling algorithm, thereby ensuring the performance of the microservice system and minimizing cloud resource renting cost.

Description

Elastic scaling method, system, medium and device for microservice system in cloud environment

technical field

The invention belongs to the technical field of software, and relates to a scaling method and system, in particular to an elastic scaling method, system, medium and device for a microservice system in a cloud environment.

Background technique

With the expansion of software scale and the rapid development of new technologies such as cloud computing, software developers have higher and higher requirements for software architecture. Rapidly changing business requirements and the internal complexity of large-scale And even the entire life cycle of the software brings huge challenges. Software developers hope to use the elastic characteristics of cloud computing to develop flexible and efficient software systems, but traditional software development architectures such as monolithic architectures limit the rapid development and flexible scaling of software. To this end, the microservice development style has been proposed and successfully applied to many large-scale commercial software systems. The software system based on microservices splits high-coupling large-scale software into a series of service sets with independent life cycle, high cohesion and low coupling, thereby reducing the internal complexity of the software, improving the scalability of the system, and More flexible scaling is achieved by reducing service granularity. However, the independence between microservices also brings a large performance loss, which needs to be compensated by the task scheduling method. At the same time, the containerized deployment method and the automatic scaling of many microservice instances also require the support of scaling methods.

At present, the research on microservice systems is still in its infancy, and the research on elastic scaling mainly focuses on task scheduling and automatic scaling in the cloud environment. Task scheduling in the cloud environment focuses on how to arrange the execution of tasks in the workflow in the cloud environment, and use a large number of pay-as-you-go computing resources in the cloud environment to scale resources to achieve a trade-off between performance and cost; however, most studies are limited For the scheduling of a single workflow, the simultaneous scheduling of multiple workflows and the continuous workload are ignored. Automatic scaling in the cloud environment focuses on the management of computing resources, predicting the response time of requests and predicting the amount of resources required to meet performance requirements through modeling and analysis; however, this modeling and estimation method cannot accurately reflect the actual demand for resources. And these methods do not involve a specific task scheduling method, and the scheduling method also affects the resource demand. In addition, the deployment of microservices is mainly based on containers, and the strategy of "one microservice instance and one container" is usually used for deployment, which makes the scaling of microservices actually the scaling of containers loaded with service instances, and needs to consider containers and virtual machines. Simultaneous scaling, and container-to-VM placement issues.

Therefore, how to provide an elastic scaling method, system, medium and device for a microservice system in a cloud environment to solve the problem that the existing technology cannot accurately reflect the actual demand of resources, and does not involve a specific task scheduling method, and the scheduling method will also Defects such as affecting the resource demand, not considering the simultaneous scaling of the container and the virtual machine, and the placement of the container to the virtual machine have become technical problems to be solved urgently by those skilled in the art.

SUMMARY OF THE INVENTION

In view of the above-mentioned shortcomings of the prior art, the purpose of the present invention is to provide an elastic scaling method, system, medium and device for a micro-service system in a cloud environment, so as to solve the problem that the prior art cannot accurately reflect the actual demand of resources, and It does not involve a specific task scheduling method, and the scheduling method also affects the resource demand, and does not consider the simultaneous scaling of the container and the virtual machine, and the placement of the container to the virtual machine.

In order to achieve the above object and other related objects, the present invention provides an elastic scaling method of a microservice system in a cloud environment, wherein the microservice system in the cloud environment includes a microservice instance layer and a virtual machine layer, and each microservice instance packaged in a container and deployed on a virtual machine; the elastic scaling method of the microservice system in the cloud environment includes: monitoring the work attribute information of each microservice instance in the microservice system in the cloud environment; Before and during the operation of the microservice system, determine the optimal cost-effective container type for each microservice instance; form the task scheduling scheme based on the task workflow and the optimal cost-effective container type for each microservice instance; read The scheduling scheme of the task is obtained to obtain the type and quantity of the newly added microservice instance, and the newly added microservice instance is deployed on the leased or newly added virtual machine.

In an embodiment of the present invention, the work attribute information of each microservice instance includes the actual response time of the microservice instance and/or the end-to-end response time of the workflow.

In an embodiment of the present invention, the step of monitoring the work attribute information of each microservice instance in the microservice system in the cloud environment further includes: judging whether the task times out according to the deadline defined by the workflow, If it times out, store the delay time.

In an embodiment of the present invention, before executing the step of determining the optimal cost-effective container type for each microservice instance, the method for elastic scaling of the microservice system in the cloud environment further includes: calculating the average value of each microservice instance. Execution time, average data transfer volume and communication latency between microservice instances.

In an embodiment of the present invention, the step of determining the optimal cost-effective container type for each microservice instance includes: initializing container types corresponding to all types of microservice instances; calculating the expected completion of the workflow under the current container type. time; when the expected completion time is greater than the deadline of the workflow, calculate the benefit ratio when the container type corresponding to the i-th microservice instance is replaced with a type with more resources and a higher price.

In an embodiment of the present invention, the step of forming the task scheduling scheme based on the task workflow and the optimal cost-effective container type for each microservice instance includes: extracting the optimal value corresponding to each microservice instance. The running speed of the cost-effective container type, calculates the ranking of each task in the workflow, and calculates the sub-deadline time of each task based on the ranking of the tasks; when multiple workflows need to be scheduled in one scheduling cycle, and many When there is competition for microservice instances among the workflows, by adding unified entry tasks and exit tasks, multiple workflows are integrated into a single workflow; the expected completion time of each ready task in the workflow is calculated; the A ready task is a task that has been executed and completed by all predecessor tasks; based on the sub-deadline of each task, the expected completion time of each ready task and the number of subsequent tasks, the scheduling urgency of the ready task is calculated, and the scheduling urgency is selected. The ready task corresponding to the minimum value of , as the object of subsequent scheduling; traverse all microservice instances that can execute the task, and determine whether the task can meet the sub-deadline; determine whether the task can meet the sub-deadline by calculating the task slack Satisfy the sub-deadline; when the task slack is a non-negative number, it means that there are some microservice instances that can complete the task before the sub-deadline, then calculating and scheduling the task to the microservice instance will cause When the task slack is negative, it means that all some microservice instances cannot meet the sub-deadline, then the task is calculated in the Describe the minimum computing speed of the microservice instance required to complete the task before the deadline, so as to create a new microservice instance according to the minimum computing speed of the microservice instance; if a new microservice instance is created, traverse the leased virtual machine, and select the For the virtual machine of the container image required by the microservice instance, select the virtual machine with the smallest difference between the remaining resources of the virtual machine and the resources required by the container, and deploy the newly created microservice instance on the virtual machine; return to the computing Steps that describe the expected completion time of each ready task in the workflow.

In an embodiment of the present invention, the elastic scaling method of the microservice system in the cloud environment further includes: when the rented virtual machine is not enough to deploy all newly added microservice instances, renting a new virtual machine for deploying the remaining unused virtual machines. The deployed microservice instance; the type and quantity of the leased new virtual machine and the mapping method to the virtual machine are solved by means of a pre-stored variable size packing problem.

Another aspect of the present invention provides an elastic scaling system for a microservice system in a cloud environment. The microservice system in the cloud environment includes a microservice instance layer and a virtual machine layer. Each microservice instance is encapsulated in a container and deployed. on a virtual machine; the elastic scaling system of the microservice system in the cloud environment includes: a monitoring module for monitoring the work attribute information of each microservice instance in the microservice system in the cloud environment; a container type determination module, It is used to determine the optimal cost-effective container type for each microservice instance before and during the operation of the microservice system; the scheduling scheme forms a module for the workflow of tasks and the optimal cost-effective container for each microservice instance Based on the type, the scheduling scheme of the task is formed; the deployment module is used to read the scheduling scheme of the task to obtain the type and quantity of the newly added microservice instance, and deploy the newly added microservice instance in the leased or added to the virtual machine.

Another aspect of the present invention provides a medium on which a computer program is stored, and when the computer program is executed by a processor, implements the elastic scaling method of the microservice system in the cloud environment.

A final aspect of the present invention provides an apparatus, comprising: a processor and a memory; the memory is used for storing a computer program, and the processor is used for executing the computer program stored in the memory, so that the apparatus executes the cloud environment The elastic scaling method of the microservice system.

As described above, the elastic scaling method, system, medium and device of a microservice system in a cloud environment according to the present invention have the following beneficial effects:

First, the present invention combines the task scheduling algorithm and the resource scaling algorithm, uses the task scheduling algorithm to obtain the scheduling scheme and accurately calculates the amount of resources required for system scaling, thereby reducing system operation costs while ensuring system performance.

Second, the present invention proposes a combined scaling problem of containers and virtual machines for the resource provisioning mode mainly based on virtual machines in cloud environments, and uses the VSBPP solution method to obtain a cost-optimized solution for virtual machine expansion and container deployment.

Third, the present invention comprehensively considers the overall structure of the workflow, calculates the optimal cost-effective container type for each microservice, and divides the deadline based on this, which improves the reliability of deadline division and improves the performance of the algorithm.

Description of drawings

FIG. 1 is a schematic diagram showing the principle structure of the microservice system in the cloud environment of the present invention.

FIG. 2A is a schematic flowchart of an elastic scaling method of a microservice system in a cloud environment according to an embodiment of the present invention.

FIG. 2B is a schematic flowchart of S22 in the elastic scaling method of the microservice system in the cloud environment of the present invention.

FIG. 2C is a schematic flowchart of S23 in the elastic scaling method of the microservice system in the cloud environment of the present invention.

FIG. 3 is a schematic diagram showing the principle structure of an elastic scaling system of a microservice system in a cloud environment according to an embodiment of the present invention.

Component label description

detailed description

The embodiments of the present invention are described below through specific specific examples, and those skilled in the art can easily understand other advantages and effects of the present invention from the contents disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that the following embodiments and features in the embodiments may be combined with each other under the condition of no conflict.

It should be noted that the drawings provided in the following embodiments are only used to illustrate the basic concept of the present invention in a schematic way, so the drawings only show the components related to the present invention rather than the number, shape and number of components in actual implementation. For dimension drawing, the type, quantity and proportion of each component can be changed at will in actual implementation, and the component layout may also be more complicated.

The technical principles of the elastic scaling method, system, medium and device of the microservice system in the cloud environment according to the present invention are as follows:

The invention includes the optimal cost-effective container type solution, heterogeneous workflow scheduling based on task urgency, and VSBPP-based container virtual machine combination scaling; wherein, the optimal cost-effective container type solution is based on the workflow describing the structure of the microservice system, Starting from the container type with the least amount of resources, replace the container type for each microservice in turn, and calculate the revenue ratio caused by the replacement of the container type, that is, the ratio of the performance improvement and the price increase, and select the microservice container type with the highest revenue ratio. Actual replacement, repeat this process until the performance of the microservice system meets the requirements under a certain container type scheme, which is the optimal cost-effective container type; heterogeneous workflow scheduling based on task urgency to describe the structure of user requests. Based on the workflow and the optimal cost-effective container type, calculate the sub-deadline, expected completion time, and the number of subsequent tasks to be scheduled for each task in the user request, and use the ratio of these three values as the task's scheduling urgency to determine task scheduling. Schedule each task in turn according to the scheduling order, and determine whether the task can meet the sub-deadline on the existing service instance: if it is satisfied, then calculate the task caused by each service instance that meets the sub-deadline. Cost increase, and select the service instance with the smallest cost increase for task allocation; if not satisfied, create a new container that conforms to the optimal cost-effective container type, deploy the service instance in it, and assign tasks to the new service instance; based on VSBPP's container virtual machine combination scaling obtains the type and quantity of newly added containers from the scheduling scheme obtained by the scheduling algorithm, and tries to deploy it on the leased virtual machine. If the resources of the leased virtual machine are not enough to deploy all the new containers, Then a batch of new virtual machines are leased to deploy the remaining un-deployed containers. The type and quantity of newly leased virtual machines and the mapping scheme from containers to virtual machines are solved by the VSBPP solution method. The invention comprehensively considers the task scheduling algorithm and the resource scaling algorithm, accurately determines the number of resources to be expanded through the task scheduling algorithm, and then solves the cost-optimized scaling scheme through the resource scaling algorithm, ensures the performance of the micro-service system, and minimizes the cost of cloud resource rental. .

Example 1

This embodiment provides an elastic scaling method for a microservice system in a cloud environment. The microservice system in the cloud environment includes a microservice instance layer and a virtual machine layer, and each microservice instance is packaged in a container and deployed in a On the virtual machine; the elastic scaling method of the microservice system in the cloud environment includes:

Monitoring the work attribute information of each microservice instance in the microservice system in the cloud environment;

Before and during the operation of the microservice system, determine the optimal cost-effective container type for each microservice instance;

Based on the task workflow and the best cost-effective container type for each microservice instance, the task scheduling scheme is formed;

The scheduling scheme of the task is read to obtain the type and quantity of the newly added microservice instance, and the newly added microservice instance is deployed on the leased or newly added virtual machine.

The elastic scaling method of the microservice system in the cloud environment provided by this embodiment will be described in detail below with reference to the drawings. Please refer to Figure 1, which shows a schematic diagram of the principle structure of a microservice system in a cloud environment. As shown in FIG. 1 , the microservice system 1 in the cloud environment includes a microservice instance layer and a virtual machine layer, and each microservice instance is encapsulated in a container and deployed in a virtual machine. In this embodiment, the microservice system is represented in the form of workflow and described by a Directed Acyclic Graph (DAG), and multiple user requests will be cached in the workload queue, as shown in the figure The workflow layer in 1 is shown. At a certain time T, when a user requests to enter the system, it will trigger the execution of a function in the system. The user request can be represented by the workflow and DAG corresponding to the function, and each vertex in the DAG represents a task in the request , an edge between two vertices represents a dependency between tasks.

Please refer to FIG. 2A , which is a schematic flowchart of an embodiment of an elastic scaling method of a microservice system in a cloud environment. As shown in FIG. 2A , the elastic scaling method of the microservice system in the cloud environment specifically includes the following steps:

S21: Monitor the work attribute information of each microservice instance in the microservice system in the cloud environment, and determine whether the task (in this embodiment, the task) times out according to the deadline defined by the workflow, and if Timeout, storage delay time. In this embodiment, the work attribute information of each microservice instance includes information such as the actual response time of the microservice instance and/or the end-to-end response time of the workflow. Compare the deadline defined by the workflow with the actual response time of the microservice instance to determine whether the user request timed out.

S22, before and during the running of the microservice system, determine the optimal cost-effective container type for each microservice instance. In this embodiment, when the microservice system needs to expand the number of service instances of a certain microservice, the corresponding container type is preferentially selected to ensure the optimization of performance and cost. Before solving, through the data monitored by S21, find the average execution time of each type of microservice instance (the average execution time of each type of microservice instance is equal to the sum of the execution times of multiple executions of each type of microservice instance divided by execution times) and the average data transfer volume between microservice instances (the average data transfer volume between microservice instances is equal to the sum of the time consumed by multiple data transfers between microservice instances divided by the number of transfers) and communication delays, And make real-time updates when the microservice system is running.

Please refer to FIG. 2B , which is a schematic flowchart of S22 . As shown in Figure 2B, the S22 specifically includes the following steps:

S221, initialize container types corresponding to all types of microservice instances.

S222: Calculate the expected completion time of the workflow under the current container type.

makespan=max{FT _c } Formula (3)

Among them, t _p is the predecessor task of task t _c , and currently t _{c can be executed only when all predecessor tasks of t c} _are completed. data _p,c is the average data transmission amount between tasks t _p and t _c , b is the network bandwidth, TT _p,c represents the data transmission time between tasks t _p and t _c , that is, the communication delay; FT _p represents t The completion time of _p , ET _c represents the average execution time of t _c .

S223, when the expected completion time is greater than the expiration time of the workflow, calculate the revenue ratio when the container type corresponding to the i-th microservice instance is replaced with a type with more resources and a higher price.

Formula (4)

Among them, duration _i is the running time of the i-th container, interval is the charging time unit of the cloud service provider, the value is the virtual machine charging unit time provided by the cloud service provider, price _i is the unit price of the i-th container, The unit price varies with the amount of resources in the container.

Calculate the revenue ratio of all microservice types to get the set {gain _i }. Among them, makespan _before , cost _before , makespan _after , and cost _after represent the expected completion time and total container price before and after replacement, respectively. The i corresponding to the maximum revenue ratio is selected, the container type corresponding to the i-th microservice is actually replaced, and the process returns to step S222.

When calculating the revenue ratio gain _i , the total cost of the container depends on the unit price of the container and the running time of the container. After the replacement, the unit price of the container increases, but the running time of the container decreases, so the following situations may exist:

(1) cost is reduced after replacement, then select cost difference as gain _i ;

(2) The cost remains unchanged after replacement, and the difference of makespan is selected as gain _i .

If the expected completion time meets the deadline of the workflow, the algorithm stops, and the container type corresponding to each microservice is the optimal cost-effective container type.

S23, a task scheduling scheme is formed based on the task workflow and the best cost-effective container type for each microservice instance.

Please refer to FIG. 2C , which is a schematic flowchart of S23 . As shown in Figure 2C, the S23 includes the following steps:

S231, extracting the running speed of the optimal cost-effective container type corresponding to each microservice instance, calculating the ranking of each task in the workflow, and calculating the sub-deadline time of each task based on the ranking of the tasks.

In this embodiment, the rank of each task in the workflow is calculated according to formula (6).

Among them, task t _j is the successor task of task t _i , ET ^* _i is the execution time of t _i on the optimal cost-effective container type, and TT _i,j is the data transmission time between t _i and t _j . The physical meaning of rank is: in the absence of task queuing time, the expected time from the start of task t _i to the completion of the entire workflow.

According to its physical meaning, based on the rank of the task, the sub-deadline of each task is calculated, that is, the latest allowed completion time of each task. If a task cannot be executed before its child deadlines, it can be considered that the workflow to which this task belongs will time out:

Among them, subdeadline _i is the sub-deadline of task t _i , cpLength is the critical path length of the workflow, that is, the expected time to complete the execution of the entire workflow, and deadline is the deadline of the entire workflow.

S232, when multiple workflows need to be scheduled in one scheduling cycle, and there is competition for microservice instances among multiple workflows, by adding unified entry tasks and exit tasks, that is, there is no predecessor task or no predecessor task in one workflow. Two types of special tasks for successor tasks, which combine multiple workflows into a single workflow.

S233: Calculate the expected completion time of each ready task in the workflow; the ready task is a task that has been executed and completed by all predecessor tasks. In particular, an entry task without a predecessor task must be the first task executed in each workflow. The formula for calculating the expected completion time is as follows:

Among them, XFT(t _c ) is the expected completion time of the ready task t _c , I _i,j represents the jth microservice instance of the ith microservice, EFT(t _c ,I _i,j ) and ET(t _c , I _i,j ) represent the earliest completion time and execution time of the task t _c on the microservice instance I _{i, j} , respectively, w _c is the calculation amount of the task t _c , and _{si, j} is the microservice instance I _{i, j} The processing speed of , avail(I _i,j ) is the available time of the microservice instance I _i,j , and AFT(t _p ) is the actual completion time of the task t _p . The expected completion time is the minimum value of the earliest completion time among all microservice instances. It should be noted that the task t _c can only be executed on the service instance of its corresponding type of microservice.

S234, based on the sub-deadline time of each task, the expected completion time of each ready task, and the number of subsequent tasks, calculate the scheduling urgency of the ready task, and select the ready task corresponding to the minimum value of the scheduling urgency, as a follow-up Scheduled object.

In this embodiment, the scheduling urgency of the ready task is calculated according to formula (11):

Among them, hop(t _i ) is the number of subsequent tasks to be scheduled for task t _i , and the number of subsequent tasks to be scheduled for a ready task is defined as the maximum path length from the task to the exit task. When the value of the scheduling urgency is smaller, the expected completion time of the task is closer to the sub-deadline time, and the number of subsequent tasks waiting to be scheduled is also greater, and the task also needs to be scheduled first.

Select the ready task with the smallest scheduling urgency value as the object of subsequent scheduling.

S235: For the scheduled task, traverse all microservice instances that can execute the task, and determine whether the task can meet the sub-deadline; and determine whether the task can meet the sub-deadline by calculating the task slack.

In this embodiment, the task slack is calculated according to formula (12):

Laxity(t _c ,I _i,j )=subdeadline _c -EFT(t _c ,I _i,j ) Equation (12)

The physical meaning of Laxity(t _c ,I _i,j ) is: when the task t _c is scheduled to the instance I _i,j , the difference between its sub-deadline time and the earliest completion time.

When the task laxity Laxity(t _c , I _{i, j} ) is a non-negative number, it means that there are some microservice instances that can complete the task before the sub-deadline, then the task is calculated and scheduled to the microservice The cost increase caused by the instance incrCost _i, _j , schedule the task to the microservice instance corresponding to the minimum cost increase.

In this embodiment, the calculation formula of the cost increase incrCost _i,j is as follows:

incrCost _i,j = cost′-cost formula (13)

Among them, cost and cost' represent the cost before and after the task t _c is scheduled to the service instance I _i,j respectively, duration _x is the rental duration of the xth virtual machine, interval is the charging time unit of the cloud service provider, price _x is the unit price of the xth virtual machine.

When the task slack is a negative number, it means that all some microservice instances meet the sub-deadline, and then calculate the minimum microservice instance computing speed minSpeed required to complete the task before the sub-deadline, so as to calculate the minimum microservice instance calculation speed minSpeed according to the minimum microservice Instance computing speed, create a new microservice instance.

In this embodiment, the minimum microservice instance computing speed minSpeed required to complete the task before the sub-deadline is calculated according to formula (15):

Among them, IT(I ^* _i,j ) is the creation time of a new service instance, and is selected according to the following strategies:

(1) When minSpeed is greater than the maximum processing speed of the available virtual machine type, calculate the earliest completion time that the task can achieve on the existing microservice instance according to formula (9), and create a new service instance with the maximum processing speed. And the earliest completion time (including the creation time of the new service instance) that the task can execute on this instance, whichever is shorter in the two schemes;

(2) When minSpeed is less than the processing speed of the optimal cost-effective container type of the microservice corresponding to the task, create a new optimal cost-effective container and deploy the microservice instance, and schedule the task to the microservice instance;

(3) When minSpeed is between the maximum processing speed of the available virtual machine type and the processing speed of the optimal cost-effective container type of the microservice corresponding to the task, create a new container with a processing speed slightly higher than minSpeed and deploy the service instance, Schedule tasks to this instance.

S236, if a new microservice instance is created, traverse the leased virtual machines, select the virtual machine loaded with the container image required by the microservice instance, and select the one with the smallest difference between the remaining resources of the virtual machine and the resources required by the container. virtual machine, and deploy the new microservice instance to the virtual machine; at the same time, readjust the expected completion time of the task. If there is no container image required by the service instance in the rented virtual machine, the service instance is added to the set newIns and deployed by the container virtual machine combined with the scaling module (in this embodiment, the new service instance deployed in advance is no longer Participate in the deployment of the container virtual machine combination scaling module). Returning to S233, that is, returning to the step of calculating the expected completion time of each ready task in the workflow.

S24: Read the scheduling scheme of the task to obtain the type and quantity of the newly added microservice instance therefrom, and deploy the newly added microservice instance on the leased or newly added virtual machine.

Specifically, the scheduling scheme of the task is read, the undeployed new service instance set newIns is obtained, the newly added service instances and their corresponding container types are obtained therefrom, and they are arranged in ascending order according to the amount of resources required by the containers. According to the sorting results, new service instances are added to the leased virtual machines in turn. The selection is based on the Best Fit principle, that is, the virtual machine with the smallest difference between the remaining resources of the virtual machine and the resources required by the container is selected.

When the leased virtual machines are not enough to deploy all the newly added microservice instances, the new virtual machines are leased to deploy the remaining undeployed microservice instances; the type and quantity of the leased new virtual machines and the mapping method to the virtual machines are determined by The pre-stored variable-sized bin pack problem (VSBPP) is solved. Among them, the newly added service instances are items in VSBPP, and the types of virtual machines that can be rented are boxes of different capacities.

In this embodiment, a VSBPP solving algorithm such as the FFDLS algorithm and the IFFD algorithm is used to solve the type and quantity of the leased new virtual machine and the mapping method to the virtual machine.

Specifically, the objective function in the VSBPP solution algorithm is to minimize the rental cost of the newly added virtual machine. The virtual machines provided in the cloud environment are often based on the number of time units leased. For example, the virtual machine of Amazon EC2 is charged by the hour, and the part less than one hour is charged by one hour. Therefore, the rental fee calculation formula is shown in formula (16):

Among them, duration _i is the rental duration of the ith virtual machine, interval is the charging time unit of the cloud service provider, and price _i is the unit price of the ith virtual machine.

After obtaining the solution of the pre-stored variable-size bin packing problem, calculate the remaining resource amount for each newly leased virtual machine, that is, the total amount of resources owned by the virtual machine minus the amount of resources occupied by the service instance, and according to this The proportion of the required resources of the newly added service instances on the virtual machine, and the remaining resources are allocated to the newly added service instances in proportion.

The elastic scaling method of the microservice system in the cloud environment described in this embodiment has the following beneficial effects:

First, this embodiment combines the task scheduling algorithm and the resource scaling algorithm, uses the task scheduling algorithm to obtain the scheduling scheme and accurately calculates the amount of resources required for system scaling, which reduces system operation costs while ensuring system performance.

Second, this embodiment proposes a combined scaling problem of containers and virtual machines for the resource provisioning method based on virtual machines in a cloud environment, and uses the VSBPP solution method to obtain a cost-optimized solution for virtual machine expansion and container deployment.

Third, this embodiment comprehensively considers the overall structure of the workflow, calculates the optimal cost-effective container type for each microservice, and divides the deadline based on this, which improves the reliability of deadline division and improves the performance of the algorithm. .

This embodiment also provides a medium (also referred to as a computer-readable storage medium) on which a computer program is stored, and when the computer program is executed by a processor, implements the above-mentioned elastic scaling method of a microservice system in a cloud environment.

Those of ordinary skill in the art can understand that the computer-readable storage medium means that all or part of the steps of implementing the above method embodiments can be completed by hardware related to computer programs. The aforementioned computer program may be stored in a computer-readable storage medium. When the program is executed, the steps including the above method embodiments are executed; and the foregoing storage medium includes: ROM, RAM, magnetic disk or optical disk and other media that can store program codes.

This embodiment further provides an elastic scaling system for a microservice system in a cloud environment. The microservice system in the cloud environment includes a microservice instance layer and a virtual machine layer. Each microservice instance is encapsulated in a container and deployed on On a virtual machine; the elastic scaling system of the microservice system in the cloud environment includes:

a monitoring module for monitoring the work attribute information of each microservice instance in the microservice system in the cloud environment;

A container type determination module, used to determine the optimal cost-effective container type for each microservice instance before and during the operation of the microservice system;

The scheduling scheme forming module is used to form the scheduling scheme of the task based on the workflow of the task and the best cost-effective container type for each microservice instance;

The deployment module is used for reading the scheduling scheme of the task, so as to obtain the type and quantity of the newly added microservice instance, and deploy the newly added microservice instance on the leased or newly added virtual machine.

The elastic scaling system of the microservice system in the cloud environment provided by this embodiment will be described in detail below with reference to the drawings. Please refer to FIG. 3 , which is a schematic diagram showing the principle structure of an elastic scaling system of a microservice system in a cloud environment in an embodiment. As shown in FIG. 3 , the elastic scaling system 3 of the microservice system in the cloud environment includes a monitoring module 31 , a container type determination module 32 , a scheduling scheme forming module 33 and a deployment module 34 .

The monitoring module 31 is used to monitor the work attribute information of each microservice instance in the microservice system in the cloud environment, and judge the task according to the deadline defined by the workflow (in this embodiment, the task ) whether it times out, if it times out, store the delay time. In this embodiment, the work attribute information of each microservice instance includes information such as the actual response time of the microservice instance and/or the end-to-end response time of the workflow. Compare the deadline defined by the workflow with the actual response time of the microservice instance to determine whether the user request timed out.

The container type determination module 32 coupled with the monitoring module 31 is configured to determine the optimal cost-effective container type for each microservice instance before and during the operation of the microservice system.

In this embodiment, when the microservice system needs to expand the number of service instances of a certain microservice, the corresponding container type is preferentially selected to ensure the optimization of performance and cost. Before solving, the container type determination module 32 obtains the average execution time of each type of microservice instance through the data monitored by the monitoring module 31 (the average execution time of each type of microservice instance is equal to the average execution time of each type of microservice instance). The sum of the execution time of multiple executions of the instance divided by the number of executions) and the average data transfer volume between microservice instances (the average data transfer volume between microservice instances is equal to the time it takes to transfer data multiple times between microservice instances) The sum divided by the number of transfers) and communication latency, and updated in real-time as the microservice system runs.

Specifically, the container type determination module 32 is used to initialize the container types corresponding to all types of microservice instances; calculate the expected completion time of the workflow under the current container type; when the expected completion time is greater than the expiration time of the workflow, Calculate the revenue ratio when the container type corresponding to the i-th microservice instance is replaced with a type with more resources and a higher price. If the expected completion time meets the deadline of the workflow, the container type determination module 32 stops, and the container type corresponding to each microservice currently is the optimal cost-effective container type.

The scheduling scheme forming module 33 coupled with the monitoring module 31 and the container type determining module 32 is configured to form the scheduling scheme of the task based on the workflow of the task and the best cost-effective container type for each microservice instance.

Specifically, the scheduling scheme forming module 33 is used to extract the running speed of the optimal cost-effective container type corresponding to each microservice instance, calculate the ranking of each task in the workflow, and calculate the ranking of each task based on the ranking of the tasks. The sub-deadline of the task; when multiple workflows need to be scheduled in a scheduling cycle and there is competition for microservice instances among multiple workflows, the multiple workflows can be integrated by adding unified entry tasks and exit tasks into a single workflow; calculate the expected completion time of each ready task in the workflow; the ready task is the completed task of all predecessor tasks; based on the sub-deadline of each task, the expected completion time of each ready task time and the number of subsequent tasks, calculate the scheduling urgency of the ready task, and select the ready task corresponding to the minimum value of the scheduling urgency as the object of subsequent scheduling; traverse all microservice instances that can execute the task, and determine the Whether the task can meet the sub-deadline; determine whether the task can meet the sub-deadline by calculating the task slack; when the task slack is a non-negative number, it means that there are some microservice instances that can be used in the If the task is completed before the sub-deadline, the cost increase caused by scheduling the task to the microservice instance is calculated, and the task is scheduled to the microservice instance corresponding to the minimum cost increase; when the task slackness When it is a negative number, it means that all the microservice instances meet the sub-deadline time, then calculate the minimum microservice instance computing speed required to complete the task before the sub-deadline time, and then create a new microservice instance according to the minimum microservice instance computing speed. Service instance; if a new microservice instance is created, traverse the leased virtual machine, select the virtual machine loaded with the container image required by the microservice instance, and select the smallest difference between the remaining resources of the virtual machine and the resources required by the container. and deploys the newly created microservice instance on the virtual machine; returns and calculates the expected completion time of each ready task in the workflow.

The deployment module 34, which is respectively coupled with the container type determination module 32 and the scheduling scheme forming module 33, is used to read the scheduling scheme of the task, so as to obtain the type and number of newly added microservice instances from it, and to add the newly added microservices. Service instances are deployed on leased virtual machines. When the leased virtual machines are not enough to deploy all the newly added microservice instances, the new virtual machines are leased to deploy the remaining undeployed microservice instances; the type and quantity of the leased new virtual machines and the mapping method to the virtual machines are determined by The pre-stored variable-sized bin pack problem (VSBPP) is solved. Among them, the newly added service instances are items in VSBPP, and the types of virtual machines that can be rented are boxes of different capacities.

Specifically, the deployment module 34 uses VSBPP solving algorithms such as the FFDLS algorithm and the IFFD algorithm to solve the type and quantity of the leased new virtual machine and the mapping method to the virtual machine. After obtaining the solution of the pre-stored variable-size bin packing problem, calculate the remaining resource amount for each newly leased virtual machine, that is, the total amount of resources owned by the virtual machine minus the amount of resources occupied by the service instance, and according to this The proportion of the required resources of the newly added service instances on the virtual machine, and the remaining resources are allocated to the newly added service instances in proportion.

In this embodiment, the specific computing processes in the monitoring module 31 , the container type determination module 32 , the scheduling scheme forming module 33 and the deployment module 34 in the elastic scaling system 3 of the microservice system in the cloud environment are as in the microservice system in the cloud environment. It is the same as that described in the elastic scaling method of , and will not be repeated here.

It should be noted that it should be understood that the division of each module of the above system is only a division of logical functions, and may be fully or partially integrated into a physical entity in actual implementation, or may be physically separated. And these modules can all be implemented in the form of software calling through processing elements, or all of them can be implemented in hardware, and some modules can be implemented in the form of calling software through processing elements, and some modules can be implemented in hardware. For example, the x module may be a separately established processing element, or may be integrated in a certain chip of the above-mentioned system to be implemented. In addition, the x module can also be stored in the memory of the above-mentioned system in the form of program code, and is called by a certain processing element of the above-mentioned system to execute the function of the above-mentioned x module. The implementation of other modules is similar. All or part of these modules can be integrated together or implemented independently. The processing element described here may be an integrated circuit with signal processing capability. In the implementation process, each step of the above-mentioned method or each of the above-mentioned modules can be completed by an integrated logic circuit of hardware in the processor element or an instruction in the form of software. The above modules may be one or more integrated circuits configured to implement the above methods, such as: one or more specific integrated circuits (Application Specific Integrated Circuit, ASIC for short), one or more microprocessors (Digital Singnal Processor, DSP for short), one or more Field Programmable Gate Arrays (FPGA for short), etc. When one of the above modules is implemented in the form of a processing element scheduler code, the processing element may be a general-purpose processor, such as a central processing unit (Central Processing Unit, CPU for short) or other processors that can call program codes. These modules can be integrated together and implemented in the form of a System-on-a-chip (SOC for short).

Embodiment 2

This embodiment provides a device, the device includes: a processor, a memory, a transceiver, a communication interface or/and a system bus; the memory and the communication interface are connected to the processor and the transceiver through the system bus and complete mutual communication, The memory is used to store the computer program, the communication interface is used to communicate with other devices, the processor and the transceiver are used to run the computer program, so that the device executes each step of the elastic scaling method of the microservice system in the cloud environment as described above.

The system bus mentioned above may be a Peripheral Component Interconnect (PCI for short) bus or an Extended Industry Standard Architecture (EISA for short) bus or the like. The system bus can be divided into address bus, data bus, control bus and so on. For ease of presentation, only one thick line is used in the figure, but it does not mean that there is only one bus or one type of bus. The communication interface is used to realize the communication between the database access device and other devices (such as client, read-write library and read-only library). The memory may include random access memory (Random Access Memory, RAM for short), and may also include non-volatile memory (non-volatile memory), such as at least one disk storage.

The above-mentioned processor may be a general-purpose processor, including a central processing unit (Central Processing Unit, referred to as CPU), a network processor (Network Processor, referred to as NP), etc.; may also be a digital signal processor (Digital Signal Processing, referred to as DSP) , Application Specific Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, and discrete hardware components.

The protection scope of the elastic scaling method of the microservice system in the cloud environment according to the present invention is not limited to the execution sequence of the steps listed in this embodiment. All solutions are included in the protection scope of the present invention.

The present invention also provides an elastic scaling system for a microservice system in a cloud environment. The elastic scaling system for a microservice system in a cloud environment can implement the elastic scaling method for a microservice system in a cloud environment described in the present invention. The implementation device of the elastic scaling method of the microservice system in the cloud environment includes but is not limited to the structure of the elastic scaling system of the microservice system in the cloud environment enumerated in this embodiment. The structural deformation and replacement are all included in the protection scope of the present invention.

To sum up, the elastic scaling method, system, medium and device of a microservice system in a cloud environment according to the present invention have the following beneficial effects:

Third, the present invention comprehensively considers the overall structure of the workflow, calculates the optimal cost-effective container type for each microservice, and divides the deadline based on this, which improves the reliability of deadline division and improves the performance of the algorithm. The invention effectively overcomes various shortcomings in the prior art and has high industrial utilization value.

The above-mentioned embodiments merely illustrate the principles and effects of the present invention, but are not intended to limit the present invention. Anyone skilled in the art can modify or change the above embodiments without departing from the spirit and scope of the present invention. Therefore, all equivalent modifications or changes made by those with ordinary knowledge in the technical field without departing from the spirit and technical idea disclosed in the present invention should still be covered by the claims of the present invention.

Claims

A method for elastic scaling of a microservice system in a cloud environment, characterized in that the microservice system in the cloud environment includes a microservice instance layer and a virtual machine layer, and each microservice instance is encapsulated in a container and deployed in a On the virtual machine; the elastic scaling method of the microservice system in the cloud environment includes:

Monitoring the work attribute information of each microservice instance in the microservice system in the cloud environment;

Before and during the operation of the microservice system, determine the optimal cost-effective container type for each microservice instance;

Based on the task workflow and the best cost-effective container type for each microservice instance, the task scheduling scheme is formed;

The scheduling scheme of the task is read to obtain the type and quantity of the newly added microservice instance, and the newly added microservice instance is deployed on the leased or newly added virtual machine.
The elastic scaling method for a microservice system in a cloud environment according to claim 1, wherein the work attribute information of each microservice instance includes the actual response time of the microservice instance and/or the end-to-end workflow of the work flow Response time.
The elastic scaling method of a microservice system in a cloud environment according to claim 2, wherein the step of monitoring the work attribute information of each microservice instance in the microservice system in the cloud environment further comprises: according to the work The deadline defined by the stream is used to determine whether the task has timed out, and if it times out, the delay time is stored.
The elastic scaling method of a microservice system in a cloud environment according to claim 2, wherein before the step of determining the optimal cost-effective container type for each microservice instance is performed, the elasticity of the microservice system in the cloud environment Scaling methods also include:

Calculate the average execution time for each microservice instance, the average data transfer volume and communication latency between microservice instances.
The elastic scaling method of a microservice system in a cloud environment according to claim 2, wherein the step of determining the optimal cost-effective container type for each microservice instance comprises:

Initialize container types corresponding to all types of microservice instances;

Calculate the expected completion time of the workflow under the current container type;

When the expected completion time is greater than the deadline of the workflow, calculate the revenue ratio when the container type corresponding to the i-th microservice instance is replaced with a type with more resources and a higher price.
The elastic scaling method of a microservice system in a cloud environment according to claim 5, wherein the task scheduling scheme is formed on the basis of the task workflow and the optimal cost-effective container type for each microservice instance. Steps include:

Extract the running speed of the optimal cost-effective container type corresponding to each microservice instance, calculate the ranking of each task in the workflow, and calculate the sub-deadline of each task based on the ranking of the tasks;

When multiple workflows need to be scheduled in a scheduling cycle and there is competition for microservice instances among multiple workflows, the multiple workflows can be integrated into a single workflow by adding unified entry tasks and exit tasks;

Calculate the expected completion time of each ready task in the workflow; the ready task is a task that has been executed and completed by all predecessor tasks;

Based on the sub-deadline time of each task, the expected completion time of each ready task and the number of subsequent tasks, the scheduling urgency of the ready task is calculated, and the ready task corresponding to the minimum value of the scheduling urgency is selected as the subsequent scheduling object;

Traverse all microservice instances that can execute the task, and determine whether the task can meet the sub-deadline; determine whether the task can meet the sub-deadline by calculating the task slack;

When the task slack is a non-negative number, it means that there are some microservice instances that can complete the task before the sub-deadline, then calculate the cost increase caused by scheduling the task to the microservice instance, The task is scheduled to the microservice instance corresponding to the minimum cost increase;

When the task slack is a negative number, it means that all the microservice instances cannot meet the sub-deadline, and then calculate the minimum microservice instance computing speed required to complete the task before the sub-deadline, so as to calculate the minimum microservice instance calculation speed according to the minimum microservice Instance computing speed, create a new microservice instance;

If a new microservice instance is created, the leased virtual machines are traversed, and the virtual machine loaded with the container image required by the microservice instance is selected, and the virtual machine with the smallest difference between the remaining resources of the virtual machine and the resources required by the container is selected. , and deploy the new microservice instance to the virtual machine;

Return to the step of calculating the expected completion time of each ready task in the workflow.
The elastic scaling method for a microservice system in a cloud environment according to claim 6, wherein the elastic scaling method for a microservice system in the cloud environment further comprises:

When the leased virtual machines are not enough to deploy all the newly added microservice instances, the new virtual machines are leased to deploy the remaining undeployed microservice instances; the type, quantity and mapping method of the leased new virtual machines to virtual machines are determined by Pre-stored variable-size bin packing problem is solved.
An elastic scaling system for a microservice system in a cloud environment, characterized in that the microservice system in the cloud environment includes a microservice instance layer and a virtual machine layer, and each microservice instance is packaged in a container and deployed in a On a virtual machine; the elastic scaling system of the microservice system in the cloud environment includes:

a monitoring module for monitoring the work attribute information of each microservice instance in the microservice system in the cloud environment;

A container type determination module, used to determine the optimal cost-effective container type for each microservice instance before and during the operation of the microservice system;

The scheduling scheme forming module is used to form the scheduling scheme of the task based on the workflow of the task and the best cost-effective container type for each microservice instance;

The deployment module is used for reading the scheduling scheme of the task, so as to obtain the type and quantity of the newly added microservice instance, and deploy the newly added microservice instance on the leased or newly added virtual machine.
A medium on which a computer program is stored, characterized in that, when the computer program is executed by a processor, the method for elastic scaling of a microservice system in a cloud environment according to any one of claims 1 to 7 is implemented.
A device, characterized in that it includes: a processor and a memory;

The memory is used for storing a computer program, and the processor is used for executing the computer program stored in the memory, so that the device executes the elastic scaling of the microservice system in the cloud environment according to any one of claims 1 to 7 method.