Cloud platform resource interface calling method and device based on time estimation and storage medium

Abstract

The invention discloses a cloud platform resource interface calling method and device based on time estimation and a storage medium. The method comprises the steps that resource interface calling tasks are classified; establishing a task type container for each type of tasks, and storing task type data; establishing a periodic scheduling thread and a common thread pool; when a resource interface needs to be called to execute a task, calling a resource interface address, and returning a resource unique identifier; a resource interface calling task is generated and stored in a task library; different scheduling threads periodically scan tasks, load the tasks conforming to the task type of the scheduling thread into a memory, sequentially traverse each task in the memory, put the tasks conforming to conditions into a public thread pool to be executed, query a resource interface of the cloud platform according to a resource unique identifier, judge a state, and change the state of the task into a successful state if the execution is successful; and if the state of the task is in execution and the maximum calling frequency is reached, adjusting the scheduling period and restarting execution. According to the invention, blind resource interface requests can be reduced.

Description

TECHNICAL FIELD

[0001] The present application belongs to the field of cloud computing, and particularly relates to a cloud platform resource interface calling method based on time estimation, a device and a storage medium. BACKGROUND

[0002] A multi-cloud management platform (CMP) is a tool that helps enterprises manage multiple public clouds, private clouds, and hybrid clouds uniformly, aiming to optimize costs, improve operational efficiency, enhance security, and simplify the complexity of cross-cloud environments.

[0003] A cloud platform is an infrastructure and software environment that provides cloud computing services, allowing users to access computing, storage, network, database, and other resources on demand through the Internet without managing the underlying hardware.

[0004] A UUID (Universally Unique Identifier) is a 128-bit (16-byte) identifier used to identify information, usually represented as a 32-bit hexadecimal string (such as 550e8400-e29b-41d4-a716-446655440000), with global uniqueness, suitable for resource identification in distributed systems.

[0005] As more and more business loads migrate to the cloud, enterprise users may deploy their businesses to various types of cloud platforms, such as public clouds and private clouds, according to their business scenarios. Enterprises urgently need a multi-cloud management platform (CMP) for unified management and operation of resource interfaces on various cloud platforms. However, the CMP platform may differ from traditional software applications in implementing remote calls to resource interfaces of various cloud platforms. The main differences are as follows: 1. When calling cloud platform resource interfaces, it may be synchronous or asynchronous. If it is an asynchronous task, the CMP cannot directly obtain the final result of the cloud platform resource operation. The cloud platform cannot notify the CMP platform through asynchronous callback. 2. The multi-cloud management platform may call different cloud platforms and different cloud resource interfaces, with a large number of resource operations.

[0006] Traditional cloud platform resource interface calling methods mainly include the following two types:

[0007] The first traditional technical solution is shown in Figure 1 The implementation steps are as follows:

[0008] 1. The system calls the interface provided by the cloud platform and provides a callback interface to the third party at the same time.

[0009] 2. After the cloud platform system function processing is completed, the original system platform-provided interface is called back.

[0010] The disadvantages of this technical solution are:

[0011] This solution is more suitable for both systems to negotiate business scenarios or third-party systems to provide callback registration mechanisms. There are two reasons why the multi-cloud management platform is not suitable for this scenario:

[0012] 1. The multi-cloud management platform calls many resource interfaces of the cloud platform, and cannot provide callbacks for each resource interface.

[0013] 2. The multi-cloud management platform call may be an interface provided by open source software, which does not provide callback functions.

[0014] The second traditional technical solution is as shown in Figure 2 The implementation steps are as follows:

[0015] 1. The user initiates a resource operation on the multi-cloud management platform, such as creating a virtual machine. The multi-cloud management platform calls the third-party cloud platform operation interface and returns the resource ID.

[0016] 2. The cloud platform sends a delayed message, and the delay time varies according to different resource operations. For example, the delay time is 1 minute, 2 minutes, or 3 minutes. The message content includes: resource ID, cloud platform address, and message topic: create virtual machine.

[0017] 3. After the multi-cloud management platform receives the delayed message with the topic of creating a virtual machine, it calls the pre-written listening logic.

[0018] 4. The listening logic queries the status of the resource according to the message content by calling the third-party platform query interface.

[0019] 5. If the interface query of the resource status is not successful, steps 2, 3, and 4 are repeated.

[0020] The disadvantages of this technical solution are:

[0021] 1. The MQ delay message is executed at any time, which depends on the message middleware framework. It cannot be freely set according to the actual situation of the downstream request interface resource opening.

[0022] 2. The introduction of message middleware requires more deployment resources.

[0023] 3. The message circulates in the system platform, and if the message is lost, the interface cannot be normally executed. The failure risk is relatively high, and the entire process is not easy to monitor. SUMMARY

[0024] The application aims at the deficiencies in the prior art, and provides a cloud platform resource interface calling method based on time estimation, equipment and a storage medium.

[0025] To achieve the above object, the application adopts the following technical solutions:

[0026] A cloud platform resource interface calling method based on time estimation comprises the following steps:

[0027] According to the resource interface opening time length after calling the cloud platform resource interface, the resource interface calling tasks are classified;

[0028] A task type container is established for each type of resource interface calling task to store task type data;

[0029] A period scheduling thread and a public thread pool are established;

[0030] When a user needs to call the cloud platform resource interface to execute a task, the cloud platform resource interface address is called to return the unique identifier UUID of the required resource on the cloud platform;

[0031] A resource interface calling task is generated and saved in a resource interface task library;

[0032] Different scheduling threads of different nodes periodically scan the resource interface calling tasks, load the resource interface calling tasks meeting the task type of the current scheduling thread into the memory, sequentially traverse each task in the memory according to the conditions, put the resource interface calling tasks meeting the conditions into the public thread pool to execute, query the cloud platform resource interface according to the unique identifier UUID of the resource, and judge whether the execution is successful; if the execution is successful, the execution state of the task is changed to successful;

[0033] If the state of the task is in execution and the maximum number of calling times has been reached, the scheduling period is readjusted and the execution is restarted.

[0034] To optimize the above technical solutions, the following specific measures are taken:

[0035] Further, the classification of the resource interface calling tasks is specifically that the resource interface calling tasks with the same resource interface opening time length belong to the same type.

[0036] Further, the attribute information contained in the generated resource interface calling task includes: task type, interface address, client, maximum calling number, current calling number, state, error description, creation time and resource unique identifier.

[0037] Further, the condition for loading the resource interface calling task meeting the scheduling thread task type into the memory is:

[0038] The task state is initial state, and the difference between the current scheduling time and the task creation time is within the interval (T*d*0.1, T+T*d*0.1), wherein T is the scheduling period of the resource interface calling task, and d is the resource scheduling evaluation coefficient;

[0039] The task state is failure state, and the maximum calling number has not been reached;

[0040] The task state is executing, and the maximum calling number has not been reached.

[0041] Further, the specific process of sequentially traversing each task in the memory according to the condition and putting the resource interface calling task meeting the condition into the common thread pool for execution is:

[0042] Locking the resource interface calling task to be called in the resource interface task library to prevent other nodes from repeatedly reading and executing;

[0043] Querying whether the state value of the resource interface calling task is one of unexecuted, executing or failure, if yes, modifying the state value of the task record to executing, and if not, skipping the task;

[0044] According to the resource UUID saved in the task record, querying the underlying interface to view the resource state;

[0045] If the returned resource state is success, the state of the task is modified to success; if the returned resource state is failure, the state of the task is modified to failure, and the error information is recorded;

[0046] The current calling number of the task is increased by 1, and the task is updated to the resource interface task library;

[0047] Releasing the row lock of the resource interface task library.

[0048] Further, the re-adjustment of the scheduling period is specifically: new scheduling period = current period * maximum calling number.

[0049] The application further provides an electronic device, which comprises a memory, a processor and a computer program stored in the memory and capable of running on the processor, and the processor implements the cloud platform resource interface calling method based on time estimation when executing the computer program.

[0050] The application further provides a computer readable storage medium storing a computer program, wherein the computer program enables a computer to execute the cloud platform resource interface calling method based on time estimation.

[0051] The application has the following advantages:

[0052] 1. After the cloud platform resource interface is called, a periodic scheduling thread is established according to the resource opening time, and the time period is flexibly defined. Each scheduling thread corresponds to a group of storage task type containers. As long as the interface calling execution meets a certain type of task, the interface execution can be completed under the scheduling thread.

[0053] 2. Different nodes of the deployment service can be concurrently executed. When the cloud management platform resource operation is more, the service node is increased, and the cloud platform resource interface calling speed is improved. And the execution of the whole system only depends on the database, and the deployment is simple.

[0054] 3. The failed task can be repeatedly executed, and the fault tolerance is good. According to the maximum number of calls configured, the execution is stopped, and the task execution state and the task execution result are viewed, and the whole process of calling the cloud platform resource interface is monitored.

[0055] 4. The scheme introduces a resource scheduling evaluation coefficient to ensure that the task is not immediately executed, and the cloud platform is given sufficient resource opening time after the interface is called.

[0056] 5. If the estimated opening time is inaccurate, a new periodic scheduling can be established according to the task execution number and the task period, and the interface is executed in the new periodic scheduling. BRIEF DESCRIPTION OF DRAWINGS

[0057] Figure 1 It is a principle diagram of the first traditional technical scheme.

[0058] Figure 2 It is a principle diagram of the second traditional technical scheme.

[0059] Figure 3 It is a whole principle diagram of the cloud platform resource interface calling method based on time estimation.

[0060] Figure 4 It is a flowchart of the initialization configuration stage.

[0061] Figure 5 It is a flowchart of the system running stage.

[0062] Figure 6 It is a periodic scheduling principle diagram.

[0063] Figure 7This is a flowchart illustrating how to iterate through each task in memory and place it into a shared thread pool for execution. Detailed Implementation

[0064] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0065] Example 1

[0066] This invention proposes a cloud platform resource interface invocation method based on time estimation. The overall technical solution of this invention is as follows: Figure 2 As shown: After the service starts, a certain number of task type containers, such as T1_Container and T2_Container, and a certain number of periodic scheduling threads, such as T1_Schedule and T2_Schedule, are initialized. The number is related to the resource interface's open duration, such as the estimated interface open duration T1 and T2. Each interface corresponds to a task type, which is registered in the task type container during initialization. When a cloud platform resource interface is called, the resource UUID is returned first, and an interface task is generated and saved to the resource interface task library. Different scheduling threads on different nodes periodically scan the tasks, load the relevant task types into memory, and iterate through them in order according to conditions. Tasks that meet the conditions are placed in the thread pool for execution. The cloud platform resource interface is queried based on the resource UUID to check if the execution was successful. Finally, if the execution is successful, the task's execution status is changed to success; otherwise, it is marked as failure.

[0067] The more detailed implementation steps are as follows:

[0068] This method consists of two stages:

[0069] (1) Initialization configuration phase: When the service starts, the initialization interface calls require resources and related data.

[0070] (2) System runtime phase: Multi-cloud management platform, when making resource service requests or resource operations, the execution call process of the multi-cloud management platform.

[0071] During the initial configuration phase, such as Figure 4 As shown:

[0072] Step 1: Categorize resource interface call tasks based on the resource interface's activation duration after invoking the cloud platform resource interface; examples are shown in Table 1 below:

[0073] Table 1

[0074] Calling cloud platform interface Resource opening duration Creating virtual machine 1 minute Virtual machine startup 20 seconds Virtual machine shutdown 20 seconds Creating database cluster 2 minutes Floating IP binding network card 10 seconds Floating IP unbinding network card 10 seconds

[0075] Based on estimations, the entire multi-cloud management platform schedules cloud platform resource interfaces at 1 minute, 20 seconds, 2 minutes, and 10 seconds per cycle.

[0076] Step 2: Create a task type container for each type of resource interface call task to store task type data; the task type name is the interface name. See Table 2 below for an example:

[0077] Table 2

[0078]

[0079]

[0080] Step 3: Initialize and establish the periodic scheduling thread and the common thread pool; examples are shown in Table 3:

[0081] Table 3

[0082]

[0083] During system operation, such as Figure 5 As shown.

[0084] Step 1: When a user needs to call the cloud platform resource interface to perform a task, call the cloud platform resource interface address and return the unique identifier (UUID) of the required cloud platform resource.

[0085] In this embodiment, the task is to create a virtual machine on a multi-cloud management platform and return the unique identifier (UUID) of the created virtual machine.

[0086] Step 2: Generate resource interface call tasks and save them to the resource interface task library;

[0087] In this embodiment, a task is generated to create a virtual machine.

[0088] The generated task includes the required attribute information listed in Table 4 below:

[0089] Table 4

[0090]

[0091]

[0092] Step 3: Different scheduling threads on different nodes (e.g., T1minSchedule) periodically scan resource interface call tasks and load resource interface call tasks that match the task type of their respective scheduling thread (e.g., createVm) into memory. To avoid immediate execution of generated tasks, it is necessary to determine the earliest and latest execution times of the tasks.Figure 6 The condition of loading the task into the memory is as follows:

[0093] It is judged whether the task is one of the following three conditions:

[0094] The task state is the initial state, and the difference between the current scheduling time and the task creation time is within the interval (T*d*0.1, T+T*d*0.1), wherein T is the scheduling period of the resource interface calling task, and d is the resource scheduling evaluation coefficient;

[0095] The task state is the failure state, and the maximum number of calls is not reached;

[0096] The task state is in execution, and the maximum number of calls is not reached.

[0097] Step four: according to the condition sequence, each task in the memory is traversed, and the resource interface calling task meeting the condition is put into the public thread pool for execution, and the execution logic is as follows Figure 7 The flow is as follows:

[0098] Lock the resource interface calling task to be called in the resource interface task library to prevent other nodes from repeatedly reading and executing;

[0099] Query whether the state value of the resource interface calling task is one of unexecuted, in execution or failure, if yes, modify the state value of the task record to in execution, if not, skip the task;

[0100] According to the resource UUID saved in the task record, the underlying interface is queried to view the resource state;

[0101] If the returned resource state is success, the state of the task is modified to success; if the returned resource state is failure, the state of the task is modified to failure, and the error information is recorded;

[0102] The current number of calls of the task is increased by 1, and the task is updated to the resource interface task library;

[0103] Release the row lock of the resource interface task library.

[0104] Step five: according to the unique identifier UUID of the resource, the resource interface of the cloud platform is queried to judge whether the execution is successful, if yes, the execution state of the task is changed to success; if the state of the task is in execution, and the maximum number of calls has been reached, the scheduling period is adjusted again, and the new scheduling period = current period * maximum number of calls, and the execution is started again.

[0105] Embodiment two

[0106] The application provides an electronic device, comprising a memory, a processor and a computer program stored in the memory and executable on the processor, and when the processor executes the computer program, a cloud platform resource interface calling method based on time estimation is realized.

[0107] Embodiment three

[0108] The application provides a computer readable storage medium, which stores a computer program, and the computer program enables a computer to execute the cloud platform resource interface calling method based on time estimation.

[0109] In the embodiments disclosed in the present application, the computer storage medium can be a tangible medium which can contain or store programs for use by or in connection with an instruction execution system, device or apparatus. The computer storage medium can include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared or semiconductor system, device or apparatus, or any suitable combination of the above. More specific examples of the computer storage medium can include one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device or any suitable combination of the above.

[0110] Those skilled in the art can realize that the units and algorithm steps of each example described in combination with the embodiments disclosed in the present application can be realized by electronic hardware or a combination of computer software and electronic hardware. Whether the functions are realized in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to realize the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0111] The above is only the preferred embodiment of the present application, and the protection scope of the present application is not limited to the above-mentioned embodiments. Any technical solution falling within the concept of the present application shall fall within the protection scope of the present application. It should be noted that, for ordinary skilled in the art, some improvements and refinements without departing from the principles of the present application shall be considered within the protection scope of the present application.

Claims

1. A time estimation based cloud platform resource interface calling method, characterized in that, The method comprises the following steps: According to the resource interface opening time after calling the cloud platform resource interface, the resource interface calling task is classified; A task type container is established for each type of resource interface calling task to store task type data; A periodic scheduling thread and a common thread pool are established; When a user needs to call a cloud platform resource interface to execute a task, the cloud platform resource interface address is called, and the unique identifier UUID of the required resource on the cloud platform is returned; A resource interface calling task is generated and saved in a resource interface task library; Different scheduling threads of different nodes periodically scan the resource interface calling tasks, load the resource interface calling tasks of the same type as the scheduling thread into the memory, sequentially traverse each task in the memory according to the conditions, put the resource interface calling tasks meeting the conditions into the common thread pool for execution, query the cloud platform resource interface according to the unique identifier UUID of the resource, and determine whether the execution is successful. If the execution is successful, the execution state of the task is changed to successful. If the state of the task is executing and the maximum number of calls has been reached, the scheduling period is adjusted and the execution is restarted.

2. The time estimate based cloud platform resource interface invocation method of claim 1, wherein, The classification of the resource interface calling task is specifically that the resource interface calling tasks with the same resource interface opening time are of the same type.

3. The time estimate based cloud platform resource interface invocation method of claim 1, wherein, The generated resource interface calling task contains attribute information including task type, interface address, client, maximum number of calls, current number of calls, state, error description, creation time and resource unique identifier.

4. The time estimate based cloud platform resource interface invocation method of claim 1, wherein, The condition for loading the resource interface calling tasks of the same type as the scheduling thread into the memory is that the task state is initial state, and the difference between the current scheduling time and the task creation time is within the interval (T*d*0.1, T+T*d*0.1), wherein T is the scheduling period of the resource interface calling task, and d is the resource scheduling evaluation coefficient. The task state is failure state, and the maximum number of calls has not been reached. The task state is executing, and the maximum number of calls has not been reached. The specific process of sequentially traversing each task in the memory according to the conditions and putting the resource interface calling tasks meeting the conditions into the common thread pool for execution is as follows:

5. The time estimate based cloud platform resource interface invocation method of claim 1, wherein, Lock the resource interface calling task to be called in the resource interface task library to prevent other nodes from repeatedly reading and executing; Query whether the state value of the resource interface calling task is one of unexecuted, executing or failed. If yes, modify the state value of the task record to executing. If not, skip the task; According to the resource UUID saved in the task record, query the underlying interface to view the resource state; If the returned resource state is successful, modify the state of the task to successful. If the returned resource state is failed, modify the state of the task to failed and record the error information; Increase the current number of calls of the task by 1, and update the task to the resource interface task library; Release the row lock of the resource interface task library. The adjustment of the scheduling period is specifically that the new scheduling period = current period * maximum number of calls.

6. The time estimate based cloud platform resource interface invocation method of claim 1, wherein, It comprises:

7. An electronic device, comprising: ​ The memory, the processor and the computer program stored in the memory and capable of running on the processor, wherein the processor executes the computer program to implement the method for calling cloud platform resource interface based on time estimation according to any one of claims 1-6.

8. A computer readable storage medium storing a computer program, characterized in that, The computer program enables the computer to execute the method for calling cloud platform resource interface based on time estimation according to any one of claims 1-6.

Images