CN110990138A - Resource scheduling method, device, server and storage medium - Google Patents

Resource scheduling method, device, server and storage medium Download PDF

Info

Publication number
CN110990138A
CN110990138A CN201911224422.6A CN201911224422A CN110990138A CN 110990138 A CN110990138 A CN 110990138A CN 201911224422 A CN201911224422 A CN 201911224422A CN 110990138 A CN110990138 A CN 110990138A
Authority
CN
China
Prior art keywords
service
calling
type
historical
instances
Prior art date
Legal status (The legal status 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 status listed.)
Granted
Application number
CN201911224422.6A
Other languages
Chinese (zh)
Other versions
CN110990138B (en
Inventor
陈凯鑫
龙佳文
张健
田泱
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Sankuai Online Technology Co Ltd
Original Assignee
Beijing Sankuai Online Technology Co Ltd
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 Beijing Sankuai Online Technology Co Ltd filed Critical Beijing Sankuai Online Technology Co Ltd
Priority to CN201911224422.6A priority Critical patent/CN110990138B/en
Publication of CN110990138A publication Critical patent/CN110990138A/en
Application granted granted Critical
Publication of CN110990138B publication Critical patent/CN110990138B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • 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
    • 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
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N20/00—Machine learning
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Medical Informatics (AREA)
  • Evolutionary Computation (AREA)
  • Data Mining & Analysis (AREA)
  • Computing Systems (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Artificial Intelligence (AREA)
  • Debugging And Monitoring (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

The application provides a resource scheduling method, a resource scheduling device, a server and a storage medium, and belongs to the technical field of cloud services. The method comprises the following steps: for a plurality of service instances of any type in a cloud service architecture, acquiring first historical time calling characteristics of the plurality of service instances, and acquiring first historical operating data of the plurality of service instances; inputting first historical time calling characteristics and first historical operation data of a plurality of service instances into a first service calling characteristic model, and predicting first calling quantity of the service instances of the type in a first preset time length in the future; the main server adjusts the number of the type of online service instances in the cloud service architecture according to the first calling number of the type of service instances and the current second calling number of the type of service instances, so that the number of the type of online service instances in the cloud service architecture corresponds to the number of the type of service requests, and the utilization rate of the online service instances is improved.

Description

Resource scheduling method, device, server and storage medium
Technical Field
The present application relates to the field of cloud service technologies, and in particular, to a resource scheduling method, an apparatus, a server, and a storage medium.
Background
With the development of cloud service technology, more and more network services can be processed through Node servers. The Node server comprises a plurality of execution nodes, and each execution Node comprises a plurality of types of service instances. Wherein each type of service instance can handle a corresponding type of network service request. Moreover, for each type of network service request, the more online service instances in the Node server, the shorter the time for the Node server to return the result corresponding to the network service request. However, each type of service instance occupies certain resources of the Node server, so how to schedule the resources of each type of service instance in the Node server is a key point of interest in the industry.
Disclosure of Invention
The embodiment of the application provides a resource scheduling method, a resource scheduling device, a server and a storage medium, and can solve the problem of low resource utilization rate in a cloud service architecture. The technical scheme is as follows:
according to an aspect of the embodiments of the present application, a method for scheduling resources is provided, the method including:
for a plurality of service instances of any type in a cloud service architecture, acquiring first historical time calling characteristics of the plurality of service instances, and acquiring first historical operating data of the plurality of service instances;
inputting first historical time calling characteristics and first historical operation data of the plurality of service instances into a first service calling characteristic model, and predicting a first calling number of the service instances of the type in a first preset time length in the future;
adjusting the online service instances of the type in the cloud service architecture according to the first calling quantity of the service instances of the type and the current second calling quantity of the service instances of the type;
and allocating resources for the online service instance of the type according to the adjusted online service instance of the type.
In another possible implementation manner, the method further includes:
acquiring second historical time calling characteristics and second historical operating data of a plurality of types of service instances in the cloud service architecture;
and training a second service calling feature model through a machine learning algorithm and a statistical analysis algorithm according to the second historical time calling feature and the second historical operating data to obtain the first service calling feature model.
In another possible implementation, the second historical operating data includes at least one operating indicator; the training a second service calling feature model according to the second historical time calling feature and the second historical operating data through a machine learning algorithm and a statistical analysis algorithm to obtain the first service calling feature model comprises:
determining the weight of each operation index through the statistical analysis algorithm;
and training the second service calling feature model through the machine learning algorithm according to the weight of each operation index, the second historical time calling feature and each operation index in the second historical operation data to obtain the first service calling feature model.
In another possible implementation manner, the training, by the machine learning algorithm, the second service invocation feature model according to the weight of each operation index, the second historical time invocation feature, and each operation index in the second historical operation data, to obtain the first service invocation feature model includes:
predicting a third calling quantity of each type of service instance in a second preset time length in the future through the statistical analysis algorithm;
predicting a fourth calling number of each type of service instance in a second preset time in the future through the second service calling feature model according to the weight of each operation index, the second historical time calling feature and each operation index in the second historical operation data;
and training the first weight of each operation index in the second service call characteristic model through the machine learning algorithm according to the difference value between the third call quantity and the fourth call quantity to obtain the first service call characteristic model.
In another possible implementation manner, the training, by the machine learning algorithm, a weight of each operation index in the second service invocation feature model according to a difference between the third invocation number and the fourth invocation number to obtain the first service invocation feature model includes:
if the difference value between the third calling quantity and the fourth calling quantity is larger than a first quantity threshold value, adjusting the weight of each operation index in the second service calling feature model to obtain a third service calling feature model;
predicting a fifth calling number of the service instances of each type in a second preset time length in the future through the third service calling feature model;
if the difference between the third calling quantity and the fifth calling quantity is larger than a first quantity threshold value, adjusting the weight again until the difference between the third calling quantity and the fifth calling quantity is smaller than a first quantity threshold value, and determining that the third service calling feature model obtained by the last adjustment is the first service calling feature model.
In another possible implementation manner, the obtaining the first historical time invocation feature of the plurality of service instances includes:
acquiring recorded historical calling information of a plurality of service instances of the type in the cloud service architecture according to the type, wherein the historical calling information comprises calling time and calling quantity;
and determining a first historical time calling characteristic of the plurality of service instances according to the historical calling information.
According to another aspect of the embodiments of the present application, there is provided a resource scheduling apparatus, including:
the acquisition module is used for acquiring first historical time calling characteristics of a plurality of service instances of any type in a cloud service architecture and first historical operating data of the plurality of service instances;
the prediction module is used for inputting first historical time calling characteristics and first historical running data of the plurality of service instances into a first service calling characteristic model and predicting first calling quantity of the type of service instances in a first preset time length in the future;
the adjusting module is used for adjusting the online service instances of the types in the cloud service architecture according to the first calling quantity of the service instances of the types and the current second calling quantity of the service instances of the types;
and the allocation module is used for allocating resources for the online service instances of the types according to the adjusted online service instances of the types.
In another possible implementation manner, the apparatus further includes:
the obtaining module is further configured to obtain second historical time calling features and second historical operating data of multiple types of service instances in the cloud service architecture;
and the training module is used for training a second service calling feature model according to the second historical time calling feature and the second historical operating data through a machine learning algorithm and a statistical analysis algorithm to obtain the first service calling feature model.
In another possible implementation manner, the training module is further configured to determine, through the statistical analysis algorithm, a weight of each operation index; and training the second service calling feature model through the machine learning algorithm according to the weight of each operation index, the second historical time calling feature and each operation index in the second historical operation data to obtain the first service calling feature model.
In another possible implementation manner, the training module is further configured to predict, through the statistical analysis algorithm, a third invocation number of the service instances of each type in a second preset time period in the future; predicting a fourth calling number of each type of service instance in a second preset time in the future through the second service calling feature model according to the weight of each operation index, the second historical time calling feature and each operation index in the second historical operation data; and training the first weight of each operation index in the second service call characteristic model through the machine learning algorithm according to the difference value between the third call quantity and the fourth call quantity to obtain the first service call characteristic model.
In another possible implementation manner, the training module is further configured to adjust a weight of each operation index in the second service invocation feature model if a difference between the third invocation number and the fourth invocation number is greater than a first number threshold, so as to obtain a third service invocation feature model; predicting a fifth calling number of the service instances of each type in a second preset time length in the future through the third service calling feature model; if the difference between the third calling quantity and the fifth calling quantity is larger than a first quantity threshold value, adjusting the weight again until the difference between the third calling quantity and the fifth calling quantity is smaller than a first quantity threshold value, and determining that the third service calling feature model obtained by the last adjustment is the first service calling feature model.
In another possible implementation manner, the obtaining module is further configured to obtain, according to the type, recorded historical invocation information of the plurality of service instances of the type in the cloud service architecture, where the historical invocation information includes invocation time and invocation number; and determining a first historical time calling characteristic of the plurality of service instances according to the historical calling information.
According to another aspect of embodiments of the present application, there is provided a server, including: the resource scheduling method comprises a processor and a memory, wherein at least one instruction is stored in the memory, and is loaded and executed by the processor to realize the operation in the resource scheduling method according to any one of the above possible implementation manners.
According to another aspect of embodiments of the present application, there is provided a computer-readable storage medium having at least one instruction stored therein, the at least one instruction being loaded by a processor and having an instruction to implement operations as performed in the resource scheduling method.
In the embodiment of the application, for a plurality of service instances of any type in a cloud service architecture, obtaining first historical time calling characteristics and first historical operating data of the plurality of service instances; inputting first historical time calling characteristics and first historical operation data of a plurality of service instances into a first service calling characteristic model, and predicting a first calling number of the service instances of the type in a first preset time length in the future; adjusting the online service instances of the types in the cloud service architecture according to the first calling number of the service instances of the types and the current second calling number of the service instances of the types; and allocating resources for the online type service instance according to the adjusted online type service instance. The number of the online service instances of the type in the cloud service architecture is adjusted according to the first calling number of the service instances of the type and the current second calling number of the service instances of the type, so that the number of the online service instances of the type in the cloud service architecture corresponds to the number of the service requests of the type, and therefore the utilization rate of the online service instances is improved.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.
FIG. 1 is a schematic illustration of an implementation environment provided by an embodiment of the present application;
fig. 2 is a schematic diagram of a resource scheduling scheme provided in an embodiment of the present application;
fig. 3 is a flowchart of a resource scheduling method according to an embodiment of the present application;
FIG. 4 is a flowchart of a first service invocation feature model training method provided by an embodiment of the present application;
FIG. 5 is a flow chart of a method for obtaining a database according to an embodiment of the present disclosure;
fig. 6 is a schematic structural diagram of a resource scheduling apparatus according to an embodiment of the present application;
fig. 7 is a schematic structural diagram of a server according to an embodiment of the present application.
Detailed Description
To make the objects, technical solutions and advantages of the present application more clear, embodiments of the present application will be described in further detail below with reference to the accompanying drawings.
Fig. 1 is a schematic diagram of an implementation environment provided by an embodiment of the present application. Referring to fig. 1, the implementation environment includes a terminal 101 and a cloud service architecture 102.
The terminal 101 and the cloud service architecture 102 are connected through a wireless or wired network. Moreover, a client for providing services by the cloud service architecture 102 may be installed on the terminal 101, and a user corresponding to the terminal 101 may implement functions such as data transmission and message interaction with the cloud service architecture 102 through the client. The client may be a client installed on the terminal 101 and including an internet access function. For example, the client may be a browser, a social application, a gaming application, or a take-away application, among others.
The terminal 101 may be a computer, a mobile phone, a tablet computer or other electronic devices. The cloud service architecture 102 may be a server, a server cluster composed of several servers, or a cloud computing service center.
In the embodiment of the present Application, the cloud service architecture 102 includes an API (Application programming interface) gateway, a master server, and a plurality of slave servers. Each server comprises a plurality of execution nodes, each execution node comprises a plurality of types of service instances, the types of the service instances in each execution node can be the same or different, and the number of the service instances of each type can be 1, 2 or more; and the master server may control the slave servers. For example, the master server may adjust the number of service instances within each slave server.
The API gateway classifies the service requests according to different service types and distributes the service requests to the servers for processing. The service type can be takeaway service, voice service, video service, internet search service and the like, and correspondingly, the service instance can be takeaway service instance, voice service instance, video service instance, internet search service instance and the like.
For ease of illustration, the types of service instances are named service instance A, service instance B, service instance C, service instance D, and so on. Referring to fig. 2, the cloud service architecture 102 includes API gateways, a master server, and a plurality of slave servers. Each server comprises an execution node A, an execution node B and the like; multiple types of service instances are included in executing node a and executing node B. For example, the execution node a includes a service instance a, a service instance B, a service instance C, and a service instance D; the executing node B comprises a service instance A, a service instance B, a service instance C and a service instance D.
When a user uses the terminal 101 to send a service request to the cloud service framework 102, the cloud service framework 102 allocates the service request to an execution node containing the service instance of the type in the server through the API gateway, then the service instance in the execution node processes the service request, and finally the cloud service framework 102 returns the processing result to the terminal. For example, when the terminal 101 uses a take-away application, the terminal 101 sends a service request of a take-away order to the cloud service framework 102. The cloud service framework 102 distributes the services of the takeout order to the takeout service instances in the execution nodes through the API gateway for processing; finally, the cloud service framework 102 returns the processing result to the first terminal 101.
For each type of network service request, the more resources of the corresponding online service instance of the type in the cloud server architecture, the shorter the time for the cloud server architecture to return the result corresponding to the network service request. In the embodiment of the present application, with continued reference to fig. 2, the master server monitors and records the time-call characteristics and the operation data of each type of service instance in the cloud service architecture 102 to form a database. And the main server obtains a first service calling feature model through machine learning algorithm and statistical algorithm training according to the data stored in the database. The main server predicts a first calling number of the service instances in the cloud service framework 102 within a first preset time in the future through the first service calling feature model, and dynamically adjusts the online type service instances in the cloud service framework 102 according to a prediction result. The main server schedules resources of the service instances in the cloud service architecture 102, so that the number of the service instances in the cloud service architecture 102 corresponds to the number of the service requests, and the utilization rate of the service instances in the cloud service architecture 102 is improved.
Fig. 3 is a flowchart of a resource scheduling method according to an embodiment of the present application. Referring to fig. 3, the resource scheduling method includes the following steps:
301. for a plurality of service instances of any type in a cloud service architecture, a main server acquires first historical time calling characteristics of the plurality of service instances and first historical operating data of the plurality of service instances.
In the embodiment of the application, in the operation process of the cloud service architecture, the main server monitors the calling quantity of each type of service instance in each time period in the cloud service architecture and the operation data of each type of service instance to obtain monitoring data, and stores the monitoring data in the database.
In one possible implementation, the primary server may retrieve a first historical time invocation feature for a plurality of service instances from a database. Accordingly, the step may include: the main server obtains recorded historical calling information of a plurality of service instances of the type in the cloud service architecture according to the type, wherein the historical calling information comprises calling time and calling quantity. The main server determines a first historical time calling characteristic of the plurality of service instances according to the historical calling information.
In one possible implementation, the relationship between the invocation time and the number of invocations for each type of service instance is contained in the primary server. Accordingly, the main server determines the calling time of each type of service instance, and determines the first historical time calling characteristic of each type of service instance from the relation between the calling time and the calling number of each type of service instance. For example, the main server includes the number of calls of the service instance a in each time period from monday to sunday. The main server determines that the calling time of the service instance A is 12:00 am on Monday, and the main server determines the calling number of the service instance A of 12:00 am on Monday according to the relation of the calling number of the service instance A of 12:00 am on Monday.
In one possible implementation, the primary server may obtain first historical operational data for a plurality of service instances from a database. Accordingly, the step may include: the main server obtains recorded historical operation data of a plurality of service instances of the type in the cloud service architecture according to the type, wherein the historical operation data comprises calling time and operation data. The main server determines first historical operating data of the plurality of service instances according to the historical operating data. The operation data comprises at least one of CPU occupancy rate, memory usage, calling distribution, execution node pressure, event cycle time and calling time consumption distribution of the type of service instance.
In one possible implementation, the relationship between the invocation time and the running data of each type of service instance is contained in the main server. Accordingly, the main server determines the calling time of each type of service instance, and determines the first historical operation data of each type of service instance from the relationship between the calling time and the operation data of each type of service instance. For example, the main server contains the operation data of the service instance A in each time period from Monday to Sunday. The main server determines that the calling time of the service instance A is 12:00 am on Monday, and the main server determines the operation data of the service instance A at 12:00 am on Monday according to the relation of the operation data of the service instance A at 12:00 am on Monday.
Another point to be noted is that the main server may periodically obtain the first historical time calling feature and the first historical operating data of the plurality of service instances from the database. The set time may be a time of a third preset duration. The third preset time period may be 30min, 1h, 1.5h, and the like, and in the embodiment of the present application, the third preset time period is not specifically limited, and may be set and changed as needed.
302. The main server inputs a first historical time calling characteristic and first historical running data of the plurality of service instances into a first service calling characteristic model, and predicts a first calling number of the service instances of the type in a first preset time length in the future.
In the embodiment of the application, a first historical time calling characteristic and first historical running data of a plurality of service instances of any type are input into a first service calling characteristic model, and the first service calling characteristic model predicts a first calling number of the service instances of the type in a first preset time length in the future. The first preset duration may be 30min, 1h, 1.5h, and the like, and in the embodiment of the present application, the first preset duration is not specifically limited, and may be set and changed as needed.
In one possible implementation, the relationship between the invocation time and the number of invocations for each type of service instance is contained in the primary server. Correspondingly, the main server determines the calling time of the future first preset duration of each type of service instance, and determines the first calling number in the future first preset duration from the relationship between the multiple calling time and the calling number of each type of service instance.
In a possible implementation manner, the main server determines the first call quantity within a first preset time in the future according to an average value of the call quantities corresponding to the multiple call times. For example, the relationship between the number of calls of the service instance a in each time period from monday to sunday is contained in the main server. The main server determines that the calling time of the future first preset duration of the service instance A is 12:00 pm on Monday, and determines that the first calling number of the service instance A at 12:00 pm on Monday is Q according to the average value of the calling numbers Q1, Q2, Q3 and the like of the service instance A at 12:00 pm on Monday for multiple times.
In another possible implementation, the main server contains the call time and the running data of each type of service instance, and the relationship between the running data and the number of calls. Correspondingly, the main server determines the calling time of the future first preset duration of each type of service instance, and determines the running data of the future first preset duration of each type of service instance from the relationship between the calling time and the running data of each type of service instance; and determining the first calling number according to the relation between the running data and the calling number.
In another possible implementation, the first service invocation feature model includes a weight of each operation index. The first service call characteristic model predicts a first call number of the service instance of the type in a first preset time length in the future through each operation index and the weight of each operation index. For example, the main server inputs the CPU occupancy rate and the memory usage of the service instance a into the first service invocation feature model, and the first service invocation feature model predicts the first invocation number of the service instance a in the first preset time duration in the future through the CPU occupancy rate and the memory usage of the service instance a, the weight of the CPU occupancy rate and the weight of the memory usage.
303. And the main server adjusts the online service instances of the type in the cloud service architecture according to the first calling number of the service instances of the type and the current second calling number of the service instances of the type.
In the embodiment of the present application, the first number of calls of the service instance of the type may be the first number of calls of the service instance a, the first number of calls of the service instance B, the first number of calls of the service instance C, and the first number of calls of the service instance D.
In a possible implementation manner, the main server adjusts the online service instance of the type in the cloud service architecture according to a difference value between the first call quantity of the service instance of the type and the current second call quantity of the service instance of the type. When the difference value between the first calling quantity of the service instance of the type and the current second calling quantity of the service instance of the type is larger than a second quantity threshold value, the main server adjusts the online service instance of the type in the cloud service architecture; when the difference value between the first calling quantity of the service instance of the type and the current second calling quantity of the service instance of the type is smaller than the second quantity threshold value, the main server does not adjust the online service instance of the type in the cloud service architecture. The second quantity threshold may be 0, 10, 20, 30, 40, etc., and in the embodiment of the present application, the second quantity threshold is not particularly limited, and may be set and changed as needed.
It should be noted that, for each type of service instance, the corresponding second number threshold may be the same or different. For example, the second number threshold for type service a is set to 20, the second number threshold for type service B is set to 20, the second number threshold for type service C is set to 30, and the second number threshold for type service D is set to 40. When the difference value between the first calling quantity of the type service A and the current second calling quantity of the service instance A is larger than 20, the main server adjusts the online service instance A in the cloud service architecture; when the difference value between the first calling number of the service instance A and the current second calling number of the service instance A is less than 20, the main server does not adjust the service instance A on line in the cloud service architecture.
In another possible implementation manner, the main server adjusts the online service instance of the type in the cloud service architecture according to a change rate between the first call quantity of the service instance of the type and the current second call quantity of the service instance of the type.
When the change rate between the first calling quantity of the type of service instance and the current second calling quantity of the type of service instance is larger than a first change rate threshold value, the main server adjusts the type of online service instance in the cloud service architecture; when the change rate between the first calling quantity of the type of the service instance and the current second calling quantity of the type of the service instance is smaller than the first change rate threshold value, the main server does not adjust the type of the online service instance in the cloud service architecture. The first change rate threshold may be 0%, 5%, 10%, 15%, or the like, and in the embodiment of the present application, the first change rate threshold is not specifically limited, and may be set and changed as needed.
It should be noted that, for each type of service instance, the corresponding first change rate threshold may be the same or different. For example, the first rate of change threshold for type service a is set to 10%, the first rate of change threshold for type service B is set to 10%, the first rate of change threshold for type service C is set to 15%, and the first rate of change threshold for type service D is set to 5%. When the change rate between the first calling quantity of the type service A and the current second calling quantity of the service instance A is larger than 10%, the main server adjusts the online service instance A in the cloud service architecture; when the change rate between the first calling number of the service instance A and the current second calling number of the service instance A is less than 10%, the main server does not adjust the service instance A on line in the cloud service architecture.
Adjusting a type of online service instance in a cloud service architecture may adjust the type of online service instance to a first number of invocations of the type of service instance. For example, if the first number of calls of the service instance a is 1000, the number of online service instances a in the cloud service architecture is adjusted to be 1000.
In the embodiment of the application, the main server increases the number of the type of online service instances by downloading the type of service instances in the cloud service architecture, and the main server reduces the number of the type of online service instances by closing the type of online service instances in the cloud service architecture.
In one possible implementation, the host server increases the number of service instances of the type online by downloading the service instances of the type within an execution node in the cloud service architecture. In one possible implementation, the downloading of the online service instance of the type may be performed simultaneously in a plurality of executing nodes. Correspondingly, the main server determines the number of execution nodes for downloading the service instances of the type according to the number of the online service instances needing to be increased. The main server distributes the service instances of the type that need to be downloaded evenly among the plurality of executing nodes. For example, the number of service instances a needs to be increased by 200, the main server determines that the number of execution nodes downloading the service instances of the type is 10, and determines that each execution node downloads the number of service instances a is 20.
In the embodiment of the application, the number of the type online service instances in the cloud service architecture is increased by simultaneously downloading the type service instances in the multiple execution nodes, so that the number of the type online service instances can be rapidly adjusted, and the adjustment efficiency of the cloud service architecture is improved.
In another possible implementation manner, the main server may download the service instance of the type in only one execution node, and when the CPU occupancy of the execution node reaches the first CPU occupancy threshold, another execution node continues to download the service instance of the type until the service instance of the type online reaches the first call number. The first CPU occupancy threshold may be 50%, 60%, 70%, and the like, and in the embodiment of the present application, the first CPU occupancy threshold is not specifically limited, and may be set and changed as needed. For example, the first CPU occupancy threshold of the execution node is 60%, when the execution node a downloads the service instance a, when the CPU occupancy of the execution node a reaches 60%, the main server starts the execution node B to continue downloading the service instance a, when the CPU occupancy of the execution node B reaches 60%, the main server starts the execution node C to continue downloading the service instance a until the online service instance a reaches the first call number, and then the main server stops.
In the embodiment of the application, the number of the type online service instances in the cloud service architecture is increased according to the CPU occupancy rate of the execution node, the CPU occupancy rate of the execution node is prevented from being too high, and the stability of the cloud service architecture is improved.
304. And the main server allocates resources for the type of online service instance according to the adjusted type of online service instance.
In a possible implementation manner, the main server allocates resources for the type of service instance according to the adjusted number of the type of online service instance. Accordingly, the greater the number of service instances of the type online, the more resources the host server allocates to the service instances of the type, and the greater the number of service requests of the type processed by the host server.
In the embodiment of the application, for a plurality of service instances of any type in a cloud service architecture, a main server acquires a first historical time calling characteristic and first historical operating data of the plurality of service instances. The main server inputs a first historical time calling characteristic and first historical running data of the plurality of service instances into a first service calling characteristic model, and predicts a first calling number of the service instances of the type in a first preset time length in the future. And the main server adjusts the type of online service instance in the cloud service architecture according to the first calling number of the type of service instance and the current second calling number of the type of service instance. And the main server allocates resources for the type of online service instance according to the adjusted type of online service instance. The main server adjusts the number of the type of online service instances in the cloud service architecture according to the first calling number of the type of service instances and the current second calling number of the type of service instances, so that the number of the type of online service instances in the cloud service architecture corresponds to the number of the type of service requests, and therefore the utilization rate of the online service instances is improved.
Fig. 4 is a flowchart of a first service invocation feature model training method provided in an embodiment of the present application, and in the embodiment of the present application, a description is given by taking an example of training a first service invocation feature model by a master server. Referring to fig. 4, the method includes:
401. the main server obtains second historical time calling characteristics and second historical operating data of a plurality of types of service instances in the cloud service architecture.
In the embodiment of the application, in the operation process of the main server, the main server monitors the calling quantity of each type of service instance in each time period in the cloud service architecture and the operation data of each type of service instance to obtain monitoring data, and stores the monitoring data in the database.
In one possible implementation, the primary server may retrieve a second historical time invocation feature for the plurality of service instances from the database. Accordingly, the step may include: the main server obtains recorded historical calling information of a plurality of service instances of the type in the cloud service architecture according to the type, wherein the historical calling information comprises calling time and calling quantity. The main server determines a second historical time calling characteristic of the plurality of service instances according to the historical calling information.
In one possible implementation, the relationship between the invocation time and the number of invocations for each type of service instance is contained in the primary server. Accordingly, the main server determines the calling time of each type of service instance, and determines the second historical time calling characteristic of each type of service instance from the relation between the calling time and the calling number of each type of service instance.
In another possible implementation, the primary server may obtain second historical operational data for the plurality of service instances from a database. Accordingly, the step may include: the main server obtains recorded historical operation data of a plurality of service instances of the type in the cloud service architecture according to the type, wherein the historical operation data comprises calling time and operation data. The main server determines second historical operating data of the plurality of service instances according to the historical operating data. The operation data comprises at least one of CPU occupancy rate, memory usage, calling distribution, execution node pressure, event cycle time and calling time consumption distribution of the type of service instance.
In another possible implementation, the relationship between the invocation time and the running data of each type of service instance is contained in the main server. Accordingly, the main server determines the calling time of each type of service instance, and determines the second historical operation data of each type of service instance from the relationship between the calling time and the operation data of each type of service instance.
In one possible implementation, the multiple types of service instances refer to each type of service instance that is online in the current cloud service architecture. Correspondingly, the main server determines each type of online service instance in the current cloud service architecture, and acquires second historical time calling characteristics and second historical operating data of each type of online service instance. For example, if the service instances online in the current cloud service architecture include a service instance a, a service instance B, and a service instance C, the main server obtains a second historical time calling feature and second historical operating data of the service instance a, the service instance B, and the service instance C.
In another possible implementation manner, the multiple types of service instances refer to all types of service instances stored in the current cloud service architecture. Correspondingly, the main server determines all types of service instances stored in the current cloud service architecture, and acquires second historical time calling characteristics and second historical operating data of each type of service instance stored in the current cloud service architecture. For example, all the service instances stored in the current cloud service architecture are service instance a, service instance B, service instance C, service instance D, and service instance E, and the master server obtains the second historical time calling feature and the second historical operating data of service instance a, service instance B, service instance C, service instance D, and service instance E.
402. And the main server trains a second service calling feature model according to the second historical time calling feature and the second historical operating data through a machine learning algorithm and a statistical analysis algorithm to obtain a first service calling feature model.
In the embodiment of the application, the main server trains the second service calling feature model through a machine learning algorithm and a statistical analysis algorithm to obtain the first service calling feature model. The corresponding present step can be realized by the following steps (1) to (2), including:
(1) the main server determines the weight of each operation index through a statistical analysis algorithm.
In the embodiment of the present application, the main server may perform statistics on the historical invocation characteristics and each operation index of the service instance of the type. Correspondingly, the main server determines the correlation between the service instance history calling characteristics of the type and each operation index according to a statistical analysis algorithm. And the main server determines the weight of the operation index with strong correlation to be large according to the correlation between each operation index and the historical calling characteristics.
In one possible implementation, the historical invocation feature may be a historical invocation amount. The correlation may be a positive correlation between the running metric and the historical invocation amount. Correspondingly, the main server determines the positive correlation between the operation index of the service instance of the type and the historical call quantity according to a statistical analysis algorithm, and determines that the operation index with strong positive correlation has large weight. For example, when the historical call quantity of the service instance A changes at 100, 200 and 300, the main server counts the change of each operation index, and determines the positive correlation between each operation index when the historical call quantity of the service instance A changes at 100, 200 and 300 according to a statistical analysis algorithm. The main server determines that the operation index with strong positive correlation has large weight.
(2) And the main server trains a second service calling feature model through a machine learning algorithm according to the weight of each operation index, the second historical time calling feature and each operation index in the second historical operation data to obtain a first service calling feature model.
In the embodiment of the application, each type of service instance corresponds to one service call feature model. And parameters in each service calling feature model correspond to the time calling features and the running data of the service instances of the type. Therefore, the weight of each operation index in the first service invocation feature model corresponding to each type of service instance is different, and in the process of training the second service invocation feature model by the machine learning algorithm, the main server needs to adjust the weight of each operation index to obtain the first service invocation feature model.
Accordingly, the present step may include being achieved by the following steps (a) to (c):
(a) and the main server predicts the third calling number of each type of service instance in a second preset time length in the future through a statistical analysis algorithm.
In one possible implementation manner, the main server predicts the third calling number of the service instance of the type within the future second preset time length through a statistical analysis algorithm of the historical calling characteristics of the service instance of the type. Correspondingly, the main server carries out a statistical analysis algorithm on the calling time and the calling number of the service instances of the type. And the main server predicts the third calling number of the service instance of the type in a second preset time length in the future according to the result of the statistical analysis algorithm carried out by the calling time and the calling number. In the process of statistical analysis, the statistical period of the main server can be one day, one week or one month; in the embodiment of the present application, the statistical period is not particularly limited, and may be set and changed as needed.
For example, the statistical period of the service instance a is set to be one day, if the second preset duration in the future is 12:00 am, the statistical analysis is performed on the historical calling characteristics of the service instance a at 12:00 am every day, and the third calling number of the service instance a at 12:00 am in the future is predicted.
(b) And the main server predicts the fourth calling quantity of each type of service instance in a second preset time in the future through a second service calling feature model according to the weight of each operation index, the second historical time calling feature and each operation index in the second historical operation data.
(c) And the main server trains the weight of each operation index in the second service call characteristic model through a machine learning algorithm according to the difference value between the third call quantity and the fourth call quantity to obtain the first service call characteristic model.
In a possible implementation manner, if a difference between the third calling number and the fourth calling number is greater than a first number threshold, the main server adjusts the weight of each operation index in the second service calling feature model to obtain a third service calling feature model. Wherein the first number threshold may be 5, 10, 15, 20, etc.; in the embodiment of the present application, the first number threshold is not particularly limited, and may be set and changed as needed.
And the main server predicts a fifth calling number of each type of service instance in a second preset time length in the future through a third service calling feature model. If the difference value between the third calling quantity and the fifth calling quantity is larger than the first quantity threshold value, the main server adjusts the weight again until the difference value between the third calling quantity and the fifth calling quantity is smaller than the first quantity threshold value, and the third service calling feature model obtained through the last adjustment is determined to be the first service calling feature model.
For example, the first quantity threshold of the service instance a is set to 15, and the main server determines, through a statistical analysis algorithm, that the third calling quantity of the service instance a in the second preset time period in the future is 100. And the main server determines that the fourth calling number of the service instance A in a second preset time length in the future is 80 through the second service calling characteristic model. At this time, the difference value between the third calling quantity and the fourth calling quantity is 20 and is greater than the first quantity threshold value 15, and the main server adjusts the weight of each operation index of the service instance a to obtain a third service calling feature model.
And the main server predicts that the fifth calling number of the service instance A in a second preset time length in the future is 90 through a third service calling feature model, at the moment, the difference value between the third calling number and the fifth calling number is 10 and is smaller than a first number threshold value 15, and the main server determines that the third service calling feature model obtained through the last adjustment is the first service calling feature model.
In the embodiment of the application, the main server calls the features and the second historical operating data according to the second historical time of the multiple types of service instances, the weight of each operating index in the second service calling feature model is trained through a machine learning algorithm and a statistical analysis algorithm, and the first service calling feature model of the type of service instances is obtained through cross validation of the machine learning algorithm and the statistical analysis algorithm. Therefore, the first service calling feature model can accurately predict the first calling number of the type of service instance, and the number of the type of online service instance in the cloud service architecture is adjusted according to the prediction result, so that the number of the type of online service instance in the cloud service architecture corresponds to the number of the type of service request, and the utilization rate of the online service instance is improved.
Fig. 5 is a flowchart of a method for acquiring a database according to an embodiment of the present application. Referring to fig. 5, the method comprises the steps of:
501. the main server receives the service requests initiated by the terminal and determines the number of each type of service request.
In the embodiment of the present application, the service request refers to a service request initiated from all current terminals to the main server. The service request initiated by the terminal may include a service request a, a service request B, a service request C, a service request D, and the like.
In one possible implementation, the primary server determines the number of service requests of each type according to the type of the service request. Correspondingly, the main server receives the service request initiated by the terminal and determines the type of the service request. The main server determines the number of service requests of each type according to the type of each service request. For example, the main server receives 5 service requests initiated by the terminal, and the main server determines the types of the 5 service requests as service request a, service request B, and then the main server determines that the number of service requests a is 2 and the number of service requests B is 3.
In another possible implementation manner, each type of service request contains different request functions, and the main server determines the type of the service request according to the request function of the service request. Correspondingly, the main server receives the service request initiated by the terminal and determines the request function of the service request. The main server determines the service request type according to the request function of the service request. For example, the service request a includes a function of the service a, and the main server determines that the service request is the service request a through the function of the service a.
502. And the main server determines the time calling characteristics and the operation data of each type of service instance in the current cloud service according to the number of each type of service request.
In the embodiment of the application, for each type of service request, the main server needs to call the online service instance of the type to process. Correspondingly, the main server determines the calling number of the online service instance of each type according to the number of the service requests of each type. And the main server determines the time calling characteristics and the operation data of each type of service instance according to the calling number of the type of online service instance.
In one possible implementation manner, the main server stores the relationship between the calling number of each type of online service instance and the running data of the type of service instance. Correspondingly, the main server determines the calling number of the online service instance of the type, and determines the operation data of the service instance of the type from the relation between the calling number of the online service instance of the type and the operation data of the type.
It should be noted that, when an online service instance of the type exists in the current cloud service architecture, for each type of service request, the online service instance of the type is called between the main servers for processing. And the main server returns the processing result of the online service instance to the service request.
In another possible implementation manner, when the online service instance of the type does not exist in the current cloud service architecture, the processor may download a specific function package according to a request function of the service request, generate the online service instance of the type through the downloaded function package, and then process the service request through the online service instance. For example, the service type of the service request is a service request E, and if there is no corresponding online service instance E in the current cloud service architecture, the processor downloads a specific function package according to the service request E, generates a corresponding online service instance E through the downloaded specific function package, and then processes the service request E through the online service instance E.
503. The main server stores the time calling characteristics and the running data of each type of service instance in the current cloud service architecture.
The main server can monitor and store the time calling characteristics and the operation data of each type of service instance in the current cloud service architecture in real time to obtain a database.
In the embodiment of the application, the main server monitors and stores the time calling characteristics and the operation data of each type of service instance in the current cloud service architecture to obtain the database. Therefore, the database stores historical time invocation features and historical operational data for each type of service instance. The main server can train a second service calling feature model according to second historical time calling features and second historical operating data of each type of service instance stored in the database through a machine learning algorithm and a statistical analysis algorithm to obtain a first service calling feature model of each type of service instance. And the main server can predict the first calling number of the service instance of the type through the first service calling feature model of the type according to the first historical time calling feature and the first historical operating data of the service instance of the type stored in the database.
Fig. 6 is a schematic structural diagram of a resource scheduling apparatus according to an embodiment of the present application. Referring to fig. 6, the apparatus includes:
an obtaining module 601, configured to obtain, for multiple service instances of any type in a cloud service architecture, first historical time invocation features and first historical operation data of the multiple service instances;
the prediction module 602 is used for inputting a first historical time calling characteristic and first historical operation data of a plurality of service instances into a first service calling characteristic model and predicting a first calling number of the type service instances in a first preset time length in the future;
the adjusting module 603 is configured to adjust the online service instances of the types in the cloud service architecture according to the first call quantity of the service instances of the types and the current second call quantity of the service instances of the types;
the allocating module 604 is configured to allocate resources to the online-type service instance according to the adjusted online-type service instance.
In another possible implementation manner, the apparatus further includes:
the obtaining module 601 is further configured to obtain second historical time calling features and second historical operating data of multiple types of service instances in the cloud service architecture;
and the training module is used for training the second service calling feature model according to the second historical time calling feature and the second historical operating data through a machine learning algorithm and a statistical analysis algorithm to obtain the first service calling feature model.
In another possible implementation manner, the training module is further configured to determine a weight of each operation index through a statistical analysis algorithm; and training a second service calling feature model through a machine learning algorithm according to the weight of each operation index, the second historical time calling feature and each operation index in the second historical operation data to obtain a first service calling feature model.
In another possible implementation manner, the training module is further configured to predict, through a statistical analysis algorithm, a third invocation number of each type of service instance within a second preset time duration in the future; predicting a fourth calling quantity of each type of service instance in a second preset time in the future through a second service calling feature model according to the weight of each operation index, the second historical time calling feature and each operation index in the second historical operation data; and training the first weight of each operation index in the second service call characteristic model through a machine learning algorithm according to the difference value between the third call quantity and the fourth call quantity to obtain a first service call characteristic model.
In another possible implementation manner, the training module is further configured to adjust the weight of each operation index in the second service invocation feature model if a difference between the third invocation number and the fourth invocation number is greater than a first number threshold, so as to obtain a third service invocation feature model; predicting a fifth calling number of each type of service instance in a second preset time length in the future through a third service calling feature model; and if the difference value between the third calling quantity and the fifth calling quantity is larger than the first quantity threshold value, adjusting the weight again until the difference value between the third calling quantity and the fifth calling quantity is smaller than the first quantity threshold value, and determining that the third service calling feature model obtained by the last adjustment is the first service calling feature model.
In another possible implementation manner, the obtaining module 601 is further configured to obtain, according to the type, historical invocation information of the plurality of service instances of the type in the recorded cloud service architecture, where the historical invocation information includes invocation time and invocation number; a first historical temporal invocation signature of the plurality of service instances is determined based on the historical invocation information.
In the embodiment of the application, for a plurality of service instances of any type in a cloud service architecture, obtaining first historical time calling characteristics and first historical operating data of the plurality of service instances; inputting first historical time calling characteristics and first historical operation data of a plurality of service instances into a first service calling characteristic model, and predicting a first calling number of the service instances of the type in a first preset time length in the future; adjusting the online service instances of the types in the cloud service architecture according to the first calling number of the service instances of the types and the current second calling number of the service instances of the types; and allocating resources for the online type service instance according to the adjusted online type service instance. The number of the online service instances of the type in the cloud service architecture is adjusted according to the first calling number of the service instances of the type and the current second calling number of the service instances of the type, so that the number of the online service instances of the type in the cloud service architecture corresponds to the number of the service requests of the type, and therefore the utilization rate of the online service instances is improved.
It should be noted that: in the resource scheduling apparatus provided in the foregoing embodiment, when performing resource scheduling, only the division of the functional modules is described as an example, and in practical applications, the function allocation may be completed by different functional modules according to needs, that is, the internal structure of the server is divided into different functional modules to complete all or part of the functions described above. In addition, the resource scheduling apparatus and the resource scheduling method provided in the foregoing embodiments belong to the same concept, and specific implementation processes thereof are described in the method embodiments for details, which are not described herein again.
Fig. 7 is a schematic structural diagram of a server 700 according to an embodiment of the present application, where the server 700 may generate a relatively large difference due to a difference in configuration or performance, and may include one or more processors (CPUs) 701 and one or more memories 702, where at least one instruction is stored in the memory 702, and the at least one instruction is loaded and executed by the processor 701 to implement the resource scheduling method provided by each method embodiment. Of course, the server may also have components such as a wired or wireless network interface, a keyboard, and an input/output interface, so as to perform input/output, and the server may also include other components for implementing the functions of the device, which are not described herein again.
The embodiment of the present application further provides a computer-readable storage medium, where at least one instruction is stored in the computer-readable storage medium, and the at least one instruction is loaded by a processor and has an operation to implement the resource scheduling method of the foregoing embodiment.
It will be understood by those skilled in the art that all or part of the steps of implementing the above embodiments may be implemented by hardware, or may be implemented by a program instructing relevant hardware, where the program may be stored in a storage medium, and the storage medium may be a read-only memory, a magnetic disk, an optical disk, or the like.
The above description is only a preferred embodiment of the present application and should not be taken as limiting the present application, and any modifications, equivalents, improvements, etc. made within the spirit and principle of the present application should be included in the protection scope of the present application.

Claims (14)

1. A method for scheduling resources, the method comprising:
for a plurality of service instances of any type in a cloud service architecture, acquiring first historical time calling characteristics of the plurality of service instances, and acquiring first historical operating data of the plurality of service instances;
inputting first historical time calling characteristics and first historical operation data of the plurality of service instances into a first service calling characteristic model, and predicting a first calling number of the service instances of the type in a first preset time length in the future;
adjusting the online service instances of the type in the cloud service architecture according to the first calling quantity of the service instances of the type and the current second calling quantity of the service instances of the type;
and allocating resources for the online service instance of the type according to the adjusted online service instance of the type.
2. The method of claim 1, further comprising:
acquiring second historical time calling characteristics and second historical operating data of a plurality of types of service instances in the cloud service architecture;
and training a second service calling feature model through a machine learning algorithm and a statistical analysis algorithm according to the second historical time calling feature and the second historical operating data to obtain the first service calling feature model.
3. The method of claim 2, wherein the second historical operating data includes at least one operating metric; the training a second service calling feature model according to the second historical time calling feature and the second historical operating data through a machine learning algorithm and a statistical analysis algorithm to obtain the first service calling feature model comprises:
determining the weight of each operation index through the statistical analysis algorithm;
and training the second service calling feature model through the machine learning algorithm according to the weight of each operation index, the second historical time calling feature and each operation index in the second historical operation data to obtain the first service calling feature model.
4. The method of claim 3, wherein the training the second service invocation feature model through the machine learning algorithm according to the weight of each operation index, the second historical time invocation feature and each operation index in the second historical operation data to obtain the first service invocation feature model comprises:
predicting a third calling quantity of each type of service instance in a second preset time length in the future through the statistical analysis algorithm;
predicting a fourth calling number of each type of service instance in a second preset time in the future through the second service calling feature model according to the weight of each operation index, the second historical time calling feature and each operation index in the second historical operation data;
and training the first weight of each operation index in the second service call characteristic model through the machine learning algorithm according to the difference value between the third call quantity and the fourth call quantity to obtain the first service call characteristic model.
5. The method of claim 4, wherein the training the weight of each running index in the second service invocation feature model through the machine learning algorithm by the difference between the third invocation number and the fourth invocation number to obtain the first service invocation feature model comprises:
if the difference value between the third calling quantity and the fourth calling quantity is larger than a first quantity threshold value, adjusting the weight of each operation index in the second service calling feature model to obtain a third service calling feature model;
predicting a fifth calling number of the service instances of each type in a second preset time length in the future through the third service calling feature model;
if the difference between the third calling quantity and the fifth calling quantity is larger than a first quantity threshold value, adjusting the weight again until the difference between the third calling quantity and the fifth calling quantity is smaller than a first quantity threshold value, and determining that the third service calling feature model obtained by the last adjustment is the first service calling feature model.
6. The method of claim 1, wherein obtaining the first historical time invocation feature for the plurality of service instances comprises:
acquiring recorded historical calling information of a plurality of service instances of the type in the cloud service architecture according to the type, wherein the historical calling information comprises calling time and calling quantity;
and determining a first historical time calling characteristic of the plurality of service instances according to the historical calling information.
7. An apparatus for scheduling resources, the apparatus comprising:
the acquisition module is used for acquiring first historical time calling characteristics of a plurality of service instances of any type in a cloud service architecture and first historical operating data of the plurality of service instances;
the prediction module is used for inputting first historical time calling characteristics and first historical running data of the plurality of service instances into a first service calling characteristic model and predicting first calling quantity of the type of service instances in a first preset time length in the future;
the adjusting module is used for adjusting the online service instances of the types in the cloud service architecture according to the first calling quantity of the service instances of the types and the current second calling quantity of the service instances of the types;
and the allocation module is used for allocating resources for the online service instances of the types according to the adjusted online service instances of the types.
8. The apparatus of claim 7, further comprising:
the obtaining module is further configured to obtain second historical time calling features and second historical operating data of multiple types of service instances in the cloud service architecture;
and the training module is used for training a second service calling feature model according to the second historical time calling feature and the second historical operating data through a machine learning algorithm and a statistical analysis algorithm to obtain the first service calling feature model.
9. The apparatus of claim 8, wherein the training module is further configured to determine a weight of each of the operation indicators through the statistical analysis algorithm; and training the second service calling feature model through the machine learning algorithm according to the weight of each operation index, the second historical time calling feature and each operation index in the second historical operation data to obtain the first service calling feature model.
10. The apparatus of claim 9, wherein the training module is further configured to predict, through the statistical analysis algorithm, a third number of calls for the each type of service instance within a second predetermined duration in the future; predicting a fourth calling number of each type of service instance in a second preset time in the future through the second service calling feature model according to the weight of each operation index, the second historical time calling feature and each operation index in the second historical operation data; and training the first weight of each operation index in the second service call characteristic model through the machine learning algorithm according to the difference value between the third call quantity and the fourth call quantity to obtain the first service call characteristic model.
11. The apparatus of claim 10, wherein the training module is further configured to adjust a weight of each operation index in the second service invocation feature model to obtain a third service invocation feature model if a difference between the third invocation number and the fourth invocation number is greater than a first number threshold; predicting a fifth calling number of the service instances of each type in a second preset time length in the future through the third service calling feature model; if the difference between the third calling quantity and the fifth calling quantity is larger than a first quantity threshold value, adjusting the weight again until the difference between the third calling quantity and the fifth calling quantity is smaller than a first quantity threshold value, and determining that the third service calling feature model obtained by the last adjustment is the first service calling feature model.
12. The apparatus according to claim 7, wherein the obtaining module is further configured to obtain, according to the type, recorded historical invocation information of a plurality of service instances of the type in the cloud service architecture, where the historical invocation information includes invocation time and invocation number; and determining a first historical time calling characteristic of the plurality of service instances according to the historical calling information.
13. A server, characterized in that the server comprises:
a processor and a memory, the memory having stored therein at least one instruction that is loaded and executed by the processor to implement the operations in the scheduling method of any of claims 1 to 6.
14. A computer-readable storage medium having stored therein at least one instruction, which is loaded and executed by a processor, to perform operations performed in the scheduling method of any one of claims 1 to 6.
CN201911224422.6A 2019-12-04 2019-12-04 Resource scheduling method, device, server and storage medium Active CN110990138B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201911224422.6A CN110990138B (en) 2019-12-04 2019-12-04 Resource scheduling method, device, server and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201911224422.6A CN110990138B (en) 2019-12-04 2019-12-04 Resource scheduling method, device, server and storage medium

Publications (2)

Publication Number Publication Date
CN110990138A true CN110990138A (en) 2020-04-10
CN110990138B CN110990138B (en) 2023-04-14

Family

ID=70089784

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201911224422.6A Active CN110990138B (en) 2019-12-04 2019-12-04 Resource scheduling method, device, server and storage medium

Country Status (1)

Country Link
CN (1) CN110990138B (en)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111813523A (en) * 2020-07-09 2020-10-23 北京奇艺世纪科技有限公司 Duration pre-estimation model generation method, system resource scheduling method, device, electronic equipment and storage medium
CN112156453A (en) * 2020-10-21 2021-01-01 腾讯科技（深圳）有限公司 Example adaptive adjustment method, apparatus, computer readable storage medium and device
CN112346860A (en) * 2020-10-27 2021-02-09 四川长虹电器股份有限公司 Method and system for elastically deploying service based on machine learning
CN112733892A (en) * 2020-12-28 2021-04-30 北京聚云科技有限公司 Data interaction method and device for model training
CN113747506A (en) * 2020-05-28 2021-12-03 华为技术有限公司 Resource scheduling method, device and network system
CN113791765A (en) * 2021-09-15 2021-12-14 平安科技（深圳）有限公司 Resource arranging method, device and equipment of cloud service and storage medium
CN114844843A (en) * 2022-03-24 2022-08-02 清华大学 Method and device for adjusting number of application instances
CN115629858A (en) * 2022-10-17 2023-01-20 南京航空航天大学 Self-adaptive method for number of function examples in server-free background and application
CN117648167A (en) * 2023-12-11 2024-03-05 北京火山引擎科技有限公司 Resource scheduling method, device, equipment and storage medium

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101043389A (en) * 2007-04-20 2007-09-26 北京航空航天大学 Control system of grid service container
CN106161485A (en) * 2015-03-23 2016-11-23 腾讯科技（深圳）有限公司 Resource regulating method, device and the system of a kind of infrastructure service cluster
CN107679634A (en) * 2017-10-27 2018-02-09 国网陕西省电力公司西安供电公司 A kind of method that power supply trouble based on data visualization reports analysis and prediction for repairment
CN109062769A (en) * 2018-08-21 2018-12-21 南京星邺汇捷网络科技有限公司 The method, apparatus and equipment of IT system performance risk trend prediction
CN109284871A (en) * 2018-09-30 2019-01-29 北京金山云网络技术有限公司 Resource adjusting method, device and cloud platform
CN109548164A (en) * 2019-01-11 2019-03-29 长沙学院 A kind of adaptive scheduling switching method and system based on loading demand
CN110287003A (en) * 2019-06-28 2019-09-27 北京九章云极科技有限公司 The management method and management system of resource

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101043389A (en) * 2007-04-20 2007-09-26 北京航空航天大学 Control system of grid service container
CN106161485A (en) * 2015-03-23 2016-11-23 腾讯科技（深圳）有限公司 Resource regulating method, device and the system of a kind of infrastructure service cluster
CN107679634A (en) * 2017-10-27 2018-02-09 国网陕西省电力公司西安供电公司 A kind of method that power supply trouble based on data visualization reports analysis and prediction for repairment
CN109062769A (en) * 2018-08-21 2018-12-21 南京星邺汇捷网络科技有限公司 The method, apparatus and equipment of IT system performance risk trend prediction
CN109284871A (en) * 2018-09-30 2019-01-29 北京金山云网络技术有限公司 Resource adjusting method, device and cloud platform
CN109548164A (en) * 2019-01-11 2019-03-29 长沙学院 A kind of adaptive scheduling switching method and system based on loading demand
CN110287003A (en) * 2019-06-28 2019-09-27 北京九章云极科技有限公司 The management method and management system of resource

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
文豪等: "分布式服务架构在信号处理***中的应用", 《无线电工程》 *

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113747506A (en) * 2020-05-28 2021-12-03 华为技术有限公司 Resource scheduling method, device and network system
CN111813523A (en) * 2020-07-09 2020-10-23 北京奇艺世纪科技有限公司 Duration pre-estimation model generation method, system resource scheduling method, device, electronic equipment and storage medium
CN112156453A (en) * 2020-10-21 2021-01-01 腾讯科技（深圳）有限公司 Example adaptive adjustment method, apparatus, computer readable storage medium and device
CN112346860A (en) * 2020-10-27 2021-02-09 四川长虹电器股份有限公司 Method and system for elastically deploying service based on machine learning
CN112346860B (en) * 2020-10-27 2022-02-08 四川长虹电器股份有限公司 Method and system for elastically deploying service based on machine learning
CN112733892A (en) * 2020-12-28 2021-04-30 北京聚云科技有限公司 Data interaction method and device for model training
CN113791765A (en) * 2021-09-15 2021-12-14 平安科技（深圳）有限公司 Resource arranging method, device and equipment of cloud service and storage medium
CN113791765B (en) * 2021-09-15 2024-03-08 平安科技（深圳）有限公司 Resource arrangement method, device and equipment of cloud service and storage medium
CN114844843A (en) * 2022-03-24 2022-08-02 清华大学 Method and device for adjusting number of application instances
CN115629858A (en) * 2022-10-17 2023-01-20 南京航空航天大学 Self-adaptive method for number of function examples in server-free background and application
CN117648167A (en) * 2023-12-11 2024-03-05 北京火山引擎科技有限公司 Resource scheduling method, device, equipment and storage medium

Also Published As

Publication number Publication date
CN110990138B (en) 2023-04-14

Similar Documents

Publication Publication Date Title
CN110990138B (en) Resource scheduling method, device, server and storage medium
Bhattacharjee et al. Barista: Efficient and scalable serverless serving system for deep learning prediction services
CN112162865B (en) Scheduling method and device of server and server
CN109597685B (en) Task allocation method, device and server
CN110474852B (en) Bandwidth scheduling method and device
US9898315B1 (en) Management of demand for virtual computing resources
CN110209549B (en) Data processing method, related device, related equipment and system
CN112579304A (en) Resource scheduling method, device, equipment and medium based on distributed platform
CN109995669A (en) Distributed current-limiting method, device, equipment and readable storage medium storing program for executing
EP2757474A2 (en) Adaptive virtualization
CN115421930B (en) Task processing method, system, device, equipment and computer readable storage medium
CN115033340A (en) Host selection method and related device
CN113079045B (en) Bandwidth allocation method, device, server and storage medium
CN106407636B (en) Integration result statistical method and device
CN115202889B (en) Computing resource adjusting method and computing system
CN115562841B (en) Cloud video service self-adaptive resource scheduling system and method
CN111813524A (en) Task execution method and device, electronic equipment and storage medium
CN114896296B (en) Cloud service resource allocation method and device, electronic equipment and computer readable medium
CN114936089A (en) Resource scheduling method, system, device and storage medium
CN115658319A (en) Resource scheduling method, system, device and storage medium
CN112685157B (en) Task processing method, device, computer equipment and storage medium
CN113904940A (en) Resource adjusting method and device, electronic equipment and computer readable storage medium
CN114153714A (en) Log information based capacity adjustment method, device, equipment and storage medium
CN112448855A (en) Method and system for updating block chain system parameters
CN113762972A (en) Data storage control method and device, electronic equipment and storage medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant