Heterogeneous cloud pool task processing method and device, equipment, medium and program product

Abstract

The embodiment of the invention provides a heterogeneous cloud pool task processing method and device, equipment, a medium and a program product, and the method comprises the steps: obtaining a combined message flow which is a message queue containing a plurality of cloud pool architectures; distributing the message queues of various cloud pool architectures in the combined message flow to corresponding target message queues according to the architecture identifier, and generating a distribution result; loading metadata of each target message queue according to a distribution result, and generating a message task flow; and the message queue is issued to the plurality of cloud pools according to the message task flow, so that the system delay fluctuation is reduced.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of cloud computing, and particularly relates to a heterogeneous cloud pool task processing method and device, equipment, medium and program product. BACKGROUND

[0002] In the unified scheduling architecture of an enterprise-level self-developed cloud platform, the cloud platform needs to be connected to hundreds of underlying heterogeneous cloud pools. Due to differences in construction time, technical route and evolution path, these cloud pools form multi-dimensional heterogeneity. When user instructions are issued to any one or more cloud pools through the cloud platform, the technical characteristics of different cloud pools need to be adapted.

[0003] In the prior art, when processing tasks, a consumer dynamically loads data required by an architecture according to an architecture identifier carried in a message and assembles an adapted request body, and finally calls an interface of a target cloud pool to complete an operation. Tasks of all cloud pools are mixed and delivered to the same message queue, and the consumer randomly consumes tasks.

[0004] However, in the prior art, the consumer cannot reuse the loaded dynamic resources, and frequently triggers database queries, configuration parsing and authentication operations. The mixed delivery of tasks causes the consumer to frequently switch contexts, repeatedly load configurations and authentication information, and thus the system delay fluctuation is increased. SUMMARY

[0005] Embodiments of the present application provide a heterogeneous cloud pool task processing method, device, equipment, medium and program product to solve the problem of increased system delay fluctuation in the prior art.

[0006] In a first aspect, embodiments of the present application provide a cloud computing application delivery method applied to a cloud computing transaction platform, comprising:

[0007] Obtaining a combined message stream, wherein the combined message stream is a message queue containing multiple cloud pool architectures;

[0008] According to the architecture identifier, the message queues of the multiple cloud pool architectures in the combined message stream are distributed to corresponding target message queues to generate a distribution result;

[0009] According to the distribution result, the metadata of each target message queue is loaded to generate a message task stream;

[0010] According to the message task stream, the message queue is issued to multiple cloud pools.

[0011] In one possible implementation, the step of allocating message queues of multiple cloud pool architectures in the combined message stream to corresponding target message queues based on architecture identifiers and generating allocation results includes: calculating the affinity of message queues of multiple cloud pool architectures based on the architecture identifiers; dividing the message queues of multiple cloud pool architectures based on the affinity of the message queues of multiple cloud pool architectures to generate multiple affinity consumer groups; and allocating the multiple affinity consumer groups to corresponding target message queues to generate allocation results.

[0012] In one possible implementation, the step of loading the metadata of each target message queue according to the allocation result and generating a message task flow includes: loading the metadata of each target message queue according to the allocation result and creating an encryption key according to the metadata; establishing a client connection pool according to the encryption key and establishing an authentication session between the client and the cloud pool; creating a runtime context according to the authentication session between the client and the cloud pool and generating a message task flow according to the runtime context.

[0013] In one possible implementation, after the message queue is distributed to multiple cloud pools according to the message task flow, the method further includes: obtaining the load status and queue length of the instance; generating an adjustment strategy for the message queue based on the load status and queue length of the instance using a load optimization algorithm; adjusting the routing weight according to the message queue adjustment strategy; and allocating the message queue according to the adjusted routing weight.

[0014] In one possible implementation, after adjusting the routing weights according to the message queue adjustment strategy, the method further includes: monitoring the processing status of message task flows sent to multiple cloud pools and obtaining performance data; calculating the routing strategy score based on the performance data using a predefined evaluation model; adjusting the message distribution strategy according to the routing strategy score; and allocating computing resources according to the adjusted message distribution strategy.

[0015] In one possible implementation, after obtaining the combined message stream, the method further includes: generating a cache partitioning strategy based on the parameter template call frequency and request body call frequency of historical task data; partitioning the cache into resident memory and persistent memory according to the cache partitioning strategy; and partitioning the multiple message queues in the combined message stream into the resident memory and persistent memory according to the access frequency of the multiple message queues.

[0016] Secondly, embodiments of this application provide a heterogeneous cloud pool task processing device, comprising:

[0017] The first acquisition module is used to acquire a combined message stream, wherein the combined message stream is a message queue containing multiple cloud pool architectures;

[0018] The allocation module is used to allocate message queues of multiple cloud pool architectures in the combined message stream to the corresponding target message queues according to the architecture identifier, and generate allocation results;

[0019] The loading module is used to load the metadata of each target message queue according to the allocation result and generate a message task flow;

[0020] The distribution module is used to distribute the message queue to multiple cloud pools according to the message task flow.

[0021] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0022] The memory stores computer-executed instructions;

[0023] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0024] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0025] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0026] The heterogeneous cloud pool task processing method, apparatus, device, medium, and program product for cloud computing applications provided in this application's embodiments route message queues containing multiple cloud pool architectures to dedicated queues, allocate message queues of multiple cloud pool architectures to corresponding target message queues according to architecture identifiers, ensure that message queue instances process tasks of the same architecture, avoid context switching, load metadata of target message queues according to allocation results, generate message task streams, and distribute message task streams to multiple cloud pools, thereby reducing system latency fluctuations. Attached Figure Description

[0027] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0028] Figure 1 This is a schematic diagram of the system structure of a computer device provided in an embodiment of this application;

[0029] Figure 2 Flowchart of the heterogeneous cloud pool task processing method provided in this application Figure 1 ;

[0030] Figure 3 Flowchart of the heterogeneous cloud pool task processing method provided in this application Figure 2 ;

[0031] Figure 4 Flowchart of the heterogeneous cloud pool task processing method provided in this application Figure 3 ;

[0032] Figure 4 Flowchart of the heterogeneous cloud pool task processing method provided in this application Figure 6 ;

[0033] Figure 7 A schematic diagram of the heterogeneous cloud pool task processing device provided in this application;

[0034] Figure 1 A schematic diagram of the structure of the electronic device provided in this application.

[0035] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0036] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0037] First, let's explain the terms used in this application:

[0038] Heterogeneous cloud pools refer to multiple cloud resource pools that differ in their technical approaches, interface specifications, or data storage structures.

[0039] Combined message flow: refers to a unified message queue input that includes identifiers for multiple cloud pool architectures.

[0040] Architecture Identifier: A key field in the message used to identify the type of the target cloud pool.

[0041] Heterogeneous Affinity Consumer Group: A group of consumer instances deployed as a cluster that subscribes to and processes dedicated queues for a specific architecture.

[0042] Consumer: refers to a continuously running background service or application.

[0043] In the unified scheduling architecture of an enterprise-level self-developed cloud platform, the cloud platform needs to connect to hundreds of underlying heterogeneous cloud pools. These cloud pools exhibit multi-dimensional heterogeneity due to differences in construction time, technical routes, and evolution paths. When user commands are issued to any one or more cloud pools through the cloud platform, they need to be adapted to the technical characteristics of different cloud pools. In existing technologies, when processing tasks, consumers dynamically load the data required by the architecture based on the architecture identifier carried in the message and assemble the adapted request body, ultimately calling the target cloud pool's interface to complete the operation. Tasks from all cloud pools are mixed and delivered to the same message queue, and consumers consume tasks randomly. However, in existing technologies, consumers cannot reuse already loaded dynamic resources, frequently triggering database queries, configuration parsing, and authentication operations. Mixed task delivery causes consumers to frequently switch contexts and repeatedly load configuration and authentication information, leading to increased system latency fluctuations.

[0044] To address the aforementioned technical issues, this application proposes the following technical concept: Based on the pain points of existing technologies, the inventors first analyzed the context switching problem caused by mixed task delivery and proposed an approach to isolate task flows through a pre-sorting mechanism. Subsequently, considering the uniformity requirements of general consumer code, an architecture-friendly consumer group was designed, enabling consumers to proactively preload configuration resources in deterministic task flows and reuse loaded connection pools and caches through a state maintenance mechanism. For example, in the pre-sorting module, after a message is routed to a dedicated queue, the consumer instance proactively loads the target cloud pool's API configuration, authentication information, and template parameters upon startup, avoiding cold start delays. During runtime, consumers continuously process similar tasks, keeping HTTP long connections active, asynchronously refreshing tokens, and keeping template objects resident in memory, significantly reducing the processing overhead of each request. Finally, through the linkage mechanism between sorting and consumption, general consumers achieve efficient adaptation to heterogeneous cloud pools under a unified code deployment, solving core problems such as frequent dynamic resource loading, cache invalidation, and complex operation and maintenance.

[0045] Figure 1 This is a schematic diagram of the system architecture of the computer device provided in an embodiment of this application. Figure 1 As shown, the computer device includes: a receiving device 101, a processing device 102, and a display device 103.

[0046] It is understood that the structure illustrated in the embodiments of this application does not constitute a specific limitation on the heterogeneous cloud pool task processing method. In other feasible embodiments of this application, the above architecture may include more or fewer components than illustrated, or combine some components, or split some components, or arrange different components, which can be determined according to the actual application scenario and is not limited here. Figure 2 The components shown can be implemented in hardware, software, or a combination of both.

[0047] In the specific implementation process, the receiving device 101 can be an input / output interface or a communication interface, and can acquire combined message streams.

[0048] The processing device 102 can generate message task streams.

[0049] The display device 103 can be used to display the aforementioned message task flow, etc.

[0050] The display device can also be a touch screen, used to receive user commands while displaying the above content, so as to realize the operation interaction with the user.

[0051] It should be understood that the above-mentioned processing device can be implemented by a processor reading instructions from memory and executing those instructions, or it can be implemented by a chip circuit.

[0052] Furthermore, the network architecture and business scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0053] Figure 1 Flowchart of the heterogeneous cloud pool task processing method provided in this application Figure 2 ,like Figure 3 As shown, the method includes:

[0054] S201: Obtain the combined message stream, where the combined message stream is a message queue containing multiple cloud pool architectures.

[0055] In this embodiment, the combined message stream is obtained through the message sorting module.

[0056] Specifically, before the message task enters the consumption layer, the message sorting module performs traffic distribution according to the cloud pool architecture.

[0057] In this embodiment, the message sorting module is an independent lightweight proxy service that monitors the unified access queue, parses the architecture identifier in the message, and routes the architecture identifier to the corresponding architecture-specific queue to achieve logical isolation of the task flow.

[0058] In this embodiment, the message sorting module's mechanism includes, but is not limited to: multi-threaded parallel processing, a batch retrieval strategy from the upstream queue, and writing homogeneous task sets into the target queue through a batch push mechanism.

[0059] In this embodiment, the message sorting module supports dynamic configuration of routing rules and has scalability and fault tolerance.

[0060] In this embodiment, the message sorting module is deployed in a cluster, which can receive external messages in batches.

[0061] S202: Based on the architecture identifier, allocate message queues of multiple cloud pool architectures in the combined message stream to the corresponding target message queues and generate allocation results.

[0062] Specifically, the heterogeneous affinity consumer group module calculates the affinity of message queues based on the architecture identifier and generates multiple affinity consumer groups, which are then assigned to the corresponding target message queues.

[0063] In this embodiment, the heterogeneous affinity consumer group module is deployed as a cluster of consumer groups, all subscribing to corresponding architecture-specific queues. Dynamic task distribution is achieved through the load balancing mechanism of the message middleware. The message middleware selects an instance from the message group to process the message based on the consumer group's subscription relationship and current load status.

[0064] In this embodiment, the consumer actively triggers the preloading mechanism during the startup phase: based on the architecture identifier of the subscribed queue, it loads the core metadata such as parameter templates, authentication configurations, and API addresses required by the architecture from the configuration center or database in advance, and initializes the corresponding authentication session (such as obtaining a token), establishes an API client connection pool, and completes preparations such as loading encryption keys.

[0065] In this embodiment, the system maintains established HTTP persistent connections, authentication sessions, and local cached objects for an extended period. The connection pool remains active, and the token is refreshed asynchronously in the background.

[0066] S203: Load the metadata of each target message queue according to the allocation result and generate a message task flow.

[0067] Specifically, the target message queue's metadata is loaded through the heterogeneous affinity consumer group module, an encryption key is created and written into the runtime context, and a message task flow is generated based on the runtime context.

[0068] S204: Distribute message queues to multiple cloud pools according to message task flow.

[0069] In this embodiment, the underlying cloud pool receives the message task stream, executes the instructions in the message task stream, and returns the execution result.

[0070] As can be seen from the above embodiments, by routing message queues containing multiple cloud pool architectures to dedicated queues, and allocating message queues of multiple cloud pool architectures to corresponding target message queues according to architecture identifiers, it is ensured that message queue instances process tasks of the same architecture, avoiding context switching. Based on the allocation results, the metadata of the target message queue is loaded, a message task flow is generated, and the message task flow is distributed to multiple cloud pools, thereby reducing system latency fluctuations.

[0071] In one embodiment of this application, step S202 includes:

[0072] S2021: Calculate the affinity of message queues for various cloud pool architectures based on the architecture identifier.

[0073] In this embodiment, the architecture identifier records information including but not limited to the location of the cloud pool, the network topology of the cloud pool, and the type of the cloud pool.

[0074] Specifically, the affinity of message queues is obtained by calculating the network latency, data dependencies, and resource usage patterns between message queues.

[0075] S2022: Divide message queues of various cloud pool architectures into multiple affinity consumer groups based on the affinity of message queues of various cloud pool architectures.

[0076] Specifically, using the affinity matrix as input, the similarity between message queues is calculated, and the queues are grouped according to the similarity to generate multiple affinity consumer groups.

[0077] S2023: Assign multiple affinity consumer groups to the corresponding target message queues and generate the assignment results.

[0078] Specifically, each affinity consumer group is assigned to one or more target message queues based on the priority of the affinity consumer group and the current state of the target message queue, generating an allocation result.

[0079] As can be seen from the above embodiments, by calculating the affinity of message queues through architectural identifiers, dividing message queues of the same type according to affinity, generating multiple affinity consumer groups, avoiding frequent context switching, and reducing the system's resource consumption.

[0080] In one embodiment of this application, step S203 includes:

[0081] S2031: Load the metadata of each target message queue according to the allocation result, and create an encryption key based on the metadata.

[0082] In this embodiment, the metadata of each target message queue includes, but is not limited to, queue name, access endpoint, security policy, and authentication credentials.

[0083] S2032: Establish a client connection pool based on the encryption key and establish an authentication session between the client and the cloud pool.

[0084] Specifically, the client connection pool is initialized using an encryption key, and the connection pool manages multiple client connection instances. When a connection instance is created, a secure channel is established with the cloud pool through a security protocol, the integrity of the message is verified using an encryption key, and the digital certificate is encrypted using the encryption key.

[0085] S2033: Create a runtime context based on the authentication session between the client and the cloud pool, and generate a message task flow based on the runtime context.

[0086] In this embodiment, the content recorded in the runtime context includes, but is not limited to, task execution environment parameters, access control lists, and session timeout settings.

[0087] As can be seen from the above embodiments, by obtaining the metadata of each target message queue, creating an encryption key, using the encryption key to establish a client connection pool and authentication session, writing the authentication session into the runtime context, and generating a message task flow, the repeated creation of the context is avoided, thus improving the system's operating efficiency.

[0088] Figure 2 Flowchart of the heterogeneous cloud pool task processing method provided in this application Figure 3 ,like Figure 4 As shown, after step S204, the following steps are also included:

[0089] S301: Get the instance's load status and queue length.

[0090] In this embodiment, the load status includes, but is not limited to, CPU utilization, memory utilization, and disk occupancy.

[0091] In this embodiment, the queue length is the number of messages to be processed in the message queue.

[0092] S302: Generate message queue adjustment strategies based on instance load status and queue length using a load optimization algorithm.

[0093] Specifically, based on the input strength indicators and historical trends, an adjustment strategy is output.

[0094] In this embodiment, the adjustment strategy includes, but is not limited to, reallocating message queues, adjusting the number of instances, and modifying processing priorities.

[0095] S303: Adjust the routing weights according to the message queue adjustment policy, and allocate message queues according to the adjusted routing weights.

[0096] Specifically, for traffic from high-load instances, the routing weight is reduced, while the weight of low-load instances is increased simultaneously.

[0097] As can be seen from the above embodiments, by obtaining the load status and queue length in real time, generating the message queue adjustment strategy through the load optimization algorithm, and adjusting the routing weight according to the adjustment strategy, the data throughput of the system can be improved.

[0098] In one embodiment of this application, after step S303, the method further includes:

[0099] S304: Monitor the processing status of message task flows sent to multiple cloud pools and obtain performance data.

[0100] In this embodiment, the monitored processing status includes, but is not limited to, task start time, end time, and resource consumption.

[0101] In this embodiment, performance data includes, but is not limited to, throughput, average latency, and error rate.

[0102] S305: Calculates routing policy scores based on performance data using a predefined evaluation model.

[0103] Specifically, the routing policy score is calculated by weighting and summing the performance data using a predefined evaluation model.

[0104] S306: Adjust the message distribution strategy based on the routing strategy score, and allocate computing resources according to the adjusted message distribution strategy.

[0105] Specifically, if the routing strategy score is lower than a preset threshold, the routing algorithm is switched and the message distribution strategy is regenerated.

[0106] As can be seen from the above embodiments, by monitoring the processing status of the message task flow after weight adjustment, obtaining performance data, calculating the routing strategy score based on the performance data, and adjusting the message distribution strategy based on the strategy score, the utilization rate of computing resources is improved.

[0107] Figure 3 Flowchart of the heterogeneous cloud pool task processing method provided in this application Figure 4 ,like Figure 5 As shown, after step S201, the following steps are also included:

[0108] S401: Generate a cache partitioning strategy based on the frequency of parameter template calls and request body calls in historical task data.

[0109] Specifically, based on the set time window and counter, the frequency of calls to the historical task database, statistical parameter templates, and request bodies is counted.

[0110] S402: Divide the cache into resident memory and persistent memory according to the cache partitioning strategy.

[0111] In this embodiment, resident memory is used to store frequently accessed data, while persistent content is used to store infrequently persistent data.

[0112] S403: Based on the access frequency of multiple message queues in the combined message stream, divide multiple message queues into resident memory and persistent memory.

[0113] Specifically, the access frequency is compared with the access frequency threshold. Message queues with access frequency higher than the access frequency threshold are allocated to resident memory, while message queues with access frequency lower than the access frequency threshold are allocated to persistent memory.

[0114] As can be seen from the above embodiments, by using the parameter template call frequency and request body call frequency of historical task data, the cache is divided into resident memory and persistent memory according to the call frequency. The message queue with high access frequency is allocated to resident memory according to the access frequency of the message queue. By dynamically adjusting the caching strategy, memory resource waste is avoided and system processing efficiency is optimized.

[0115] Figure 4 Flowchart of the heterogeneous cloud pool task processing method provided in this application Figure 6 In this embodiment, the heterogeneous affinity consumer group module is deployed in a cluster, comprising multiple containers. Different containers are initialized with different parameters upon startup as affinity consumer groups (multiple consumers within each consumer group). Each container carries its own cache and connection pool components, and a scheduled task updates the internal cache periodically. Each container processes messages for a specific architecture and connects to the cloud pool group corresponding to that architecture. The database stores persistent data, including template parameters for the consumer group and business data generated during message processing. The configuration center stores persistent configuration messages, and the monitoring center monitors the status of each node and performs health checks.

[0116] Figure 6 This is a schematic diagram of the heterogeneous cloud pool task processing device provided in this application, as shown below. Figure 7 As shown, the heterogeneous cloud pool task processing device 60 provided in this embodiment includes: a first acquisition module 601, an allocation module 602, a loading module 603, and a distribution module 604.

[0117] The first acquisition module 601 is used to acquire the combined message stream, wherein the combined message stream is a message queue containing multiple cloud pool architectures.

[0118] The allocation module 602 is used to allocate message queues of multiple cloud pool architectures in the combined message stream to the corresponding target message queues according to the architecture identifier, and generate allocation results.

[0119] Loading module 603 is used to load the metadata of each target message queue according to the allocation result and generate a message task flow.

[0120] The distribution module 604 is used to distribute message queues to multiple cloud pools according to the message task flow.

[0121] In one embodiment of this application, the allocation module 602 includes:

[0122] The computing unit is used to calculate the affinity of message queues for various cloud pool architectures based on the architecture identifier.

[0123] The partitioning unit is used to partition message queues of various cloud pool architectures based on their affinity, and generate multiple affinity consumer groups.

[0124] The allocation unit is used to assign multiple affinity consumer groups to the corresponding target message queues and generate allocation results.

[0125] In one embodiment of this application, the loading module 603 includes:

[0126] The loading unit is used to load the metadata of each target message queue according to the allocation result and create an encryption key based on the metadata.

[0127] The establishment unit is used to establish a client connection pool based on the encryption key and to establish an authentication session between the client and the cloud pool.

[0128] The creation unit is used to create a runtime context based on the authentication session between the client and the cloud pool, and to generate a message task flow based on the runtime context.

[0129] In one embodiment of this application, the heterogeneous cloud pool task processing device 60 further includes:

[0130] The second acquisition module is used to obtain the instance's load status and queue length.

[0131] The first generation module is used to generate message queue adjustment strategies based on the instance's load status and queue length using a load optimization algorithm.

[0132] The first adjustment module is used to adjust the routing weights according to the message queue adjustment strategy and allocate message queues according to the adjusted routing weights.

[0133] In one embodiment of this application, the heterogeneous cloud pool task processing device 60 further includes:

[0134] The monitoring module is used to monitor the processing status of message task flows sent to multiple cloud pools and obtain performance data.

[0135] The calculation module is used to calculate the routing policy score based on performance data using a predefined evaluation model.

[0136] The second adjustment module is used to adjust the message distribution strategy based on the routing strategy score and allocate computing resources according to the adjusted message distribution strategy.

[0137] In one embodiment of this application, the heterogeneous cloud pool task processing device 60 further includes:

[0138] The second generation module is used to generate a cache partitioning strategy based on the frequency of parameter template calls and request body calls in historical task data.

[0139] The first partitioning module is used to divide the cache into resident memory and persistent memory according to the cache partitioning strategy.

[0140] The second partitioning module is used to partition multiple message queues into resident memory and persistent memory based on the access frequency of multiple message queues in the combined message stream.

[0141] The heterogeneous cloud pool task processing device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0142] Figure 7 A schematic diagram of the structure of the electronic device provided in this application. ​ As shown, the electronic device 70 provided in this embodiment includes at least one processor 701 and a memory 702. Optionally, the electronic device 70 further includes a communication component 703. The processor 701, memory 702, and communication component 703 are connected via a bus.

[0143] In the specific implementation process, at least one processor 701 executes computer execution instructions stored in memory 702, causing at least one processor 701 to execute the above-mentioned heterogeneous cloud pool task processing method.

[0144] The specific implementation process of processor 701 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0145] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0146] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0147] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0148] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described heterogeneous cloud pool task processing method.

[0149] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described heterogeneous cloud pool task processing method.

[0150] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0151] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0152] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0153] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0154] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0155] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0156] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0157] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A heterogeneous cloud pool task processing method, characterized in that, include: Obtain a combined message stream, wherein the combined message stream is a message queue containing multiple cloud pool architectures; Based on the architecture identifier, message queues of various cloud pool architectures in the combined message stream are allocated to the corresponding target message queues, and allocation results are generated. Based on the allocation results, the metadata of each target message queue is loaded to generate a message task flow; The message queue is distributed to multiple cloud pools according to the message task flow.

2. The method according to claim 1, characterized in that, The step of allocating message queues of various cloud pool architectures in the combined message stream to corresponding target message queues based on the architecture identifier, and generating allocation results, includes: The affinity of message queues for various cloud pool architectures is calculated based on the architecture identifier. The message queues of the various cloud pool architectures are divided according to their affinity, and multiple affinity consumer groups are generated. The multiple affinity consumer groups are assigned to their corresponding target message queues, generating the assignment results.

3. The method according to claim 1, characterized in that, The step of loading the metadata of each target message queue according to the allocation result and generating a message task flow includes: The metadata of each target message queue is loaded according to the allocation result, and an encryption key is created based on the metadata; A client connection pool is established based on the encryption key, and an authentication session between the client and the cloud pool is established. A runtime context is created based on the authentication session between the client and the cloud pool, and a message task flow is generated based on the runtime context.

4. The method according to claim 1, characterized in that, After the message queue is distributed to multiple cloud pools according to the message task flow, the method further includes: Get the instance's load status and queue length; A message queue adjustment strategy is generated based on the load status and queue length of the instance using a load optimization algorithm; The routing weights are adjusted according to the message queue adjustment strategy, and message queues are allocated according to the adjusted routing weights.

5. The method according to claim 4, characterized in that, After adjusting the routing weights according to the message queue adjustment strategy, the method further includes: Monitor the processing status of message task streams sent to multiple cloud pools and obtain performance data; The routing strategy score is calculated based on the performance data using a predefined evaluation model. The message distribution strategy is adjusted based on the routing strategy score, and computing resources are allocated according to the adjusted message distribution strategy.

6. The method according to any one of claims 1 to 5, characterized in that, After obtaining the combined message stream, the process further includes: A cache partitioning strategy is generated based on the frequency of parameter template calls and request body calls in historical task data; The cache is divided into resident memory and persistent memory according to the cache partitioning strategy. The multiple message queues in the combined message stream are divided into resident memory and persistent memory based on their access frequency.

7. A heterogeneous cloud pool task processing device, characterized in that, include: The first acquisition module is used to acquire a combined message stream, wherein the combined message stream is a message queue containing multiple cloud pool architectures; The allocation module is used to allocate message queues of multiple cloud pool architectures in the combined message stream to the corresponding target message queues according to the architecture identifier, and generate allocation results; The loading module is used to load the metadata of each target message queue according to the allocation result and generate a message task flow; The distribution module is used to distribute the message queue to multiple cloud pools according to the message task flow.

8. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the heterogeneous cloud pool task processing method as described in any one of claims 1 to 6.

9. 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 heterogeneous cloud pool task processing method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the heterogeneous cloud pool task processing method according to any one of claims 1 to 6.

Images