Cross-cloud data processing method and device, public cloud device, medium and program product

By using message queues to process data between public and private cloud devices, the problem of high device coupling in cross-cloud services is solved, the reliability and security of data transmission are achieved, and the transmission efficiency is improved.

CN116800736BActive Publication Date: 2026-06-30TENCENT TECHNOLOGY (SHENZHEN) CO LTD

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
TENCENT TECHNOLOGY (SHENZHEN) CO LTD
Filing Date
2022-03-18
Publication Date
2026-06-30

AI Technical Summary

Technical Problem

In cross-cloud services, devices are highly coupled and interfaces are difficult to maintain, resulting in low data transmission security.

Method used

By using message queues (such as CMQ) for data processing between public and private cloud devices, business distribution data is obtained and added to the main data queue, and then added to their respective sub-data queues, achieving unified management and distribution of data.

Benefits of technology

It reduces coupling between devices, improves the reliability and security of data transmission, and increases data transmission efficiency by adding data only once when multiple private cloud devices have the same data.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN116800736B_ABST
    Figure CN116800736B_ABST
Patent Text Reader

Abstract

This application discloses a cross-cloud data processing method, apparatus, public cloud device, medium, and program product, applicable to the field of cloud technology. The method includes: acquiring at least one service distribution data for multiple private cloud devices, adding the at least one service distribution data to a main data queue, extracting service distribution data for each private cloud device from the main data queue, and adding the service distribution data for each private cloud device to a corresponding sub-data queue for each private cloud device. Using this application embodiment can improve the reliability and security of cross-cloud data communication. This application embodiment can be applied to various scenarios such as cloud technology, artificial intelligence, smart transportation, and assisted driving.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of cloud technology, and in particular to a cross-cloud data processing method, apparatus, public cloud equipment, media, and program product. Background Technology

[0002] Cross-cloud services refer to data communication between public and private cloud devices, typically achieved by calling specific interfaces of the other party. For example, a public cloud device calls a data interface on a private cloud device and sends data to achieve data delivery. However, this approach results in high coupling between devices, makes interfaces difficult to maintain, and leads to low data transmission security. Therefore, improving the reliability and security of cross-cloud data communication has become an urgent problem to be solved. Summary of the Invention

[0003] This application provides a cross-cloud data processing method, apparatus, public cloud equipment, medium, and program product that can improve the reliability and security of cross-cloud data communication.

[0004] On one hand, embodiments of this application provide a cross-cloud data processing method, which includes:

[0005] Obtain at least one service distribution data for multiple private cloud devices, and add at least one service distribution data to the master data queue;

[0006] Extract the service distribution data for each private cloud device from the master data queue;

[0007] The service distribution data of each private cloud device is added to the corresponding sub-data queue of each private cloud device; each private cloud device is used to obtain the service distribution data of its own according to the corresponding sub-data queue.

[0008] On one hand, embodiments of this application provide a cross-cloud data processing apparatus, which includes:

[0009] The processing module is used to obtain at least one service distribution data for multiple private cloud devices and add at least one service distribution data to the main data queue;

[0010] The extraction module is used to extract the service distribution data of each private cloud device from the main data queue.

[0011] The processing module is also used to add the service distribution data of each private cloud device to the corresponding sub-data queue of each private cloud device; each private cloud device is used to obtain the service distribution data of its own according to the corresponding sub-data queue.

[0012] On one hand, embodiments of this application provide a public cloud device, which includes a processor and a memory, wherein the memory is used to store a computer program, the computer program including program instructions, and the processor is configured to call the program instructions to execute some or all of the steps in the above method.

[0013] On one hand, embodiments of this application provide a computer-readable storage medium storing a computer program, the computer program including program instructions, which, when executed by a processor, are used to perform some or all of the steps in the above-described method.

[0014] Accordingly, according to one aspect of this application, a computer program product or computer program is provided, comprising program instructions stored in a computer-readable storage medium. A processor of a computer device reads the program instructions from the computer-readable storage medium and executes the program instructions, causing the computer device to perform the cross-cloud data processing method provided above.

[0015] In this embodiment, at least one service distribution data for multiple private cloud devices can be obtained and added to a main data queue. Service distribution data for each private cloud device is then extracted from the main data queue and added to a corresponding sub-data queue for each private cloud device. This method allows for the unified addition of service distribution data to the main data queue and separate addition to the sub-data queues, reducing the coupling between public and private cloud devices during data communication, improving data transmission reliability and security. Furthermore, when multiple private cloud devices have the same service distribution data, this data can be added to the main data queue only once and then to the corresponding sub-data queues, improving data transmission efficiency. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A schematic diagram of an application architecture provided for an embodiment of this application;

[0018] Figure 2 A flowchart illustrating a cross-cloud data processing method provided in an embodiment of this application;

[0019] Figure 3A schematic diagram of a cross-cloud data processing framework provided in an embodiment of this application;

[0020] Figure 4 A flowchart illustrating a cross-cloud data processing method provided in an embodiment of this application;

[0021] Figure 5 A schematic diagram illustrating a cross-cloud data transmission process provided in an embodiment of this application;

[0022] Figure 6 A schematic diagram illustrating a cross-cloud data transmission process based on data delivery, provided for an embodiment of this application;

[0023] Figure 7 This is a schematic diagram of the structure of a cross-cloud data processing device provided in an embodiment of this application;

[0024] Figure 8 This is a schematic diagram of the structure of a public cloud device provided in an embodiment of this application. Detailed Implementation

[0025] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0026] The cross-cloud data processing method proposed in this application is implemented on a public cloud device, which can be a server. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms, but is not limited to these. This application can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, smart transportation, and assisted driving.

[0027] Next, the technical terms involved in the technical field to which the solutions of the embodiments of this application may be applied will be introduced:

[0028] I. Cloud Technology:

[0029] Cloud technology is a collective term for network technologies, information technologies, integration technologies, management platform technologies, and application technologies applied based on the cloud computing business model. It can form resource pools, providing flexible and convenient on-demand access. Cloud computing technology will become a crucial support. Backend services of technical network systems require substantial computing and storage resources, such as video websites, image websites, and many portal websites. With the rapid development and application of the internet industry, every item may have its own identification mark in the future, requiring transmission to backend systems for logical processing. Data at different levels will be processed separately, and various industry data will all require robust system support, which can only be achieved through cloud computing.

[0030] In one possible implementation, the cross-cloud data processing method provided in this application embodiment can be combined with cloud applications in cloud technology. For example, the business data distribution task of the technical solution in this application can be specifically combined with a hybrid cloud to achieve cross-cloud communication. Hybrid cloud, which integrates public cloud and private cloud, is the main model and development direction of cloud computing in recent years. Private cloud is mainly geared towards enterprise users. For security reasons, enterprises prefer to store data in private clouds, but at the same time, they also want to obtain computing resources from public clouds. In this case, hybrid cloud is increasingly being adopted. It mixes and matches public and private clouds to achieve the best results. This personalized solution achieves both cost-effectiveness and security.

[0031] II. Cross-cloud communication:

[0032] Cross-cloud communication, a concept within hybrid cloud environments, refers to data communication between public and private cloud devices in a hybrid cloud model. The technical solution presented in this application enables reliable data transmission between public and private clouds. Cross-cloud communication can be broadly categorized into two types: data delivery and data reporting.

[0033] (1) Data delivery: In the hybrid cloud model, data (such as business data, configuration data, business service operation information, etc.) on public cloud devices are delivered to private cloud devices.

[0034] (2) Data reporting: In the hybrid cloud model, data (such as business data, indicator data, etc.) on private cloud devices are reported to public cloud devices. This application can achieve reliable and stable data transmission in the aforementioned process.

[0035] III. Message Queues:

[0036] Message queues are an important component in distributed systems. They can solve problems such as application coupling, asynchronous messaging, and traffic shaping, and achieve high-performance, high-availability, scalable, and eventually consistent architectures. They are an indispensable middleware in large-scale distributed systems. Common message queues include Kafka (a distributed, high-throughput, and highly scalable message queue system) and RabbitMQ (an open-source message queue system).

[0037] The message queue used in this application's technical solution when performing business data distribution tasks can be CMQ (Cloud Message Queue). CMQ is a distributed message queue service that provides a reliable message-based asynchronous communication mechanism. It can store messages sent and received between distributed applications (or different components of the same application) in a reliable and efficient CMQ queue, preventing message loss. CMQ supports simultaneous read and write operations by multiple processes without interference between sending and receiving, and does not require each application or component to be constantly running.

[0038] In some embodiments, see Figure 1 , Figure 1 This is a schematic diagram of an application architecture provided for an embodiment of this application, through which the cross-cloud data processing method proposed in this application can be executed. Figure 1 As shown, this can include public cloud devices and multiple private cloud devices. The public cloud devices can obtain one or more service distribution data points for multiple private cloud devices, add this data point to a main data queue, and then add it from the main data queue to a corresponding sub-data queue of each private cloud device. When a private cloud device detects the existence of service distribution data in a corresponding sub-data queue, it can retrieve the data locally for processing. For example, the private cloud device can update its local database based on the retrieved service distribution data. Figure 1 The example only shows 3 private cloud devices; there is no limit to the actual number of private cloud devices.

[0039] Understandable Figure 1 This is merely an illustrative representation of a possible application architecture for the technical solution of this application, and does not limit the specific architecture of the technical solution of this application. That is, the technical solution of this application may also provide other forms of application architecture.

[0040] Optionally, in some embodiments, public cloud devices can execute the cross-cloud data processing method according to actual business needs to improve the reliability of cross-cloud data transmission. The technical solution of this application can be applied to any cross-cloud device communication scenario. That is, the public cloud device can obtain the service distribution data to be distributed and add it to the main data queue, determine the private cloud device corresponding to the service distribution data, and add the service distribution data to the sub-data queue of the private cloud device. The private cloud device then obtains the distributed service distribution data from the sub-data queue, which can improve the security of cross-cloud communication and the efficiency of data transmission.

[0041] Optionally, the data involved in this application, such as business distribution data, can be stored in the database of a public cloud device or in a blockchain, such as through a blockchain distributed system. This application does not impose any restrictions on this.

[0042] It is understood that the above scenarios are merely examples and do not constitute a limitation on the application scenarios of the technical solutions provided in the embodiments of this application. The technical solutions of this application can also be applied to other scenarios. For example, as those skilled in the art will know, with the evolution of system 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.

[0043] Based on the above description, this application proposes a cross-cloud data processing method, which can be executed by the aforementioned public cloud devices. Please refer to... Figure 2 , Figure 2 This is a flowchart illustrating a cross-cloud data processing method provided in an embodiment of this application. Figure 2 As shown, the flow of the cross-cloud data processing method in this application embodiment may include the following:

[0044] S201. Obtain at least one service distribution data for multiple private cloud devices and add at least one service distribution data to the master data queue.

[0045] In some embodiments, public cloud devices and private cloud devices can be devices in any cross-cloud scenario. For example, a private cloud device can be a terminal device containing an application, and a public cloud device can be the backend server corresponding to that application. Alternatively, a private cloud device can be an application server containing an application. In this case, the private cloud device can act as the backend server corresponding to the frontend of the application, and the public cloud device can act as the central server corresponding to the private cloud device, used for unified management of application data within the private cloud device. The specific types of public and private cloud devices are not limited here. Business distribution data can be any business data related to the cross-cloud scenario. For example, a private cloud device can be an application server with an application, and a public cloud device can be the corresponding central server. This business distribution data can be application update data, such as version update data of a component in the application, or update data of a business function in the application. The type of business distribution data is not limited here. For ease of explanation, the following will use the example of a private cloud device as the application server and a public cloud device as the corresponding central server for the private cloud device.

[0046] In some embodiments, if multiple private cloud devices each have an application, then the at least one service distribution data obtained by the public cloud device for the multiple private cloud devices may include application update data, and this update data belongs to the service distribution data of each private cloud device. This update data can be configured by the relevant business personnel corresponding to the public cloud device. Optionally, if some of the multiple private cloud devices have an application, then the at least one service distribution data obtained by the public cloud device may include the application update data, and this update data belongs only to the service distribution data of each of the private cloud devices that have the application. A private cloud device may have one or more applications.

[0047] For example, suppose multiple private cloud devices are application servers with application A, and public cloud devices are corresponding central servers. Suppose that an application update operation is performed on application A on the public cloud device to obtain update program data for application A, such as configuration data of a newly added business service in application A. This update program data belongs to the business distribution data of each of the multiple private cloud devices.

[0048] For example, if application A and application B are related, such as application A being a shopping app and application B being a cashback app for application A, let private cloud device 1 and private cloud device 2 be the application servers corresponding to application A, and private cloud device 3 and private cloud device 4 be the application servers corresponding to application B. The public cloud device can be the central server corresponding to private cloud devices 1-4, and uniformly manage some application data (such as product information) in application A and application B; (1) Let the update program data be for changing the price of product A in application A and application B from 10 yuan to 20 yuan. Then multiple private cloud devices have the application (i.e., application A or application B) indicated by the update program data, and the update program data belongs to the business distribution data of each private cloud device; (2) Let the update program data be for changing the price of product A in application A from 10 yuan to 20 yuan. Then only private cloud device 1 and private cloud device 2 among multiple private cloud devices have the application (i.e., application A) indicated by the update program data, and the update program data belongs to the business distribution data of private cloud device 1 and private cloud device 2.

[0049] In one possible implementation, suppose multiple private cloud devices have the same or different applications, and N of these private cloud devices subscribe to a target service within the application. Then, at least one service distribution data can include subscription data indicated by the target service, and at this point, the subscription data belongs only to the private cloud devices that have subscribed to the target service. Therefore, for a public cloud device to obtain at least one service distribution data for multiple private cloud devices, specifically, it can obtain the subscription data indicated by the target service when a service distribution event for the target service is triggered.

[0050] The target business can be any business within the application. For example, if the target business is an update service, the subscription data could be update service data; or if the target business is a check-in service, the subscription data could be check-in notification information. There are no specific limitations on the specific types of target businesses and subscription data. The business distribution event can be any type of event. For example, it could be a scheduled subscription event, where the public cloud detects the arrival of a subscription time point and retrieves and distributes subscription data, such as generating and distributing check-in notification information when a preset time point is detected; or it could be a command instruction event, where the subscription data is retrieved and distributed when a command for distributing subscription data is detected. This command can be generated by relevant business personnel through relevant distribution controls, or it can be automatically generated by the public cloud device when it detects the generation of subscription data, such as generating update service data and a distribution command after detecting an update operation by relevant business personnel on the application.

[0051] In some embodiments, different private cloud devices may have different applications, private cloud devices with the same application may subscribe to different target services, private cloud devices subscribing to the same target service may have different service distribution events, and the service distribution data corresponding to private cloud devices subscribing to the same target service may contain the same subscription data. When a service distribution event for the same target service is triggered at the same time, it indicates that at least two private cloud devices have the same subscription data at the same time. In this case, the subscription data can be merged to obtain one subscription data, and this subscription data can be used as the service distribution data for the at least two private cloud devices.

[0052] In some embodiments, any one of the multiple private cloud devices is designated as the target private cloud device, and at least one service distribution data may further include data requested by the target private cloud device. Therefore, obtaining at least one service distribution data for multiple private cloud devices can specifically involve: upon receiving a data request from the target private cloud device, the data request carrying a data identifier of the requested data; obtaining the requested data associated with the data identifier; and using this requested data as at least one service distribution data. The data identifier can be set by relevant business personnel according to the business scenario to which the requested data belongs. For example, if the requested data is the identity information of user A, then the data identifier can be an identifier representing the user, user A, user information, or identity information, etc. The specific type of data identifier is not limited here.

[0053] Therefore, the aforementioned at least one service distribution data includes service distribution data belonging to only one private cloud device and service distribution data belonging to more than one private cloud device. When a public cloud device obtains at least one service distribution data, it can add that at least one service distribution data to the main data queue. When two or more private cloud devices have the same service distribution data, that service distribution data is added to the main data queue only once. Subsequently, service distribution data in the main data queue can be added to multiple sub-data queues simultaneously.

[0054] S202. Extract the service distribution data of each private cloud device from the master data queue.

[0055] In some embodiments, the public cloud device sequentially determines one or more private cloud devices to which each service distribution data in the master data queue belongs, and extracts the service distribution data and distributes it to the one or more private cloud devices to which it belongs.

[0056] Based on the above description, the public cloud device can sequentially determine one or more private cloud devices to which each service distribution data in the master data queue belongs. If the service distribution data is application update data, then the private cloud device to which the service distribution data belongs is the private cloud device that owns the application; if the service distribution data is subscription data for a target service, then the private cloud device to which the service distribution data belongs is the private cloud device that has subscribed to the target service; if the service distribution data is data requested by a target private cloud device, then the private cloud device to which the service distribution data belongs is the target private cloud device.

[0057] S203. Add the service distribution data of each private cloud device to the corresponding sub-data queue of each private cloud device.

[0058] In one possible implementation, public cloud devices can sequentially add service distribution data from the main data queue to the corresponding sub-data queue of the allocated private cloud device. One private cloud device can correspond to one sub-data queue. Each private cloud device can then retrieve its assigned service distribution data based on its respective sub-data queue.

[0059] In some embodiments, the private cloud device can actively acquire service distribution data from the corresponding sub-data queue, or the public cloud device can forward the data. When the private cloud device actively acquires the data, each private cloud device has access permissions to the corresponding sub-data queue in the public cloud device. Each private cloud device is used to pull the service distribution data from the corresponding sub-data queue according to its access permissions. That is, the private cloud device has a monitoring mechanism for the corresponding sub-data queue. When data is detected in the corresponding sub-data queue, the service distribution data added by the public cloud device can be obtained from it. When the public cloud device forwards the data, the private cloud device can send data query commands to the public cloud device in real time or periodically. When the public cloud device finds that the added service distribution data exists in the indicated sub-data queue according to the data query command, it forwards the service distribution data to the corresponding private cloud device.

[0060] In some embodiments, when a private cloud device obtains its assigned service distribution data, it can perform data processing based on that data. For example, suppose multiple private cloud devices each have an application, and the service distribution data of these devices each includes application update data. Each private cloud device updates its own application based on the retrieved update data. If the update data changes the price of product A to 20 yuan, the private cloud device can update the price of product A in its locally stored application.

[0061] In one possible implementation, the above description only covers the cross-cloud data delivery process from a public cloud device to a private cloud device. The cross-cloud communication process between multiple private cloud devices can also follow the same process. Assume the multiple private cloud devices include a first private cloud device and a second private cloud device. When a public cloud device receives a data forwarding request from the first private cloud device, the data forwarding request carries forwarding service data and the device identifier of the second private cloud device. This forwarding service data can be data belonging to at least one service distribution data set, or it can be other data. The forwarding service data is added to the sub-data queue corresponding to the second private cloud device, so that the second private cloud device can retrieve the forwarding service data from the corresponding sub-data queue. The public cloud device can either directly add the forwarding service data to the sub-data queue corresponding to the second private cloud device, or it can first add it to the main data queue, and then add the forwarding service data from the main data queue to the sub-data queue corresponding to the second private cloud device as the main data queue sequentially adds data. In this case, the forwarding service data located in the main data queue can be understood as the service distribution data of the second private cloud device. There can be one or more second private cloud devices. When there are multiple devices, the data forwarding request carries the device identifiers of the multiple second private cloud devices. The public cloud device will add the forwarded service data to the sub-data queues corresponding to the multiple second private cloud devices respectively.

[0062] In some embodiments, the same process can be followed when a private cloud device reports data to a public cloud device. Taking any one of multiple private cloud devices as the target private cloud device, the target private cloud device sends a data reporting request carrying the reported business data. The public cloud device can receive the reported business data for storage or processing; alternatively, it can add the reported business data to the corresponding sub-data queue of the public cloud device, which then pulls the reported business data from that sub-data queue; or it can first add the reported business data to the main data queue (the main data queue used for data reporting and the main data queue used for data distribution can be the same queue or different queues), and then add the reported business data from the main data queue to the corresponding sub-data queue of the public cloud device. The reported business data in the main data queue can then be understood as business distribution data for the public cloud device. The public cloud device can have one or more sub-data queues, and it can determine which sub-data queue the reported business data belongs to before adding it to that queue. The judgment rule can be arbitrary, such as determining it based on the business type of the reported business data. For example, when the reported business data is user identity data, it belongs to sub-data queue A; when the reported business data is user payment data, it belongs to sub-data queue B, and so on. No limitation is made here. Subsequently, public cloud devices can pull different reported business data according to different sub-data queues and store them in appropriate locations or perform appropriate processing, etc. This can be set by relevant business personnel according to the actual application scenario.

[0063] Optionally, the above process can be implemented through cross-cloud services. Both public cloud devices and private cloud devices can have cross-cloud services, which can be used to perform data reporting and data distribution.

[0064] For example, such as Figure 3 As shown, Figure 3A schematic diagram of a cross-cloud data processing framework provided in this application embodiment; wherein, the cross-cloud service may include a data sending service and a data receiving service, and public cloud devices, private cloud device A (such as a management device providing business services) and private cloud device B (such as a business processing device providing business services) all have the cross-cloud service, and cross-cloud data interaction between public cloud devices and private cloud devices and cross-cloud data interaction between private cloud devices can be realized through the cross-cloud service; (1) When the public cloud device distributes data, it may call the data sending service in the cross-cloud service to add the business distribution data to the main data queue in CMQ, and add the business distribution data in the main data queue to the sub-data queue A corresponding to private cloud device A and the sub-data queue B corresponding to private cloud device B in sequence, and the private cloud device A calls the data receiving service in the cross-cloud service to retrieve the data from the sub-data queue A. (1) Pull business distribution data. Private cloud device B calls the data receiving service in the cross-cloud service to pull business distribution data from sub-data queue B; (2) When private cloud device A reports data, private cloud device A can call the data sending service to send a data reporting request to add the reported business data to the main data queue in CMQ. The public cloud device will add the reported business data in the main data queue to the corresponding sub-data queue of the public cloud device in turn and call the data receiving service to pull it; (3) When private cloud device A communicates with private cloud device B, private cloud device A can call the data sending service to send a data forwarding request to add the forwarded business data to the main data queue in CMQ. The public cloud device will add the forwarded business data in the main data queue to the corresponding sub-data queue of private cloud device B. Private cloud device B will call the data receiving service to pull it.

[0065] In this embodiment, at least one service distribution data for multiple private cloud devices can be obtained and added to a main data queue. Service distribution data for each private cloud device is then extracted from the main data queue and added to a corresponding sub-data queue for each private cloud device. This method reduces the coupling between public and private cloud devices during data communication, improves data transmission reliability and security, and, when multiple private cloud devices have the same service distribution data, allows the data to be added only once to the main data queue and then to the corresponding sub-data queues, reducing data footprint and improving data transmission efficiency.

[0066] Please see Figure 4 , Figure 4 This is a flowchart illustrating a cross-cloud data processing method provided in an embodiment of this application. This method can be executed by the aforementioned public cloud device. Figure 4 As shown, the process of the cross-cloud data processing method in this embodiment may include the following:

[0067] S401. Obtain at least one service distribution data for multiple private cloud devices, and add at least one service distribution data to the main data queue. The specific implementation of step S401 can be found in the relevant descriptions of the above embodiments, and will not be repeated here.

[0068] S402. Extract the service distribution data of each private cloud device from the master data queue.

[0069] In some embodiments, when a public cloud device obtains service distribution data, it adds a data identifier to the service distribution data and adds the identified data distribution data to the main data queue. When retrieving service distribution data from each private cloud device, the service distribution data corresponding to each private cloud device can be determined based on the data identifier. This data identifier can be related to the business scenario of the service distribution data, the private cloud device to which the data is to be distributed, or the type of service distribution data. The specific rules for generating the data identifier can be set by relevant business personnel and are not limited here. Therefore, exemplarily:

[0070] (1) When the business distribution data is data actively distributed by public cloud devices, such as when updating program data, any private cloud device with the application where the updated program data is located can obtain the business distribution data. In this case, the data identifier of the business distribution data can be generated based on the business scenario. For example, if the business distribution data is the update data of a product, the data identifier can be the product information; or if the business distribution data is the identity update data of user A, the data identifier can be the identity information, etc.

[0071] (2) When the service distribution data is the subscription data of the target service, any private cloud device that has subscribed to the target service can obtain the service distribution data. In this case, the data identifier of the service distribution data can be generated based on the target service.

[0072] (3) When the service distribution data is the service data requested by a private cloud device, only the private cloud device that sent the request can obtain the service distribution data. The data identifier of the service distribution data can be generated based on the device identifier of the private cloud device (optionally, it can also be generated based on the service scenario and device identifier of the service distribution data), indicating that the service distribution data belongs to the private cloud device with the device identifier.

[0073] (4) When the service distribution data is forwarded service data requested by a private cloud device to another private cloud device, only the other private cloud device can obtain the service distribution data. The data identifier of the service distribution data can be generated based on the device identifier of the other private cloud device (optionally, it can also be generated based on the service scenario and device identifier of the service distribution data), indicating that the service distribution data belongs to the other private cloud device.

[0074] (5) When the business distribution data is the business data reported by the private cloud device, the business distribution data is obtained by the public cloud device. The data identifier of the business distribution data can be generated based on the device identifier of the public cloud device (optionally, it can also be generated based on the business scenario and device identifier of the business distribution data), indicating that the business distribution data is obtained by the public cloud device.

[0075] Therefore, it can be understood that when a private cloud device has the permission to obtain service distribution data under a certain data identifier, it can extract that service distribution data from the main data queue as the corresponding service distribution data for the aforementioned private cloud device. This data identifier can be understood as the data topic of the service distribution data. Service distribution data can be distributed and added through this data topic. Service distribution data can be processed uniformly in the main data queue, and added to its respective sub-data queues according to the data topic to be obtained set by the private cloud device. This allows the private cloud device to pull only the service distribution data it is interested in without adding the full amount of service distribution data to the corresponding sub-data queue, improving the efficiency and convenience of cross-cloud communication.

[0076] S403. Add the service distribution data of each private cloud device to the corresponding sub-data queue of each private cloud device.

[0077] Each private cloud device can be used to obtain the corresponding business distribution data based on the corresponding sub-data queue.

[0078] In some embodiments, a public cloud device can determine the service distribution data belonging to each private cloud device based on the data identifier of the service distribution data in the main data queue, and add the service distribution data (which may also be service distribution data carrying a data identifier) ​​to the corresponding sub-data queue. Assume that at least one service distribution data includes target service distribution data, such as subscription data indicated by the target service. The target service belongs to a service subscribed to in an application, multiple private cloud devices have the application, and N of the multiple private cloud devices have subscribed to the target service. Therefore, the public cloud device can add the target service distribution data (subscription data) to the sub-data queues corresponding to the N private cloud devices respectively.

[0079] In some embodiments, the private cloud device can poll the corresponding sub-data queue in real time or periodically, and when it detects that there is new service distribution data, it can pull the service distribution data from the corresponding sub-data queue to the private cloud device. Optionally, the private cloud device may have at least one local data queue. When the private cloud device pulls service distribution data, it can add the service distribution data to the local data queue, and then consume the service distribution data from the local data queue.

[0080] S404. After successfully adding the service distribution data to the sub-data queue corresponding to each private cloud device, delete the successfully added service distribution data from the main data queue.

[0081] In some embodiments, at least one service distribution data includes target service distribution data, and the service distribution data of N private cloud devices in a plurality of private cloud devices all include target service distribution data. Therefore, after the public cloud device successfully adds the target service distribution data to the sub-data queues corresponding to the N private cloud devices respectively, it can delete the target service distribution data in the main data queue.

[0082] In some embodiments, after a private cloud device successfully retrieves the service distribution data from the corresponding sub-data queue, a public cloud device can also retrieve and delete the successfully retrieved data from the corresponding sub-data queue. Let any one of the multiple private cloud devices be identified as the target private cloud device. If a successful retrieval notification message for service distribution data is received from the target private cloud device, then the service distribution data indicated by the successful retrieval notification message in the sub-data queue corresponding to the target private cloud device is deleted.

[0083] Therefore, the technical solution of this application can realize cross-cloud communication in a hybrid cloud model. Through multiple data queues, reliable bidirectional data synchronization, secure communication, and stability between public cloud devices and private cloud devices can be achieved. Public cloud devices can establish communication relationships with multiple private cloud devices, suitable for one-to-one or one-to-many communication scenarios between devices. In addition, the data queue CMQ, as an intermediate component for data distribution and storage, also possesses core functions such as data buffering and exception retry. It can perform exception detection and data retention, and resend data in case of distribution failure to ensure no data is missed. It prevents data loss during abnormal data transmission and provides a complete and reliable compensation mechanism for data transmission. The main data queue can provide data delivery capabilities, adding business distribution data to corresponding sub-data queues based on the data topic to ensure data integrity and transmission accuracy. Compared to directly sending data through data transmission interfaces, this reduces coupling between devices and achieves high reusability. Furthermore, when a new private cloud device needs to communicate across clouds with a public cloud device, this method allows for rapid integration and establishment of communication relationships without the need to maintain and configure interactive interface information, improving convenience.

[0084] In some embodiments, the cross-cloud communication of this application can be initiated by calling the RPC (Remote Procedure Call) interface corresponding to the internal cross-cloud service. By calling the cross-cloud service through this interface to report or send data, lightweight data communication and decoupling of communication processes between devices can be achieved. Whether the device is on a public cloud or private cloud side, it only needs to interface with the corresponding cross-cloud service, which will handle the data transmission, allowing it to focus solely on its internal business. The cross-cloud service can include data sending and data receiving services.

[0085] Therefore: (1) When acting as a public cloud device, the RPC interface corresponding to the data sending service in the public cloud device can be called to add business distribution data to the main data queue through the data sending service, and then add the business distribution data from the main data queue to the corresponding sub-data queues in sequence. The private cloud device can also call the RPC interface corresponding to the data receiving service in the private cloud device to pull business distribution data from the corresponding sub-data queues through the data receiving service. The pulled business distribution data can also be forwarded to the local data queue, and different business services on the private cloud device side can obtain their respective business distribution data from the local data queue. (2) When acting as a private cloud device, the RPC interface corresponding to the data sending service in the private cloud device can be called to add the reported business data to the main data queue through the data sending service. The public cloud device can also call the RPC interface corresponding to the data receiving service to add the reported business data from the main data queue to the corresponding sub-data queues of the public cloud device in sequence, and obtain the reported business data from the sub-data queues through the data receiving service.

[0086] Based on the above description, such as Figure 5 As shown, Figure 5 This application provides a schematic diagram of a cross-cloud data transmission process according to an embodiment of the present application; wherein, the Figure 5 The data reporting and distribution process is described: Producers (public or private cloud devices) add business distribution data to the main data queue via cross-cloud services, and then add the business distribution data from the main data queue to the corresponding sub-data queues according to data topics. Consumers (private or public cloud devices) poll the corresponding sub-data queues to consume data, i.e., pull the relevant business distribution data from them. For example... Figure 6 As shown, Figure 6 This application provides a schematic diagram of a cross-cloud data transmission process based on data delivery. A public cloud device acquires service distribution data and makes an RPC call to the data sending service on the public cloud device to add the service distribution data to the main data queue of the CMQ. The data is then added to the corresponding sub-data queue in the CMQ according to the data topic of the service distribution data. A private cloud device makes an RPC call to the data receiving service to pull the added service distribution data from the corresponding sub-data queue to its local data queue. The service on the private cloud device can then pull the required service distribution data from the local data queue.

[0087] In this embodiment, at least one service distribution data for multiple private cloud devices can be acquired and added to a main data queue. Service distribution data for each private cloud device is then extracted from the main data queue and added to a corresponding sub-data queue for each private cloud device. After successfully adding the service distribution data to the corresponding sub-data queue, the successfully added service distribution data is deleted from the main data queue. If a successful acquisition notification message for service distribution data is received from a target private cloud device, the service distribution data indicated by the successful acquisition notification message is deleted from the corresponding sub-data queue of the target private cloud device. This method reduces the coupling between public and private cloud devices during data communication, improves the reliability and security of data transmission, and, when multiple private cloud devices have the same service distribution data, only the service distribution data needs to be added once to the main data queue before being added to the corresponding sub-data queue, reducing data space usage and improving data transmission efficiency.

[0088] Please see Figure 7 , Figure 7 This is a schematic diagram of a cross-cloud data processing device provided in this application. It should be noted that... Figure 7 The cross-cloud data processing apparatus shown is used to execute the present application. Figure 2 and Figure 4 The methods in the illustrated embodiments are shown only in the parts relevant to the embodiments of this application for ease of explanation; specific technical details are not disclosed. Reference to this application is required. Figure 2 and Figure 4 The illustrated embodiment. The cross-cloud data processing device 700 may include: a processing module 701 and an extraction module 702. Wherein:

[0089] Processing module 701 is used to obtain at least one service distribution data for multiple private cloud devices and add at least one service distribution data to the main data queue;

[0090] Extraction module 702 is used to extract the service distribution data of each private cloud device from the main data queue;

[0091] The processing module 701 is also used to add the service distribution data of each private cloud device to the sub-data queue corresponding to each private cloud device; each private cloud device is used to obtain the service distribution data of its own according to the corresponding sub-data queue.

[0092] In one possible implementation, all of the aforementioned private cloud devices have applications, and the at least one service distribution data includes application updater data;

[0093] When processing module 702 adds the service distribution data of each private cloud device to the corresponding sub-data queue of each private cloud device, it specifically performs the following functions:

[0094] The update program data is added to the corresponding sub-data queue for each private cloud device.

[0095] In one possible implementation, all of the aforementioned private cloud devices have an application, and N of the private cloud devices subscribe to a target service in the application, wherein the at least one service distribution data includes the subscription data indicated by the target service.

[0096] When processing module 701 is used to obtain at least one service distribution data for multiple private cloud devices, it is specifically used for:

[0097] When the business distribution event of the target business is triggered, obtain the subscription data indicated by the target business;

[0098] When processing module 701 adds the service distribution data of each private cloud device to the corresponding sub-data queue of each private cloud device, it specifically performs the following functions:

[0099] Add the subscribed data to the sub-data queues corresponding to each of the N private cloud devices.

[0100] In one possible implementation, the plurality of private cloud devices includes a first private cloud device and a second private cloud device; the processing module 701 is further configured to:

[0101] Obtain the data forwarding request sent by the first private cloud device; the data forwarding request carries forwarding service data;

[0102] The forwarding service data is added to the sub-data queue corresponding to the second private cloud device, so that the second private cloud device can obtain the forwarding service data from the corresponding sub-data queue.

[0103] In one possible implementation, any one of the aforementioned private cloud devices is referred to as the target private cloud device;

[0104] Processing module 701 is also used for:

[0105] If a successful acquisition message for service distribution data is received from the target private cloud device, the service distribution data indicated by the successful acquisition message is deleted from the sub-data queue corresponding to the target private cloud device.

[0106] In one possible implementation, the at least one service distribution data includes target service distribution data, and the service distribution data of N private cloud devices among the plurality of private cloud devices all include target service data; the processing module 701 is further configured to:

[0107] After successfully adding the target service distribution data to the sub-data queues corresponding to the N private cloud devices, delete the target service distribution data from the main data queue.

[0108] In one possible implementation, each of the above private cloud devices has access to the corresponding sub-data queue in the public cloud device, and each private cloud device is used to pull the corresponding business distribution data from the corresponding sub-data queue according to the access to the corresponding sub-data queue.

[0109] The aforementioned private cloud devices all have applications, and the service distribution data of these private cloud devices includes application update data. Each private cloud device is used to update its own applications based on the retrieved update data.

[0110] In this embodiment, the processing module acquires at least one service distribution data for multiple private cloud devices and adds the at least one service distribution data to the main data queue; the extraction module extracts the service distribution data for each private cloud device from the main data queue; and the processing module adds the service distribution data for each private cloud device to the corresponding sub-data queue for each private cloud device. Through this device, service distribution data can be uniformly added to the main data queue and then separately added to the sub-data queues, reducing the coupling between public and private cloud devices during data communication, improving the reliability and security of data transmission, and when multiple private cloud devices have the same service distribution data, the service distribution data can be added to the main data queue only once and then separately added to the corresponding sub-data queues, reducing data space usage and improving data transmission efficiency.

[0111] In the various embodiments of this application, the functional modules can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules, and this application does not impose any limitations on this.

[0112] Please see Figure 8 , Figure 8 This is a schematic diagram of the structure of a public cloud device provided in an embodiment of this application. Figure 8As shown, the public cloud device 800 includes at least one processor 801 and a memory 802. Optionally, the public cloud device may also include a network interface. The processor 801, memory 802, and network interface can exchange data. The network interface, controlled by the processor 801, is used to send and receive messages. The memory 802 stores a computer program, which includes program instructions. The processor 801 executes the program instructions stored in the memory 802. The processor 801 is configured to invoke the program instructions to execute the aforementioned method.

[0113] The memory 802 may include volatile memory, such as random-access memory (RAM); the memory 802 may also include non-volatile memory, such as flash memory, solid-state drive (SSD), etc.; the memory 802 may also include a combination of the above types of memory.

[0114] The processor 801 may be a central processing unit (CPU). In one embodiment, the processor 801 may also be a graphics processing unit (GPU). The processor 801 may also be a combination of a CPU and a GPU.

[0115] In one possible implementation, memory 802 is used to store program instructions, which processor 801 can invoke to perform the following steps:

[0116] Obtain at least one service distribution data for multiple private cloud devices, and add the at least one service distribution data to the main data queue;

[0117] Extract the service distribution data for each private cloud device from the master data queue;

[0118] The service distribution data of each private cloud device is added to the sub-data queue corresponding to each private cloud device; each private cloud device is used to obtain the service distribution data according to the corresponding sub-data queue.

[0119] In one possible implementation, all of the aforementioned private cloud devices have applications, and the at least one service distribution data includes application updater data;

[0120] When processing module 702 adds the service distribution data of each private cloud device to the corresponding sub-data queue of each private cloud device, it specifically performs the following functions:

[0121] The update program data is added to the corresponding sub-data queue for each private cloud device.

[0122] In one possible implementation, all of the aforementioned private cloud devices have an application, and N of the private cloud devices subscribe to a target service in the application, wherein the at least one service distribution data includes the subscription data indicated by the target service.

[0123] When processing module 701 is used to obtain at least one service distribution data for multiple private cloud devices, it is specifically used for:

[0124] When the business distribution event of the target business is triggered, obtain the subscription data indicated by the target business;

[0125] When processing module 701 adds the service distribution data of each private cloud device to the corresponding sub-data queue of each private cloud device, it specifically performs the following functions:

[0126] Add the subscribed data to the sub-data queues corresponding to each of the N private cloud devices.

[0127] In one possible implementation, the plurality of private cloud devices includes a first private cloud device and a second private cloud device; the processing module 701 is further configured to:

[0128] Obtain the data forwarding request sent by the first private cloud device; the data forwarding request carries forwarding service data;

[0129] The forwarding service data is added to the sub-data queue corresponding to the second private cloud device, so that the second private cloud device can obtain the forwarding service data from the corresponding sub-data queue.

[0130] In one possible implementation, any one of the aforementioned private cloud devices is referred to as the target private cloud device;

[0131] Processing module 701 is also used for:

[0132] If a successful acquisition message for service distribution data is received from the target private cloud device, the service distribution data indicated by the successful acquisition message is deleted from the sub-data queue corresponding to the target private cloud device.

[0133] In one possible implementation, the at least one service distribution data includes target service distribution data, and the service distribution data of N private cloud devices among the plurality of private cloud devices all include target service data; the processing module 701 is further configured to:

[0134] After successfully adding the target service distribution data to the sub-data queues corresponding to the N private cloud devices, delete the target service distribution data from the main data queue.

[0135] In one possible implementation, each of the above private cloud devices has access to the corresponding sub-data queue in the public cloud device, and each private cloud device is used to pull the corresponding business distribution data from the corresponding sub-data queue according to the access to the corresponding sub-data queue.

[0136] The aforementioned private cloud devices all have applications, and the service distribution data of these private cloud devices includes application update data. Each private cloud device is used to update its own applications based on the retrieved update data.

[0137] In specific implementations, the cross-cloud data processing device 700, processor 801, memory 802, etc. described above can execute the implementation methods described in the above method embodiments, or they can execute the implementation methods described in the embodiments of this application, which will not be repeated here.

[0138] This application also provides a computer-readable storage medium storing a computer program. The computer program includes program instructions, which, when executed by a processor, enable the processor to perform some or all of the steps described in the above method embodiments. Optionally, the computer storage medium can be volatile or non-volatile. The computer-readable storage medium may primarily include a program storage area and a data storage area. The program storage area may store an operating system, at least one application program required for a given function, etc.; the data storage area may store data created based on the use of blockchain nodes, etc.

[0139] This application also provides a computer program product, which includes computer instructions that, when executed by a processor, can implement some or all of the steps in the above-described method.

[0140] In this article, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0141] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The aforementioned program can be stored in a computer storage medium, which can be a computer-readable storage medium. When executed, the program can include the processes of the embodiments of the above methods. The aforementioned storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0142] The above-disclosed embodiments are merely some of the embodiments of this application, and should not be construed as limiting the scope of this application. Those skilled in the art can understand that all or part of the processes for implementing the above embodiments, and equivalent changes made in accordance with the claims of this application, still fall within the scope of this application.

Claims

1. A cross-cloud data processing method, characterized in that, The method is applied to public cloud devices, and the method includes: Obtain at least one service distribution data for multiple private cloud devices, and call the Remote Procedure Call (RPC) interface corresponding to the data sending service in the public cloud device to add the at least one service distribution data to the main data queue; Extract the service distribution data for each private cloud device from the master data queue; The service distribution data of each private cloud device is added to the corresponding sub-data queue of each private cloud device. Each private cloud device is used to call the RPC interface corresponding to the data receiving service in the private cloud device and obtain the service distribution data according to the corresponding sub-data queue. Among them, one private cloud device corresponds to one sub-data queue, and each private cloud device has access rights to the corresponding sub-data queue in the public cloud device. Each private cloud device is used to pull the service distribution data from the corresponding sub-data queue according to the access rights to the corresponding sub-data queue. The main data queue and the sub-data queue are cloud message queues (CMQ).

2. The method according to claim 1, characterized in that, Each of the multiple private cloud devices has an application, and the at least one service distribution data includes update program data for the application; The step of adding the service distribution data of each private cloud device to the sub-data queue corresponding to each private cloud device includes: The update program data is added to the sub-data queue corresponding to each private cloud device.

3. The method according to claim 1, characterized in that, The plurality of private cloud devices each have an application, and N of the plurality of private cloud devices subscribe to a target service in the application. The at least one service distribution data includes the subscription data indicated by the target service. Obtain at least one service distribution data for multiple private cloud devices, including: When the service distribution event of the target service is triggered, the subscription data indicated by the target service is obtained; The step of adding the service distribution data of each private cloud device to the sub-data queue corresponding to each private cloud device includes: The subscription data is added to the sub-data queues corresponding to the N private cloud devices respectively.

4. The method according to claim 1, characterized in that, The plurality of private cloud devices includes a first private cloud device and a second private cloud device; the method further includes: Obtain the data forwarding request sent by the first private cloud device; the data forwarding request carries forwarding service data; The forwarding service data is added to the sub-data queue corresponding to the second private cloud device, so that the second private cloud device can obtain the forwarding service data from the corresponding sub-data queue.

5. The method according to claim 1, characterized in that, Any one of the plurality of private cloud devices is referred to as the target private cloud device; The method further includes: If a successful acquisition notification message for service distribution data is received from the target private cloud device, the service distribution data indicated by the successful acquisition notification message is deleted from the sub-data queue corresponding to the target private cloud device.

6. The method according to claim 1, characterized in that, The at least one service distribution data includes target service distribution data, and the service distribution data of N private cloud devices among the plurality of private cloud devices all include target service data; the method further includes: After successfully adding the target service distribution data to the sub-data queues corresponding to the N private cloud devices, the target service distribution data is deleted from the main data queue.

7. The method according to claim 1, characterized in that, Each of the multiple private cloud devices has an application program, and the service distribution data of the multiple private cloud devices includes update program data of the application program. Each private cloud device is used to update its own application program according to the retrieved update program data.

8. A cross-cloud data processing device, characterized in that, The device includes: The processing module is used to obtain at least one service distribution data for multiple private cloud devices, and call the remote procedure call (RPC) interface corresponding to the data sending service in the public cloud device to add the at least one service distribution data to the main data queue. The extraction module is used to extract the service distribution data of each private cloud device from the master data queue. The processing module is further configured to add the service distribution data of each private cloud device to the corresponding sub-data queue of each private cloud device; each private cloud device is configured to call the RPC interface corresponding to the data receiving service in the private cloud device and obtain the service distribution data of its own according to the corresponding sub-data queue; wherein, one private cloud device corresponds to one sub-data queue, each private cloud device has access permissions to the corresponding sub-data queue in the public cloud device, and each private cloud device is configured to pull the service distribution data of its own according to the access permissions to the corresponding sub-data queue; the main data queue and the sub-data queue are cloud message queues (CMQ).

9. A public cloud device, characterized in that, The system includes a processor and a memory, wherein the memory is used to store a computer program, the computer program including program instructions, and the processor is configured to invoke the program instructions to perform the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program including program instructions that, when executed by a processor, cause the processor to perform the method as described in any one of claims 1-7.

11. A computer program product, characterized in that, The computer program product includes computer instructions that, when executed by a processor, implement the method as described in any one of claims 1-7.