WO2018137585A1 - 扩容方法及扩容装置 - Google Patents

扩容方法及扩容装置 Download PDF

Info

Publication number
WO2018137585A1
WO2018137585A1 PCT/CN2018/073672 CN2018073672W WO2018137585A1 WO 2018137585 A1 WO2018137585 A1 WO 2018137585A1 CN 2018073672 W CN2018073672 W CN 2018073672W WO 2018137585 A1 WO2018137585 A1 WO 2018137585A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
workload
services
application
target
Prior art date
Application number
PCT/CN2018/073672
Other languages
English (en)
French (fr)
Inventor
卓东辉
徐俊
单海军
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2018137585A1 publication Critical patent/WO2018137585A1/zh
Priority to US16/523,028 priority Critical patent/US11216310B2/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3006—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5072—Grid computing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5083—Techniques for rebalancing the load in a distributed system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N20/00—Machine learning
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N5/00—Computing arrangements using knowledge-based models
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N5/00—Computing arrangements using knowledge-based models
    • G06N5/02—Knowledge representation; Symbolic representation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/5019—Workload prediction

Definitions

  • the present application relates to the field of communications technologies, and in particular, to a method for expanding a capacity and a device for expanding a capacity.
  • PaaS Platform as a Service
  • PaaS Platform as a Service
  • the expansion in PaaS is provided by the Auto Scaling mechanism, and the existing elastic scaling mechanism is controlled by a single service.
  • each service's elastic scaling controller can dynamically add or release resources for the service according to the actual workload requirements according to the elastic scaling mechanism.
  • Micro-service emphasizes the decomposition of an application into many small services, and the development and maintenance of each service is independent. Services communicate via a lightweight network protocol. Multiple services call each other to implement the functionality of the application.
  • an application is decomposed into multiple microservices, the overall complexity of the application is reduced, but at the same time, new requirements are imposed on the elastic expansion of resources.
  • an application includes service A, service B, service C, service D, and service E.
  • resources of the application can be expanded step by step. Service request is first expanded to service A. Before service A is expanded, service B cannot sense the need for capacity expansion.
  • the embodiment of the present application provides a capacity expansion method and a capacity expansion device, which solves the problem of low rate of step-by-step capacity expansion in the prior art.
  • a method for expanding a volume comprising: obtaining a measured workload of a first service of an application and an application model of the application, wherein the application model includes a call relationship between all services of the application and the call a ratio of workload corresponding to each call relationship in the relationship, the first service serving any one of the services; according to the first service of the first service and the first service of the first service in the application model Invoking a relationship, determining each of the upper-level services of the first service; and determining, according to the second calling relationship of the first service and each of the sub-services of the first service in the application model, determining each of the first services a subordinate service; obtaining a measured workload of each of the upper level services of the first service; determining a workload based on the first service, a measured workload of each of the upper services of the first service, and a first workload ratio corresponding to the first calling relationship, determining a predicted workload of the first service; and a predicted workload according to the first service and a
  • the expansion method provided by the embodiment of the present application expands the application model, and the application model can represent the calling relationship between the services of the application and the workload ratio corresponding to the calling relationship, so the expansion device can be based on the application model of the application. Predicting the forecasting workload of any service of the application, and obtaining the forecasting workload of all the target services, and then simultaneously expanding all the target services according to the predicted workload of all the target services, compared with the prior art
  • the method of capacity expansion increases the rate of capacity expansion, which in turn can quickly improve the overall performance of the application in a short period of time, further ensuring SLA indicators such as application reliability, throughput, and response delay.
  • the method before the acquiring the application model, further includes: acquiring a service interface description file of each service of the all services and a configuration file of each service, where each service The service interface description file includes a name of each service, and the configuration file of each service includes a calling relationship between the each service and a next-level service of each service; according to each service and each service The calling relationship between the next-level services, determining the calling relationship between the all services; obtaining the workload history of each service according to the name of each service, according to the workload history and all the services The calling relationship determines the proportion of the workload corresponding to each of the calling relationships; the application model is generated according to the calling relationship between the all services and the workload ratio corresponding to each calling relationship.
  • the application model generation method determines the calling relationship of all services of the application through the service interface description file and the configuration file of the service, and calculates the workload corresponding to each calling relationship according to the calling relationship of all services.
  • the scale determines the application model for the application.
  • the application model can represent the calling relationship between the services of the application and the workload ratio corresponding to the calling relationship, so the expansion device can predict the predicted workload of any service of the application according to the application model of the application.
  • the overall performance of the application can be quickly improved in a short period of time, and the SLA indicators such as reliability, throughput, and response delay of the application are further ensured.
  • the workload history record of each service is obtained according to the name of each service, and the workload ratio corresponding to each call relationship is updated according to the workload history record and each call relationship.
  • the application model is updated according to the per-call relationship and the updated workload ratio corresponding to each of the call relationships.
  • the application model update method provided by the embodiment of the present application can update the workload ratio corresponding to each call relationship in the application model by acquiring the workload history record of each service, so that the application model can more accurately reflect the service between the services.
  • the change in the workload ratio allows for more accurate expansion scenarios while rapidly expanding capacity, thus ensuring SLAs such as application reliability, throughput, and response latency.
  • the service interface description file and the configuration file of the third service are obtained, and each fourth service in the at least one fourth service is updated.
  • a configuration file wherein the service interface description file of the third service includes a name of the third service, and the configuration file of the third service includes a third call of the third service and each of the at least one fifth service a relationship, the configuration file after each fourth service update includes a fourth call relationship of the fourth service and the third service, and the fourth service is a higher level service of the third service, the fifth service For the next level service of the third service; updating the calling relationship between all the services according to the application model, the third calling relationship, and the fourth calling relationship; according to each of all the services of the updated application
  • the name of the service obtains the workload history of each service of all the services of the application after the update, according to the workload of each service of all the services of the updated application
  • the calling relationship between the history record and the updated all services determines the workload ratio corresponding to each calling relationship in the
  • the model updating method provided by the embodiment of the present application can make the application model more accurately reflect the change of the calling relationship and the workload ratio after the application is updated, by updating all the calling relationships and the workload ratio of the application when the application adds the service, and then When capacity expansion is required, a more accurate expansion example can be obtained while rapidly expanding, thereby ensuring SLA indicators such as application reliability, throughput, and response delay.
  • the configuration file of each seventh service update in the at least one seventh service is obtained, where before the application deletes the sixth service, The seventh service is a higher-level service of the sixth service, and after the application deletes the sixth service, the configuration file of each seventh service update includes the seventh service and the at least one eighth service.
  • the eighth service is a next level service of the seventh service; updating the calling relationship between the all services according to the application model and the fifth calling relationship; according to the updated service of the application
  • the name of each service in the service obtains the workload history of each service of all the services of the update, according to the updated workload history of each service of the application and the updated
  • the calling relationship between all services determines the proportion of the workload corresponding to each calling relationship in the calling relationship between the updated all services; according to the updated office Call relations effort proportional relationship between the call and the service and all the updated call each corresponding relationship between the service update application model of the application.
  • the model updating method provided by the embodiment of the present application can make the application model more accurately reflect the change of the calling relationship and the workload ratio after the application is updated by updating all the calling relationships and the workload ratios of the application when the application is deleted.
  • capacity expansion is required, a more accurate expansion example can be obtained while rapidly expanding, thereby ensuring SLA indicators such as application reliability, throughput, and response delay.
  • the embodiment of the present application provides a specific implementation for determining a predicted workload of the first service.
  • ⁇ k ⁇ K f(k)*e ki represents the workload of service i calculated from f(k) and e ki
  • max(d(v i ), ⁇ k ⁇ K f(k)*e ki ) Indicates that the larger value of ⁇ k ⁇ K f(k)*e ki and d(v i ) is determined as the predicted workload of service i, since the measured workload of the upper-level service based on the first service is considered
  • the workload of the first service and the measured workload of the first service are both factors, so that a more accurate prediction workload of the first service can be obtained, thereby obtaining a more accurate number of expansion instances, which further ensures the application.
  • SLA indicators such as reliability, throughput, and response latency.
  • the each target service is expanded according to a predicted workload of each target service in all target services, including: a predicted workload according to the each target service, and the pre-stored each
  • the corresponding relationship between the workload of the target service and the number of instances is determined as the first instance number of each target service expansion, and the target service is expanded according to the first instance number.
  • the expansion method provided by the embodiment of the present application, by comparing the correspondence between the workload and the pre-stored workload and the number of instances, the number of instances of the expansion can be determined more accurately, and the application can be further expanded while obtaining more Accurate expansion scenarios ensure SLA metrics such as application reliability, throughput, and response latency.
  • the method before the each target service is expanded according to the first instance number, the method further includes: obtaining resource utilization of each target service; and if the resource utilization of each target service And exceeding a preset threshold, determining, according to a pre-stored correspondence between the resource utilization of each target service and the number of instances, a second instance number for each target service expansion; according to the first instance number and the second instance number Determine the number of target instances to be expanded for each target service, and expand each target service based on the number of target instances.
  • the expansion method provided by the embodiment of the present application, when the application is expanded, the number of instances obtained according to the resource utilization rate, the number of instances determined by the predicted workload, and the instance obtained according to the resource utilization rate may be determined according to resource utilization ratio of each service. The number can be used to obtain a more accurate number of target expansion instances, which further enables the application to rapidly expand based on more accurate expansion instances, thereby ensuring SLA indicators such as application reliability, throughput, and response delay.
  • the number of target instances determined to be expanded for each target service according to the first instance number and the second instance number includes: if the first instance number is greater than the second instance number, Determining that the first instance number is a target instance number for each target service expansion; if the first instance number is not greater than the second instance number, determining that the second instance number is a target for expanding each target service The number of instances.
  • the number of target instances to be expanded is determined in two ways, and the application expansion can be satisfied by using multiple conditions. The comparison of the number of target instances determined by two different methods can be obtained under the premise of rapid expansion. The number of more accurate expansions can further enable the application to rapidly expand and obtain more accurate expansion instances, thus ensuring SLA indicators such as application reliability, throughput, and response delay.
  • a capacity expansion device includes: a workload estimator and a telescopic controller; the workload estimator is configured to: acquire a measured workload of the first service of the application and an application model of the application, where The application model includes a call relationship between all services of the application and a workload ratio corresponding to each call relationship in the call relationship, the first service serving any one of the services; according to the application model Determining, by the first call relationship of the first service and each of the upper-level services of the first service, each upper-level service of the first service; and, according to the first service and the first service in the application model a second calling relationship of each of the subordinate services, determining each subordinate service of the first service; obtaining a measured workload of each of the upper level services of the first service; and according to the measured workload of the first service, Determining the predicted workload of the first service by the measured workload of each of the upper-level services of the first service and the first workload ratio corresponding to the first call relationship; Determining a predicted
  • the expansion device further includes: a model generator, configured to: obtain a service interface description file of each service of the all services, and a configuration file of each service, where each The service interface description file of each service includes the name of each service, and the configuration file of each service includes a calling relationship between the each service and the next level service of each service; according to each service and the a calling relationship between the next-level services of each service, determining a calling relationship between the all services; obtaining a workload history record of each service according to the name of each service, according to the workload history and the The calling relationship between all the services determines the proportion of the workload corresponding to each of the calling relationships; the application model is generated according to the calling relationship between the all services and the workload ratio corresponding to each calling relationship.
  • a model generator configured to: obtain a service interface description file of each service of the all services, and a configuration file of each service, where each The service interface description file of each service includes the name of each service, and the configuration file of each service includes a calling relationship between the each service and the next level
  • the expansion device further includes: a model updater, configured to: obtain a workload history record of each service according to the name of each service, according to the workload history record and the Each call relationship updates the proportion of the workload corresponding to each call relationship; and updates the application model according to each call relationship and the updated workload ratio corresponding to each call relationship.
  • a model updater configured to: obtain a workload history record of each service according to the name of each service, according to the workload history record and the Each call relationship updates the proportion of the workload corresponding to each call relationship; and updates the application model according to each call relationship and the updated workload ratio corresponding to each call relationship.
  • the expansion device further includes: a model updater, configured to: obtain a service interface description file and a configuration file of the third service if a third service is added to the updated application And a configuration file after each fourth service update in the at least one fourth service, wherein the service interface description file of the third service includes a name of the third service, and the configuration file of the third service includes the third service And a third calling relationship of each of the at least one fifth service, the configuration file after each fourth service update includes a fourth calling relationship of the fourth service and the third service, the fourth The service is a higher-level service of the third service, and the fifth service is a next-level service of the third service; and the service is updated according to the application model, the third call relationship, and the fourth call relationship Call relationship; obtain the workload history of each service of all the services of the updated application according to the name of each service in all the services of the updated application, Determining, according to the workload relationship of each service in all the services of the updated application, and the calling relationship between the updated services
  • the expansion device further includes: a model updater, configured to: acquire the seventh service update in the at least one seventh service, if the sixth service is deleted in the updated application a configuration file, wherein, before the application deletes the sixth service, the seventh service is a higher-level service of the sixth service, and after the application deletes the sixth service, the configuration after each seventh service update
  • the file includes a fifth calling relationship of each of the seventh service and the at least one eighth service, where the eighth service is a next level service of the seventh service; updating the all according to the application model and the fifth calling relationship
  • the calling relationship between the services obtaining the workload history of each of the services of the updated application according to the updated name of each service of the application, according to the updated application of the application
  • the invocation relationship between the workload history of each service in all services and the updated all services is determined in the calling relationship with all the services after the update The proportion of the workload corresponding to the calling relationship; updating the application according to the updated calling relationship between the calling relationships of all the services and the workload ratio corresponding to each calling
  • the scaling controller is specifically configured to: determine, according to the predicted workload of each target service, and the pre-stored correspondence between the workload of each target service and the number of instances, The number of the first instance of the target service is expanded, and the target service is expanded according to the first instance number.
  • the scaling controller is further configured to: before the each target service is expanded according to the first instance number, obtain resource utilization of each target service; if the target service is The resource utilization exceeds a preset threshold, and the second instance number of each target service expansion is determined according to the pre-stored correspondence between the resource utilization of each target service and the number of instances; according to the first instance number and the first The second instance number is determined as the number of target instances for each target service expansion, and the target service is expanded according to the target instance number.
  • the scaling controller is specifically configured to: if the first instance number is greater than the second instance number, determine the first instance number as the number of target instances for each target service expansion; The first instance number is not greater than the second instance number, and the second instance number is determined to be the number of target instances for each target service expansion.
  • an embodiment of the present application provides a capacity expansion device, including: a processor, a memory, a bus, and a communication interface; the memory is configured to store a computer execution instruction, and the processor is connected to the memory through the bus, and the expansion device is In operation, the processor executes the computer-executed instructions stored in the memory to cause the expansion device to perform the expansion method of any of the above.
  • the embodiment of the present application provides a computer storage medium for storing computer software instructions used in the expansion method of any one of the above, which comprises a program designed to execute any of the foregoing expansion methods.
  • an embodiment of the present application provides a computer program, where the computer program includes instructions, when the computer program is executed by a computer, to enable a computer to execute the flow in the expansion method of any of the above.
  • FIG. 1 is a schematic diagram of a method for expanding a current elastic mechanism
  • FIG. 2 is a schematic diagram of an application model provided by an embodiment of the present application.
  • FIG. 3 is a schematic structural diagram of a capacity expansion device according to an embodiment of the present disclosure.
  • FIG. 4 is a schematic diagram of a computer device according to an embodiment of the present application.
  • FIG. 5 is a schematic diagram of a specific implementation of generating an application model according to an embodiment of the present application.
  • FIG. 6 is a schematic diagram of generating an application model according to an embodiment of the present application.
  • FIG. 7 is a schematic diagram of an update application model according to an embodiment of the present application.
  • FIG. 8 is a schematic diagram of still another update application model according to an embodiment of the present application.
  • FIG. 9 is a schematic diagram of still another update application model provided by an embodiment of the present application.
  • FIG. 10 is a schematic flowchart of a method for expanding a capacity according to an embodiment of the present disclosure
  • FIG. 11 is a schematic flowchart of a prediction workload according to an embodiment of the present application.
  • FIG. 12 is a schematic flowchart of still another method for expanding a capacity according to an embodiment of the present disclosure.
  • FIG. 13 is a schematic flowchart of still another method for expanding a capacity according to an embodiment of the present disclosure
  • FIG. 14 is an internal structural diagram of a telescopic controller according to an embodiment of the present disclosure.
  • FIG. 15 is a schematic flowchart of still another method for expanding a capacity according to an embodiment of the present application.
  • an application is an executable file connected by a function library that provides all the functions of the application.
  • a service in an application is executed by multiple instances, each instance being called a service instance of the service, each service instance being an execution unit of the service, and an execution unit performing a fixed workload.
  • Application model a directed graph composed of nodes, edges and edge weights, as shown in FIG. 2 , is a schematic diagram of an application model provided by an embodiment of the present application.
  • the application model may be divided into a coarse-grained model and a fine-grained model.
  • each node in the coarse-grained model represents a service
  • each directed edge represents a calling relationship between services
  • the edge weight represents the proportion of the workload generated by the service in the call.
  • FIG. 2A of FIG. 2 a schematic diagram of a coarse-grained application model provided by an embodiment of the present application, where node A represents service A, node B represents service B, node C represents service C, node D represents service D, and node E represents service.
  • one workload on service A requires two workloads of service B and two workloads of service C.
  • One workload on service B requires one workload of service D, and one service on service C.
  • the workload requires 1 workload for Service E.
  • Each node in the fine-grained model represents each function in each service in an application, each directed edge represents a calling relationship between functions, and the edge weight represents the proportion of the workload generated by the function in the call.
  • 2B in FIG. 2 is a partial application model corresponding to service S in application Y
  • node A.op represents a service in application Y.
  • the functions A and B.op of S indicate the function B of the service S in the application Y
  • C.op indicates the function C of the service S in the application Y
  • D.op indicates the function D and E.op of the service S in the application Y.
  • One workload on function A requires two workloads of function B and two workloads of function C.
  • One workload on function B requires one workload of function D, and one workload on function C.
  • a workload of function E is required.
  • the fine-grained model predicts a more accurate workload, but the maintenance cost is higher, and the coarse-grained model predicts a general workload, but the maintenance is convenient, and the current coarse expansion can solve the problem of slow expansion.
  • the coarse-grained model is the same as the method of establishing and maintaining the fine-grained model. Therefore, the coarse-grained model is taken as an example for description in the embodiment of the present application.
  • a component can be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread in execution, a program, and/or a computer.
  • an application running on a computer device and the computer device can be a component.
  • One or more components can reside within a process and/or thread of execution, and the components can be located in a computer and/or distributed between two or more computers. Moreover, these components can execute from various computer readable media having various data structures thereon.
  • These components may be passed, for example, by having one or more data packets (eg, data from one component that interacts with the local system, another component of the distributed system, and/or signaled through, such as the Internet)
  • the network interacts with other systems to communicate in a local and/or remote process.
  • the application 1 includes five services, namely, service A, service B, service C, service D, and service E.
  • service A is the upper level service of service B and service C
  • service B is the upper level service of service D
  • service C is the upper level service of service E
  • service B, service C, service D and service E are All the subordinate services of service A need to take a long time to complete the overall expansion of the application according to the existing step-by-step expansion mode.
  • the waiting time for the user to request the application service is too long, and the response of the application service is not obtained.
  • the experience is poor. Therefore, how to increase the rate of capacity expansion is an urgent problem to be solved.
  • the embodiment of the present application provides a method and an apparatus for expanding a capacity, which can simultaneously expand the service in the application, thereby increasing the rate of the expansion.
  • the embodiment of the present application adopts the following technical solutions:
  • FIG. 3 is a schematic structural diagram of a capacity expansion device provided by an embodiment of the present application.
  • the expansion device 300 includes a telescopic controller 310 and a workload estimator 320.
  • the scaling controller 310 is configured to determine the target expansion number according to the predicted workload of the corresponding target service and expand the target service.
  • the scaling controller of the service A is configured to determine the target expansion number of the service A according to the predicted workload of the service A.
  • the service A is expanded.
  • the telescopic controller of the service B is used to determine the target expansion number of the service B and expand the service B according to the predicted workload of the service B.
  • the telescopic controller of the service C is used to determine the predicted workload according to the service C.
  • the service expansion number of the service C is expanded and the service C is expanded, and the like; the workload estimator 320 is configured to estimate the predicted workload of all the target services according to the application model, for example, the workload estimator 320 estimates the service A and the service B according to the application model. , the forecast workload of services such as service C.
  • the specific method of capacity expansion and the manner of workload prediction will be described in the following method embodiments, and details are not described herein again.
  • the application model in the embodiment of the present application may be an application model generated by the model generator 331 or an application model updated by the model updater 332, which is not specifically limited in this embodiment of the present application.
  • the specific manner of generating the application model and the manner of updating the application model will be explained in the following method embodiments, and details are not described herein again.
  • model generator 331 and the model updater 332 in FIG. 3 may be integrated in the expansion device provided in the embodiment of the present application, and may be deployed independently from the expansion device provided in the embodiment of the present application. limited.
  • the queue in each service is used to cache the work that the service needs to process, and the thread in each service is used to process the work in the service, and the monitor in each service is used to
  • the capacity expansion device 300 transmits the workload, which is collectively described herein, and will not be described below.
  • the service expansion device in the embodiment of the present application can be implemented by the computer device (or system) in FIG.
  • FIG. 4 is a schematic diagram of a computer device according to an embodiment of the present application.
  • Computer device 400 includes at least one processor 401, a communication bus 402, a memory 403, and at least one communication interface 404.
  • the processor 401 can be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more programs for controlling the execution of the program of the present application. integrated circuit.
  • CPU central processing unit
  • ASIC application-specific integrated circuit
  • Communication bus 402 can include a path for communicating information between the components described above.
  • the communication interface 404 uses a device such as any transceiver for communicating with other devices or communication networks, such as Ethernet, Radio Access Network (RAN), Wireless Local Area Networks (WLAN), etc. .
  • a device such as any transceiver for communicating with other devices or communication networks, such as Ethernet, Radio Access Network (RAN), Wireless Local Area Networks (WLAN), etc. .
  • RAN Radio Access Network
  • WLAN Wireless Local Area Networks
  • the memory 403 may be a Read-Only Memory (ROM) or other type of static storage device that can store static information and instructions, a Random Access Memory (RAM) or other type that can store information and instructions.
  • the dynamic storage device can also be an Electrically Erasable Programmable Read-Only Memory (EEPROM), a Compact Disc Read-Only Memory (CD-ROM) or other optical disc storage, and a disc storage device. (including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or can be used to carry or store desired program code in the form of instructions or data structures and can be Any other media accessed, but not limited to this.
  • the memory can exist independently and be connected to the processor via a bus. The memory can also be integrated with the processor.
  • the memory 403 is used to store application code for executing the solution of the present application, and is controlled by the processor 401 for execution.
  • the processor 401 is configured to execute the application code stored in the memory 403, thereby implementing the alarm method in the embodiment of the present application.
  • the processor 401 may include one or more CPUs, such as CPU0 and CPU1 in FIG.
  • computer device 400 can include multiple processors, such as processor 401 and processor 408 in FIG. Each of these processors can be a single-CPU processor or a multi-core processor.
  • a processor herein may refer to one or more devices, circuits, and/or processing cores for processing data, such as computer program instructions.
  • computer device 400 may also include an output device 405 and an input device 406.
  • Output device 405 is in communication with processor 401 and can display information in a variety of ways.
  • the output device 305 can be a liquid crystal display (LCD), a light emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector.
  • Input device 406 is in communication with processor 401 and can accept user input in a variety of ways.
  • input device 406 can be a mouse, keyboard, touch screen device, or sensing device, and the like.
  • the computer device 400 described above can be a general purpose computer device or a special purpose computer device.
  • the computer device 400 can be a desktop computer, a portable computer, a network server, a personal digital assistant (PDA), a mobile phone, a tablet, a wireless terminal device, a communication device, an embedded device, or have the following FIG. A device of similar structure.
  • PDA personal digital assistant
  • the embodiment of the present application does not limit the type of computer device 400.
  • the generation process of the application model is first given as follows.
  • the model generator 331 generates an application model, including steps K1-K4:
  • K1 Get the service interface description file for each service in all services and the configuration file for each service.
  • the service interface description file of each service includes the name of each service, and the configuration file of each service includes a calling relationship between each service and a next-level service of each service.
  • K2 Determine the calling relationship between all services based on the calling relationship between each service and the next-level service of each service.
  • K3 Obtain the workload history of each service according to the name of each service, and determine the workload ratio corresponding to each calling relationship according to the workload history and the calling relationship between all services.
  • K4 Generate an application model based on the calling relationship between all services and the workload ratio corresponding to each calling relationship.
  • 5A in FIG. 5 is a schematic diagram of an implementation process for determining a calling relationship of all services in an application.
  • WSDL Web Service Description Language
  • the model generator 331 creates an empty model to determine whether there is an unprocessed service. If there is an unprocessed service, the model generator 331 acquires the WSDL file of the service and extracts the service name from the WSDL file. Further, the model generator 331 adds a new node to the service in the model according to the service name, and acquires a configuration file (config file) of the service.
  • config file configuration file
  • model generator 331 extracts the calling relationship of the service in the config file and the next-level service of the service, and adds an edge to each calling relationship in the model.
  • the model generator 331 can determine the calling relationship between all the services in the application model.
  • the calling relationship between all services can be confirmed after the application development is completed, and is usually reconfirmed only after the application's service is updated.
  • the service update of the application includes adding services or reducing services.
  • 5B in FIG. 5 is a schematic diagram of an implementation process for generating an application model according to a call relationship and a workload ratio between all services.
  • the model generator 331 acquires the workload history record of each service.
  • the workload history data is recorded by recording the number of Query Per Second (QPS) data processed per second per service.
  • QPS Query Per Second
  • Second calculate the total QPS data for each service and add the total QPS data for each service to the history table.
  • the workload ratio between the various services is calculated from the historical data.
  • the workload ratio is updated to the weight on the edge corresponding to each call relationship in the call relationship between all services, and after the respective services of the application are processed, the model generator 331 generates the application model.
  • application 1 measures the processing power of each instance of the service through QPS data. It is assumed that the processing capability of each instance of service A is 160 QPS, the processing capability of each instance of service B is 300 QPS, the processing capability of each instance of service C is 500 QPS, and the processing capability of each instance of service D is 500 QPS, service E.
  • the processing power of each instance is 800 QPS.
  • the service interface description files of the service A, the service B, the service C, the service D, and the service E respectively include the names of the service A, the service B, the service C, the service D, and the service E.
  • the configuration file of the service A includes the calling relationship 1 of the service A and the service B, and the calling relationship 2 of the service A and the service C.
  • the configuration file of the service B includes the calling relationship 3 of the service B and the service D; the configuration file of the service C The calling relationship 4 of the service C and the service E is included; the configuration file of the service D includes the calling relationship 5 in which the service D is empty; and the configuration file of the service E includes the calling relationship 6 in which the service E is empty.
  • the model generator 331 can then generate an application model by:
  • the model generator 331 acquires the service interface description files of the service A, the service B, the service C, the service D, and the service E in the application 1, and the configuration files of the service A, the service B, the service C, the service D, and the service E.
  • the model generator 331 can be according to the method of 6A in FIG. 6, according to the names in the service interface description files of the service A, the service B, the service C, the service D, and the service E, respectively, the service A, the service B, and the service C.
  • service D and service E generate a node, according to service A, service B, service C, service D and service E configuration file in the call relationship 1, call relationship 2, call relationship 3, call relationship 4, call relationship 5 and
  • the call relationship 6 generates an edge for each call relationship, and it can be concluded that the call relationship shown in 6A in FIG. 6 is: service A calls service B and service C, service B calls service D, and service C calls service E.
  • Table 1 is the workload history 1 of the application 1 at time T1, wherein the workload history of each instance of each service at time T1 is as shown in Table 1:
  • the total workload of application 1 on each service at time T1 is: service A-200QPS, service B-600QPS, service C-600QPS, service D-1200QPS, and service E-600QPS.
  • Table 3 is the workload history 2 of the application 1 at time T2, wherein the workload history of each instance of each service at time T2 is as shown in Table 3:
  • the total workload of Application 1 on each service at time T2 is: Service A-300QPS, Service B-900QPS, Service C-900QPS, Service D-1800QPS, and Service E-900QPS.
  • service A includes 2 instances, respectively A1 and A2; service B includes 3 instances, respectively B1, B2, and B3; service C includes 3 Examples are C1, C2, and C3; Service D includes 4 instances, namely D1, D2, D3, and D4; Service E includes 2 instances, which are E1 and E2, respectively.
  • Service A Service B Service C Service D Service E T1 200QPS 600QPS 600QPS 1200QPS 600QPS T2 300QPS 900QPS 900QPS 1800QPS 900QPS
  • the workload ratio corresponding to each call relationship is used as the weight of the edge of the call relationship in 6A in FIG. 6, and the application model shown in FIG. 6B is obtained.
  • the embodiment of the present application only the workload records of the T1 time and the T2 time are taken as an example for description. In an actual application, the corresponding work of the calling relationship in the application model may be determined according to the workload record of the customized time period.
  • the amount ratio is not specifically limited in the embodiment of the present application.
  • the embodiment of the present application is only an exemplary method for calculating the workload between services in the method of averaging. In practice, other mathematical methods may be used to analyze the workload ratio between services, which is not specifically limited in this embodiment of the present application. .
  • the number of instances of the service A and the service E are both 2.
  • the number of instances of the service B and the service C are both 3, and the number of the service D instances is 4.
  • the processing capability of the instances on the respective services may be the same or different, and the number of the instances on the respective services may be the same or different, which is not specifically limited in this embodiment of the present application.
  • the application model generation method determines the calling relationship of all services of the application through the service interface description file and the configuration file of the service, and calculates the workload corresponding to each calling relationship according to the calling relationship of all services.
  • the scale determines the application model for the application.
  • the application model can represent the calling relationship between the services of the application and the workload ratio corresponding to the calling relationship, so the expansion device can predict the predicted workload of any service of the application according to the application model of the application.
  • the overall performance of the application can be quickly improved in a short period of time, and the service level agreement (SLA) indicators promised to the customer such as reliability, throughput, and response delay of the application are further ensured.
  • SLA service level agreement
  • the model generator 331 is configured to support the execution of steps K1-K4 in the embodiment of the present application.
  • K1-K4 actions may be performed by the processor 401 in the computer device 400 shown in FIG. 4, and the application code stored in the memory 403 is called, which is not limited in this embodiment.
  • the model updater 332 may be used to update the application model, and three specific updates of the application model are given below. the way.
  • the first application model is updated: including steps M1-M3:
  • M1 Get the workload history of each service based on the name of each service.
  • M2 Update the workload ratio corresponding to each call relationship according to the workload history and each call relationship.
  • M3 Update the application model according to each call relationship and the updated workload ratio corresponding to each call relationship.
  • Table 5 is the workload history 3 of the application 1 at the time T3, wherein the workload history of each instance of each service at time T3 is as shown in Table 5:
  • the total workload of Application 1 on each service at time T3 is: Service A-200QPS, Service B-700QPS, Service C-1300QPS, Service D-1400QPS, and Service E-1300QPS.
  • Service A Service B Service C Service D Service E T1 200QPS 600QPS 600QPS 1200QPS 600QPS T2 300QPS 900QPS 900QPS 1800QPS 900QPS T3 200QPS 700QPS 1300QPS 1400QPS 1300QPS
  • the application model update method provided by the embodiment of the present application can update the workload ratio corresponding to each call relationship in the application model by acquiring the workload history record of each service, so that the application model can more accurately reflect the service between the services.
  • the change in the workload ratio allows for more accurate expansion scenarios while rapidly expanding capacity, thus ensuring SLAs such as application reliability, throughput, and response latency.
  • model updater 332 is configured to perform the steps M1-M3 in the foregoing embodiment of the present application.
  • the operations of the above-mentioned M1 - M3 can be performed by the processor 401 in the computer device 400 shown in FIG. 4 to call the application code stored in the memory 403, which is not limited in this embodiment of the present application.
  • W1 If a third service is added to the updated application, obtain a service interface description file and a configuration file of the third service, and a configuration file after each fourth service update in the at least one fourth service.
  • the service interface description file of the third service includes a name of the third service, and the configuration file of the third service includes a third service relationship and a third call relationship of each fifth service of the at least one fifth service, each fourth service
  • the updated configuration file includes a fourth invocation relationship of each of the fourth service and the third service, the fourth service is a higher level service of the third service, and the fifth service is a lower level service of the third service.
  • W2 Update the calling relationship between all services according to the application model, the third calling relationship, and the fourth calling relationship.
  • W3 Obtain the workload history of each service of all the services of the updated application according to the name of each service in all the services of the updated application.
  • W4 determining, according to the calling relationship between each service workload history of all services in the updated application and the updated calling service relationship, the work corresponding to each calling relationship in the calling relationship between all the updated services The proportion.
  • W5 Update the applied application model according to the calling relationship between all the updated services and the workload ratio corresponding to each calling relationship in the calling relationship between all the updated services.
  • the application 1 adds the service F
  • the service interface description file in the service F includes the name of the service F
  • the configuration file of the service F includes the calling relationship 7 of the service F and the service E
  • the service F does not call other services.
  • the model updater 332 updates the calling relationship of the application model shown in FIG. 6A to the application 1 shown in FIG. 7 according to the calling relationship and the calling relationship 7 of the application model shown in FIG. 6A. Call relationship.
  • Table 7 is the workload history 4 of the application 1 at time T4, wherein the historical workload on each instance of each service at time T4 is as shown in Table 7:
  • the workload ratio corresponding to each call relationship is used as the weight of the edge in which the call relationship exists in 8A in FIG. 8, that is, the application model shown in FIG. 8B is obtained.
  • the embodiment of the present application only uses an exemplary workload history record only after one application is added.
  • the application model is updated more accurately after the application is updated.
  • a plurality of workloads may be obtained as needed, and the ratio of the workloads of the respective call relationships may be obtained by other algorithms.
  • This is not specifically limited in the embodiment of the present application; and the workload history to be updated in the embodiment of the present application is further understood for ease of understanding.
  • the data is recorded in the same history table.
  • a new history table may be created to re-record the updated workload historical data, which is not specifically limited in this embodiment of the present application.
  • the model updating method provided by the embodiment of the present application can make the application model more accurately reflect the change of the calling relationship and the workload ratio after the application is updated, by updating all the calling relationships and the workload ratio of the application when the application adds the service, and then When capacity expansion is required, a more accurate expansion example can be obtained while rapidly expanding, thereby ensuring SLA indicators such as application reliability, throughput, and response delay.
  • model updater 332 is configured to perform the steps W1-W5 in the foregoing embodiment of the present application.
  • the operations of the above-mentioned W1-W5 may be performed by the processor 401 in the computer device 400 shown in FIG. 4, and the application code stored in the memory 403 is called, which is not limited in this embodiment.
  • the third application model is updated: including steps P1-P5:
  • the seventh service is the upper-level service of the sixth service before the application deletes the sixth service, and after the application deletes the sixth service, each seventh service updated configuration file includes each seventh service and at least The fifth call relationship of the eighth service, and the eighth service is the next level service of the seventh service.
  • P2 Update the calling relationship between all services according to the application model and the fifth calling relationship.
  • P3 Obtain the workload history of each service in all the services of the updated application according to the name of each service in all the services of the updated application.
  • P4 determining, according to the calling relationship between the workload history of each service and all the updated services among all the services of the updated application, the work corresponding to each calling relationship in the calling relationship between all the updated services The proportion.
  • P5 Update the applied application model according to the calling relationship between all the updated services and the workload ratio corresponding to each calling relationship in the calling relationship between all the updated services.
  • model updater 332 is updated to the calling relationship of the application 1 as shown by 9A in FIG. 9 in accordance with the calling relationship and the calling relationship 8 of the application model shown in FIG. 6A.
  • Table 9 is the workload history 5 of the application 1 at time T5, wherein the historical workload on each instance of each service at time T5 is as shown in Table 9:
  • the workload ratio corresponding to each call relationship is taken as the weight of the edge in which the call relationship exists in 9A in FIG. 9, that is, the application model shown in FIG. 9B is obtained.
  • the model generator deletes the name of the service and the corresponding calling relationship according to the application model.
  • the embodiment of the present application only uses an exemplary workload history record after the application is deleted.
  • the application model is updated more accurately after the application is updated.
  • a plurality of workloads may be obtained as needed, and the ratio of the workload corresponding to each of the call relationships may be obtained by other algorithms, which is not specifically limited in this embodiment of the present application.
  • the model updating method provided by the embodiment of the present application can make the application model more accurately reflect the change of the calling relationship and the workload ratio after the application is updated by updating all the calling relationships and the workload ratios of the application when the application is deleted.
  • capacity expansion is required, a more accurate expansion example can be obtained while rapidly expanding, thereby ensuring SLA indicators such as application reliability, throughput, and response delay.
  • the model updater 332 in the expansion device 300 is configured to support the expansion device 300 to perform the steps P1-P5 in the foregoing embodiment of the present application.
  • the operations of the above-mentioned P1 - P5 can be performed by the processor 401 in the computer device 400 shown in FIG. 4 to call the application code stored in the memory 403, which is not limited in this embodiment of the present application.
  • the three methods for updating the application model in the embodiment of the present application are independent of each other, and another service may be added after the service is deleted, or an update of another service may be deleted after adding one service.
  • the update of the service may be deleted or added on the premise that only the workload ratio is updated, which is not specifically limited in this embodiment of the present application.
  • the application model provided by the embodiment of the present application updates the application model of the application according to the updated workload history record and the updated call relationship of all the services, so as to obtain a more accurate application model, and further enable the application to rapidly expand. Get more accurate expansion examples to ensure SLA metrics such as application reliability, throughput, and response latency.
  • a flowchart of a method for expanding a capacity provided by an embodiment of the present application includes steps S1001-S1007:
  • the expansion device acquires the measured workload of the first service of the application and the application model of the application.
  • the application model includes a call relationship between all services of the application and a workload ratio corresponding to each call relationship in the call relationship, and the first service serves any one of all services.
  • the measured workload provided in the embodiment of the present application includes the workload currently being processed by the service and the workload waiting to be processed in the queue of the service.
  • the expansion device determines each upper-level service of the first service according to the first calling relationship between the first service and the upper-level service of the first service in the application model.
  • the expansion device determines each subordinate service of the first service according to a second invocation relationship between the first service in the application model and each subordinate service of the first service.
  • the expansion device acquires the measured workload of each upper-level service of the first service.
  • the expansion device determines the predicted workload of the first service according to the measured workload of the first service, the measured workload of each upper-level service of the first service, and the first workload ratio corresponding to the first calling relationship. .
  • the expansion device determines a predicted workload of each subordinate service according to a predicted workload of the first service and a second workload ratio corresponding to the second calling relationship.
  • the expansion device expands each target service according to the predicted workload of each target service in all target services.
  • all target services include the first service and each subordinate service of the first service.
  • the expansion method provided by the embodiment of the present application expands the application model, and the application model can represent the calling relationship between the services of the application and the workload ratio corresponding to the calling relationship, so the expansion device can be based on the application model of the application. Predicting the forecasting workload of any service of the application, and obtaining the forecasting workload of all the target services, and then simultaneously expanding all the target services according to the predicted workload of all the target services, compared with the prior art
  • the method of capacity expansion increases the rate of capacity expansion, which in turn can quickly improve the overall performance of the application in a short period of time, further ensuring SLA indicators such as application reliability, throughput, and response delay.
  • the workload estimator 320 in the expansion device 300 is configured to support the expansion device 300 to perform steps S1001-S1006 in the embodiment of the present application; the expansion controller 310 in the expansion device 300 is configured to support the expansion device 300. Step S1007 in the embodiment of the present application is performed.
  • the operations of the foregoing S1001-S1007 may be performed by the processor 401 in the computer device 400 shown in FIG. 4, and the application code stored in the memory 403 is called, and the embodiment of the present application does not impose any limitation.
  • step S1005 includes: the expansion device determines a predicted workload for each target service according to formula (1).
  • V represents the set of all services in the application
  • K represents the set of upper-level services k of the service i in the application
  • K ⁇ V v i represents the service i
  • d(v i ) represents the measured workload of the service i
  • f (k) represents the measured workload of the upper-level service k of the service i
  • e ki represents the workload ratio of the service k and the service i
  • the service i serves any of all the services.
  • the embodiment of the present application provides a specific implementation for determining a predicted workload of the first service.
  • ⁇ k ⁇ K f(k)*e ki represents the workload of service i calculated from f(k) and e ki
  • ⁇ k ⁇ K f(k)*e ki ) shows a larger value ⁇ k ⁇ K f (k) * e ki
  • d (v i) is determined as the prediction of the workload of the service i, considering the actual workload of a service based on the first service determination
  • the workload of the first service and the measured workload of the first service are both factors, so that a more accurate prediction workload of the first service can be obtained, thereby obtaining a more accurate number of expansion instances, which further ensures the application.
  • SLA indicators such as reliability, throughput, and response latency.
  • FIG. 11 is a schematic flowchart of a prediction workload according to an embodiment of the present application.
  • the workload estimator 320 receives an application model and workload information (A, 100 QPS) sent by a monitor of each service, ( C, 300QPS), the workload estimator 320 can calculate the workload prediction values of service A, service B, service C, service D, and service E according to the application model are 100QPS, 300QPS, 300QPS, 600QPS, 300QPS, respectively, and will work.
  • the quantity prediction value is sent to the elastic extension controller 310 of each service, and the elastic extension controller 310 predicts the number of instances of the adjustment service according to the workload to simultaneously expand the plurality of services of the same application.
  • step S1007 includes steps S1007A-S1007B:
  • the S1007A and the expansion device determine the first instance number for each target service expansion according to the predicted workload of each target service and the correspondence between the workload and the number of instances of each target service stored in advance.
  • the S1007B and the expansion device expand each target service according to the first instance number.
  • the number of instances of the expansion can be determined more accurately, and the application can be further expanded while obtaining more Accurate expansion scenarios ensure SLA metrics such as application reliability, throughput, and response latency.
  • the telescopic controller 310 in the expansion device 300 is configured to support the expansion device 300 to perform steps S1007A-S1007B in the embodiment of the present application.
  • the operations of the foregoing S1007A-S1007B may be performed by the processor 401 in the computer device 400 shown in FIG. 4, and the application code stored in the memory 403 is called, which is not limited in this embodiment.
  • step S1007C-S1007E is further included before step S1007B, and step S1007B includes step S1007B1:
  • the S1007C and the expansion device obtain the resource utilization rate of each target service.
  • the expansion device determines the second instance number for each target service expansion according to the pre-stored correspondence between the resource utilization of each target service and the number of instances.
  • the S1007E and the expansion device determine the number of target instances for each target service expansion according to the first instance number and the second instance number.
  • the S1007B1 expands the capacity of each target service according to the number of target instances.
  • the number of instances obtained according to the resource utilization rate, the number of instances determined by the predicted workload, and the instance obtained according to the resource utilization rate may be determined according to resource utilization ratio of each service.
  • the number can be used to obtain a more accurate number of target expansion instances, which further enables the application to rapidly expand based on more accurate expansion instances, thereby ensuring SLA indicators such as application reliability, throughput, and response delay.
  • the expansion controller 310 in the expansion device 300 is configured to support the expansion device 300 to perform steps S1007C-S1007E and S1007B1 in the embodiment of the present application.
  • the operations of the foregoing S1007C-S1007E and S1007B1 may be performed by the processor 401 in the computer device 400 shown in FIG. 4 by calling the application code stored in the memory 403, which is not limited in this embodiment of the present application.
  • an internal structure diagram of a telescopic controller provided by an embodiment of the present application includes a workload resource correspondence table, a resource estimator, a policy evaluator, a scaling policy file, and a telescopic instruction executor.
  • the scaling controller may provide a sub-expansion method to expand the service corresponding to the scaling controller according to the embodiment of the present application.
  • the workload resource correspondence table and the scaling policy may be a file or a small database.
  • the correspondence between the workload and the number of instances is stored in the working resource comparison table.
  • the resource utilization and instance number correspondence table is stored in the scaling policy file.
  • the input of the scaling controller includes the predicted workload and the resource utilization of the service.
  • the resource estimator of the scaling controller estimates the required number of first instances by querying the workload resource comparison table.
  • the policy evaluator evaluates the scaling policy.
  • the relationship between the resource utilization rate and the number of instances determines the second instance number, and sends the second instance number to the telescopic instruction executor.
  • the telescopic instruction executor determines which number of the two expansion instances of the resource estimator and the policy evaluator are large. Which instance number is used as the number of target instances, and the expansion is performed according to the number of instances in which the target is compared.
  • expansion in the embodiment of the present application may be to increase the number of instances, and may also reduce the number of instances, which is not specifically limited in this embodiment of the present application.
  • the number of target instances to be expanded is determined in two ways, and the application expansion can be satisfied by using multiple conditions.
  • the comparison of the number of target instances determined by two different methods can be obtained under the premise of rapid expansion.
  • the number of more accurate expansions can further enable the application to rapidly expand and obtain more accurate expansion instances, thus ensuring SLA indicators such as application reliability, throughput, and response delay.
  • the expansion controller 310 in the expansion device 300 is configured to support the expansion device 300 to perform steps S1007C-S1007E and S1007D in the embodiment of the present application.
  • the operations of the foregoing S1007C-S1007E and S1007D may be performed by the processor 401 in the computer device 400 shown in FIG. 4, and the application code stored in the memory 403 is called, which is not limited in this embodiment.
  • step S1007E includes S1007E1-S1007E2:
  • the expansion device determines that the first instance number is the number of target instances that are expanded for each target service.
  • the number of expansion target instances obtained by comparing the predicted workload of the service with the number of expansion instances obtained according to the resource utilization ratio can obtain the number of expansion target instances, and the service expansion can be more accurately determined.
  • the number of instances, in combination with the application model can more accurately determine the number of instances of the sub-services that need to be expanded, and further enable the application to rapidly expand and obtain more accurate expansion instances, thereby ensuring application reliability and throughput.
  • SLA indicators such as response delay.
  • the expansion controller 310 in the expansion device 300 is configured to support the expansion device 300 to perform steps S1007E1-S1007E2 in the embodiment of the present application.
  • the operations of the foregoing S1007E1-S1007E2 may be performed by the processor 401 in the computer device 400 shown in FIG. 4, and the application code stored in the memory 403 is called, and the embodiment of the present application does not impose any limitation.
  • the service interface description file and the configuration file of the service determine the calling relationship of all services of the application
  • the application model of the application is determined by calculating the workload ratio of the service and the service sub-service
  • the application model can represent the association relationship between the services of the application, so the prediction workload of any service of the application can be predicted according to the application model of the application and the number of target instances of the target service expansion can be calculated, and the number of target instances can be
  • the target service is simultaneously expanded as a whole, thereby increasing the rate of capacity expansion, thereby rapidly improving the overall performance of the application in a short period of time, and further ensuring the application reliability, throughput, and response delay to the SLA.
  • the expansion device acquires the measured workload of the service B at 1000 TPS and the application model of the application 1 as shown in 6B in FIG. 6 at time T6.
  • the expansion device determines that the upper-level service of service B is service A according to the calling relationship between service B and each upper-level service of service B in the application model.
  • the expansion device determines that the subordinate service of the service B is the service D according to the calling relationship between the service B and each subordinate service of the service B in the application model.
  • the fourth step the expansion device acquires the measured workload of the service A at the time of T6 is 600 QPS.
  • the capacity expansion device according to formula (1), the measured workload of service A 600QPS, the measured workload of service B 1000QPS, and the application model of service 1 in service B and service
  • the expansion device calculates the predicted workload 3600QPS of the service D according to the workload ratio of the service D and the service B in the application model of the application 1 and the service B prediction workload 1800QPS.
  • the capacity expansion device determines the number of instances of the service B and the service D that need to be expanded according to the correspondence between the workload of the service B and the service D and the number of instances.
  • Table 11 is the correspondence between the workload of Service B and the number of instances. It can be known from the processing capability of each instance of Service B that each instance of Service B can process 300 QPS. The expansion device determines that the number of instances of the service B needs to be six according to the table 11, and that the existing instances of the service B are three by the table 1 and the table 3. Therefore, the service B needs to expand three instances.
  • Table 12 is the correspondence between the service D workload and the number of instances. Similarly, the processing capability of each instance of the above service D can be known that each instance of the service D can process 500 QPS. Due to 3500QPS
  • the expansion device determines that the number of instances of the service D needs to be 8 according to Table 12, and the existing instances of the service D are four according to Tables 1 and 3. Therefore, the service D needs to expand 4 instances.
  • the correspondence between the workload and the number of instances given in the embodiment of the present application is a linearly increasing correspondence.
  • the workload and the number of instances are The correspondence relationship may also be other corresponding relationships such as non-linear growth.
  • the correspondence between the workload and the number of instances may be determined as needed according to the actual situation of the application, which is not specifically limited in this embodiment of the present application.
  • the capacity expansion device obtains the resource utilization rate of the service B and the resource utilization rate of the service D. It is assumed that the number of instances in which service B and service D need to be expanded according to resource utilization is determined according to the following relationship between resource utilization and number of instances.
  • the default threshold of the resource utilization of the service B is: the ideal resource utilization rate does not exceed 70%.
  • the actual resource utilization ratio of the three instances of the actual service B is 210% at the time T6, and the ideal number of instances is 3.
  • Service B has three instances, so there is no need to expand the service B according to the service utilization of the service B.
  • the default threshold of resource utilization of service D is: the ideal resource utilization does not exceed 70%.
  • the actual resource utilization of the four instances of the actual service D at T6 is 420%, and the ideal number of instances is 6.
  • Service D has four instances. According to the usage of resource utilization, two instances need to be added for service D.
  • the correspondence between the resource utilization rate and the number of instances in the embodiment of the present application is only the correspondence between the resource utilization rate and the number of instances determined by a policy according to an example.
  • the correspondence between the resource utilization rate and the number of instances may also be a corresponding relationship determined according to other rules. According to the actual situation of the application, the correspondence between the resource utilization rate and the number of instances may be determined as needed. This is not specifically limited.
  • the capacity expansion device determines the number of instances of the service B and the service D to be expanded according to the number of instances of the service B and the service D that need to be expanded according to the seventh step and the eighth step, respectively.
  • the tenth step, the capacity expansion of the service B according to the above calculation is to increase the number of expansions of the three instances and the service D by adding four instances and simultaneously performing resource expansion on the service B and the service D of the application 1.
  • the expansion method provided by the embodiment of the present application can be applied to applications developed according to the micro service development concept, and can also be applied to applications developed based on the serverless computing architecture, and the staff will write a well-written function.
  • the expansion device dynamically determines the number of instances of the function according to the demand of the workload, and can simultaneously expand the plurality of functions, thereby no longer paying attention to the influence of the infrastructure devices such as the server and the network on the application.
  • the application development result of the non-server computing is applicable to the Internet of Things (IoT) scenario, which is not specifically limited in this embodiment of the present application.
  • IoT Internet of Things
  • a computer program product includes one or more computer instructions.
  • the computer can be a general purpose computer, a special purpose computer, a computer network, or other programmable device.
  • the computer instructions can be stored in a computer readable medium or transferred from one computer readable medium to another computer readable medium, for example, computer instructions can be wired from a website site, computer, server or data center (eg, coaxial cable , Fiber, Digital Subscriber Line (DSL) or wireless (eg infrared, wireless, microwave, etc.) to another website, computer, server or data center.
  • a website site computer, server or data center
  • DSL Digital Subscriber Line
  • wireless eg infrared, wireless, microwave, etc.
  • the computer readable medium can be any available media that can be stored by a computer or a storage device that includes one or more servers, data centers, etc. that can be integrated with the media.
  • the usable medium may be a magnetic medium (for example, a floppy disk, a hard disk, a magnetic tape), an optical medium (for example, a DVD), or a semiconductor medium (for example, a Solid State Disk (SSD)).

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Mathematical Physics (AREA)
  • Computing Systems (AREA)
  • Evolutionary Computation (AREA)
  • Data Mining & Analysis (AREA)
  • Artificial Intelligence (AREA)
  • Quality & Reliability (AREA)
  • Computational Linguistics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Medical Informatics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本申请实施例提供扩容方法及扩容装置，涉及通信技术领域，解决了现有技术中扩容的速率慢的问题。该方法包括：获取应用的第一服务的实测工作量和应用的应用模型；获取第一服务的每个上一级服务的实测工作量；根据第一服务的实测工作量、第一服务的每个上一级服务的实测工作量、以及与第一调用关系对应的第一工作量比例，确定第一服务的预测工作量；根据第一服务的预测工作量以及与第二调用关系对应的第二工作量比例，确定每个下级服务的预测工作量；根据所有目标服务中每个目标服务的预测工作量，对每个目标服务扩容。

Description

扩容方法及扩容装置
本申请要求于2017年01月26日提交中国专利局、申请号为201710061782.3、申请名称为“扩容方法及扩容装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及通信技术领域，尤其涉及扩容方法及扩容装置。
背景技术
平台作为服务(Platform as a Service，PaaS)是以平台服务为主的一种云服务方式，包括对应用的部署、升级和扩容等能力。其中，PaaS中的扩容由弹性伸缩(Auto Scaling)机制提供，现有的弹性伸缩机制以单个服务为控制对象。当应用运行在PaaS平台上时，每个服务的弹性伸缩控制器可以根据实际的工作量需求按照弹性伸缩机制动态地为该服务增加或释放资源。
然而，目前的软件开发逐渐采用微服务理念，微服务强调把一个应用按功能分解成很多个小型的服务，每个服务的开发和维护都是独立的。服务之间通过轻量的网络协议进行通讯。多个服务相互调用实现应用的功能。当把一个应用分解成多个微服务后，应用的整体复杂度降低了，但同时也对资源的弹性伸缩提出了新的要求。如图1所示，假设一个应用包括服务A、服务B、服务C、服务D和服务E，按照现有的弹性伸缩机制只能对应用的各个服务逐级进行资源扩容，当服务A出现大量的服务请求时，首先对服务A扩容，当服务A扩容完成之前，服务B无法感知需要扩容，大量的服务请求阻塞在服务B和服务C请求队列中，一段时间之后，随着服务B和服务C的资源使用率不断上升，弹性伸缩机制会为服务B和服务C扩容。但是应用的整体性能还是没有提升，因为服务D和服务E又变成了新的性能瓶颈。这种逐级扩容的方式需要很长时间才能完成对应用的整体扩容，进而导致用户请求应用服务的等待时间过长，甚至得不到应用的响应，用户体验较差。
因此，如何提高扩容的速率是目前亟待解决的问题。
发明内容
本申请的实施例提供扩容方法及扩容装置，解决了现有技术中逐级扩容的速率低的问题。
为达到上述目的，本申请的实施例采用如下技术方案：
一方面，提供一种扩容方法，该方法包括：获取应用的第一服务的实测工作量和该应用的应用模型，其中，该应用模型包括该应用的所有服务之间的调用关系以及与该调用关系中每个调用关系对应的工作量比例，该第一服务为该所有服务中的任意一个服务；根据该应用模型中该第一服务与该第一服务的每个上一级服务的第一调用关系，确定该第一服务的每个上一级服务；以及，根据该应用模型中该第一服务与该第一服务的每个下级服务的第二调用关系，确定该第一服务的每个下级服务；获取该第一服务的每个上一级服务的实测工作量；根据该第一服务的实测工作量、该第一服务 的每个上一级服务的实测工作量、以及与该第一调用关系对应的第一工作量比例，确定该第一服务的预测工作量；根据该第一服务的预测工作量以及与该第二调用关系对应的第二工作量比例，确定该每个下级服务的预测工作量；根据所有目标服务中每个目标服务的预测工作量，对该每个目标服务扩容，其中，该所有目标服务包括该第一服务和该第一服务的每个下级服务。本申请实施例提供的扩容方法通过应用模型进行扩容，由于该应用模型可以表征该应用各个服务之间的调用关系以及与该调用关系对应的工作量比例，因此扩容装置可以根据该应用的应用模型预测该应用的任意一个服务的预测工作量，得到所有目标服务的预测工作量，进而可以根据所有目标服务的预测工作量，对所有目标服务同时扩容，相对于现有技术中只能对服务逐级扩容的方法，提高了扩容的速率，进而可在短时间内迅速提高该应用的整体性能，进一步保障了应用的可靠性、吞吐量和响应时延等SLA指标。
一种可能的实现方式中，在该获取该应用模型之前，该方法还包括：获取该所有服务中每个服务的服务接口描述文件和该每个服务的配置文件，其中，该每个服务的服务接口描述文件包括该每个服务的名称，该每个服务的配置文件包括该每个服务和该每个服务的下一级服务之间的调用关系；根据该每个服务和该每个服务的下一级服务之间的调用关系，确定该所有服务之间的调用关系；根据该每个服务的名称获取该每个服务的工作量历史记录，根据该工作量历史记录和该所有服务之间的调用关系，确定与该每个调用关系对应的工作量比例；根据该所有服务之间的调用关系和与该每个调用关系对应的工作量比例，生成该应用模型。本申请实施例提供的应用模型生成的方法，通过服务的服务接口描述文件和配置文件确定该应用的所有服务的调用关系，并根据所有服务的调用关系和通过计算每个调用关系对应的工作量比例确定该应用的应用模型。也就是说，该应用模型可以表征该应用各个服务之间的调用关系以及与该调用关系对应的工作量比例，因此扩容装置可以根据该应用的应用模型预测该应用的任意一个服务的预测工作量，得到所有目标服务的预测工作量，进而可以根据所有目标服务的预测工作量，对所有目标服务同时扩容，从而提高了扩容的速率。进一步的，可在短时间内迅速提高该应用的整体性能，进一步保障了应用的可靠性、吞吐量和响应时延等SLA指标。
一种可能的实现方式中，根据该每个服务的名称获取该每个服务的工作量历史记录，根据该工作量历史记录和该每个调用关系，更新该每个调用关系对应的工作量比例；根据该每个调用关系和该每个调用关系对应的更新后的工作量比例，更新该应用模型。本申请实施例提供的应用模型更新的方法，通过获取的每个服务的工作量历史记录更新应用模型中的每个调用关系对应的工作量比例，可以使应用模型更加准确的反映出服务之间的工作量比例的变化，进而当需要扩容时可以在快速扩容的同时获得更准确的扩容实例，从而保障了应用的可靠性、吞吐量和响应时延等SLA指标。
一种可能的实现方式中，若更新后的该应用中增加了第三服务，获取该第三服务的服务接口描述文件和配置文件、以及至少一个第四服务中每个第四服务更新后的配置文件，其中，该第三服务的服务接口描述文件包括该第三服务的名称，该第三服务的配置文件包括该第三服务和至少一个第五服务中每个第五服务的第三调用关系，该每个第四服务更新后的配置文件包括该每个第四服务和该第三服务的第四调用关系， 该第四服务为该第三服务的上一级服务，该第五服务为该第三服务的下一级服务；根据该应用模型、该第三调用关系和该第四调用关系，更新该所有服务之间的调用关系；根据更新后的该应用的所有服务中每个服务的名称获取该更新后的该应用的所有服务中每个服务的工作量历史记录，根据该更新后的该应用的所有服务中每个服务的工作量历史记录和更新后的该所有服务之间的调用关系确定与该更新后的该所有服务之间的调用关系中每个调用关系对应的工作量比例；根据该更新后的该所有服务之间的调用关系和与该更新后的该所有服务之间的调用关系中每个调用关系对应的工作量比例，更新该应用的应用模型。本申请实施例提供的模型更新方法，通过在应用增加服务时更新该应用的所有调用关系和工作量比例，可以使应用模型更加准确的反映出应用更新后调用关系和工作量比例的变化，进而当需要扩容时可以在快速扩容的同时获得更准确的扩容实例，从而保障了应用的可靠性、吞吐量和响应时延等SLA指标。
一种可能的实现方式中，若更新后的该应用中删除了第六服务，获取至少一个第七服务中每个第七服务更新后的配置文件，其中，在该应用删除第六服务之前，该第七服务为该第六服务的上一级服务，在该应用删除第六服务之后，该每个第七服务更新后的配置文件中包括该每个第七服务和至少一个第八服务的第五调用关系，该第八服务为该第七服务的下一级服务；根据该应用模型和该第五调用关系，更新该所有服务之间的调用关系；根据更新后的该应用的所有服务中每个服务的名称获取该更新后的该应用的所有服务中每个服务的工作量历史记录，根据该更新后的该应用的所有服务中每个服务的工作量历史记录和更新后的该所有服务之间的调用关系确定与该更新后的该所有服务之间的调用关系中每个调用关系对应的工作量比例；根据该更新后的该所有服务之间的调用关系和与该更新后的该所有服务之间的调用关系中每个调用关系对应的工作量比例，更新该应用的应用模型。本申请实施例提供的模型更新方法，通过在应用删除服务时更新该应用的所有调用关系和工作量比例，可以使应用模型更加准确的反映出应用更新后调用关系和工作量比例的变化，进而当需要扩容时可以在快速扩容的同时获得更准确的扩容实例，从而保障了应用的可靠性、吞吐量和响应时延等SLA指标。
一种可能的实现方式中，该根据该第一服务的实测工作量、该第一服务的每个上一级服务的实测工作量、以及与该第一调用关系对应的第一工作量比例，确定该第一服务的预测工作量，包括：根据预设公式确定该第一服务的预测工作量；该预设公式包括：f(v i)＝max(d(v i),∑ k∈Kf(k)*e ki)；其中，V表示该应用中所有服务的集合，K表示该应用中服务i的上一级服务k的集合，K∈V，v i表示该服务i，d(v i)表示该服务i的实测工作量，f(k)表示该服务i的上一级服务k的实测工作量，e ki表示该服务k和该服务i的工作量比例，该服务i为该所有服务中的任意一个服务。本申请实施例提供了一种确定第一服务的预测工作量的具体实现。其中∑ k∈Kf(k)*e ki表示根据f(k)和e ki计算得到的服务i的工作量，max(d(v i),∑ k∈Kf(k)*e ki)表示将∑ k∈Kf(k)*e ki和d(v i)中的较大值确定为服务i的预测工作量，由于考虑了基于第一服务的上一级服务的实测工作量确定的第一服务的工作量和第一服务的实测工作量两方面的因素，因此可以获得更准确的第一服务的预测工作量，进而可以获得更准确的 扩容实例数，进一步的可以保障了应用的可靠性、吞吐量和响应时延等SLA指标。
一种可能的实现方式中，该根据所有目标服务中每个目标服务的预测工作量，对该每个目标服务扩容，包括：根据该每个目标服务的预测工作量、以及预先存储的该每个目标服务的工作量和实例数的对应关系，确定为该每个目标服务扩容的第一实例数，并根据该第一实例数对该每个目标服务扩容。根据本申请实施例提供的扩容方法，通过预测工作量和预先存储的工作量和实例数的对应关系对比，进而可以更准确的确定扩容的实例数，进一步使该应用可以快速扩容的同时获得更准确的扩容实例，从而保障了应用的可靠性、吞吐量和响应时延等SLA指标。
一种可能的实现方式中，在根据该第一实例数对该每个目标服务扩容之前，该方法还包括：获取该每个目标服务的资源利用率；若该每个目标服务的资源利用率超过预设阈值，根据预先存储的该每个目标服务的资源利用率和实例数的对应关系确定为该每个目标服务扩容的第二实例数；根据该第一实例数和该第二实例数确定为对该每个目标服务扩容的目标实例数，并根据该目标实例数对该每个目标服务扩容。根据本申请实施例提供的扩容方法，当对应用扩容时可以根据每个服务的资源利用率确定根据资源利用率获得的实例数，通过预测工作量确定的实例数和根据资源利用率获得的实例数可以获得更准确的目标扩容实例数，进一步使该应用可以根据更准确的扩容实例快速扩容，从而保障了应用的可靠性、吞吐量和响应时延等SLA指标。
一种可能的实现方式中，该根据该第一实例数和该第二实例数确定为对该每个目标服务扩容的目标实例数包括：若该第一实例数大于该第二实例数，将确定该第一实例数为对该每个目标服务扩容的目标实例数；若该第一实例数不大于该第二实例数，将确定该第二实例数为对该每个目标服务扩容的目标实例数。本申请实施例中，通过两种方式确定扩容的目标实例数，可以满足多种条件触发的应用扩容，通过两种不同方式确定的目标实例数的比较，在可以快速扩容的前提下还可以获得更准确的扩容实例数，进一步使该应用可以快速扩容的同时获得更准确的扩容实例，从而保障了应用的可靠性、吞吐量和响应时延等SLA指标。
另一方面，提供一种扩容装置，该扩容装置包括：工作量估算器和伸缩控制器；该工作量估算器用于：获取应用的第一服务的实测工作量和该应用的应用模型，其中，该应用模型包括该应用的所有服务之间的调用关系以及与该调用关系中每个调用关系对应的工作量比例，该第一服务为该所有服务中的任意一个服务；根据该应用模型中该第一服务与该第一服务的每个上一级服务的第一调用关系，确定该第一服务的每个上一级服务；以及，根据该应用模型中该第一服务与该第一服务的每个下级服务的第二调用关系，确定该第一服务的每个下级服务；获取该第一服务的每个上一级服务的实测工作量；根据该第一服务的实测工作量、该第一服务的每个上一级服务的实测工作量、以及与该第一调用关系对应的第一工作量比例，确定该第一服务的预测工作量；根据该第一服务的预测工作量以及与该第二调用关系对应的第二工作量比例，确定该每个下级服务的预测工作量；该伸缩控制器用于：根据所有目标服务中每个目标服务的预测工作量，对该每个目标服务扩容，其中，该所有目标服务包括该第一服务和该第一服务的每个下级服务。
一种可能的实现方式中，该扩容装置还包括：模型生成器；该模型生成器用于： 获取该所有服务中每个服务的服务接口描述文件和该每个服务的配置文件，其中，该每个服务的服务接口描述文件包括该每个服务的名称，该每个服务的配置文件包括该每个服务和该每个服务的下一级服务之间的调用关系；根据该每个服务和该每个服务的下一级服务之间的调用关系，确定该所有服务之间的调用关系；根据该每个服务的名称获取该每个服务的工作量历史记录，根据该工作量历史记录和该所有服务之间的调用关系，确定与该每个调用关系对应的工作量比例；根据该所有服务之间的调用关系和与该每个调用关系对应的工作量比例，生成该应用模型。
一种可能的实现方式中，该扩容装置还包括：模型更新器；该模型更新器用于：根据该每个服务的名称获取该每个服务的工作量历史记录，根据该工作量历史记录和该每个调用关系，更新该每个调用关系对应的工作量比例；根据该每个调用关系和该每个调用关系对应的更新后的工作量比例，更新该应用模型。
一种可能的实现方式中，该扩容装置还包括：模型更新器；该模型更新器用于：若更新后的该应用中增加了第三服务，获取该第三服务的服务接口描述文件和配置文件、以及至少一个第四服务中每个第四服务更新后的配置文件，其中，该第三服务的服务接口描述文件包括该第三服务的名称，该第三服务的配置文件包括该第三服务和至少一个第五服务中每个第五服务的第三调用关系，该每个第四服务更新后的配置文件包括该每个第四服务和该第三服务的第四调用关系，该第四服务为该第三服务的上一级服务，该第五服务为该第三服务的下一级服务；根据该应用模型、该第三调用关系和该第四调用关系，更新该所有服务之间的调用关系；根据更新后的该应用的所有服务中每个服务的名称获取该更新后的该应用的所有服务中每个服务的工作量历史记录，根据该更新后的该应用的所有服务中每个服务的工作量历史记录和更新后的该所有服务之间的调用关系确定与该更新后的该所有服务之间的调用关系中每个调用关系对应的工作量比例；根据该更新后的该所有服务之间的调用关系和与该更新后的该所有服务之间的调用关系中每个调用关系对应的工作量比例，更新该应用的应用模型。
一种可能的实现方式中，该扩容装置还包括：模型更新器；该模型更新器用于：若更新后的该应用中删除了第六服务，获取至少一个第七服务中每个第七服务更新后的配置文件，其中，在该应用删除第六服务之前，该第七服务为该第六服务的上一级服务，在该应用删除第六服务之后，该每个第七服务更新后的配置文件中包括该每个第七服务和至少一个第八服务的第五调用关系，该第八服务为该第七服务的下一级服务；根据该应用模型和该第五调用关系，更新该所有服务之间的调用关系；根据更新后的该应用的所有服务中每个服务的名称获取该更新后的该应用的所有服务中每个服务的工作量历史记录，根据该更新后的该应用的所有服务中每个服务的工作量历史记录和更新后的该所有服务之间的调用关系确定与该更新后的该所有服务之间的调用关系中每个调用关系对应的工作量比例；根据该更新后的该所有服务之间的调用关系和与该更新后的该所有服务之间的调用关系中每个调用关系对应的工作量比例，更新该应用的应用模型。
一种可能的实现方式中，该工作量估算器具体用于：根据预设公式确定该第一服务的预测工作量；该预设公式包括：f(v i)＝max(d(v i),∑ k∈Kf(k)*e ki)；其中，V表示该应用中所有服务的集合，K表示该应用中服务i的上一级服务k的集合，K∈V， v i表示该服务i，d(v i)表示该服务i的实测工作量，f(k)表示该服务i的上一级服务k的实测工作量，e ki表示该服务k和该服务i的工作量比例，该服务i为该所有服务中的任意一个服务。
一种可能的实现方式中，该伸缩控制器具体用于：根据该每个目标服务的预测工作量、以及预先存储的该每个目标服务的工作量和实例数的对应关系，确定为该每个目标服务扩容的第一实例数，并根据该第一实例数对该每个目标服务扩容。
一种可能的实现方式中，该伸缩控制器还用于：在根据该第一实例数对该每个目标服务扩容之前，获取该每个目标服务的资源利用率；若该每个目标服务的资源利用率超过预设阈值，根据预先存储的该每个目标服务的资源利用率和实例数的对应关系确定为该每个目标服务扩容的第二实例数；根据该第一实例数和该第二实例数确定为对该每个目标服务扩容的目标实例数，并根据该目标实例数对该每个目标服务扩容。
一种可能的实现方式中，该伸缩控制器具体用于：若该第一实例数大于该第二实例数，将确定该第一实例数为对该每个目标服务扩容的目标实例数；若该第一实例数不大于该第二实例数，将确定该第二实例数为对该每个目标服务扩容的目标实例数。
又一方面，本申请实施例提供一种扩容装置，包括：处理器、存储器、总线和通信接口；该存储器用于存储计算机执行指令，该处理器与该存储器通过该总线连接，当该扩容装置运行时，该处理器执行该存储器存储的该计算机执行指令，以使该扩容装置执行如上述任意一项的扩容方法。
又一方面，本申请实施例提供了一种计算机存储介质，用于储存为上述任意一项的扩容方法所用的计算机软件指令，其包含用于执行上述任意一项扩容方法所设计的程序。
又一方面，本申请实施例提供了一种计算机程序，该计算机程序包括指令，当该计算机程序被计算机执行时，使得计算机可以执行上述任意一项的扩容方法中的流程。
另外，上述扩容装置实施例中任一种设计方式所带来的技术效果可参见上述扩容方法实施例中不同设计方式所带来的技术效果，此处不再赘述。
本申请的这些方面或其他方面在以下实施例的描述中会更加简明易懂。
附图说明
图1为现有弹性机制的扩容方法示意图；
图2为本申请实施例提供的一种应用模型示意图；
图3为本申请实施例提供的一种扩容装置的结构示意图；
图4为本申请实施例提供的一种计算机设备示意图；
图5为本申请实施例提供的一种应用模型的生成的具体实现示意图；
图6为本申请实施例提供的一种应用模型的生成示意图；
图7为本申请实施例提供的一种更新应用模型的示意图；
图8为本申请实施例提供的又一种更新应用模型的示意图；
图9为本申请实施例提供的又一种更新应用模型的示意图；
图10为本申请实施例提供的一种扩容方法流程示意图；
图11为本申请实施例提供的一种预测工作量的流程示意图；
图12为本申请实施例提供的又一种扩容方法流程示意图；
图13为本申请实施例提供的又一种扩容方法流程示意图；
图14为本申请实施例提供的一种伸缩控制器的内部结构图；
图15为本申请实施例提供的又一种扩容方法流程示意图。
具体实施方式
首先，为了便于理解本申请的方案，本申请给出相关定义。
应用：软件开发理念中，一个应用是由函数库连接起来的可执行文件，该可执行文件提供应用的所有功能。
实例：应用中的一个服务由多个实例执行，每个实例称为该服务的服务实例，每个服务实例为该服务的一个执行单元，一个执行单元可执行固定的工作量。
应用模型：由节点、边和边权值组成的有向图，如图2所示，为本申请实施例提供的一种应用模型示意图。本申请实施例中，根据节点的定义，应用模型可分为粗粒度模型和细粒度模型。
其中，粗粒度模型中每个节点代表一个服务，每条有向边代表一种服务之间的调用关系，边权值代表服务在调用中产生的工作量比例。如图2中的2A所示，为本申请实施例提供的粗粒度应用模型示意图，节点A表示服务A、节点B表示服务B、节点C表示服务C、节点D表示服务D和节点E表示服务E。其中，服务A上的1个工作量需要服务B的2个工作量和服务C的2个工作量，服务B上的1个工作量需要服务D的1个工作量，服务C上的1个工作量需要服务E的1个工作量。
细粒度模型中的每个节点表示一个应用中的每个服务中的每个功能，每条有向边代表一种功能之间的调用关系，边权值代表功能在调用中产生的工作量比例。如图2中的2B所示，为本申请实施例提供的细粒度应用模型示意图，假设图2中的2B为应用Y中服务S对应的部分应用模型，节点A.op表示应用Y中的服务S的功能A、B.op表示应用Y中的服务S的功能B、C.op表示应用Y中的服务S的功能C、D.op表示应用Y中的服务S的功能D和E.op表示应用Y中的服务S的功能E。其中功能A上的一个工作量需要功能B的2个工作量和功能C的2个工作量，功能B上的1个工作量需要功能D的1个工作量，功能C上的1个工作量需要功能E的1个工作量。
需要说明的是，本申请实施例中，细粒度模型预测工作量更准确，但是维护成本较高，粗粒度模型预测工作量一般，但维护方便，使用粗粒度即可解决目前扩容慢的问题，并且粗粒度模型和细粒度模型的建立和维护方法相同，因此本申请实施例中以粗粒度模型为例进行说明。
需要说明的是，本文中的“/”表示或的意思，例如，A/B可以表示A或B；本文中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。“多个”是指两个或多于两个。
如本申请所使用的术语“组件”、“模块”、“系统”等等旨在指代计算机相关实体，该计算机相关实体可以是硬件、固件、硬件和软件的结合、软件或者运行中的软件。例如，组件可以是，但不限于是：在处理器上运行的处理、处理器、对象、可执行文件、执行中的线程、程序和/或计算机。作为示例，在计算机设备上运行的应用和该计算机设备都可以是组件。一个或多个组件可以存在于执行中的过程和/或线程中， 并且组件可以位于一个计算机中以及/或者分布在两个或更多个计算机之间。此外，这些组件能够从在其上具有各种数据结构的各种计算机可读介质中执行。这些组件可以通过诸如根据具有一个或多个数据分组(例如，来自一个组件的数据，该组件与本地系统、分布式系统中的另一个组件进行交互和/或以信号的方式通过诸如互联网之类的网络与其它系统进行交互)的信号，以本地和/或远程过程的方式进行通信。
需要说明的是，本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。
需要说明的是，本申请实施例中，“的(of)”，“相应的(corresponding，relevant)”和“对应的(corresponding)”有时可以混用，应当指出的是，在不强调其区别时，其所要表达的含义是一致的。
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。
为了更好的描述本申请实施例的扩容方法，首先给出本申请实施例的一个应用场景：
如背景技术中的图1所示，假设应用1包括5个服务，分别为服务A、服务B、服务C、服务D和服务E。其中，服务A为服务B和服务C的上一级服务，服务B为服务D的上一级服务，服务C为服务E的上一级服务，服务B、服务C、服务D和服务E为服务A的所有下级服务，按照现有的逐级扩容的方式需要很长时间才能完成对应用的整体扩容，进而导致用户请求应用服务的等待时间过长，甚至得不到应用服务的响应，用户体验较差。因此，如何提高扩容的速率是目前亟待解决的问题。
为了解决该问题，本申请实施例提供一种扩容方法及装置，能够对应用中的服务同时扩容，从而提高扩容的速率，为达到上述目的，本申请的实施例采用如下技术方案：
图3为本申请的实施例所应用提供的扩容装置的结构示意图，该扩容装置300包括：伸缩控制器310和工作量估算器320。其中，伸缩控制器310用于根据对应的目标服务的预测工作量确定目标扩容数并对目标服务进行扩容，比如服务A的伸缩控制器用于根据服务A的预测工作量确定服务A的目标扩容数并对服务A进行扩容，服务B的伸缩控制器用于根据服务B的预测工作量确定服务B的目标扩容数并对服务B进行扩容，服务C的伸缩控制器用于根据服务C的预测工作量确定服务C的目标扩容数并对服务C进行扩容，等等；工作量估算器320用于根据应用模型估算所有目标服务的预测工作量，比如工作量估算器320根据应用模型估算服务A、服务B、服务C等服务的预测工作量。具体的扩容方式和工作量预测的方式将在下述方法实施例中阐述，此处不再赘述。
其中，本申请实施例中的应用模型可以是由模型生成器331生成的应用模型，也可以是经过模型更新器332更新后的应用模型，本申请实施例对此不作具体限定。具体的生成应用模型的方式和更新应用模型的方式将在下述方法实施例中阐述，此处不再赘述。
另外，图3中的模型生成器331和模型更新器332可能集成在本申请实施例提供 的扩容装置中，也可能独立于本申请实施例提供的扩容装置部署，本申请实施例对此不作具体限定。
其中，在图3所示的扩容装置300中，每个服务中的队列用于缓存服务需要处理的工作，每个服务中的线程用于处理服务中工作，每个服务中的监控器用于向扩容装置300发送工作量，在此进行统一说明，以下不再赘述。
如图4所示，本申请实施例中的服务扩容装置可以通过图4中的计算机设备(或系统)来实现。
图4所示为本申请实施例提供的计算机设备示意图。计算机设备400包括至少一个处理器401，通信总线402，存储器403以及至少一个通信接口404。
处理器401可以是一个通用中央处理器(Central Processing Unit，CPU)，微处理器，特定应用集成电路(Application-Specific Integrated Circuit，ASIC)，或一个或多个用于控制本申请方案程序执行的集成电路。
通信总线402可包括一通路，在上述组件之间传送信息。
通信接口404，使用任何收发器一类的装置，用于与其他设备或通信网络通信，如以太网，无线接入网(Radio Access Network，RAN)，无线局域网(Wireless Local Area Networks，WLAN)等。
存储器403可以是只读存储器(Read-Only Memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(Random Access Memory，RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，EEPROM)、只读光盘(Compact Disc Read-Only Memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器可以是独立存在，通过总线与处理器相连接。存储器也可以和处理器集成在一起。
其中，存储器403用于存储执行本申请方案的应用程序代码，并由处理器401来控制执行。处理器401用于执行存储器403中存储的应用程序代码，从而实现本申请实施例中的告警方法。
在具体实现中，作为一种实施例，处理器401可以包括一个或多个CPU，例如图4中的CPU0和CPU1。
在具体实现中，作为一种实施例，计算机设备400可以包括多个处理器，例如图4中的处理器401和处理器408。这些处理器中的每一个可以是一个单核(single-CPU)处理器，也可以是一个多核(multi-CPU)处理器。这里的处理器可以指一个或多个设备、电路、和/或用于处理数据(例如计算机程序指令)的处理核。
在具体实现中，作为一种实施例，计算机设备400还可以包括输出设备405和输入设备406。输出设备405和处理器401通信，可以以多种方式来显示信息。例如，输出设备305可以是液晶显示器(Liquid Crystal Display，LCD)，发光二级管(Light Emitting Diode，LED)显示设备，阴极射线管(Cathode Ray Tube，CRT)显示设备，或投影仪(projector)等。输入设备406和处理器401通信，可以以多种方式接受用 户的输入。例如，输入设备406可以是鼠标、键盘、触摸屏设备或传感设备等。
上述的计算机设备400可以是一个通用计算机设备或者是一个专用计算机设备。在具体实现中，计算机设备400可以是台式机、便携式电脑、网络服务器、掌上电脑(Personal Digital Assistant，PDA)、移动手机、平板电脑、无线终端设备、通信设备、嵌入式设备或有图4中类似结构的设备。本申请实施例不限定计算机设备400的类型。
如上所述，由于本申请实施例提供的扩容方法需要使用应用的应用模型，因此，首先给出应用模型的生成过程如下。
模型生成器331生成应用模型，包括步骤K1-K4：
K1：获取所有服务中的每个服务的服务接口描述文件和每个服务的配置文件。
其中，每个服务的服务接口描述文件包括每个服务的名称，每个服务的配置文件包括每个服务和每个服务的下一级服务之间的调用关系。
K2：根据每个服务和每个服务的下一级服务之间的调用关系，确定所有服务之间的调用关系。
K3：根据每个服务的名称获取每个服务的工作量历史记录，根据工作量历史记录和所有服务之间的调用关系，确定与每个调用关系对应的工作量比例。
K4：根据所有服务之间的调用关系和与每个调用关系对应的工作量比例，生成应用模型。
其中，上述步骤K1-K2可通过图5中的5A的流程实现。具体的，图5中的5A为一种确定应用中所有服务的调用关系的实现流程示意图。假设应用1中Web服务的接口描述语言(Web Service Description Language，WSDL)文件为服务接口描述文件。首先，模型生成器331创建空模型，判断是否有没处理的服务，如果存在没处理的服务，模型生成器331获取该服务的WSDL文件，从WSDL文件中提取该服务名称。进而，模型生成器331根据该服务名称，在模型中为该服务添加一个新节点，并获取该服务的配置文件(config文件)。进而，模型生成器331提取config文件中该服务和该服务的下一级服务的调用关系，并在模型中为每个调用关系添加一条边。当应用所有的服务都处理完毕，模型生成器331即可确定应用模型的中所有服务之间的调用关系。
需要说明的是，所有服务之间的调用关系在应用开发完成后即可确认完成，通常只有在该应用的服务更新后才重新确认。其中，该应用的服务更新包括增加服务或者减少服务。
其中，上述步骤K3-K4可以通过图5中的5B的流程实现。具体的，图5中的5B为一种根据所有服务之间的调用关系和工作量比例生成应用模型的实现流程示意图。首先，模型生成器331获取每个服务的工作量历史记录，本申请实施例中通过记录每个服务每秒钟处理的请求数量(Query Per Second，QPS)数据记录工作量历史数据。其次，计算各个服务的总QPS数据，将各个服务的总QPS数据添加到历史表中。进而，通过历史数据计算各个服务间的工作量比例。最后，将工作量比例更新到所有服务之间的调用关系中每个调用关系对应的边上的权值，当将该应用的各个服务都处理之后，模型生成器331生成应用模型。
示例性的，假设应用1通过QPS数据来衡量服务的每个实例的处理能力。其中， 假设服务A每个实例的处理能力为160QPS、服务B的每个实例的处理能力为300QPS、服务C每个实例的处理能力为500QPS、服务D每个实例的处理能力为500QPS、服务E每个实例的处理能力为800QPS。服务A、服务B、服务C、服务D和服务E的各个服务接口描述文件分别包括服务A、服务B、服务C、服务D和服务E的名称。服务A的配置文件中包括服务A和服务B的调用关系1、以及服务A和服务C的调用关系2；服务B的配置文件中包括服务B和服务D的调用关系3；服务C的配置文件中包括服务C和服务E的调用关系4；服务D的配置文件中包括服务D为空的调用关系5；服务E的配置文件中包括服务E为空的调用关系6。则模型生成器331可以通过如下方式生成应用模型：
首先，模型生成器331获取应用1中服务A、服务B、服务C、服务D和服务E的服务接口描述文件和服务A、服务B、服务C、服务D和服务E的配置文件。
其次，模型生成器331可以按照图6中的6A的方法，根据服务A、服务B、服务C、服务D和服务E的服务接口描述文件中的名称，分别为服务A、服务B、服务C、服务D和服务E生成一个节点，根据服务A、服务B、服务C、服务D和服务E的配置文件中的调用关系1、调用关系2、调用关系3、调用关系4、调用关系5和调用关系6为每个调用关系生成一条边，进而可以得出如图6中的6A中所示调用关系为：服务A调用服务B和服务C，服务B调用服务D，服务C调用服务E。
然后，模型生成器331根据每个服务的服务接口描述文件中的服务的名称获取应用1的每个服务的工作量历史记录。
示例性的，假设表1为应用1在T1时刻的工作量历史记录1，其中，在T1时刻各个服务的各个实例的工作量历史记录具体如表1所示：
表1
  服务A 服务B 服务C 服务D 服务E
实例 A1＝100QPS B1＝200QPS C1＝200QPS D1＝300QPS E1＝300QPS
实例 A2＝100QPS B2＝200QPS C2＝200QPS D2＝300QPS E2＝300QPS
实例   B3＝200QPS C3＝200QPS D3＝300QPS  
实例       D4＝300QPS  
根据表1得出，应用1在T1时刻的各个服务上的总工作量分别为：服务A-200QPS、服务B-600QPS、服务C-600QPS、服务D-1200QPS和服务E-600QPS。
将T1时刻的各个服务上的总工作量添加到历史表中，如表2所示：
表2
时间 服务A 服务B 服务C 服务D 服务E
T1 200QPS 600QPS 600QPS 1200QPS 600QPS
假设表3为应用1在T2时刻工作量历史记录2，其中，在T2时刻各个服务的各个实例的工作量历史记录具体如表3所示：
表3
  服务A 服务B 服务C 服务D 服务E
实例 A1＝150QPS B1＝300QPS C1＝300QPS D1＝450QPS E1＝450QPS
实例 A2＝150QPS B2＝300QPS C2＝300QPS D2＝450QPS E2＝450QPS
实例   B3＝300QPS C3＝300QPS D3＝450QPS  
实例       D4＝450QPS  
根据表3得出，应用1在T2时刻的各个服务上的总工作量分别为：服务A-300QPS、服务B-900QPS、服务C-900QPS、服务D-1800QPS和服务E-900QPS。
由表1和表3可以看出，在T1时刻和T2时刻，服务A包括2个实例，分别为A1和A2；服务B包括3个实例，分别为B1、B2和B3；服务C包括3个实例，分别为C1、C2和C3；服务D包括4个实例，分别为D1、D2、D3和D4；服务E包括2个实例，分别为E1和E2。
将T2时刻的各个服务上的总工作量添加到历史表中，如表4所示：
表4
时间 服务A 服务B 服务C 服务D 服务E
T1 200QPS 600QPS 600QPS 1200QPS 600QPS
T2 300QPS 900QPS 900QPS 1800QPS 900QPS
根据表4，计算各个存在调用关系的服务之间的QPS比例的平均值，分别为服务B/服务A＝(900+600)/(200+300)＝3、服务C/服务A＝(900+600)/(200+300)＝3、服务D/服务B＝(1200+1800)/(900+600)＝2、服务E/服务C＝(600+900)/(900+600)＝1。因此，每个调用关系对应的工作量比例分别为：BA＝3、CA＝3、DB＝2、EC＝1。将每个调用关系对应的工作量比例作为如图6中的6A中存在调用关系的边的权重，即可得到如图6中的6B所示的应用模型。
需要说明的是，本申请实施例中仅以T1时刻和T2时刻的工作量记录为例进行说明，实际应用中可以根据自定义的时间段的工作量记录确定应用模型中调用关系的对应的工作量比例，本申请实施例对此不作具体限定。另外，本申请实施例仅是示例性的以取平均值的方法计算服务间的工作量比例，实际应用中可以采用其他数学方法分析服务间的工作量比例，本申请实施例对此不作具体限定。
需要说明的是，本申请实施例以服务A和服务E的实例数都为2、服务B和服务C实例数都为3、服务D实例数为4为例进行说明。当然，各个服务上的实例的处理能力可以相同也可以不同，各个服务上的实例数可以相同也可以不同，本申请实施例对此不作具体限定。
本申请实施例提供的应用模型生成的方法，通过服务的服务接口描述文件和配置文件确定该应用的所有服务的调用关系，并根据所有服务的调用关系和通过计算每个调用关系对应的工作量比例确定该应用的应用模型。也就是说，该应用模型可以表征该应用各个服务之间的调用关系以及与该调用关系对应的工作量比例，因此扩容装置可以根据该应用的应用模型预测该应用的任意一个服务的预测工作量，得到所有目标服务的预测工作量，进而可以根据所有目标服务的预测工作量，对所有目标服务同时 扩容，从而提高了扩容的速率。进一步的，可在短时间内迅速提高该应用的整体性能，进一步保障了应用的可靠性、吞吐量和响应时延等对客户承诺的服务指标(Service Level Agreement，SLA)指标。
具体的，结合图3，模型生成器331用于支持执行本申请实施例中的步骤K1-K4。
具体的，上述K1-K4的动作可以由图4所示的计算机设备400中的处理器401调用存储器403中存储的应用程序代码来执行，本申请实施例对此不作任何限定。
可选的，考虑到应用的服务是动态变化的，为了更加准确的描述应用的各个服务之间的关系，可以采用模型更新器332更新应用模型，下面将给出应用模型的三种具体的更新方式。
第一种应用模型的更新方式：包括步骤M1-M3：
M1：根据每个服务的名称获取每个服务的工作量历史记录。
M2：根据工作量历史记录和每个调用关系，更新每个调用关系对应的工作量比例。
M3：根据每个调用关系和每个调用关系对应的更新后的工作量比例，更新应用模型。
示例性的，假设表5为应用1在T3时刻工作量历史记录3，其中，在T3时刻各个服务的各个实例的工作量历史记录具体如表5所示：
表5
  服务A 服务B 服务C 服务D 服务E
实例 A1＝90QPS B1＝220QPS C1＝350QPS D1＝360QPS E1＝650QPS
实例 A2＝110QPS B2＝250QPS C2＝480QPS D2＝390QPS E2＝650QPS
实例   B3＝230QPS C3＝470QPS D3＝300QPS  
实例       D4＝350QPS  
根据表5可以得出，应用1在T3时刻的各个服务上的总工作量分别为：服务A-200QPS、服务B-700QPS、服务C-1300QPS、服务D-1400QPS和服务E-1300QPS。
将T3时刻的各个服务上的总工作量添加到历史表中，如表6所示：
表6
时间 服务A 服务B 服务C 服务D 服务E
T1 200QPS 600QPS 600QPS 1200QPS 600QPS
T2 300QPS 900QPS 900QPS 1800QPS 900QPS
T3 200QPS 700QPS 1300QPS 1400QPS 1300QPS
根据表6，计算各个存在调用关系的服务之间的QPS比例的平均值，分别为服务B/服务A＝(900+600+700)/(200+300+200)＝3、服务C/服务A＝(900+600+1300)/(200+300+200)＝4、服务D/服务B＝(1200+1800+1400)/(900+600+700)＝2、服务E/服务C＝(600+900+1300)/(900+600+1300)＝1。因此，每个调用关系对应的工作量比例分别为：BA＝3、CA＝4、DB＝2和EC＝1。将每个调用关系对应的工作量比例作为如图6中的6B中存在调用关系的边的权重，即可得到如图7所示的应用模型。
本申请实施例提供的应用模型更新的方法，通过获取的每个服务的工作量历史记录更新应用模型中的每个调用关系对应的工作量比例，可以使应用模型更加准确的反映出服务之间的工作量比例的变化，进而当需要扩容时可以在快速扩容的同时获得更 准确的扩容实例，从而保障了应用的可靠性、吞吐量和响应时延等SLA指标。
具体的，结合图3，模型更新器332用于执行上述本申请实施例中的步骤M1-M3。
具体的，上述M1-M3的动作可以由图4所示的计算机设备400中的处理器401调用存储器403中存储的应用程序代码来执行，本申请实施例对此不作任何限定。
第二种更新应用模型方式：包括步骤W1-W5：
W1:若更新后的应用中增加了第三服务，获取第三服务的服务接口描述文件和配置文件、以及至少一个第四服务中每个第四服务更新后的配置文件。
其中，第三服务的服务接口描述文件包括第三服务的名称，第三服务的配置文件包括第三服务和至少一个第五服务中每个第五服务的第三调用关系，每个第四服务更新后的配置文件包括每个第四服务和第三服务的第四调用关系，第四服务为第三服务的上一级服务，第五服务为第三服务的下一级服务。
W2：根据应用模型、第三调用关系和第四调用关系，更新所有服务之间的调用关系。
W3：根据更新后的应用的所有服务中每个服务的名称获取更新后的应用的所有服务中每个服务的工作量历史记录。
W4：根据更新后的应用的所有服务中每个服务的工作量历史记录和更新后的所有服务之间的调用关系确定与更新后的所有服务之间的调用关系中每个调用关系对应的工作量比例。
W5：根据更新后的所有服务之间的调用关系和与更新后的所有服务之间的调用关系中每个调用关系对应的工作量比例，更新应用的应用模型。
示例性的，假设应用1增加了服务F，服务F中的服务接口描述文件中包括服务F的名称，服务F的配置文件中包括服务F和服务E的调用关系7，服务F没有调用其他服务。
按照上述方式，模型更新器332根据图6中的6A所示的应用模型的调用关系和调用关系7将图6中的6A所示的应用模型的调用关系更新为如图7所示的应用1的调用关系。
假设表7为应用1在T4时刻工作量历史记录4，其中，在T4时刻各个服务的各个实例上历史工作量具体如表7所示：
表7
  服务A 服务B 服务C 服务D 服务E 服务F
实例 A1＝100QPS B1＝200QPS C1＝200QPS D1＝300QPS E1＝300QPS F1＝600QPS
实例 A2＝100QPS B2＝200QPS C2＝200QPS D2＝300QPS E2＝300QPS  
实例   B3＝200QPS C3＝200QPS D3＝300QPS    
实例       D4＝300QPS    
根据表7可以得出，应用1在T4时刻的各个服务上的总工作量分别为：服务A-200QPS、服务B-600QPS、服务C-600QPS、服务D-1200QPS、服务E-600QPS和服务F-600QPS。
将T4时刻的各个服务上的总工作量添加到历史表中，如表8所示：
表8
时间 服务A 服务B 服务C 服务D 服务E 服务F
T1 200QPS 600QPS 600QPS 1200QPS 600QPS  
T2 300QPS 900QPS 900QPS 1800QPS 900QPS  
T3 200QPS 700QPS 1300QPS 1400QPS 1300QPS  
T4 200QPS 600QPS 600QPS 1200QPS 600QPS 600QPS
根据表8，计算T4时刻各个存在调用关系的服务之间的QPS比例的平均值，分别为：服务B/服务A＝(200+200+200)/(100+100)＝3、服务C/服务A＝(200+200+200)/(100+100)＝3、服务D/服务B＝(300+300+300+300)/(200+200+200)＝2、服务E/服务C＝(300+300)/(200+200+200)＝1、服务F/服务E＝(600)/(300+300)＝1。因此，每个调用关系对应的工作量比例分别为：BA＝3，CA＝3，DB＝2，EC＝1，FE＝1。将每个调用关系对应的工作量比例作为如图8中的8A中存在调用关系的边的权重，即得到如图8中的8B所示的应用模型。
需要说明的是，本申请实施例为了简化说明，在应用增加了服务后仅是示例性的只采用了一个时刻的工作量历史记录，实际应用中，当应用更新后为了更准确地更新应用模型可以根据需要获取多个工作量历史记录，采用其他算法获得各个调用关系对应的工作量比例，本申请实施例对此不作具体限定；另外为了便于理解，本申请实施例中将更新的工作量历史数据记录在同一个历史表中，实际应用中，当应用更新后可以建立一个新的历史表重新记录更新后的工作量历史数据，本申请实施例对此不作具体限定。
需要说明的是，当应用增加了一个服务时，调用该服务的上一级服务和该服务调用的下一级服务的会更新配置文件中的调用关系。
本申请实施例提供的模型更新方法，通过在应用增加服务时更新该应用的所有调用关系和工作量比例，可以使应用模型更加准确的反映出应用更新后调用关系和工作量比例的变化，进而当需要扩容时可以在快速扩容的同时获得更准确的扩容实例，从而保障了应用的可靠性、吞吐量和响应时延等SLA指标。
具体的，结合图3，模型更新器332用于执行上述本申请实施例中的步骤W1-W5。
具体的，上述W1-W5的动作可以由图4所示的计算机设备400中的处理器401调用存储器403中存储的应用程序代码来执行，本申请实施例对此不作任何限定。
第三种应用模型的更新方式：包括步骤P1-P5：
P1：若更新后的应用中删除了第六服务，获取至少一个第七服务中每个第七服务更新后的配置文件。
其中，在应用删除第六服务之前，第七服务为第六服务的上一级服务，在应用删除第六服务之后，每个第七服务更新后的配置文件中包括每个第七服务和至少一个第八服务的第五调用关系，第八服务为第七服务的下一级服务。
P2：根据应用模型和第五调用关系，更新所有服务之间的调用关系。
P3：根据更新后的应用的所有服务中每个服务的名称获取更新后的应用的所有服 务中每个服务的工作量历史记录。
P4：根据更新后的应用的所有服务中每个服务的工作量历史记录和更新后的所有服务之间的调用关系确定与更新后的所有服务之间的调用关系中每个调用关系对应的工作量比例。
P5：根据更新后的所有服务之间的调用关系和与更新后的所有服务之间的调用关系中每个调用关系对应的工作量比例，更新应用的应用模型。
示例性的，假设应用1删除了服务C，服务A中的配置文件中更新了服务A与服务E的调用关系8。
按照上述方式，模型更新器332根据图6中的6A所示的应用模型的调用关系和调用关系8更新为如图9中的9A所示的应用1的调用关系。
假设表9为应用1在T5时刻工作量历史记录5，其中，在T5时刻各个服务的各个实例上历史工作量具体如表9所示：
表9
  服务A 服务B 服务D 服务E
实例 A1＝100QPS B1＝200QPS D1＝300QPS E1＝300QPS
实例 A2＝100QPS B2＝200QPS D2＝300QPS E2＝300QPS
实例   B3＝200QPS D3＝300QPS  
实例     D4＝300QPS  
根据表9可以得出，应用1在T5时刻的各个服务上的总工作量分别为：服务A-200QPS、服务B-600QPS、服务D-1200QPS和服务E-600QPS。
将T5时刻的各个服务上的总工作量添加到历史表中，如表10所示：
表10
时间 服务A 服务B 服务C 服务D 服务E 服务F
T1 200QPS 600QPS 600QPS 1200QPS 600QPS  
T2 300QPS 900QPS 900QPS 1800QPS 900QPS  
T3 200QPS 700QPS 1300QPS 1400QPS 1300QPS  
T4 200QPS 600QPS 600QPS 1200QPS 600QPS 600QPS
T5 200QPS 600QPS   1200QPS 600QPS  
根据表10得出，应用1在T5时刻各个调用关系对应的工作量比例分别为：服务B/服务A＝(200+200+200)/(100+100)＝3、服务D/服务B＝(300+300+300+300)/(200+200+200)＝2、服务E/服务A＝(300+300)/(100+100)＝3。因此每个调用关系对应的工作量比例分别为：BA＝3，DB＝2，EA＝3。将每个调用关系对应的工作量比例作为如图9中的9A中存在调用关系的边的权重，即得到如图9中的9B所示的应用模型。
需要说明的是，当应用删除一个服务时，模型生成器根据将应用模型中删除该服务的名称及对应的调用关系。
需要说明的是，本申请实施例为了简化说明，在应用删除了服务后仅是示例性的只采用了一个时刻的工作量历史记录，实际应用中，当应用更新后为了更准确地更新应用模型可以根据需要获取多个工作量历史记录，采用其他算法获得各个调用关系对 应的工作量比例，本申请实施例对此不作具体限定。
本申请实施例提供的模型更新方法，通过在应用删除服务时更新该应用的所有调用关系和工作量比例，可以使应用模型更加准确的反映出应用更新后调用关系和工作量比例的变化，进而当需要扩容时可以在快速扩容的同时获得更准确的扩容实例，从而保障了应用的可靠性、吞吐量和响应时延等SLA指标。
具体的，结合图3，扩容装置300中的模型更新器332用于支持扩容装置300执行上述本申请实施例中的步骤P1-P5。
具体的，上述P1-P5的动作可以由图4所示的计算机设备400中的处理器401调用存储器403中存储的应用程序代码来执行，本申请实施例对此不作任何限定。
需要说明的是，本申请实施例中的三种更新应用模型的方式相互独立，可以在删除一个服务后再增加另一服务进行更新，也可在增加一个服务后删除一个另一个服务进的更新，也可在仅更新了工作量比例的前提下删除或增加服务的更新，本申请实施例对此不作具体限定。通过本申请实施例提供的方法，根据更新后的工作量历史记录和更新后的所有服务的调用关系更新该应用的应用模型，从而获得更准确的应用模型，进一步使该应用可以快速扩容的同时获得更准确的扩容实例，从而保障了应用的可靠性、吞吐量和响应时延等SLA指标。
下面结合图3所示的扩容装置对本申请实施例提供的扩容方法进行详细介绍。如图10所示，为本申请实施例提供的一种扩容方法的流程图，包括步骤S1001-S1007：
S1001、扩容装置获取应用的第一服务的实测工作量和应用的应用模型。
其中，应用模型包括应用的所有服务之间的调用关系以及与调用关系中每个调用关系对应的工作量比例，第一服务为所有服务中的任意一个服务。
需要说明的是，本申请实施例中提供的实测工作量包括该服务当前正在处理的工作量和在该服务的队列中等待处理的工作量。
S1002、扩容装置根据应用模型中第一服务与第一服务的每个上一级服务的第一调用关系，确定第一服务的每个上一级服务。
S1003、扩容装置根据应用模型中第一服务与第一服务的每个下级服务的第二调用关系，确定第一服务的每个下级服务。
S1004、扩容装置获取第一服务的每个上一级服务的实测工作量。
S1005、扩容装置根据第一服务的实测工作量、第一服务的每个上一级服务的实测工作量、以及与第一调用关系对应的第一工作量比例，确定第一服务的预测工作量。
S1006、扩容装置根据第一服务的预测工作量以及与第二调用关系对应的第二工作量比例，确定每个下级服务的预测工作量。
S1007、扩容装置根据所有目标服务中每个目标服务的预测工作量，对每个目标服务扩容。
其中，所有目标服务包括第一服务和第一服务的每个下级服务。
本申请实施例提供的扩容方法通过应用模型进行扩容，由于该应用模型可以表征该应用各个服务之间的调用关系以及与该调用关系对应的工作量比例，因此扩容装置可以根据该应用的应用模型预测该应用的任意一个服务的预测工作量，得到所有目标服务的预测工作量，进而可以根据所有目标服务的预测工作量，对所有目标服务同时 扩容，相对于现有技术中只能对服务逐级扩容的方法，提高了扩容的速率，进而可在短时间内迅速提高该应用的整体性能，进一步保障了应用的可靠性、吞吐量和响应时延等SLA指标。
具体的，结合图3，扩容装置300中的工作量估算器320用于支持扩容装置300执行本申请实施例中的步骤S1001-S1006；扩容装置300中的伸缩控制器310用于支持扩容装置300执行本申请实施例中的步骤S1007。
具体的，上述S1001-S1007的动作可以由图4所示的计算机设备400中的处理器401调用存储器403中存储的应用程序代码来执行，本申请实施例对此不作任何限制。
一种可能的实现方式中，步骤S1005包括：扩容装置根据公式(1)确定每个目标服务的预测工作量。
f(v i)＝max(d(v i),∑ k∈Kf(k)*e ki)     公式(1)
其中，V表示应用中所有服务的集合，K表示应用中服务i的上一级服务k的集合，K∈V，v i表示服务i，d(v i)表示服务i的实测工作量，f(k)表示服务i的上一级服务k的实测工作量，e ki表示服务k和服务i的工作量比例，服务i为所有服务中的任意一个服务。
本申请实施例提供了一种确定第一服务的预测工作量的具体实现。其中∑ k∈Kf(k)*e ki表示根据f(k)和e ki计算得到的服务i的工作量，max(d(v i),∑ k∈Kf(k)*e ki)表示将∑ k∈Kf(k)*e ki和d(v i)中的较大值确定为服务i的预测工作量，由于考虑了基于第一服务的上一级服务的实测工作量确定的第一服务的工作量和第一服务的实测工作量两方面的因素，因此可以获得更准确的第一服务的预测工作量，进而可以获得更准确的扩容实例数，进一步的可以保障了应用的可靠性、吞吐量和响应时延等SLA指标。
图11为本申请实施例提供的一种预测工作量的流程示意图，如图11所示，工作量估算器320接收应用模型和各个服务的监控器发送的工作量信息(A，100QPS)、(C，300QPS)，则工作量估算器320可以根据应用模型计算服务A、服务B、服务C、服务D、服务E的工作量预测值分别为100QPS、300QPS、300QPS、600QPS、300QPS，并将工作量预测值发送给每个服务的弹性伸缩控制器310，弹性伸缩控制器310根据工作量预测出调节服务的实例数对同一个应用的多个服务同时进行扩容。
一种可能的实现方式中，如图12所示，步骤S1007包括步骤S1007A-S1007B：
S1007A、扩容装置根据每个目标服务的预测工作量、以及预先存储的每个目标服务的工作量和实例数的对应关系，确定为每个目标服务扩容的第一实例数。
S1007B、扩容装置根据第一实例数对每个目标服务扩容。
根据本申请实施例提供的扩容方法，通过预测工作量和预先存储的工作量和实例数的对应关系对比，进而可以更准确的确定扩容的实例数，进一步使该应用可以快速扩容的同时获得更准确的扩容实例，从而保障了应用的可靠性、吞吐量和响应时延等SLA指标。
具体的，结合图3，扩容装置300中的伸缩控制器310用于支持扩容装置300执行本申请实施例中的步骤S1007A-S1007B。
具体的，上述S1007A-S1007B的动作可以由图4所示的计算机设备400中的处理器401调用存储器403中存储的应用程序代码来执行，本申请实施例对此不作任何限定。
一种可能的实现方式中，如图13所示，在步骤S1007B之前还包括步骤S1007C-S1007E、步骤S1007B包括步骤S1007B1：
S1007C、扩容装置获取每个目标服务的资源利用率。
S1007D、若每个目标服务的资源利用率超过预设阈值，扩容装置根据预先存储的每个目标服务的资源利用率和实例数的对应关系确定为每个目标服务扩容的第二实例数。
S1007E、扩容装置根据第一实例数和第二实例数确定为每个目标服务扩容的目标实例数。
S1007B1、扩容装置根据每个目标实例数对每个目标服务扩容。
根据本申请实施例提供的扩容方法，当对应用扩容时可以根据每个服务的资源利用率确定根据资源利用率获得的实例数，通过预测工作量确定的实例数和根据资源利用率获得的实例数可以获得更准确的目标扩容实例数，进一步使该应用可以根据更准确的扩容实例快速扩容，从而保障了应用的可靠性、吞吐量和响应时延等SLA指标。
具体的，结合图3，扩容装置300中的伸缩控制器310用于支持扩容装置300执行本申请实施例中的步骤S1007C-S1007E和S1007B1。
具体的，上述S1007C-S1007E和S1007B1的动作可以由图4所示的计算机设备400中的处理器401调用存储器403中存储的应用程序代码来执行，本申请实施例对此不作任何限定。
如图14所示，为本申请实施例提供的一种伸缩控制器的内部结构图，包括工作量资源对应表、资源估算器、策略评估器、伸缩策略文件和伸缩指令执行器。该伸缩控制器可以根据本申请实施例提供分扩容方法对该伸缩控制器所对应的服务进行扩容。其中，工作量资源对应表和伸缩策略可以为一个文件或者小型的数据库。工作量和实例数对应关系存储在工作资源对照表中，资源利用率和实例数对应表存储在伸缩策略文件中，伸缩控制器的输入包括预测工作量和该服务的资源利用率。当输入为预测工作量时，伸缩控制器的资源估算器通过查询工作量资源对照表估算出所需要的第一实例数，当输入为该服务的资源利用率时，策略评估器通过评估伸缩策略中资源利用率和实例数对应关系确定第二实例数，并将第二实例数发送给伸缩指令执行器，伸缩指令执行器通过判断资源估算器和策略评估器的两个扩容的实例数哪个数大将哪个实例数作为目标实例数，执行根据目标其中较的实例数进行扩容。
需要说明的是，本申请实施例中的扩容可以为增加实例数，也可以为减少实例数，本申请实施例对此不作具体限定。
本申请实施例中，通过两种方式确定扩容的目标实例数，可以满足多种条件触发的应用扩容，通过两种不同方式确定的目标实例数的比较，在可以快速扩容的前提下还可以获得更准确的扩容实例数，进一步使该应用可以快速扩容的同时获得更准确的扩容实例，从而保障了应用的可靠性、吞吐量和响应时延等SLA指标。
具体的，结合图3，扩容装置300中的伸缩控制器310用于支持扩容装置300执 行本申请实施例中的步骤S1007C-S1007E、S1007D。
具体的，上述S1007C-S1007E、S1007D的动作可以由图4所示的计算机设备400中的处理器401调用存储器403中存储的应用程序代码来执行，本申请实施例对此不作任何限定。
一种可能的实现方式中，如图15所示，步骤S1007E包括S1007E1-S1007E2:
S1007E1、若第一实例数大于第二实例数，扩容装置将确定第一实例数为对每个目标服务扩容的目标实例数。
S1007E2、若第一实例数不大于第二实例数，扩容装置将确定第二实例数为对每个目标服务扩容的目标实例数。
根据本申请实施例提供的扩容方法，通过将服务的预测工作量获得的扩容的实例数和根据资源利用率获得的扩容的实例数的比较获得扩容目标实例数，可以更准确的确定该服务扩容的实例数，进而结合应用模型可以更准确的确定该服务的子服务需要扩容的实例数，进一步使该应用可以快速扩容的同时获得更准确的扩容实例，从而保障了应用的可靠性、吞吐量和响应时延等SLA指标。
具体的，结合图3，扩容装置300中的伸缩控制器310用于支持扩容装置300执行本申请实施例中的步骤S1007E1-S1007E2。
具体的，上述S1007E1-S1007E2的动作可以由图4所示的计算机设备400中的处理器401调用存储器403中存储的应用程序代码来执行，本申请实施例对此不作任何限制。
根据本申请实施例提供的扩容方法，通过服务的服务接口描述文件和配置文件确定该应用的所有服务的调用关系，通过计算服务和服务的子服务的工作量比例确定该应用的应用模型，该应用模型可以表征该应用各个服务之间的关联关系，因此可以根据该应用的应用模型预测该应用的任意一个服务的预测工作量并计算目标服务扩容的目标实例数，通过该目标实例数可以对目标服务同时进行整体扩容，从而提高了扩容的速率，进而可在短时间内迅速提高该应用的整体性能，进一步保障了应用的可靠性、吞吐量和响应时延等对SLA。
下面，以第一服务为图6中应用1的服务B为例，对本申请实施例的扩容方法进行示例性说明：
第一步、扩容装置在T6时刻获取服务B的实测工作量为1000QPS和如图6中的6B所示的应用1的应用模型。
第二步、扩容装置根据应用模型中服务B与服务B的每个上一级服务的调用关系，确定服务B的上一级服务为服务A。
第三步、扩容装置根据应用模型中服务B与服务B的每个下级服务的调用关系，确定服务B的下级服务为服务D。
第四步、扩容装置在T6时刻获取服务A的实测工作量为600QPS。
第五步、按照图11所示的预测工作量的方式，扩容装置根据公式(1)、服务A的实测工作量600QPS、服务B的实测工作量1000QPS和应用1的应用模型中服务B和服务A的工作量比例为3，计算服务B的预测工作量f(B)＝max(d(B),∑f(A)*e BA)＝max(1000,600*3)＝1800QPS。
第六步、扩容装置根据应用1的应用模型中服务D和服务B的工作量比例为2以及服务B预测工作量1800QPS计算服务D的预测工作量3600QPS。
第七步、扩容装置分别根据服务B和服务D的工作量和实例数对应关系，确定服务B和服务D分别需要扩容的实例数。
假设表11为服务B的工作量和实例数对应关系，由上述服务B的每个实例的处理能力可知服务B每个实例可以处理300QPS。扩容装置根据表11确定服务B需要实例数为6，而由表1和表3可知服务B现有的实例为3个，因此，服务B需要扩容3个实例。
假设表12为服务D工作量和实例数对应关系，同样的，由上述服务D的每个实例的处理能力可知服务D每个实例可以处理500QPS。由于3500QPS
<3600QPS<4000QPS，因此扩容装置根据表12确定服务D需要实例数为8，而由表1和表3可知服务D现有的实例为4个，因此，服务D需要扩容4个实例。
表11
工作量 实例数
300QPS 1
600QPS 2
900QPS 3
1200QPS 4
1500QPS 5
表12
工作量 实例数
500 1
1000 2
1500 3
2000 4
3500 7
4000 8
需要说明的是，为了便于说明本申请实施例的扩容方法，本申请实施例中给出的工作量和实例数对应关系为线性增长的对应关系，在实际的应用中，工作量和实例数的对应关系也可为非线性增长等其他的对应关系，根据应用的实际情况可以按需确定工作量和实例数对应关系，本申请实施例对此不作具体限定。
第八步、扩容装置获取服务B的资源利用率和服务D的资源利用率。假设按照如下的资源利用率和实例数对应关系，确定根据资源利用率确定服务B和服务D需要扩容的实例数。
假设服务B的资源利用率的预设阈值为：理想资源利用率不超过70％，假设在T6时刻实际服务B的3个实例的实际资源利用率总和为210％，理想的实例数为3。而服务B现有3个实例，所以不需要根据服务B资源利用率使用情况为服务B扩容。
假设服务D的资源利用率的预设阈值为：理想资源利用率不超过70％，假设在T6时刻实际服务D的4个实例的实际资源利用率总和为420％，理想的实例数为6。 而服务D现有4个实例，根据资源利用率的使用情况，需要为服务D增加2个实例。
需要说明的是，为了便于说明本申请实施例的扩容方法，本申请实施例中的资源利用率和实例数对应关系只是按照示例中给出一种策略确定的资源利用率和实例数的对应关系，在实际的应用中，资源利用率和实例数的对应关系也可为根据其他规则确定的对应关系，根据应用的实际情况可以按需确定资源利用率和实例数对应关系，本申请实施例对此不作具体限定。
第九步、扩容装置根据第七步和第八步分别确定的服务B和服务D需要扩容的实例数，确定服务B和服务D扩容的目标实例数。
尽管不需要根据服务B资源利用率使用情况为服务B扩容，但是，根据服务B的预测工作量，需要为服务B扩容3个实例。因此，服务B扩容的目标实例数为增加3个实例。
根据资源利用率的使用情况，需要为服务D增加2个实例；根据服务D的预测工作量，需要为服务D增加4个实例。由于4大于2，因此，服务D扩容的目标实例数为增加4个实例。
第十步、扩容装置根据上述计算得到的服务B的扩容数为增加3个实例和服务D的扩容数为增加4个实例同时对应用1的服务B和服务D进行资源扩容。
需要说明的是，本申请实施例提供的扩容方法既可以应用于根据微服务开发理念开发的应用，也可用于基于非服务器计算(Serverless Computing)架构开发的应用，工作人员将编写好的函数提交给扩容装置，扩容装置根据工作量的需求动态的确定函数的实例数，可以对多个函数同时进行扩容，从而不再关注服务器、网络等基础设备对应用的影响。其中，非服务器计算的应用开发结果可应用于物联网(Internet of Things，IoT)场景中，本申请实施例对此不作具体限定。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式来实现。
计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读介质中，或者从一个计算机可读介质向另一个计算机可读介质传输，例如，计算机指令可以从一个网站站点、计算机、服务器或者数据中心通过有线(例如同轴电缆、光纤、数字用户线(Digital Subscriber Line，DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机可读介质可以是计算机能够存储的任何可用介质或者是包含一个或多个可以用介质集成的服务器、数据中心等存储设备。可用介质可以是磁性介质(例如，软盘、硬盘、磁带)，光介质(例如，DVD)、或者半导体介质(例如固态硬盘(Solid State Disk，SSD))等。
尽管在此结合各实施例对本申请进行了描述，然而，在实施所要求保护的本申请过程中，本领域技术人员通过查看所述附图、公开内容、以及所附权利要求书，可理解并实现所述公开实施例的其他变化。在权利要求中，“包括”(comprising)一词不排除其他组成部分或步骤，“一”或“一个”不排除多个的情况。单个处理器或其他单元可 以实现权利要求中列举的若干项功能。相互不同的从属权利要求中记载了某些措施，但这并不表示这些措施不能组合起来产生良好的效果。
尽管结合具体特征及其实施例对本申请进行了描述，显而易见的，在不脱离本申请的精神和范围的情况下，可对其进行各种修改和组合。相应地，本说明书和附图仅仅是所附权利要求所界定的本申请的示例性说明，且视为已覆盖本申请范围内的任意和所有修改、变化、组合或等同物。显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (21)

  1. 一种扩容方法，其特征在于，所述方法包括：
    获取应用的第一服务的实测工作量和所述应用的应用模型，其中，所述应用模型包括所述应用的所有服务之间的调用关系以及与所述调用关系中每个调用关系对应的工作量比例，所述第一服务为所述所有服务中的任意一个服务；
    根据所述应用模型中所述第一服务与所述第一服务的每个上一级服务的第一调用关系，确定所述第一服务的每个上一级服务；以及，根据所述应用模型中所述第一服务与所述第一服务的每个下级服务的第二调用关系，确定所述第一服务的每个下级服务；
    获取所述第一服务的每个上一级服务的实测工作量；
    根据所述第一服务的实测工作量、所述第一服务的每个上一级服务的实测工作量、以及与所述第一调用关系对应的第一工作量比例，确定所述第一服务的预测工作量；
    根据所述第一服务的预测工作量以及与所述第二调用关系对应的第二工作量比例，确定所述每个下级服务的预测工作量；
    根据所有目标服务中每个目标服务的预测工作量，对所述每个目标服务扩容，其中，所述所有目标服务包括所述第一服务和所述第一服务的每个下级服务。
  2. 根据权利要求1所述的方法，其特征在于，在所述获取所述应用模型之前，所述方法还包括：
    获取所述所有服务中每个服务的服务接口描述文件和所述每个服务的配置文件，其中，所述每个服务的服务接口描述文件包括所述每个服务的名称，所述每个服务的配置文件包括所述每个服务和所述每个服务的下一级服务之间的调用关系；
    根据所述每个服务和所述每个服务的下一级服务之间的调用关系，确定所述所有服务之间的调用关系；
    根据所述每个服务的名称获取所述每个服务的工作量历史记录，根据所述工作量历史记录和所述所有服务之间的调用关系，确定与所述每个调用关系对应的工作量比例；
    根据所述所有服务之间的调用关系和与所述每个调用关系对应的工作量比例，生成所述应用模型。
  3. 根据权利要求1或2所述的方法，其特征在于，所述方法还包括：
    根据所述每个服务的名称获取所述每个服务的工作量历史记录，根据所述工作量历史记录和所述每个调用关系，更新所述每个调用关系对应的工作量比例；
    根据所述每个调用关系和所述每个调用关系对应的更新后的工作量比例，更新所述应用模型。
  4. 根据权利要求1或2所述的方法，其特征在于，所述方法还包括：
    若更新后的所述应用中增加了第三服务，获取所述第三服务的服务接口描述文件和配置文件、以及至少一个第四服务中每个第四服务更新后的配置文件，其中，所述第三服务的服务接口描述文件包括所述第三服务的名称，所述第三服务的配置文件包括所述第三服务和至少一个第五服务中每个第五服务的第三调用关系，所述每个第四服务更新后的配置文件包括所述每个第四服务和所述第三服务的第四调用关系，所述 第四服务为所述第三服务的上一级服务，所述第五服务为所述第三服务的下一级服务；
    根据所述应用模型、所述第三调用关系和所述第四调用关系，更新所述所有服务之间的调用关系；
    根据更新后的所述应用的所有服务中每个服务的名称获取所述更新后的所述应用的所有服务中每个服务的工作量历史记录，根据所述更新后的所述应用的所有服务中每个服务的工作量历史记录和更新后的所述所有服务之间的调用关系确定与所述更新后的所述所有服务之间的调用关系中每个调用关系对应的工作量比例；
    根据所述更新后的所述所有服务之间的调用关系和与所述更新后的所述所有服务之间的调用关系中每个调用关系对应的工作量比例，更新所述应用的应用模型。
  5. 根据权利要求1或2所述的方法，其特征在于，所述方法还包括：
    若更新后的所述应用中删除了第六服务，获取至少一个第七服务中每个第七服务更新后的配置文件，其中，在所述应用删除第六服务之前，所述第七服务为所述第六服务的上一级服务，在所述应用删除第六服务之后，所述每个第七服务更新后的配置文件中包括所述每个第七服务和至少一个第八服务的第五调用关系，所述第八服务为所述第七服务的下一级服务；
    根据所述应用模型和所述第五调用关系，更新所述所有服务之间的调用关系；
    根据更新后的所述应用的所有服务中每个服务的名称获取所述更新后的所述应用的所有服务中每个服务的工作量历史记录，根据所述更新后的所述应用的所有服务中每个服务的工作量历史记录和更新后的所述所有服务之间的调用关系确定与所述更新后的所述所有服务之间的调用关系中每个调用关系对应的工作量比例；
    根据所述更新后的所述所有服务之间的调用关系和与所述更新后的所述所有服务之间的调用关系中每个调用关系对应的工作量比例，更新所述应用的应用模型。
  6. 根据权利要求1-5任一项所述的方法，其特征在于，所述根据所述第一服务的实测工作量、所述第一服务的每个上一级服务的实测工作量、以及与所述第一调用关系对应的第一工作量比例，确定所述第一服务的预测工作量，包括：
    根据预设公式确定所述第一服务的预测工作量；
    所述预设公式包括：f(v i)＝max(d(v i),∑ k∈Kf(k)*e ki)；
    其中，V表示所述应用中所有服务的集合，K表示所述应用中服务i的上一级服务k的集合，K∈V，v i表示所述服务i，d(v i)表示所述服务i的实测工作量，f(k)表示所述服务i的上一级服务k的实测工作量，e ki表示所述服务k和所述服务i的工作量比例，所述服务i为所述所有服务中的任意一个服务。
  7. 根据权利要求1-6任一项所述的方法，其特征在于，所述根据所有目标服务中每个目标服务的预测工作量，对所述每个目标服务扩容，包括：
    根据所述每个目标服务的预测工作量、以及预先存储的所述每个目标服务的工作量和实例数的对应关系，确定为所述每个目标服务扩容的第一实例数，并根据所述第一实例数对所述每个目标服务扩容。
  8. 根据权利要求7所述的方法，其特征在于，在根据所述第一实例数对所述每个目标服务扩容之前，所述方法还包括：
    获取所述每个目标服务的资源利用率；
    若所述每个目标服务的资源利用率超过预设阈值，根据预先存储的所述每个目标服务的资源利用率和实例数的对应关系确定为所述每个目标服务扩容的第二实例数；
    根据所述第一实例数和所述第二实例数确定为对所述每个目标服务扩容的目标实例数，并根据所述目标实例数对所述每个目标服务扩容。
  9. 根据权利要求7或8所述的方法，其特征在于，所述根据所述第一实例数和所述第二实例数确定为对所述每个目标服务扩容的目标实例数包括：
    若所述第一实例数大于所述第二实例数，将确定所述第一实例数为对所述每个目标服务扩容的目标实例数；
    若所述第一实例数不大于所述第二实例数，将确定所述第二实例数为对所述每个目标服务扩容的目标实例数。
  10. 一种扩容装置，其特征在于，所述扩容装置包括：工作量估算器和伸缩控制器；
    所述工作量估算器用于：
    获取应用的第一服务的实测工作量和所述应用的应用模型，其中，所述应用模型包括所述应用的所有服务之间的调用关系以及与所述调用关系中每个调用关系对应的工作量比例，所述第一服务为所述所有服务中的任意一个服务；
    根据所述应用模型中所述第一服务与所述第一服务的每个上一级服务的第一调用关系，确定所述第一服务的每个上一级服务；以及，根据所述应用模型中所述第一服务与所述第一服务的每个下级服务的第二调用关系，确定所述第一服务的每个下级服务；
    获取所述第一服务的每个上一级服务的实测工作量；
    根据所述第一服务的实测工作量、所述第一服务的每个上一级服务的实测工作量、以及与所述第一调用关系对应的第一工作量比例，确定所述第一服务的预测工作量；
    根据所述第一服务的预测工作量以及与所述第二调用关系对应的第二工作量比例，确定所述每个下级服务的预测工作量；
    所述伸缩控制器用于：
    根据所有目标服务中每个目标服务的预测工作量，对所述每个目标服务扩容，其中，所述所有目标服务包括所述第一服务和所述第一服务的每个下级服务。
  11. 根据权利要求10所述的扩容装置，其特征在于，所述扩容装置还包括：模型生成器；
    所述模型生成器用于：
    获取所述所有服务中每个服务的服务接口描述文件和所述每个服务的配置文件，其中，所述每个服务的服务接口描述文件包括所述每个服务的名称，所述每个服务的配置文件包括所述每个服务和所述每个服务的下一级服务之间的调用关系；
    根据所述每个服务和所述每个服务的下一级服务之间的调用关系，确定所述所有服务之间的调用关系；
    根据所述每个服务的名称获取所述每个服务的工作量历史记录，根据所述工作量历史记录和所述所有服务之间的调用关系，确定与所述每个调用关系对应的工作量比例；
    根据所述所有服务之间的调用关系和与所述每个调用关系对应的工作量比例，生成所述应用模型。
  12. 根据权利要求10或11所述的扩容装置，所述扩容装置还包括：模型更新器；
    所述模型更新器用于：
    根据所述每个服务的名称获取所述每个服务的工作量历史记录，根据所述工作量历史记录和所述每个调用关系，更新所述每个调用关系对应的工作量比例；
    根据所述每个调用关系和所述每个调用关系对应的更新后的工作量比例，更新所述应用模型。
  13. 根据权利要求10或11所述的扩容装置，所述扩容装置还包括：模型更新器；
    所述模型更新器用于：
    若更新后的所述应用中增加了第三服务，获取所述第三服务的服务接口描述文件和配置文件、以及至少一个第四服务中每个第四服务更新后的配置文件，其中，所述第三服务的服务接口描述文件包括所述第三服务的名称，所述第三服务的配置文件包括所述第三服务和至少一个第五服务中每个第五服务的第三调用关系，所述每个第四服务更新后的配置文件包括所述每个第四服务和所述第三服务的第四调用关系，所述第四服务为所述第三服务的上一级服务，所述第五服务为所述第三服务的下一级服务；
    根据所述应用模型、所述第三调用关系和所述第四调用关系，更新所述所有服务之间的调用关系；
    根据更新后的所述应用的所有服务中每个服务的名称获取所述更新后的所述应用的所有服务中每个服务的工作量历史记录，根据所述更新后的所述应用的所有服务中每个服务的工作量历史记录和更新后的所述所有服务之间的调用关系确定与所述更新后的所述所有服务之间的调用关系中每个调用关系对应的工作量比例；
    根据所述更新后的所述所有服务之间的调用关系和与所述更新后的所述所有服务之间的调用关系中每个调用关系对应的工作量比例，更新所述应用的应用模型。
  14. 根据权利要求10或11所述的扩容装置，所述扩容装置还包括：模型更新器；
    所述模型更新器用于：
    若更新后的所述应用中删除了第六服务，获取至少一个第七服务中每个第七服务更新后的配置文件，其中，在所述应用删除第六服务之前，所述第七服务为所述第六服务的上一级服务，在所述应用删除第六服务之后，所述每个第七服务更新后的配置文件中包括所述每个第七服务和至少一个第八服务的第五调用关系，所述第八服务为所述第七服务的下一级服务；
    根据所述应用模型和所述第五调用关系，更新所述所有服务之间的调用关系；
    根据更新后的所述应用的所有服务中每个服务的名称获取所述更新后的所述应用的所有服务中每个服务的工作量历史记录，根据所述更新后的所述应用的所有服务中每个服务的工作量历史记录和更新后的所述所有服务之间的调用关系确定与所述更新后的所述所有服务之间的调用关系中每个调用关系对应的工作量比例；
    根据所述更新后的所述所有服务之间的调用关系和与所述更新后的所述所有服务之间的调用关系中每个调用关系对应的工作量比例，更新所述应用的应用模型。
  15. 根据权利要求10-14任一项所述的扩容装置，其特征在于，所述工作量估算 器具体用于：
    根据预设公式确定所述第一服务的预测工作量；
    所述预设公式包括：f(v i)＝max(d(v i),∑ k∈Kf(k)*e ki)；
    其中，V表示所述应用中所有服务的集合，K表示所述应用中服务i的上一级服务k的集合，K∈V，v i表示所述服务i，d(v i)表示所述服务i的实测工作量，f(k)表示所述服务i的上一级服务k的实测工作量，e ki表示所述服务k和所述服务i的工作量比例，所述服务i为所述所有目标服务中的任意一个服务。
  16. 根据权利要求10-15任一项所述的扩容装置，其特征在于，所述伸缩控制器具体用于：
    根据所述每个目标服务的预测工作量、以及预先存储的所述每个目标服务的工作量和实例数的对应关系，确定为所述每个目标服务扩容的第一实例数，并根据所述第一实例数对所述每个目标服务扩容。
  17. 根据权利要求16所述的扩容装置，其特征在于，所述伸缩控制器还用于：
    在根据所述第一实例数对所述每个目标服务扩容之前，获取所述每个目标服务的资源利用率；
    若所述每个目标服务的资源利用率超过预设阈值，根据预先存储的所述每个目标服务的资源利用率和实例数的对应关系确定为所述每个目标服务扩容的第二实例数；
    根据所述第一实例数和所述第二实例数确定为对所述每个目标服务扩容的目标实例数，并根据所述目标实例数对所述每个目标服务扩容。
  18. 根据权利要求16或17所述的扩容装置，其特征在于，所述伸缩控制器具体用于：
    若所述第一实例数大于所述第二实例数，将确定所述第一实例数为对所述每个目标服务扩容的目标实例数；
    若所述第一实例数不大于所述第二实例数，将确定所述第二实例数为对所述每个目标服务扩容的目标实例数。
  19. 一种扩容装置，其特征在于，包括：处理器、存储器、总线和通信接口；
    所述存储器用于存储计算机执行指令，所述处理器与所述存储器通过所述总线连接，当所述扩容装置运行时，所述处理器执行所述存储器存储的所述计算机执行指令，以使所述扩容装置执行如权利要求1-9中任意一项所述的扩容方法。
  20. 一种计算机存储介质，其特征在于，用于储存为权利要求1-9中任意一项所述的扩容方法所用的计算机软件指令，其包含用于执行上述为权利要求1-9中任意一项所述的扩容方法所设计的程序。
  21. 一种计算机程序，其特征在于，所述计算机程序包括指令，当所述计算机程序被计算机执行时，使得计算机执行如权利要求1-9中任意一项所述的扩容方法中的流程。
PCT/CN2018/073672 2017-01-26 2018-01-22 扩容方法及扩容装置 WO2018137585A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US16/523,028 US11216310B2 (en) 2017-01-26 2019-07-26 Capacity expansion method and apparatus

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201710061782.3A CN108366082B (zh) 2017-01-26 2017-01-26 扩容方法及扩容装置
CN201710061782.3 2017-01-26

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/523,028 Continuation US11216310B2 (en) 2017-01-26 2019-07-26 Capacity expansion method and apparatus

Publications (1)

Publication Number Publication Date
WO2018137585A1 true WO2018137585A1 (zh) 2018-08-02

Family

ID=62979084

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/073672 WO2018137585A1 (zh) 2017-01-26 2018-01-22 扩容方法及扩容装置

Country Status (3)

Country Link
US (1) US11216310B2 (zh)
CN (1) CN108366082B (zh)
WO (1) WO2018137585A1 (zh)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109615081A (zh) * 2018-09-26 2019-04-12 阿里巴巴集团控股有限公司 一种模型预测系统及方法
US11055256B2 (en) 2019-04-02 2021-07-06 Intel Corporation Edge component computing system having integrated FaaS call handling capability
US20220255814A1 (en) * 2019-06-03 2022-08-11 Telefonaktiebolaget Lm Ericsson (Publ) Network Node and Methods in a Communications Network
CN112134715B (zh) * 2019-06-24 2022-06-10 腾讯科技（深圳）有限公司 一种扩容结果检测方法、装置、服务器及存储介质
CN110837386A (zh) * 2019-11-08 2020-02-25 神州数码融信软件有限公司 一种微服务架构弹性升级方法
CN113747506A (zh) * 2020-05-28 2021-12-03 华为技术有限公司 一种资源调度方法、装置和网络系统
US11044139B1 (en) * 2020-09-29 2021-06-22 Atlassian Pty Ltd Apparatuses, methods, and computer program products for dynamic generation and traversal of object dependency data structures
CN113225228B (zh) * 2021-04-30 2022-10-21 北京百度网讯科技有限公司 数据处理方法及装置
WO2023140895A1 (en) * 2022-01-19 2023-07-27 Vmware, Inc. Predictive scaling of application based on traffic at another application
US20230232195A1 (en) * 2022-01-19 2023-07-20 Vmware, Inc. Collective scaling of applications
US11614982B1 (en) * 2022-08-29 2023-03-28 Sedai Inc. Autonomous concurrency for serverless functions

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160139885A1 (en) * 2013-12-16 2016-05-19 International Business Machines Corporation Systems and methods for scaling a cloud infrastructure
CN106227605A (zh) * 2016-07-26 2016-12-14 北京北森云计算股份有限公司 一种多语言云编译的动态微服务扩容方法及装置
CN106302626A (zh) * 2015-06-29 2017-01-04 中兴通讯股份有限公司 一种弹性扩容方法、装置及系统
CN106301864A (zh) * 2015-06-11 2017-01-04 腾讯科技（深圳）有限公司 一种服务器系统扩容方法、装置及扩容处理设备

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110307412A1 (en) * 2010-06-14 2011-12-15 Jerome Rolia Reusable capacity planning scenario templates
US8856797B1 (en) 2011-10-05 2014-10-07 Amazon Technologies, Inc. Reactive auto-scaling of capacity
US8732291B2 (en) * 2012-01-13 2014-05-20 Accenture Global Services Limited Performance interference model for managing consolidated workloads in QOS-aware clouds
US9848041B2 (en) * 2015-05-01 2017-12-19 Amazon Technologies, Inc. Automatic scaling of resource instance groups within compute clusters

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160139885A1 (en) * 2013-12-16 2016-05-19 International Business Machines Corporation Systems and methods for scaling a cloud infrastructure
CN106301864A (zh) * 2015-06-11 2017-01-04 腾讯科技（深圳）有限公司 一种服务器系统扩容方法、装置及扩容处理设备
CN106302626A (zh) * 2015-06-29 2017-01-04 中兴通讯股份有限公司 一种弹性扩容方法、装置及系统
CN106227605A (zh) * 2016-07-26 2016-12-14 北京北森云计算股份有限公司 一种多语言云编译的动态微服务扩容方法及装置

Also Published As

Publication number Publication date
CN108366082B (zh) 2020-03-10
CN108366082A (zh) 2018-08-03
US20190347134A1 (en) 2019-11-14
US11216310B2 (en) 2022-01-04

Similar Documents

Publication Publication Date Title
WO2018137585A1 (zh) 扩容方法及扩容装置
JP2018198068A (ja) 分散型クラウドにおける作業負荷移動に基づくプロファイルベースのｓｌａ保証
US7870256B2 (en) Remote desktop performance model for assigning resources
US10848379B2 (en) Configuration options for cloud environments
WO2019001092A1 (zh) 负载均衡引擎，客户端，分布式计算系统以及负载均衡方法
US9584588B2 (en) Multi-stage feedback controller for prioritizing tenants for multi-tenant applications
US10705873B2 (en) Predictive virtual server scheduling and optimization of dynamic consumable resources to achieve priority-based workload performance objectives
US10574536B2 (en) Capacity engineering in distributed computing systems
JP2017107274A (ja) 仮想マシン増設方法、情報処理装置および仮想マシン増設システム
US9722930B2 (en) Exploiting probabilistic latency expressions for placing cloud applications
Sotiriadis et al. The inter-cloud meta-scheduling (ICMS) framework
US20140358620A1 (en) Tenant Selection in Quota Enforcing Request Admission Mechanisms for Shared Applications
Huang et al. Auto scaling virtual machines for web applications with queueing theory
Alkhalaileh et al. Dynamic resource allocation in hybrid mobile cloud computing for data-intensive applications
Yi et al. A multi-criteria decision approach for minimizing the influence of VNF migration
Babu et al. Interference aware prediction mechanism for auto scaling in cloud
Haeri et al. Global resource capacity algorithm with path splitting for virtual network embedding
US9769022B2 (en) Timeout value adaptation
CN113760516A (zh) 一种多云环境下的弹性伸缩方法、装置、设备及介质
Volkov et al. Development of a model and algorithms for servicing traffic in a cloud computing system
Nayyer et al. Cfro: Cloudlet federation for resource optimization
US20140351410A1 (en) Endpoint management based on endpoint type
Fan et al. Knative autoscaler optimize based on double exponential smoothing
US10193823B2 (en) Rich resource management incorporating usage statistics for fairness
US20210044497A1 (en) Hybrid approach for rate limiting in distributed systems

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18745046

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18745046

Country of ref document: EP

Kind code of ref document: A1