Cloud management method and device for multiple cloud resource pools, electronic equipment and storage medium
By adopting a CMP-adapter distributed architecture in a multi-cloud resource pool, separating synchronous request and asynchronous message processing, and utilizing RabbitMQ clusters and load balancers, the problem of high processing pressure on the cloud management platform was solved, improving the stability and availability of the system.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-26
- Publication Date
- 2026-03-27
AI Technical Summary
Existing cloud management platform adapters (CMP-adapters) face enormous processing pressure when handling multi-cloud resource pools, leading to decreased processing speed, increased response latency, and even service crashes, affecting system stability and availability.
The CMP-adapter distributed architecture separates synchronous request processing and asynchronous message processing, which are handled by different service instances. The asynchronous processing and distribution of messages are achieved through RabbitMQ clusters and load balancers, reducing the pressure on a single service.
It improved the stability and availability of the cloud management system, enabled the efficient and reliable operation of the message queue system, and enhanced the overall performance and fault tolerance of the system.
Smart Images

Figure CN121750643A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of cloud platform management, and particularly relates to a cloud management method and device for a multi-cloud resource pool, an electronic device and a storage medium. BACKGROUND
[0002] With the rapid development and popularization of cloud computing technology, more and more enterprises begin to adopt multi-cloud architecture to support their increasingly complex business scenarios. Multi-cloud architecture combines resources and services of multiple cloud service providers to provide enterprises with higher flexibility, scalability and cost-effectiveness. However, the complexity of multi-cloud environment also brings unprecedented management challenges, especially in the adaptation and interaction between the cloud management platform (CMP) and the underlying cloud resource pool. The cloud management platform adapter (CMP-adapter) is a key component in the CMP, which mainly acts as a bridge between the CMP and different cloud service providers. It is responsible for converting the unified management interface and operations of the CMP into specific application programming interface (API) calls and operations required by each cloud service provider, thereby realizing the unified management of different cloud resources in the multi-cloud environment.
[0003] However, the existing CMP-adapter design usually handles all cloud pool synchronization requests and asynchronous messages as a single service. With the increase in the number of cloud pools and the growth of business volume, this single-point design pattern causes the CMP-adapter to face huge processing pressure, resulting in decreased processing speed, increased response delay, and even service crashes, which seriously affects the stability and availability of the cloud management system. SUMMARY
[0004] The present application provides a cloud management method and device for a multi-cloud resource pool, an electronic device and a storage medium to solve the technical problem of large processing pressure of the cloud management platform and poor stability and availability of the management system under the existing multi-cloud resource pool.
[0005] In a first aspect, the present application provides a cloud management method for a multi-cloud resource pool, comprising:
[0006] Deploying a cloud management platform adapter (CMP-adapter) distributed architecture on multiple servers, the CMP-adapter distributed architecture comprising a synchronization request processing service instance and an asynchronous message processing service instance, the synchronization request processing service instance being used for processing synchronization requests, and the asynchronous request processing service instance being used for processing asynchronous messages of each cloud resource pool, and registering the synchronization request processing service instance and the asynchronous message processing service instance in a registration center respectively;
[0007] The asynchronous message processing service instance deployed in the server is integrated with a message broker software RabbitMQ node, and a RabbitMQ cluster is formed based on each RabbitMQ node, and the RabbitMQ cluster implements asynchronous processing and distribution of messages through a message queue mechanism.
[0008] Optionally, the method described above, the CMP-adapter distributed architecture implements load balancing between the synchronous request processing service instance and the asynchronous message processing service instance through a first load balancer.
[0009] Optionally, the method described above, the asynchronous message processing service instance is split into at least two cloud resource pools, and independent asynchronous consumption logic is configured for each cloud resource pool.
[0010] Optionally, the method described above, the integration of the asynchronous message processing service instance deployed in the server with the message broker software RabbitMQ node comprises:
[0011] A second load balancer is deployed in front of the RabbitMQ cluster, and the second load balancer is used to uniformly distribute asynchronous message requests from the asynchronous message processing service instance to each RabbitMQ node in the RabbitMQ cluster.
[0012] The second load balancer distributes asynchronous message requests according to a configured load balancing algorithm.
[0013] Optionally, the method described above, after the second load balancer distributes asynchronous message requests according to a configured load balancing algorithm, further comprises:
[0014] Real-time monitoring of the RabbitMQ cluster is performed to determine whether there is a RabbitMQ node failure;
[0015] If so, the failed node is confirmed, and the load of the failed node is transferred to other RabbitMQ nodes.
[0016] Optionally, the method described above, the registration center is also used to configure a gray release rule for each server, and the method further comprises:
[0017] In response to a new version service instance, traffic is directed to the new version service instance based on the gray release rule until each service is completely switched to the new version.
[0018] Optionally, the method described above, directing traffic to the new version service instance based on the gray release rule comprises:
[0019] Determine a first part of the traffic based on the gray release rule, direct the first part of the traffic to the new version of the service instance, and perform a gray test;
[0020] If the test passes, determine a second part of the traffic, direct the first part of the traffic and the second part of the traffic to the new version of the service instance, and perform a gray test until all the traffic is directed to the new version of the service instance;
[0021] If the test fails, return all the traffic to the previous version of the service instance.
[0022] In a second aspect, the present application provides a cloud management device of a multi-cloud resource pool, comprising:
[0023] A CMP architecture deployment module is configured to deploy a cloud management platform adapter (CMP-adapter) distributed architecture on a plurality of servers, wherein the CMP-adapter distributed architecture comprises a synchronous request processing service instance and an asynchronous message processing service instance, the synchronous request processing service instance is configured to process synchronous requests, the asynchronous request processing service instance is configured to process asynchronous messages of each cloud resource pool, and the synchronous request processing service instance and the asynchronous message processing service instance are registered in a registration center respectively.
[0024] A message processing module is configured to integrate the asynchronous message processing service instance deployed in the server with a message broker software (RabbitMQ) node, form a RabbitMQ cluster based on each RabbitMQ node, and realize asynchronous processing and distribution of messages through a message queue mechanism.
[0025] In a third aspect, the present application provides an electronic device, comprising a memory, a processor, and computer-executed instructions stored in the memory and executable on the processor, wherein the processor executes the computer-executed instructions to implement the cloud management method of the multi-cloud resource pool according to any one of the first aspect.
[0026] In a fourth aspect, the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and the computer program is executed by a processor to implement the cloud management method of the multi-cloud resource pool according to any one of the first aspect.
[0027] In a fifth aspect, the present application provides a computer program product, when the computer program product is executed on a terminal device, the terminal device executes the cloud management method of the multi-cloud resource pool according to any one of the first aspect.
[0028] The cloud management method, device, electronic equipment and storage medium of the multi-cloud resource pool provided by the application, by deploying CMP-adapter distributed architecture on multiple servers, the CMP-adapter distributed architecture includes a synchronous request processing service instance and an asynchronous message processing service instance, the synchronous request processing service instance is used for processing a synchronous request, the asynchronous request processing service instance is used for processing asynchronous messages of each cloud resource pool, and the synchronous request processing service instance and the asynchronous message processing service instance are registered in a registration center respectively; the asynchronous message processing service instance deployed in the server is integrated with a RabbitMQ node, a RabbitMQ cluster is formed based on each RabbitMQ node, the RabbitMQ cluster realizes asynchronous processing and distribution of messages through a message queue mechanism, the functions of the CMP-adapter are split, the synchronous request and the asynchronous message processing are respectively handed over to different service instances for processing, so as to reduce the processing pressure of a single service, the high-performance characteristics and the load balancing function of the RabbitMQ are combined, efficient and reliable operation of the message queue system is realized, and the stability and the availability of the entire cloud management system are improved. BRIEF DESCRIPTION OF DRAWINGS
[0029] The accompanying drawings, which are incorporated into and form part of the specification, illustrate embodiments consistent with the present application and, together with the specification, serve to explain the principles of the application.
[0030] Figure 1 The CMP-adapter architecture schematic diagram of the cloud management method of the multi-cloud resource pool provided by the embodiment of the application;
[0031] Figure 2 The CMP-adapter function schematic diagram of the cloud management method of the multi-cloud resource pool provided by the embodiment of the application;
[0032] Figure 3 The RabbitMQ cluster deployment schematic diagram of the cloud management method of the multi-cloud resource pool provided by the embodiment of the application;
[0033] Figure 4 The flowchart of the cloud management method of the multi-cloud resource pool provided by the embodiment of the application;
[0034] Figure 5 The schematic diagram of the cloud management device of the multi-cloud resource pool provided by the embodiment of the application;
[0035] Figure 6 The structure schematic diagram of the electronic equipment based on the cloud management of the multi-cloud resource pool provided by the embodiment of the application.
[0036] The specific embodiments of the application have been shown and described in the above drawings and the following description. These drawings and description are not meant to limit the scope of the inventive concept in any way but are merely meant to explain the inventive concept to one of ordinary skill in the art by reference to particular embodiments. DETAILED DESCRIPTION
[0037] The exemplary embodiments will be described in detail herein with reference to the attached drawings. The same numbers are used in different drawings to denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all the implementations consistent with the present application. Instead, they only represent examples of apparatuses and methods consistent with some aspects of the present application, as detailed in the appended claims.
[0038] In the related art, the existing CMP-adapter design usually processes all cloud pool synchronization requests and asynchronous messages as a single service. As the number of cloud pools increases and the traffic grows, this single-point design mode causes the CMP-adapter to face huge processing pressure, resulting in decreased processing speed, increased response delay, and even service crashes, which seriously affects the stability and availability of the cloud management system.
[0039] To solve the above technical problems, the embodiments of the present application aim to provide a cloud management method and device for a multi-cloud resource pool, an electronic device, and a storage medium. The core idea of the method is to split the functions of the CMP-adapter, process synchronization requests and asynchronous message processing by different services respectively, realize parallel processing of requests and load balancing, thereby reducing the processing pressure of a single service, improving the stability and availability of the entire cloud management system, and combining the high-performance characteristics of RabbitMQ and the load balancing function of HAProxy to realize efficient and reliable operation of the message queue system.
[0040] In order to better understand the scheme of the embodiments of the present application, the following first introduces an application scenario related to the embodiments of the present application.
[0041] Please refer to Figure 1 , Figure 1 The CMP-adapter architecture schematic diagram of the cloud management method for a multi-cloud resource pool provided by the embodiments of the present application is as follows Figure 1As shown, the CMP-adapter nodes (synchronous request processing service instances and asynchronous message processing service instances) include a plurality of CMP-adapter nodes, different CMP-adapter nodes can be divided into different cloud pools to complete different service contents. It is particularly noteworthy that these CMP-adapter nodes are not isolated, but are ingeniously divided into different cloud pools, each cloud pool carries specific service content and focuses on processing cloud service requests from specific areas or specific needs. In terms of cloud pool distribution, the cloud pool is subdivided according to the geographical region (region) or data center location of the cloud service provider. The CMP-adapter executes the corresponding request according to the region (geographical region or data center location of the cloud service provider) according to the message in the message queue.
[0042] Further, please refer to Figure 2 , Figure 2 The CMP-adapter function diagram of the cloud management method of the multi-cloud resource pool provided for the application embodiment is as shown in Figure 2 After the CMP-adapter starts, the parameters transmitted by the upper module are parsed and parsed into the parameters required by the cloud vendor. The request type is judged. If it is a synchronous request, the parameters transmitted by the cloud vendor are parsed into the parameters required by the upper module. The message is stored. If it is an asynchronous request, the openstack message queue is connected in advance, all instruction messages of the message queue are listened to, the message is stored after the message instruction is parsed and filtered.
[0043] Further, please refer to Figure 3 , Figure 3 The RabbitMQ cluster deployment diagram of the cloud management method of the multi-cloud resource pool provided for the application embodiment is as shown in Figure 3 , which includes a client (Client) and a RabbitMQ cluster (RabbitMQ Cluster). The Client refers to an application program or service that communicates with the RabbitMQ server. It can publish messages to queues, consume messages from queues, create and delete queues, exchange, etc. The RabbitMQ Cluster is a cluster system composed of multiple RabbitMQ nodes (server instances). These nodes work together to provide high availability and scalability. And a load balancer HAProxy is set between the Client and the RabbitMQ Cluster. Further, two HAProxy can be set to avoid single point of failure.
[0044] The technical solutions of the present application and how the technical solutions of the present application solve the above technical problems will be described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of the present application will be described below with reference to the drawings.
[0045] Figure 4 The flow of the cloud management method of the multi-cloud resource pool provided by the embodiments of the present application is shown in FIG. 1. As shown in FIG. 1, the method of the present embodiment comprises the following steps. Figure 4
[0046] S401: Deploy a cloud management platform adapter CMP-adapter distributed architecture on a plurality of servers, the CMP-adapter distributed architecture comprising a synchronous request processing service instance and an asynchronous message processing service instance, the synchronous request processing service instance being used for processing synchronous requests, the asynchronous request processing service instance being used for processing asynchronous messages of each cloud resource pool, and the synchronous request processing service instance and the asynchronous message processing service instance being registered in a registration center respectively.
[0047] The execution subject of the embodiments of the present application can be a server, or a cloud management system of a multi-cloud resource pool in the server, wherein the cloud management system of the multi-cloud resource pool can be implemented by software.
[0048] It can be understood that by separating the synchronous and asynchronous requests for processing, the resource utilization can be optimized, and the response time of the synchronous request can be reduced. The synchronous request processing service instance can be used to process requests that need to be responded immediately, such as user queries and control commands, which usually require fast processing time and low latency. The asynchronous message processing service instance can be used to process requests that do not need to be responded immediately, such as batch data processing and background tasks. Asynchronous processing can improve the throughput and fault tolerance of the system, can relieve stress when the system load is high, and can avoid system crash.
[0049] In the present application, the registration center is usually a service discovery mechanism, Nacos can be integrated as a registration center and a configuration center in a micro-service architecture, and the service instance information is configured. Through the registration center, other services can dynamically discover and call these instances, improve the flexibility and scalability of the system, and the registration center can cooperate with the load balancer to distribute requests to different service instances, further improve the performance and reliability of the system.
[0050] S402: Integrate the asynchronous message processing service instance deployed in the server with a message broker software RabbitMQ node, form a RabbitMQ cluster based on each RabbitMQ node, and realize asynchronous processing and distribution of messages through a message queue mechanism.
[0051] In this step, RabbitMQ is an open source message broker software that supports multiple message passing protocols. Through the message queue mechanism, it can realize the reliable transmission and processing of asynchronous messages, and is suitable for high concurrency and large-scale distributed systems. RabbitMQ cluster can distribute the load, improve the availability and fault tolerance of the system.
[0052] The cloud management method of the multi-cloud resource pool provided in the embodiment is deployed on multiple servers CMP-adapter distributed architecture, which includes a synchronous request processing service instance and an asynchronous message processing service instance, the synchronous request processing service instance is used to process synchronous requests, and the asynchronous request processing service instance is used to process asynchronous messages of each cloud resource pool, and the synchronous request processing service instance and the asynchronous message processing service instance are registered in the registration center; the asynchronous message processing service instance deployed in the server is integrated with the RabbitMQ node, a RabbitMQ cluster is formed based on each RabbitMQ node, the RabbitMQ cluster realizes asynchronous processing and distribution of messages through the message queue mechanism, the functions of the CMP-adapter are split, the synchronous request and the asynchronous message processing are respectively processed by different service instances, thereby reducing the processing pressure of a single service, combining the high performance characteristics and the load balancing function of the RabbitMQ, realizing efficient and reliable operation of the message queue system, and improving the stability and availability of the entire cloud management system.
[0053] The technical scheme of the cloud management method of the multi-cloud resource pool is described in detail below.
[0054] In a possible implementation, in the cloud management method of the multi-cloud resource pool provided in the embodiment, the CMP-adapter distributed architecture realizes load balancing between the synchronous request processing service instance and the asynchronous message processing service instance through a first load balancer.
[0055] In the embodiment, the first load balancer can be Nginx. The default load balancing mechanism of Nginx distributes requests to each backend server in turn. Its least connection mechanism distributes requests to the server with the least number of current connections, which is suitable for long connection scenarios. Further, Nginx can also distribute requests according to the hash value of the client IP address to ensure that requests from the same IP are always distributed to the same server, which is suitable for scenarios that require session maintenance.
[0056] In the embodiment, the first load balancer can uniformly distribute the requests to multiple service instances, avoid single-point overload, improve the overall performance of the system, improve the system performance, and when a service instance fails, the load balancer can automatically distribute the requests to other healthy instances, improve the fault tolerance of the system.
[0057] In a possible implementation, the cloud management method of the multi-cloud resource pool provided in the embodiment includes: splitting the asynchronous message processing service instance into at least two cloud resource pools, and configuring independent asynchronous consumption logic for each cloud resource pool.
[0058] In the embodiment, the asynchronous message processing service instance can be split according to different cloud resource pools, for example, the asynchronous message processing service is split into a south cloud pool (responsible for the south cloud resource pool and upper-layer asynchronous consumption messages), a north cloud pool (responsible for the north cloud resource pool and upper-layer asynchronous consumption messages), and a key cloud pool (responsible for the key cloud resource pool and upper-layer asynchronous consumption messages). Independent asynchronous consumption logic is configured for each cloud resource pool to ensure that the message processing of each cloud resource pool does not interfere with each other.
[0059] It can be understood that by splitting the asynchronous message processing service instance into multiple cloud resource pools, optimized asynchronous consumption logic can be configured for different cloud resource pools to improve the efficiency of message processing, the asynchronous message processing of each cloud resource pool does not interfere with each other, and the isolation and stability of the system are improved. If a cloud resource pool has a problem, it will not affect the normal operation of other cloud resource pools.
[0060] In a possible implementation, the cloud management method of the multi-cloud resource pool provided in the embodiment includes: integrating the asynchronous message processing service instance deployed in the server with a message broker software RabbitMQ node, including: a front end of the RabbitMQ cluster is deployed with a second load balancer, the second load balancer is used to uniformly distribute asynchronous message requests from the asynchronous message processing service instance to each RabbitMQ node in the RabbitMQ cluster; the second load balancer distributes asynchronous message requests according to a configured load balancing algorithm.
[0061] In the embodiment, the second load balancer can be HAProxy, which can be used to distribute network traffic to multiple backend servers. The supported load balancing algorithms include round robin, least connection and source address hashing. Among them, the round robin algorithm makes HAProxy distribute asynchronous message requests to each RabbitMQ node in turn, ensuring uniform load distribution; the least connection mechanism makes HAProxy distribute requests to the RabbitMQ node with the least number of current connections, which is suitable for long connection scenarios. Source address hashing makes HAProxy distribute requests according to the hash value of the client IP address, ensuring that requests from the same IP are always distributed to the same RabbitMQ node, which is suitable for scenarios that require session maintenance.
[0062] Further, after the second load balancer distributes asynchronous message requests according to the configured load balancing algorithm, it further includes: monitoring the RabbitMQ cluster in real time to determine whether there is a RabbitMQ node failure; if so, confirming the failure node and transferring the load of the failure node to other RabbitMQ nodes.
[0063] It can be understood that the second load balancer can be more than two, one of which is the master load balancer, and the others are standby load balancers.
[0064] Through the monitoring tool, the RabbitMQ cluster can be monitored in real time to detect the health status and performance indicators of each node. When the monitoring system detects that a RabbitMQ node fails, it immediately sends an alarm and records the failure information. After confirming the failure node, the load of the node is transferred to other healthy RabbitMQ nodes to ensure uninterrupted message processing.
[0065] In the embodiment, asynchronous message requests are evenly distributed to each node in the RabbitMQ cluster through HAProxy, avoiding single-point overload and improving the overall performance of the system. When a RabbitMQ node fails, HAProxy can automatically distribute requests to other healthy nodes, improving the fault tolerance of the system. Through real-time monitoring and fault detection, the failure of the RabbitMQ node can be discovered and handled in time, ensuring the high availability of the system.
[0066] In a possible implementation, the registration center is also configured to configure a gray release rule for each server, and the method further includes: in response to a new version service instance, directing traffic to the new version service instance based on the gray release rule until each service is completely switched to the new version.
[0067] It can be understood that the gray release is a strategy for gradually releasing a new version, which reduces the release risk by gradually introducing the new version into the production environment. The registry center can be used to configure and manage the gray release rules. Through the gray release, the stability and performance of the new version can be verified in a small range, the release risk is reduced, and through the gradual release of the new version, the impact on the production environment is reduced when problems are found.
[0068] Specifically, the traffic is directed to the new version service instance based on the gray release rules, including: determining a first part of traffic based on the gray release rules, directing the first part of traffic to the new version service instance, and performing gray testing; if the testing is passed, determining a second part of traffic, directing the first part of traffic and the second part of traffic to the new version service instance, and performing gray testing, until all traffic is directed to the new version service instance; if the testing is not passed, returning all traffic to the service instance of the previous version.
[0069] In this embodiment, the request entering the system can be intercepted and routed according to the configuration information in Nacos at the gateway layer. According to a specific identifier (such as the version number in the header) in the request, the gray traffic is directed to the service instance of the specified version. Through the dynamic configuration update function of Nacos, smooth upgrade and version switching of the service instance are realized. During the upgrade process, the traffic can be gradually switched from the old version to the new version, while the stability and performance of the new version service are monitored to ensure the success of the gray release.
[0070] In this embodiment, Nacos is used as a registry center and a configuration center, combined with the microservice architecture of Spring Cloud, to realize a flexible gray release strategy. Through fine traffic control and dynamic routing strategy, the application can ensure that the gray traffic is accurately directed to the service instance of the specified version, while ensuring the data consistency and service continuity between the new and old versions. Moreover, through the dynamic configuration update function of Nacos, smooth upgrade and version switching of the service instance are realized. This technical point ensures that during the system upgrade process, the traffic can be gradually switched from the old version to the new version, while the stability and performance of the new version service are monitored, reducing the risk of system upgrade and change.
[0071] It should be noted that for each of the foregoing method embodiments, in order to simply describe, they are all expressed as a series of action combinations, but those skilled in the art should know that the present application is not limited by the order of the described actions, because according to the present application, certain steps can be performed in other order or simultaneously. Secondly, those skilled in the art should know that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily required by the present application.
[0072] It is further noted that, in the flowcharts, the various steps are presented in sequential order for ease of explanation, but the steps are not necessarily performed in the order shown. Unless otherwise specified, the steps can be performed in different orders or at the same time. Furthermore, at least some of the steps can include multiple sub-steps or stages, which are not necessarily performed in the order shown, but can be performed at different times and / or in different orders.
[0073] Figure 5 A schematic diagram of a cloud management apparatus of a multi-cloud resource pool is provided for embodiments of the present application. As shown in the figure, the cloud management apparatus of the multi-cloud resource pool includes: Figure 5
[0074] A CMP architecture deployment module 501 is configured to deploy a cloud management platform adapter (CMP-adapter) distributed architecture on a plurality of servers, the CMP-adapter distributed architecture including a synchronous request processing service instance and an asynchronous message processing service instance, the synchronous request processing service instance being configured to process synchronous requests, and the asynchronous request processing service instance being configured to process asynchronous messages of each cloud resource pool, the synchronous request processing service instance and the asynchronous message processing service instance being registered in a registration center respectively.
[0075] A message processing module 502 is configured to integrate the asynchronous message processing service instance deployed in the servers with RabbitMQ nodes of message broker software, form a RabbitMQ cluster based on each RabbitMQ node, and implement asynchronous processing and distribution of messages through a message queue mechanism.
[0076] In a possible design, in the CMP architecture deployment module 501, the CMP-adapter distributed architecture implements load balancing between the synchronous request processing service instance and the asynchronous message processing service instance through a first load balancer.
[0077] In a possible design, in the CMP architecture deployment module 501, the asynchronous message processing service instance is split into at least two cloud resource pools, and independent asynchronous consumption logic is configured for each cloud resource pool.
[0078] In a possible design, the message processing module 502 is specifically configured to:
[0079] A front end of the RabbitMQ cluster is deployed with a second load balancer, which is configured to distribute asynchronous message requests from the asynchronous message processing service instance evenly to each RabbitMQ node in the RabbitMQ cluster.
[0080] The second load balancer distributes the asynchronous message requests according to a configured load balancing algorithm.
[0081] In a possible design, the cloud management apparatus of the multi-cloud resource pool further includes a monitoring module 503, which is specifically configured to:
[0082] monitor the RabbitMQ cluster in real time to determine whether there is a RabbitMQ node failure;
[0083] If yes, confirm the failed node and transfer the load of the failed node to other RabbitMQ nodes.
[0084] In a possible design, the cloud management apparatus of the multi-cloud resource pool further includes a gray release module 504, which is specifically configured to:
[0085] In response to a new version service instance, direct traffic to the new version service instance based on the gray release rule until each service is completely switched to the new version.
[0086] In a possible design, the monitoring module 504 is specifically configured to:
[0087] determine a first part of traffic based on the gray release rule, direct the first part of traffic to the new version service instance, and perform a gray test;
[0088] If the test is passed, determine a second part of traffic, direct the first part of traffic and the second part of traffic to the new version service instance, and perform a gray test until all traffic is directed to the new version service instance;
[0089] If the test is not passed, return all traffic to the service instance of the previous version.
[0090] It should be understood that the apparatus embodiments described above are only illustrative, and the apparatus of the present application can also be implemented in other manners. For example, the division of the units / modules in the above-described embodiments is only a logical function division, and actual implementation can have another division manner. For example, a plurality of units / modules or components can be combined, or can be integrated into another system, or some features can be omitted or not executed.
[0091] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.
[0092] Figure 6 This is a schematic diagram of the structure of an electronic device for cloud management based on a multi-cloud resource pool, provided in an embodiment of this application. (See attached diagram.) Figure 6 As shown, the electronic device of this embodiment includes: at least one processor 60 ( Figure 6 (Only one is shown) a processor, a memory 61, and a computer program stored in the memory 61 and executable on at least one processor 60, which, when executing the computer program, implements the steps in any of the above method embodiments.
[0093] The electronic device may include, but is not limited to, a processor 60 and a memory 61. Those skilled in the art will understand that... Figure 6 This is merely an example of an electronic device and does not constitute a limitation on electronic devices. It may include more or fewer components than shown in the illustration, or combinations of certain components, or different components. For example, it may also include input / output devices, network access devices, etc.
[0094] The processor 60 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.
[0095] The specific implementation process of processor 601 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.
[0096] The memory 61 can be an internal storage unit of the electronic device in some embodiments, such as a memory of the electronic device. The memory 61 can also be an external storage device of the electronic device in other embodiments, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, and the like. Further, the memory 61 can include both an internal storage unit and an external storage device of the electronic device. The memory 61 is used to store an operating system, an application program, a boot loader, data, and other programs, such as program codes of computer programs, and the like. The memory 61 can also be used to temporarily store data that has been output or is to be output.
[0097] The computer readable storage medium stores a computer program, and the computer program is executed by a processor to implement the steps in each of the above method embodiments.
[0098] The computer readable storage medium described above can be implemented by any type of volatile or nonvolatile storage devices or a combination thereof, such as a static random access memory (SRAM), an electrically erasable programmable read-only memory (EEPROM), an erasable programmable read-only memory (EPROM), a programmable read-only memory (PROM), a read-only memory (ROM), a magnetic storage, a flash memory, a magnetic disk or an optical disk. The readable storage medium can be any available medium that can be accessed by a general or special purpose computer.
[0099] An exemplary readable storage medium is coupled to the processor, so that the processor can read information from the readable storage medium and write information to the readable storage medium. Of course, the readable storage medium can also be an integral part of the processor. The processor and the readable storage medium can be located in an application specific integrated circuit (ASIC). Of course, the processor and the readable storage medium can also exist as discrete components in the electronic device described above.
[0100] Those of ordinary skill in the art can understand that all or part of the steps of the above method embodiments can be completed by program instruction related hardware. The foregoing program can be stored in a computer readable storage medium. When the program is executed, the steps of the above method embodiments are executed; and the foregoing storage medium includes ROM, RAM, a magnetic disk or an optical disk, and various media that can store program codes.
[0101] In the above embodiments, the description of each of the embodiments focuses on different aspects of the embodiments. The parts not described in detail in a certain embodiment can be seen in the relevant description of the other embodiments. The technical features of the above embodiments can be combined in any manner. In order to make the description simple, not all possible combinations of the technical features in the above embodiments are described, however, as long as the combinations of the technical features do not exist contradictory, they should be considered as falling within the scope of the disclosure.
[0102] Other embodiments of the application will be apparent to those skilled in the art from consideration of the specification and practice of the application disclosed herein. It is intended that the specification and examples be considered as exemplary only, with the true scope and spirit of the application being indicated by the following claims.
[0103] It should be understood that the application is not limited to the precise construction and combinations of the components and steps described above and shown in the accompanying drawings. Various modifications and changes can be made in the arrangement of the parts and steps without departing from the scope of the application. The scope of the application is indicated by the appended claims, rather than by the description and figures.
Claims
1. A cloud management method for a multi-cloud resource pool, characterized in that, Includes the following steps: The distributed architecture of the cloud management platform adapter (CMP-adapter) is deployed on multiple servers. The distributed architecture of the CMP-adapter includes synchronous request processing service instances and asynchronous message processing service instances. The synchronous request processing service instances are used to process synchronous requests, and the asynchronous request processing service instances are used to process asynchronous messages from various cloud resource pools. The synchronous request processing service instances and the asynchronous message processing service instances are registered in the registry center. The asynchronous message processing service instance deployed on the server is integrated with the message broker software RabbitMQ node to form a RabbitMQ cluster based on each RabbitMQ node. The RabbitMQ cluster realizes asynchronous message processing and distribution through a message queue mechanism.
2. The method according to claim 1, characterized in that, The CMP-adapter distributed architecture achieves load balancing between the synchronous request processing service instance and the asynchronous message processing service instance through a first load balancer.
3. The method according to claim 1, characterized in that, The asynchronous message processing service instance is split into at least two cloud resource pools, and independent asynchronous consumption logic is configured for each cloud resource pool.
4. The method according to claim 1, characterized in that, The integration of the asynchronous message processing service instance deployed on the server with the RabbitMQ message broker software node includes: The RabbitMQ cluster has a second load balancer deployed at the front end. The second load balancer is used to evenly distribute asynchronous message requests from the asynchronous message processing service instance to each RabbitMQ node in the RabbitMQ cluster. The second load balancer distributes asynchronous message requests according to the configured load balancing algorithm.
5. The method according to claim 4, characterized in that, After the second load balancer distributes asynchronous message requests according to the configured load balancing algorithm, it also includes: Perform real-time monitoring of the RabbitMQ cluster to determine if there are any RabbitMQ node failures; If so, confirm the faulty node and transfer its load to other RabbitMQ nodes.
6. The method according to any one of claims 1 to 5, characterized in that, The registration center is also used to configure canary release rules for each server, and the method further includes: In response to the new version service instance, traffic is redirected to the new version service instance based on the gray-scale release rules until all services are fully switched to the new version.
7. The method according to claim 6, characterized in that, The process of directing traffic to the new version service instance based on the canary release rules includes: Based on the aforementioned canary release rules, a first portion of traffic is determined, and this first portion of traffic is directed to a new version service instance for canary testing. If the test passes, the second part of the traffic is identified. The first part of the traffic and the second part of the traffic are then directed to the new version of the service instance, and a gray-scale test is conducted until all traffic is directed to the new version of the service instance. If the test fails, all traffic will be redirected to the previous version of the service instance.
8. A cloud management device for a multi-cloud resource pool, characterized in that, include: The CMP architecture deployment module is used to deploy the distributed architecture of the cloud management platform adapter CMP-adapter on multiple servers. The distributed architecture of the CMP-adapter includes synchronous request processing service instances and asynchronous message processing service instances. The synchronous request processing service instances are used to process synchronous requests, and the asynchronous request processing service instances are used to process asynchronous messages from various cloud resource pools. The synchronous request processing service instances and the asynchronous message processing service instances are registered in the registry center respectively. The message processing module is used to integrate the asynchronous message processing service deployed on the server with the RabbitMQ message broker software nodes, forming a RabbitMQ cluster based on each RabbitMQ node. The RabbitMQ cluster realizes asynchronous message processing and distribution through a message queue mechanism.
9. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 7.