Heterogeneous multi-cloud resource pool arrangement method and cloud resource management method and device

Abstract

The invention provides a heterogeneous multi-cloud resource pool arrangement method and a cloud resource management method and device.The arrangement method comprises the steps that for each target task of each cloud platform, calling relations among multiple related first APIs are arranged based on parameter information, so that the related first APIs are called to achieve the target tasks; wherein the target task is a task involved in cloud resource full life cycle management; based on the calling relation and the parameter information, packaging is carried out according to different types of the target tasks, and a second API interface corresponding to each type of target tasks is obtained; generating a first visual interface corresponding to each type of target tasks, and displaying the first visual interface to a user; wherein the first visual interface comprises an interaction control, so that a user calls the second API interface through the first visual interface to execute the target task. In this way, the functions of identification, arrangement and automatic management of heterogeneous multi-cloud resources, unified abstraction of cross-cloud resources and the like can be achieved.

Description

Technical Field

[0001] The present application relates to the field of cloud computing technology, and in particular to a heterogeneous multi-cloud resource pool orchestration method, a cloud resource management method and a device. Background Art

[0002] With the development of new technologies such as cloud computing, big data, 5G and artificial intelligence, enterprises are being driven towards digitalization and intelligence, and cloud migration has become an inevitable trend. Cloud migration refers to the process of migrating an enterprise's business, applications, data, etc. to a cloud computing platform for management and operation. Specifically, enterprises can use the cloud resources provided by cloud computing service providers to migrate traditional local data centers or servers to a cloud environment.

[0003] Configuring a multi-cloud environment is a common method for enterprises to move to the cloud. A multi-cloud environment specifically refers to an enterprise or organization using two or more different cloud service providers to provide cloud resources when building or using a cloud computing platform. This has the advantages of obtaining better performance, reliability, security, and cost control.

[0004] However, there are significant differences in the API interfaces provided by different cloud service providers, including authentication mechanisms, request formats, response structures, etc. In addition, the service and resource naming and configuration options of each cloud platform are different, which poses challenges to users' use of cloud platforms and makes it difficult to configure a multi-cloud environment. Summary of the invention

[0005] The embodiments of the present application provide a heterogeneous multi-cloud resource pool orchestration method, a cloud resource management method and a device to solve the problem of difficulty in configuring a multi-cloud environment.

[0006] In a first aspect, an embodiment of the present application provides a heterogeneous multi-cloud resource pool orchestration method, wherein the heterogeneous multi-cloud resource pool is constructed based on multiple different cloud platforms; the method includes: obtaining parameter information of first API interfaces provided by multiple cloud platforms; for each target task of each cloud platform, arranging the calling relationship between multiple related first API interfaces based on the parameter information, so that the related first API interface can achieve the target task through calling; wherein the target task is a task involved in the full life cycle management of cloud resources, and the full life cycle of cloud resources at least includes application, creation, delivery, operation and maintenance and / or destruction, and the related first API interface is an interface in the first API interface that is related to the target task; based on the calling relationship and parameter information, encapsulation is performed according to different target task categories to obtain a second API interface corresponding to each type of target task; a first visualization interface corresponding to each type of target task is generated, and the first visualization interface is displayed to the user; wherein the first visualization interface includes interactive controls, and the interactive controls are associated with the second API interface, so that the user calls the second API interface through the first visualization interface to execute the target task.

[0007] In one achievable method, the step of generating a first visualization interface corresponding to each type of target task includes: creating a service template for each type of target task; adding relevant information of the target task to the service template, wherein the relevant information includes at least application scenario information, instance specifications, and billing information; associating the service template with a second API interface corresponding to the target task, and adding input parameters of the second API interface to the service template; generating a first user-oriented visualization interface based on the service template, wherein the first visualization interface includes at least application scenario information, instance specifications, billing information, and input parameters.

[0008] In one implementable method, based on the calling relationship and parameter information, encapsulation is performed according to different target task categories, and after the step of obtaining the second API interface corresponding to each type of target task, it also includes: establishing a mapping relationship table between the second API interface and its corresponding target tasks; wherein the mapping relationship table includes at least the interface ID of the second API interface and the task ID of the target task.

[0009] In an achievable manner, the method also includes: in response to a user operation on an interactive control, calling a second API interface to execute a target task; after the target task is executed, obtaining output parameters of the second API interface, and displaying the output parameters to the user through a visual interface; in response to a user operation on an interactive control, calling the second API interface to execute the target task includes: in response to the user operation on the interactive control, determining user needs; when the user needs are cross-cloud platform needs, determining a first cloud resource allocation strategy based on the user needs; the first cloud resource allocation strategy includes at least multiple target cloud platforms and cloud resource ratios between each target cloud platform; when the user needs are single cloud platform needs, determining a second cloud resource allocation strategy based on the user needs, the second cloud resource allocation strategy includes at least one target cloud platform; calling the target second API interface based on the first cloud resource allocation strategy or the second cloud resource allocation strategy to execute the target task.

[0010] In one achievable method, the step of calling the target second API interface based on the first cloud resource allocation strategy or the second cloud resource allocation strategy to execute the target task includes: in response to the target second API interface being called, querying the mapping relationship table based on the interface ID of the target second API interface, the first cloud resource allocation strategy and / or the second cloud resource allocation strategy to determine the task ID of the target task to be executed; and calling the relevant first API interface based on the task ID to execute the target task.

[0011] In one implementable manner, the method also includes: in response to a target action of a target cloud platform, reacquiring parameter information of a target first API interface corresponding to the target action; the target action is to update the target first API interface so that the parameter information of the target first API interface changes; based on the target first API interface, determining one or more second API interfaces related thereto as second API interfaces to be updated; and repackaging the second API interface to be updated based on the reacquired parameter information.

[0012] In an achievable manner, for each target task of each cloud platform, a calling relationship between multiple related first API interfaces is arranged based on parameter information so that before the related first API interface is called to implement the target task, the step also includes: determining attribute information of the second API interface, the attribute information at least including the name, description information and version information of the second API interface; and, based on the task requirements and parameter information of the target task, determining input parameters and output parameters of the second API interface according to different target task categories; based on the calling relationship and parameter information, encapsulating according to different target task categories to obtain the second API interface corresponding to each type of target task, the step includes: based on the attribute information, calling relationship, input parameters and output parameters, encapsulating according to different target task categories to obtain the second API interface corresponding to each type of target task.

[0013] In a second aspect, an embodiment of the present application provides a cloud resource management method, wherein a heterogeneous multi-cloud resource pool is constructed based on multiple different cloud platforms; the device includes: determining a processing strategy for cloud resources based on the life cycle of the cloud resources; the life cycle is one of the stages in the entire life cycle of cloud resources, and the entire life cycle of cloud resources includes at least application, creation, delivery, operation and maintenance, and / or destruction; determining a target task to be executed based on the processing strategy; calling a target second API interface through a first visual interface to execute the target task; wherein the target second API interface is one of the second API interfaces in the heterogeneous multi-cloud resource pool orchestration method provided by the aforementioned first aspect and its various implementation methods.

[0014] In a third aspect, an embodiment of the present application provides a heterogeneous multi-cloud resource pool orchestration device, including: an acquisition module, used to obtain parameter information of a first API interface provided by multiple cloud platforms; an orchestration module, used to orchestrate the calling relationship between multiple related first API interfaces based on the parameter information for each target task of each cloud platform, so that the related first API interface can achieve the target task through calling; wherein the target task is a task involved in the full life cycle management of cloud resources, and the full life cycle of cloud resources at least includes application, creation, delivery, operation and maintenance, and / or destruction; an encapsulation module, used to encapsulate according to different target task categories based on the calling relationship and parameter information, and obtain a second API interface corresponding to each type of target task; a generation module, used to generate a first visualization interface corresponding to each type of target task, and display the first visualization interface to the user; wherein the first visualization interface includes interactive controls, and the interactive controls are associated with the second API interface, so that the user calls the second API interface through the first visualization interface to execute the target task.

[0015] In a fourth aspect, an embodiment of the present application provides a cloud resource management device, comprising: a first determination module, used to determine a processing strategy for cloud resources based on the life cycle of the cloud resources; the life cycle is one of the stages in the entire life cycle of cloud resources, and the entire life cycle of cloud resources includes at least application, creation, delivery, operation and maintenance, and / or destruction; a second determination module, used to determine a target task to be executed based on the processing strategy; a calling module, used to call a target second API interface through a first visual interface to execute the target task; wherein the target second API interface is one of the second API interfaces in the heterogeneous multi-cloud resource pool orchestration method provided by the aforementioned first aspect and its various implementation methods.

[0016] From the above content, it can be seen that the embodiment of the present application provides a heterogeneous multi-cloud resource pool orchestration method, a cloud resource management method and a device, and the heterogeneous multi-cloud resource pool orchestration method includes: obtaining parameter information of the first API interface provided by multiple cloud platforms; for each target task of each cloud platform, arranging the calling relationship between multiple related first API interfaces based on the parameter information, so that the related first API interface can realize the target task through calling; wherein the target task is the task involved in the full life cycle management of cloud resources, and the full life cycle of cloud resources at least includes application, creation, delivery, operation and maintenance and / or destruction; based on the calling relationship and parameter information, encapsulating according to the different categories of target tasks, and obtaining the second API interface corresponding to each type of target task; generating the first visualization interface corresponding to each type of target task, and displaying the first visualization interface to the user; wherein the first visualization interface includes an interactive control, and the interactive control is associated with the second API interface, so that the user can call the second API interface through the first visualization interface to execute the target task. In this way, it can play the role of identifying, arranging, automatically managing heterogeneous multi-cloud resources and unified abstraction of cross-cloud resources, and realize efficient configuration of multi-cloud environment. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 A first flow chart of the heterogeneous multi-cloud resource pool orchestration method provided in an embodiment of the present application;

[0018] Figure 2 A second flow chart of the heterogeneous multi-cloud resource pool orchestration method provided in an embodiment of the present application;

[0019] Figure 3 A schematic diagram of a second visual interface provided in an embodiment of the present application;

[0020] Figure 4 A schematic diagram of a first visual interface provided in an embodiment of the present application;

[0021] Figure 5 A schematic diagram of a process for generating a first visual interface provided in an embodiment of the present application;

[0022] Figure 6 A flowchart of a cloud resource management method provided in an embodiment of the present application;

[0023] Figure 7 It is a structural schematic diagram of a heterogeneous multi-cloud resource pool orchestration device;

[0024] Figure 8 A schematic diagram of the structure of a cloud resource management device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0025] In order to enable those skilled in the art to better understand the technical solutions in the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in the field without creative work should fall within the scope of protection of the present application.

[0026] Configuring a multi-cloud environment is a common method for enterprises to move to the cloud. A multi-cloud environment specifically refers to an enterprise or organization using two or more different cloud service providers to provide cloud resources when building or using a cloud computing platform. This has the advantages of obtaining better performance, reliability, security, and cost control.

[0027] The multi-cloud environment is supported by a heterogeneous multi-cloud resource pool, which refers to a collection of resources consisting of multiple different types of cloud platforms (such as public cloud, private cloud, hybrid cloud, etc.) and virtualization technologies (such as VMware, KVM, OpenStack, etc.). These resources may be physically scattered in different locations, but through virtualization technology and multi-cloud management platforms, they are logically integrated into a unified resource pool for users to use on demand. Users can obtain cloud resources from the multi-cloud resource pool (cloud platform) and run services based on cloud resources. In general cloud computing scenarios, applications are usually deployed in the environment of a single cloud service provider (operator). The heterogeneous multi-cloud resource pool can integrate and manage resources across cloud service providers, allowing users to choose the resources that best suit their needs from different cloud service providers. In this way, users can choose the best resources based on specific application requirements. In addition, when a cloud service fails or has performance issues, the business can be seamlessly migrated and expanded to other cloud services to ensure the continuity and stability of the application.

[0028] Cloud resources are the resources provided by the resource pool to users, specifically, various computing, storage, and network resources provided to users. Users can order, configure, and use cloud resources through the cloud service provider's platform without having to build and maintain physical infrastructure themselves.

[0029] Cloud resources mainly include the following aspects:

[0030] 1. Virtual Machines: A virtual machine is an independent computer system simulated on a physical server. Users can install and run operating systems and applications on the virtual machine.

[0031] 2. Storage: Cloud storage provides scalable storage space. Users can store data in the cloud and access it anytime and anywhere. Common cloud storage services include object storage, file storage, and block storage.

[0032] 3. Database: Cloud database is a database service managed and deployed in the cloud. Users can access and operate the database through the cloud platform.

[0033] 4. Network: Cloud network provides the creation and management functions of virtual networks. Users can customize network topology, set security rules, configure load balancing, etc. to meet the network requirements of applications.

[0034] 5. Serverless Computing: Serverless computing is a computing model that does not require attention to the underlying server. Users only need to write function code and automatically manage and run it through the cloud platform to achieve on-demand computing and elastic expansion.

[0035] 6. Container: Cloud containers provide technology for packaging applications into independent and lightweight containers, enabling applications to have consistent operating capabilities in different environments.

[0036] In the embodiment of the present application, cloud resources may also include CPU and memory, etc., which will not be elaborated here.

[0037] In order to solve the problem of difficulty in configuring a multi-cloud environment, the embodiments of the present application provide a heterogeneous multi-cloud resource pool orchestration method, a cloud resource management method and an apparatus. The heterogeneous multi-cloud resource pool orchestration method integrates the API interfaces provided by the cloud platform, and orchestrates the interfaces through a visual interface in the business orchestration service to generate a new capability interface (a second API interface). The service is published by associating the capability interface with a service template, thereby achieving rapid access to the cloud platform and realizing the purpose of full life cycle management of creation, modification, and recovery / deletion of cloud resources on the cloud platform.

[0038] The embodiment of the present application may also provide an orchestration engine, which is a platform or tool for managing cloud resources. Furthermore, the heterogeneous multi-cloud resource pool orchestration method and cloud resource management method provided in the embodiment of the present application may be deployed in the orchestration engine. In this way, the orchestration engine can be used to manage and optimize resource allocation and workload across multiple cloud platforms, achieve cross-cloud platform collaboration, achieve unified resource management and task coordination, and improve efficiency and consistency.

[0039] Furthermore, the orchestration engine may include a management side and a user side. Based on the method provided in the embodiment of the present application, on the management side, the orchestration engine can automatically allocate and schedule resources on different cloud platforms, optimize according to preset policies and real-time needs, and ensure optimal resource utilization and performance. In addition, through intelligent algorithms and real-time monitoring, the engine can achieve load balancing across multiple cloud platforms, avoid excessive or insufficient resources, and improve the overall stability and reliability of the system. On the user side, the orchestration engine can provide an intuitive user interface and self-service functions, allowing users to easily manage and monitor their resources and workloads in a multi-cloud environment. In addition, real-time analysis and reporting functions can be provided to help users understand resource usage, performance indicators, and cost analysis to support decision-making and optimization.

[0040] It is understandable that the orchestration engine may also include a development side, which provides technical support for the process engine so that the process engine can implement the aforementioned functions.

[0041] Figure 1 A first flow chart of a heterogeneous multi-cloud resource pool orchestration method provided in an embodiment of the present application.

[0042] Figure 2 A second flow chart of the heterogeneous multi-cloud resource pool orchestration method provided in an embodiment of the present application.

[0043] like Figure 1 and Figure 2 As shown, the heterogeneous multi-cloud resource pool orchestration method provided in the embodiment of the present application includes the following steps S100-S400.

[0044] S100: Obtain parameter information of a first API interface provided by multiple cloud platforms.

[0045] Among them, multiple cloud platforms are used to establish a heterogeneous multi-cloud resource pool. The first API interface can be an interface for virtual machine management (such as creating, starting, and stopping virtual machines), storage management (such as creating storage volumes), network configuration (such as setting network security groups and assigning IP addresses), database services (such as creating database instances), and cloud monitoring and log analysis interfaces. Each API interface provides programmatic access and control capabilities for specific cloud services or resource operations.

[0046] The parameter information may specifically refer to the input parameters and output parameters of the first API interface. Exemplarily, when the first API interface is an interface for activating a virtual machine, the input parameters may include the virtual machine name, number of CPU cores, memory size, operating system type, network configuration, storage configuration (such as disk type and size), and key pair information (for SSH access), etc. The output parameter is the result returned after the API operation is executed, which is used to inform the caller whether the operation is successful and the result of the operation. For the interface for activating a virtual machine, the output parameters may include the virtual machine instance ID, creation time, current status (such as running, stopped), and IP address list, etc.

[0047] In practical applications, step S100 can be implemented based on a process engine, and the step of obtaining interface parameter information can also be referred to as adding the API interfaces corresponding to each cloud platform in the process engine. In other words, the process engine can integrate and manage the API interfaces of each cloud platform, and the process engine can communicate with various cloud platforms through communication protocols such as RESTful API and SOAP to manage the first API interface.

[0048] S200: For each target task of each cloud platform, arrange the calling relationship between multiple related first API interfaces based on parameter information, so that the related first API interface can realize the target task through calling. The related first API interface is an interface related to the target task in the first API interface.

[0049] Among them, the target tasks are related to the entire life cycle of cloud resources and are the tasks involved in the management of the entire life cycle of cloud resources. The entire life cycle of cloud resources at least includes application, creation, delivery, operation and maintenance, and / or destruction. In other words, the entire life cycle of cloud resources involves multiple target tasks, which cover all stages from resource planning, application, creation, delivery, operation and maintenance to destruction.

[0050] In the application phase, the target task involves initiating resource requests to the cloud platform, such as applying for virtual machines, database instances, or storage volumes. At this time, the orchestration engine should call the corresponding API interface to initiate an application request to the cloud platform based on the parameter information provided by the user (such as resource specifications, configuration requirements, etc.).

[0051] After the application is accepted by the cloud platform, it enters the resource creation phase. At this point, the orchestration engine can call a series of first API interfaces and complete the resource creation work according to the preset process and parameter configuration. The target task involved at this time can be called a resource creation task.

[0052] After the resource is created, it enters the delivery phase. At this point, the detailed information of the resource (such as IP address, access credentials, etc.) can be obtained through the first API interface, and then delivered to the user for use. The target task involved at this time can be called a delivery task.

[0053] During the use of resources, operation and maintenance is an indispensable stage. The orchestration engine needs to be able to call the first API interface of the cloud platform to monitor, maintain, update and expand resources. At least shutdown tasks, restart tasks, startup tasks and expansion tasks are involved.

[0054] When resources are no longer needed, they enter the destruction phase, and the orchestration engine needs to call the first API interface of the cloud platform to destroy the resources, release the occupied cloud resources, and avoid unnecessary expenses. At this time, at least the target tasks involved are deleting virtual machines, releasing storage volumes, and unbinding security groups.

[0055] In the embodiment of the present application, in order to facilitate calling the first API interface, the embodiment of the present application can arrange the calling relationship between multiple related first API interfaces based on parameter information to achieve integration of the first API interface. In this way, when the target task needs to be executed, it can be directly implemented by using the integrated calling relationship.

[0056] Figure 3 A schematic diagram of a second visualization interface provided in an embodiment of the present application.

[0057] On the management side of the process engine, the orchestration service can be implemented through the second visual interface, where the second visual interface is an interface developed and opened by the development side. Figure 3 As shown, the target task can be cloud resource management, such as Figure 3The visual interface shown exemplifies the call management of the first API interface including the cloud resource test API and the cloud platform activation API. The specific orchestration steps can be implemented based on the orchestration model. The orchestration model can be a model obtained by training based on multiple orchestration instances. Based on the orchestration model, the interface orchestration can be automatically implemented. In some implementations, the interface orchestration can also be manually implemented in the second visual interface through interactive methods such as dragging and dropping. The second visual interface also provides editor control elements (such as conditional branches, loop control) and data processing functions (data mapping, conversion), etc. In this way, users can not only combine API calls, but also dynamically adjust the execution process according to the return results to implement complex business logic. The embodiments of the present application do not make specific limitations on this. It can be seen that based on the method provided in the embodiments of the present application, the process engine can provide the ability to create interfaces for cloud resources opened through orchestration.

[0058] S300: Based on the calling relationship and parameter information, encapsulation is performed according to different target task categories to obtain a second API interface corresponding to each type of target task.

[0059] It is understandable that for the same type of target tasks, such as the task of applying for a virtual machine, the parameter information of the first API interface provided by different cloud platforms is different. The embodiment of the present application can be encapsulated according to the category of the target task to obtain the second API interface for each type of target task. In this way, when the target task needs to be executed, it is only necessary to call the second API interface. For the user side, there is no need to directly understand the first API interfaces of each cloud platform and their differences, which simplifies the operation process. Through the encapsulation mechanism of S300, users only need to interact with the process engine through a unified and concise second API interface to complete the execution of various target tasks such as virtual machine application, cloud resource allocation, data backup and recovery, etc.

[0060] S400: Generate a first visualization interface corresponding to each type of target task, and display the first visualization interface to the user; wherein the first visualization interface includes interactive controls, and the interactive controls are associated with the second API interface, so that the user calls the second API interface through the first visualization interface to execute the target task.

[0061] The step of displaying the first visual interface to the user occurs after the step of publishing or putting the service on the shelf. In some implementations, the step of canceling the publishing or delisting of the service can also be implemented through the process engine, which is not specifically limited in the embodiments of the present application.

[0062] Figure 4 A schematic diagram of a first visualization interface provided in an embodiment of the present application.

[0063] The first visual interface is an interface developed and opened by the development side. On the user side of the process engine, the user can interact with the process engine through the first visual interface. Figure 4 The first visualization interface shown includes interactive controls. Based on the first visualization interface, the second API interface can be directly called to achieve the target task applied for by the virtual machine.

[0064] From the above content, it can be seen that the embodiment of the present application provides a heterogeneous multi-cloud resource pool orchestration method, which includes: obtaining parameter information of the first API interface provided by multiple cloud platforms; for each target task of each cloud platform, arranging the calling relationship between multiple related first API interfaces based on the parameter information, so that the related first API interface can achieve the target task through calling; wherein the target task is a task involved in the full life cycle management of cloud resources, and the full life cycle of cloud resources at least includes application, creation, delivery, operation and maintenance, and / or destruction; based on the calling relationship and parameter information, encapsulating according to the different categories of target tasks, and obtaining the second API interface corresponding to each type of target task; generating the first visualization interface corresponding to each type of target task, and displaying the first visualization interface to the user; wherein the first visualization interface includes an interactive control, and the interactive control is associated with the second API interface, so that the user can call the second API interface through the first visualization interface to execute the target task. In this way, it can play the role of identifying, arranging, automating management of heterogeneous multi-cloud resources and unified abstraction of cross-cloud resources.

[0065] It is worth noting that the heterogeneous multi-cloud resource pool orchestration method provided in the embodiment of the present application can realize online orchestration. Among them, online orchestration refers to the process of remotely configuring and managing resources using online tools or platforms, which allows users to perform efficient and convenient orchestration operations through the Internet at any time and any place. In the actual operation process, the user can design and manage the life cycle of cloud resources by dragging and dropping interactive controls in the first visual interface. In addition, the embodiment of the present application can encapsulate complex API call relationships into an easy-to-understand second API interface, and users can complete complex cloud resource management tasks without in-depth understanding of the API details of each cloud platform. Users can flexibly configure and manage cloud resources through a visual interface according to specific needs to adapt to different business scenarios and changes. In addition, the method provided in the embodiment of the present application also supports multiple different cloud platforms, allowing users to manage the resources of multiple cloud service providers in a unified interface, achieving compatibility and interoperability across cloud platforms.

[0066] Figure 5 A schematic diagram of a process for generating a first visual interface provided in an embodiment of the present application.

[0067] like Figure 5As shown, step S400 may include the following steps S401-S404.

[0068] S401: Create a service template for each type of target task.

[0069] Specifically, the service template can be a standardized configuration file for describing various attributes and configuration requirements of the target task. Furthermore, the service template is associated with the second API interface, and the service template can be used to generate the first visual interface. Furthermore, the service can be published or put on the shelf through the service template. In actual applications, on the management side of the process engine, a corresponding service template can be created for each type of target task.

[0070] It should also be noted that in order to improve the practicality and coverage of service templates, it is very important to build a rich service template library. The embodiment of the present application can provide a service template library, which can cover service templates related to cloud resource operations, such as EC2 instance creation, RDS database configuration, bucket management, etc. Further, the embodiment of the present application can preset API call sequences and parameter configurations for each service template, so that users can quickly generate customized services by simply selecting a service template and binding a specific business interface, thereby reducing repetitive work and improving development efficiency. In addition, the service template library provided by the embodiment of the present application can also support users to customize templates and share them to the community, which can not only promote knowledge sharing, but also allow users to create personalized service templates according to specific business needs. In this way, the service template library not only provides users with a means to quickly generate customized services, but also provides a platform for collaboration and knowledge transfer between community members.

[0071] S402: Add relevant information of the target task to the service template, where the relevant information at least includes application scenario information, instance specifications, and billing information.

[0072] The application scenario information refers to the specific scenario that the target task is applicable to, instance specifications such as the CPU, memory, and storage configuration of the virtual machine, and billing information such as the fee details by hour, volume, or yearly or monthly packages. Clearly listing this information helps users quickly select the appropriate task configuration based on actual needs.

[0073] S403: Associating the service template with the second API interface corresponding to the target task, and adding input parameters of the second API interface to the service template.

[0074] This step can specify which second API interface will be used to perform which target task, and integrate the input parameters of the second API interface into the service template, ensuring that the input parameters of the second API interface are correctly mapped to the corresponding fields of the service template so that the target task can be executed and output as expected.

[0075] S404: Generate a first visualization interface for users based on the service template, where the first visualization interface at least includes application scenario information, instance specifications, billing information, and input parameters.

[0076] In this way, the user experience can be improved. In some implementations, the first visual interface may also include functions such as execution progress display and result feedback, so that the user can understand the target task status at any time and obtain necessary information support.

[0077] In the embodiment of the present application, after step S200, the following step S501 is also included: establishing a mapping relationship table between the second API interface and each corresponding target task; wherein the mapping relationship table at least includes the interface ID of the second API interface and the task ID of the target task. In this way, when calling the second API interface, the corresponding first API interface can be directly called based on the different target cloud platforms.

[0078] Furthermore, the heterogeneous multi-cloud resource pool orchestration method provided in the embodiment of the present application may also include the following steps S600-S700.

[0079] S600: In response to the user's operation on the interactive control, calling the second API interface to execute the target task.

[0080] In this step, the corresponding second API interface can be accurately found and called to execute the target task according to the user's operation intention and in combination with the mapping relationship table. The specific calling steps will be described in detail below and will not be repeated here.

[0081] S700: After the target task is executed, output parameters of the second API interface are obtained, and the output parameters are displayed to the user through a visual interface.

[0082] After the target task is executed, the process engine can obtain the output parameters of the second API interface and display the output parameters to the user through the first visual interface, so that the user can intuitively view the result and status of the target task execution.

[0083] Further, step S600 may specifically include the following steps S601-S604:

[0084] S601: Determine user demand in response to a user operation on an interactive control.

[0085] Among them, user requirements include, for example, applying for a network bandwidth of 10 Gbps, 8 CPU cores, 4 GPU cores, 64 GB memory, 500 GB storage, a cost optimization strategy, and an application usage period of one month.

[0086] The embodiment of the present application determines that the user demand is a cross-platform demand or a single-platform demand. Specifically, the cloud platform can be determined for the user based on the policy requirements given by the user to take advantage of the advantages of different cloud platforms and provide the user with a good user experience. For example, a cloud platform has better network latency in a specific area, and another cloud platform can provide cheaper storage services, etc. At this time, the embodiment of the present application can determine the user demand as a cross-cloud platform demand. In this case, a cloud resource allocation strategy can be formulated based on user needs and combined with the characteristics of each cloud platform. The strategy includes, for example, which cloud platforms to select and how many resources to allocate on each cloud platform.

[0087] S602: When the user demand is a cross-cloud platform demand, determine a first cloud resource allocation strategy based on the user demand; the first cloud resource allocation strategy at least includes multiple target cloud platforms and cloud resource allocation ratios between the target cloud platforms.

[0088] For example, when the target task is to apply for a virtual machine, the target cloud platform and the cloud resource ratio to be applied for each target cloud platform can be determined based on user needs and platform characteristics. When the target task is to destroy cloud resources, the target cloud platform to which the cloud resources to be destroyed belong, as well as the ratio of cloud resources to be destroyed on each platform can be determined based on the current status of these cloud resources (such as whether they are in use, whether there is unfinished data transmission, etc.).

[0089] S603: When the user demand is for a single cloud platform, determine a second cloud resource allocation strategy based on the user demand, where the second cloud resource allocation strategy includes at least one target cloud platform.

[0090] For example, when the cloud resources applied for by the user are relatively small, it can be determined that the user demand is a demand involving a single cloud platform.

[0091] It is understandable that the user can also specify the target cloud platform and cloud resource ratio through the first visualization interface, and the embodiment of the present application does not specifically limit this.

[0092] S604: Calling a target second API interface based on the first cloud resource allocation strategy or the second cloud resource allocation strategy to execute a target task.

[0093] Specifically, step S604 may include the following steps S6041-S6042:

[0094] S6041: In response to the target second API interface being called, query the mapping relationship table based on the interface ID of the target second API interface, the first cloud resource allocation strategy and / or the second cloud resource allocation strategy to determine the task ID of the target task to be executed.

[0095] It is understandable that there may be multiple target tasks to be executed involved in the user needs, and the embodiment of the present application can call multiple target second API interfaces based on the user needs.

[0096] S6042: Call the relevant first API interface based on the task ID to execute the target task.

[0097] In this way, for each type of target task, the first API interface can be accurately called based on different user requirements. For example, when the target task is to apply for a virtual machine and the target cloud platform in the user's requirements is platform A, the second API interface is called, and the task ID of the first API interface used by platform A to apply for a virtual machine can be determined based on the mapping relationship table, thereby realizing the virtual machine application.

[0098] Alternatively, when the target task is to destroy cloud resources and the target cloud platforms are platform B and platform C, in response to the second API interface being called, the task ID of the first API interface used by platform B to destroy cloud resources can be determined based on the mapping relationship table, and the task ID of the first API interface used by platform C to destroy cloud resources can be determined based on the mapping relationship table, thereby realizing cloud resource destruction.

[0099] It can be understood that the relevant first API interface can be one or more, and in the specific calling process, they can be called in sequence based on the arranged calling relationship.

[0100] In an embodiment of the present application, before step S200, the following step S502 may also be included: determining attribute information of the second API interface, the attribute information including at least the name, description information and version information of the second API interface; and, based on the task requirements and parameter information of the target task, determining the input parameters and output parameters of the second API interface according to different target task categories.

[0101] Exemplarily, the input parameter may include an attribute name, such as orderID, an attribute type, such as text type, and an attribute description, such as order ID. The input parameter may also include a default value, which may be specified by the management side of the process engine. The output parameter may include an attribute name, such as data, an attribute type, such as text type, and an attribute description, such as the IP address, user name, and password login information for the enabled node. The output parameter may also include a default value, which may be specified by the management side of the process engine.

[0102] In some implementations, the input parameters and output parameters of the second API interface can be specified by the management side of the process engine, or can be edited and managed by the user side of the process engine. This embodiment of the present application does not specifically limit this.

[0103] In some implementations, step S300 may include the following step S301: based on the attribute information, the call relationship, the input parameters and the output parameters, encapsulate according to the different target task categories to obtain the second API interface corresponding to each type of target task. In this way, the second API interface can be obtained.

[0104] In some implementations, the heterogeneous multi-cloud resource pool orchestration method provided in the embodiments of the present application may also include the following steps S801-S803.

[0105] S801: In response to a target action of a target cloud platform, reacquire parameter information of a target first API interface corresponding to the target action; the target action is to update the target first API interface so that the parameter information of the target first API interface changes.

[0106] In the embodiment of the present application, the target cloud platform may be one of multiple cloud platforms, the target action may be an upgrade action on the target first API interface caused by the upgrade of the target cloud platform, or it may be an upgrade action specifically performed by the target cloud platform on the target first API interface, such as an interface version upgrade. The change in parameter information may be a change in parameter information caused by a change in the calling method of the target first API interface, or the change in parameter information may be an increase, decrease or replacement of parameter information, for example, a change in the IP address. How the parameter information specifically changes is related to the development process of the cloud platform, and the embodiment of the present application does not specifically limit this.

[0107] S802: Based on the target first API interface, determine one or more second API interfaces related thereto as second API interfaces to be updated.

[0108] It is understandable that the update of a target first API interface may involve changes in one or more second API interfaces.

[0109] S803: Re-encapsulate the second API interface to be updated based on the re-acquired parameter information.

[0110] Among them, the step of repackaging the second API interface to be updated at least includes re-determining the attribute information, call relationship, input parameters and / or output parameters, and then performing the packaging action to obtain a new second API interface. In this way, it can be ensured that after the target action of the target cloud platform, the repackaging work of the second API interface related to the target action can be completed in a timely and accurate manner, thereby maintaining the overall stability and availability of the heterogeneous multi-cloud resource pool, and realizing the automatic and rapid update of the second API interface without the need for complex operations such as code modification, reducing the workload, and being convenient and fast.

[0111] In some implementations, when the multi-cloud heterogeneous resource pool provided by the embodiment of the present application needs to be iteratively upgraded, a new API interface can be created, and the old version of the second API interface can be copied using the newly created API interface, and some information can be modified, such as modifying attribute information, call relationships, input parameters and / or output parameters. The specific modification is related to the actual upgrade requirements, and the embodiment of the present application does not specifically limit this, thereby realizing the upgrade of the second API interface. In this way, there is no need for code development, only simple configuration is required to achieve the upgrade, which can improve work efficiency and enhance user experience.

[0112] Figure 6 A flowchart of a cloud resource management method provided in an embodiment of the present application.

[0113] The embodiment of the present application may also provide a cloud resource management method, which may include the following steps S901-S903:

[0114] S901: Determine the processing strategy for cloud resources based on the life cycle of cloud resources; the life cycle is one of the stages in the entire life cycle of cloud resources, and the entire life cycle of cloud resources at least includes application, creation, delivery, operation and maintenance, and / or destruction.

[0115] The processing strategy may include destroying cloud resources, restarting virtual machines, and other strategies.

[0116] S902: Determine the target task to be executed based on the processing strategy.

[0117] S903: Call the target second API interface through the first visualization interface to execute the target task; wherein the target second API interface is one of the second API interfaces in the heterogeneous multi-cloud resource pool orchestration method in the aforementioned embodiment.

[0118] It is worth noting that steps S901-S903 may be functions developed and opened by the process engine, and may be specifically implemented on the user side of the process engine. Based on the cloud resource management method provided in the embodiment of the present application, the user side of the process engine may provide a cloud resource application page based on visual orchestration, cloud resource delivery capabilities opened through orchestration, cloud resource operations opened through orchestration (shutdown, restart, startup, and expansion, etc.), and cloud resource recovery capabilities opened through orchestration. In this way, the full life cycle management of cloud resources can be achieved.

[0119] It should also be noted that the cloud resource management method provided by the embodiment of the present application can simplify the service publishing process, facilitate users to deploy the orchestrated services to the production environment, and allocate a unique API call entry for the service for internal and external system calls. Not only does it improve the efficiency of service publishing, it also ensures the rapid launch and availability of services. At the same time, real-time monitoring of resource status can be achieved, and detailed call logs and performance indicators can be provided, which facilitates troubleshooting and performance optimization, and enhances reliability and stability.

[0120] For the full life cycle management of cloud resources, the embodiments of the present application can support automated workflows, such as automatic resource expansion, health checks, resource audits and compliance checks, etc., to improve operation and maintenance efficiency. These automated workflows ensure the efficient management and optimized use of cloud resources, while also reducing human errors and operation and maintenance costs. In this way, the user side of the process engine can not only achieve full life cycle management of cloud resources, but also improve overall operation and maintenance efficiency and performance, providing users with a more flexible, efficient and reliable cloud resource management solution.

[0121] Figure 7 The figure is a structural diagram of a heterogeneous multi-cloud resource pool orchestration device.

[0122] The embodiment of the present application also provides a heterogeneous multi-cloud resource pool orchestration device, wherein the heterogeneous multi-cloud resource pool is constructed based on multiple different cloud platforms; the device includes:

[0123] The acquisition module 1001 is used to acquire parameter information of the first API interface provided by multiple cloud platforms;

[0124] The orchestration module 1002 is used to orchestrate the calling relationship between multiple related first API interfaces based on parameter information for each target task of each cloud platform, so that the related first API interface can achieve the target task through calling; wherein the target task is a task involved in the full life cycle management of cloud resources, and the full life cycle of cloud resources at least includes application, creation, delivery, operation and maintenance, and / or destruction, and the related first API interface is an interface in the first API interface that is related to the target task;

[0125] The encapsulation module 1003 is used to encapsulate according to different target task categories based on the call relationship and parameter information to obtain a second API interface corresponding to each type of target task;

[0126] Generation module 1004 is used to generate a first visualization interface corresponding to each type of target task and display the first visualization interface to the user; wherein the first visualization interface includes interactive controls, and the interactive controls are associated with the second API interface, so that the user calls the second API interface through the first visualization interface to execute the target task.

[0127] In some implementations, the generation module 1004 is specifically used to: create a service template for each type of target task; add relevant information of the target task to the service template, the relevant information including at least application scenario information, instance specifications and billing information; associate the service template with the second API interface corresponding to the target task, and add the input parameters of the second API interface to the service template; generate a first user-oriented visualization interface based on the service template, the first visualization interface including at least application scenario information, instance specifications, billing information and input parameters.

[0128] In some implementations, it also includes an establishment module for establishing a mapping relationship table between the second API interface and its corresponding target tasks; wherein the mapping relationship table includes at least the interface ID of the second API interface and the task ID of the target task.

[0129] In some implementations, an execution module is also included, which is used to call the second API interface in response to the user's operation on the interactive control to execute the target task; after the target task is executed, the output parameters of the second API interface are obtained, and the output parameters are displayed to the user through a visual interface.

[0130] In some implementations, the execution module is specifically used to determine user needs in response to user operations on interactive controls; when the user needs are cross-cloud platform needs, a first cloud resource allocation strategy is determined based on the user needs; the first cloud resource allocation strategy includes at least multiple target cloud platforms and cloud resource ratios between each target cloud platform; when the user needs are single cloud platform needs, a second cloud resource allocation strategy is determined based on the user needs, and the second cloud resource allocation strategy includes at least one target cloud platform; the target second API interface is called based on the first cloud resource allocation strategy or the second cloud resource allocation strategy to execute the target task.

[0131] In some implementations, the execution module is specifically used to respond to the target second API interface being called, query the mapping relationship table based on the interface ID of the target second API interface, the first cloud resource allocation strategy and / or the second cloud resource allocation strategy, determine the task ID of the target task to be executed; and call the relevant first API interface based on the task ID to execute the target task.

[0132] In some implementations, a parameter determination module is also included, which is used to determine the attribute information of the second API interface, and the attribute information includes at least the name, description information and version information of the second API interface; and based on the task requirements and parameter information of the target task, the input parameters and output parameters of the second API interface are determined according to different target task categories.

[0133] In some implementations, the encapsulation module 1003 is specifically used to encapsulate according to different target task categories based on attribute information, call relationship, input parameters and output parameters, and obtain a second API interface corresponding to each type of target task.

[0134] Figure 8 A schematic diagram of the structure of a cloud resource management device provided in an embodiment of the present application.

[0135] like Figure 8 As shown, the embodiment of the present application also provides a cloud resource management device, including:

[0136] The first determination module 2001 is used to determine a processing strategy for cloud resources based on the life cycle of the cloud resources; the life cycle is one of the stages of the entire life cycle of cloud resources, and the entire life cycle of cloud resources at least includes application, creation, delivery, operation and maintenance, and / or destruction;

[0137] The second determination module 2002 is used to determine the target task to be executed based on the processing strategy;

[0138] The calling module 2003 is used to call the target second API interface through the first visual interface to execute the target task; wherein the target second API interface is one of the second API interfaces in the heterogeneous multi-cloud resource pool orchestration method in the aforementioned embodiment.

[0139] In a specific implementation, the present invention further provides a computer storage medium, wherein the computer storage medium may store a program, and when the program is executed, the program may include some or all of the steps in each embodiment of the heterogeneous multi-cloud resource pool orchestration method and cloud resource management method provided by the present invention. The storage medium may be a disk, an optical disk, a read-only memory (ROM) or a random access memory (RAM).

[0140] It is easy to understand that those skilled in the art can combine, split, reorganize, etc. the embodiments of the present application to obtain other embodiments based on the several embodiments provided in the present application, and these embodiments do not exceed the protection scope of the present application.

[0141] The above specific implementation methods further explain in detail the purpose, technical solutions and beneficial effects of the embodiments of the present application. It should be understood that the above are only specific implementation methods of the embodiments of the present application and are not used to limit the protection scope of the embodiments of the present application. Any modifications, equivalent substitutions, improvements, etc. made on the basis of the technical solutions of the embodiments of the present application should be included in the protection scope of the embodiments of the present application.

Claims

1. A heterogeneous multi-cloud resource pool orchestration method, characterized in that: The heterogeneous multi-cloud resource pool is constructed based on multiple different cloud platforms; the method includes: Obtain parameter information of a first API interface provided by a plurality of the cloud platforms; For each target task of each of the cloud platforms, a calling relationship between a plurality of related first API interfaces is arranged based on the parameter information, so that the related first API interface realizes the target task through calling; wherein the target task is a task involved in the full life cycle management of cloud resources, and the full life cycle of cloud resources at least includes application, creation, delivery, operation and maintenance, and / or destruction, and the related first API interface is an interface in the first API interface that is related to the target task; Based on the calling relationship and the parameter information, encapsulation is performed according to different categories of the target tasks to obtain a second API interface corresponding to each category of the target tasks; Generate a first visualization interface corresponding to each type of the target task, and display the first visualization interface to the user; wherein the first visualization interface includes interactive controls, and the interactive controls are associated with the second API interface, so that the user calls the second API interface through the first visualization interface to execute the target task.

2. The heterogeneous multi-cloud resource pool orchestration method according to claim 1, characterized in that: The step of generating a first visualization interface corresponding to each type of target task includes: For each type of target task, create a service template; Adding relevant information of the target task to the service template, the relevant information including at least application scenario information, instance specifications and billing information; Associating the service template with the second API interface corresponding to the target task, and adding input parameters of the second API interface to the service template; The first visual interface for the user is generated based on the service template, and the first visual interface at least includes the application scenario information, the instance specification, the billing information and the input parameters.

3. The heterogeneous multi-cloud resource pool orchestration method according to claim 1, characterized in that: Based on the calling relationship and the parameter information, encapsulating according to different categories of the target tasks to obtain the second API interface corresponding to each category of the target tasks, the method further includes: A mapping relationship table between the second API interface and each of the corresponding target tasks is established; wherein the mapping relationship table at least includes the interface ID of the second API interface and the task ID of the target task.

4. The heterogeneous multi-cloud resource pool orchestration method according to claim 3, characterized in that: The method further comprises: In response to the user's operation on the interactive control, calling the second API interface to execute the target task; After the target task is executed, output parameters of the second API interface are obtained, and the output parameters are displayed to the user through the visual interface; In response to the user's operation on the interactive control, the step of calling the second API interface to execute the target task includes: In response to the user's operation on the interactive control, determining the user demand; When the user demand is a cross-cloud platform demand, a first cloud resource allocation strategy is determined based on the user demand; the first cloud resource allocation strategy includes at least a plurality of target cloud platforms and a cloud resource allocation ratio between each of the target cloud platforms; When the user demand is a demand for a single cloud platform, determining a second cloud resource allocation strategy based on the user demand, wherein the second cloud resource allocation strategy includes at least one of the target cloud platforms; The target second API interface is called based on the first cloud resource allocation strategy or the second cloud resource allocation strategy to execute the target task.

5. The heterogeneous multi-cloud resource pool orchestration method according to claim 4, characterized in that: The step of calling the target second API interface based on the first cloud resource allocation strategy or the second cloud resource allocation strategy to execute the target task includes: In response to the target second API interface being called, querying the mapping relationship table based on the interface ID of the target second API interface, the first cloud resource allocation strategy and / or the second cloud resource allocation strategy to determine the task ID of the target task to be executed; A related first API interface is called based on the task ID to execute the target task.

6. The heterogeneous multi-cloud resource pool orchestration method according to claim 4, characterized in that: For each target task of each of the cloud platforms, before arranging the calling relationship between a plurality of related first API interfaces based on the parameter information so that the related first API interfaces can realize the target task through calling, the method further includes: Determine attribute information of the second API interface, the attribute information including at least the name, description information and version information of the second API interface; and, based on the task requirements of the target task and the parameter information, determine input parameters and output parameters of the second API interface according to different categories of the target task; Based on the calling relationship and the parameter information, encapsulating according to different categories of the target tasks to obtain the second API interface corresponding to each category of the target tasks includes: Based on the attribute information, the calling relationship, the input parameters and the output parameters, encapsulation is performed according to different categories of the target tasks to obtain the second API interface corresponding to each category of the target tasks.

7. The heterogeneous multi-cloud resource pool orchestration method according to claim 1, characterized in that: The method further comprises: In response to a target action of the target cloud platform, reacquire the parameter information of the target first API interface corresponding to the target action; the target action is to update the target first API interface so that the parameter information of the target first API interface is changed; Based on the target first API interface, determining one or more second API interfaces related thereto as second API interfaces to be updated; Based on the re-acquired parameter information, the second API interface to be updated is re-packaged.

8. A cloud resource management method, characterized in that: include: Determine a processing strategy for the cloud resources based on the life cycle of the cloud resources; the life cycle is one of the stages of the entire life cycle of the cloud resources, and the entire life cycle of the cloud resources at least includes application, creation, delivery, operation and maintenance, and / or destruction; Based on the processing strategy, determining a target task to be performed; The target second API interface is called through the first visual interface to execute the target task; wherein the target second API interface is one of the second API interfaces in the heterogeneous multi-cloud resource pool orchestration method described in any one of claims 1-7.

9. A heterogeneous multi-cloud resource pool orchestration device, characterized in that: The heterogeneous multi-cloud resource pool is constructed based on multiple different cloud platforms; the device includes: An acquisition module, used to acquire parameter information of a first API interface provided by a plurality of cloud platforms; an orchestration module, for arranging, for each target task of each of the cloud platforms, a calling relationship between a plurality of related first API interfaces based on the parameter information, so that the related first API interfaces can realize the target task through calling; wherein the target task is a task involved in the full life cycle management of cloud resources, the full life cycle of cloud resources at least includes application, creation, delivery, operation and maintenance and / or destruction, and the related first API interface is an interface in the first API interfaces that is related to the target task; A packaging module, used for packaging according to different categories of the target tasks based on the calling relationship and the parameter information, to obtain a second API interface corresponding to each category of the target tasks; A generation module is used to generate a first visualization interface corresponding to each type of the target task and display the first visualization interface to the user; wherein the first visualization interface includes interactive controls, and the interactive controls are associated with the second API interface, so that the user calls the second API interface through the first visualization interface to execute the target task.

10. A cloud resource management device, characterized in that: include: A first determination module, configured to determine a processing strategy for the cloud resources based on the life cycle of the cloud resources; The life cycle is one of the stages of the entire life cycle of cloud resources, and the entire life cycle of cloud resources at least includes application, creation, delivery, operation and maintenance, and / or destruction; A second determination module, used to determine a target task to be executed based on the processing strategy; A calling module, used to call the target second API interface through a first visual interface to execute the target task; wherein the target second API interface is one of the second API interfaces in the heterogeneous multi-cloud resource pool orchestration method described in any one of claims 1-7.

Images