Information pushing method and device based on cloud platform

Abstract

The application provides a cloud platform-based information pushing method and device; the method comprises the following steps: acquiring asset change information of assets included in a cloud platform in real time; classifying the asset change information according to the types of the assets included in the cloud platform, so as to obtain a target asset type of the assets corresponding to the asset change information; determining a to-be-pushed object corresponding to the asset change information of the target asset type; and pushing the asset change information to a terminal corresponding to the to-be-pushed object. Through the application, the asset change information can be collected in time, so that efficient and real-time information pushing can be realized.

Description

Technical Field

[0001] This application relates to Internet technology, and in particular to an information push method and device based on a cloud platform. Background Technology

[0002] The Configuration Management Database (CMDB) stores various asset data, which is aggregated by a timed synchronization module and lacks real-time automatic update push capabilities. To obtain the latest asset data, users (other systems or operations personnel) need to periodically poll the CMDB and determine whether the asset data has been updated based on the change time stored in the CMDB. However, asset users cannot obtain asset change information in real time and need to develop their own asset judgment logic and actively query the CMDB to obtain the latest asset information. Summary of the Invention

[0003] This application provides a cloud platform-based information push method, device, electronic device, computer-readable storage medium, and computer program product, which can collect asset change information in a timely manner for efficient and real-time information push.

[0004] The technical solution of this application embodiment is implemented as follows:

[0005] This application provides an information push method based on a cloud platform, including:

[0006] Real-time acquisition of asset change information for assets included in the cloud platform;

[0007] Based on the types of assets included in the cloud platform, the asset change information is classified to obtain the target asset type of the asset corresponding to the asset change information;

[0008] Identify the target objects to be pushed to corresponding asset change information of the target asset type;

[0009] The asset change information is pushed to the terminal corresponding to the object to be pushed.

[0010] This application provides an information push device based on a cloud platform, including:

[0011] The acquisition module is used to acquire asset change information of the assets included in the cloud platform;

[0012] The classification module is used to classify asset change information according to the types of assets included in the cloud platform, and obtain the target asset type corresponding to the asset change information;

[0013] The determination module is used to determine the target object to be pushed with the asset change information of the target asset type;

[0014] The push module is used to push asset change information to the terminal corresponding to the object to be pushed.

[0015] In the above scheme, the acquisition module is further configured to receive asset change information corresponding to the first hardware device reported by the proxy service when the asset type of the asset is a first hardware device with a proxy service; wherein, the asset change information corresponding to the first hardware device is the information collected and reported by the proxy service when it detects that there is an information change in the first hardware device.

[0016] In the above scheme, the acquisition module is further configured to receive asset change information corresponding to the second hardware device sent by the management terminal corresponding to the cloud platform when the asset type of the asset is a second hardware device without a proxy service; wherein, the asset change information corresponding to the second hardware device is the asset change information indicated by the asset change operation when the management terminal receives the asset change operation for the second hardware device based on the presented asset information update interface.

[0017] In the above scheme, the acquisition module is further configured to establish a long connection with the interface service module in the asset management system corresponding to the cloud-native asset when the asset type of the asset is a cloud-native asset; wherein, the interface service module is configured to provide an entry point for the resource change operation of the cloud-native asset; through the long connection, it listens for the asset change operation corresponding to the cloud-native asset, and when the asset change operation is listened to, it obtains the asset change information corresponding to the cloud-native asset.

[0018] In the above scheme, the classification module is further used to obtain the types of assets included in the cloud platform; wherein, the types of assets included in the cloud platform include hardware assets and cloud-native assets; to parse the asset change information and determine the asset type corresponding to the asset change information; and to classify the asset change information based on the types of assets included in the cloud platform and the asset type corresponding to the asset change information to obtain the target asset type of the asset corresponding to the asset change information.

[0019] In the above scheme, the device further includes a storage module, which is used to generate a first asset change event with a first protocol format through a management thread; store the first asset change event in a task queue for storing asset change events of the cloud platform; the push module is further used to retrieve the first asset change event from the task queue through a distribution thread; and push the asset change information corresponding to the first asset change event to the terminal corresponding to the object to be pushed.

[0020] In the above scheme, the push module is further configured to determine the target push thread corresponding to the object to be pushed from at least two push threads; wherein the push thread and the object to be pushed have a one-to-one correspondence; send the first asset change event to the target push thread, and push the asset change information to the terminal corresponding to the object to be pushed through the target push thread.

[0021] In the above scheme, the push module is further configured to convert the format of the first asset change event through the distribution thread to generate a second asset change event with a second protocol format; store the second asset change event in the event queue corresponding to the target push thread; and retrieve the asset change information from the event queue through the target push thread and push the asset change information to the terminal corresponding to the object to be pushed.

[0022] In the above scheme, the device further includes a second determining module, which is used to determine the target asset change method indicated by the asset change information; the determining module is also used to determine, from multiple asset change information subscription objects of the cloud platform, the subscription object corresponding to the target asset change method and the target asset type as the object to be pushed.

[0023] This application provides an electronic device, including:

[0024] Memory is used to store executable instructions for a computer;

[0025] The processor, when executing computer-executable instructions stored in the memory, implements the information push method for the asset management center provided in this application embodiment.

[0026] This application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the information push method for the asset management center provided in this application.

[0027] This application provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. The processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform the information push method for an asset management center provided in this application.

[0028] The embodiments of this application have the following beneficial effects:

[0029] In the process of pushing information based on the asset management center, the real-time asset change information is classified to determine the target objects to be pushed to, which correspond to the asset types of the real-time asset change information. In this way, by timely collecting asset change information, efficient and real-time information push can be carried out, thereby improving the availability of the overall cloud platform's asset management center based on the pushed information for real-time response or asset management functions. Attached Figure Description

[0030] Figure 1 This is an optional architecture diagram of the information push system based on a cloud platform provided in the embodiments of this application;

[0031] Figure 2 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application;

[0032] Figure 3 This is a flowchart illustrating the information push method based on a cloud platform provided in an embodiment of this application;

[0033] Figure 4 This is a schematic diagram of an optional architecture for information push based on a cloud platform provided in an embodiment of this application;

[0034] Figure 5 This is an optional flowchart illustrating the process of determining the asset type provided in the embodiments of this application;

[0035] Figure 6 This is a flowchart illustrating the information push method based on a cloud platform provided in an embodiment of this application;

[0036] Figure 7A This is an optional schematic diagram of the asset change information processing flow provided in the embodiments of this application;

[0037] Figure 7B This is an optional schematic diagram of the asset change information processing flow provided in the embodiments of this application;

[0038] Figure 8 This is an optional flowchart provided in this application embodiment, illustrating the process of pushing asset change information to the terminal corresponding to the object to be pushed based on a push thread. Detailed Implementation

[0039] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0040] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0041] In the following description, the terms "first," "second," and "third" are used merely to distinguish similar objects and do not represent a specific ordering of the objects. It is understood that "first," "second," and "third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein. In the following description, the term "multiple" means at least two.

[0042] In the implementation of this application, the collection and processing of relevant data should strictly comply with the requirements of relevant laws and regulations, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0043] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0044] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0045] 1) CMDB (Config Manager Database): The asset management center, CMDB is responsible for storing and managing various assets (such as hosts, network devices, containers, middleware, etc.) and their corresponding configuration information in the enterprise IT architecture. Its main functions include integrating, synchronizing, mapping, and visualizing asset data. CMDB is the data source for operations and maintenance systems (monitoring systems, log management systems, business operations and maintenance, etc.).

[0046] 2) Kubernetes: abbreviated as k8s, is a distributed architecture solution based on container technology. It is the foundational system used by many mainstream cloud providers when deploying cloud platforms, on which many cloud-native assets such as pods, services, middleware, and ingress run.

[0047] 3) MySQL: A relational database used to store subscriber information and asset information.

[0048] 4) Redis: A key-value database used to store message queues between modules, serving as a message transmission component, and also providing publish / subscribe functionality.

[0049] 5) Host Cluster: All host assets clusters on the cloud platform.

[0050] 6) Kubernetes cluster: A distributed management cluster for containerized services, containing various cloud-native assets.

[0051] 7) k8s apiserver: A core component in Kubernetes, providing the sole entry point for resource operations and offering mechanisms for authentication, authorization, access control, API registration, and discovery.

[0052] 8) Cloud platform: A service platform that provides cloud-based services for developers to use when creating applications, including cloud computing and cloud storage.

[0053] 9) Cloud computing: A computing model that distributes computing tasks across a resource pool consisting of a large number of computers, enabling various application systems to access computing power, storage space, and information services as needed. The network providing these resources is called the cloud. From the user's perspective, cloud resources appear infinitely scalable, readily available, on-demand, and expandable, with payment based on usage.

[0054] 10) Cloud storage: A new concept that has been extended and developed from the concept of cloud computing. A distributed cloud storage system (hereinafter referred to as storage system) refers to a storage system that uses cluster applications, grid technology and distributed storage file system functions to bring together a large number of storage devices of various types in the network (storage devices are also called storage nodes) to work together through application software or application interfaces to provide data storage and business access functions to the outside world.

[0055] This application provides a cloud platform-based information push method, apparatus, device, computer-readable storage medium, and computer program product. This enables the real-time distribution of cloud platform asset change information from a unified data source to various subscribers (such as other operation and maintenance management systems or personnel), thereby supporting real-time response or asset management functions and improving the overall availability of the cloud platform operation and maintenance system. Furthermore, the distribution process in this application embodiment allows the system to support efficient distribution to large-scale subscriptions and possesses scalability in the push method.

[0056] See Figure 1 , Figure 1This is an optional architecture diagram of the cloud platform-based information push system 100 provided in the embodiments of this application. To realize the application scenario of information push (for example, the application scenario of information push can be that other systems in the same platform, such as monitoring systems or log systems, need some relevant asset change information during operation, so they obtain the required relevant information through the information push system), the terminal (terminal 400 is shown as an example) connects to the server 200 through the network 300. The network 300 can be a wide area network or a local area network, or a combination of the two.

[0057] Terminal 400 is used by users to access client 401 and is displayed on display interface 401-1 (display interface 401-1 is shown as an example). Terminal 400 and server 200 are interconnected via wired or wireless network.

[0058] Server 200 is used to obtain asset change information of assets included in the cloud platform in real time; classify the asset change information according to the type of assets included in the cloud platform to obtain the target asset type of the asset corresponding to the asset change information; determine the object to be pushed to the asset change information of the target asset type; and push the asset change information to the terminal 400 corresponding to the object to be pushed.

[0059] Terminal 400 is also used to display received asset change information on display interface 401-1.

[0060] In some embodiments, server 200 may 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, and big data and artificial intelligence platforms. Terminal 400 may be a smartphone, tablet, laptop, desktop computer, set-top box, or mobile device (e.g., mobile phone, portable music player, personal digital assistant, dedicated messaging device, portable gaming device, smart speaker, and smartwatch), but is not limited thereto. Terminal devices and servers can be directly or indirectly connected via wired or wireless communication, which is not limited in this embodiment.

[0061] See Figure 2 , Figure 2 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. In practical applications, the electronic device can be... Figure 1 The server 200 or terminal 400 shown are described in the following document. Figure 2 , Figure 2The illustrated electronic device includes at least one processor 410, a memory 450, at least one network interface 420, and a user interface 430. The various components in terminal 400 are coupled together via a bus system 440. It is understood that the bus system 440 is used to implement communication between these components. In addition to a data bus, the bus system 440 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in… Figure 2 The general labeled all buses as Bus System 440.

[0062] Processor 410 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among them, the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0063] User interface 430 includes one or more output devices 431 that enable the presentation of media content, including one or more speakers and / or one or more visual displays. User interface 430 also includes one or more input devices 432, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.

[0064] The memory 450 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state storage, hard disk drives, optical disk drives, etc. The memory 450 may optionally include one or more storage devices physically located away from the processor 410.

[0065] The memory 450 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), and the volatile memory may be random access memory (RAM). The memory 450 described in this application embodiment is intended to include any suitable type of memory.

[0066] In some embodiments, memory 450 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.

[0067] Operating system 451 includes system programs for handling various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, driver layer, etc., for implementing various basic business functions and handling hardware-based tasks;

[0068] The network communication module 452 is used to reach other computing devices via one or more (wired or wireless) network interfaces 420, exemplary network interfaces 420 including: Bluetooth, WiFi, and Universal Serial Bus (USB), etc.

[0069] Presentation module 453 is configured to enable the presentation of information (e.g., a user interface for operating peripheral devices and displaying content and information) via one or more output devices 431 associated with user interface 430 (e.g., a display screen, a speaker, etc.).

[0070] The input processing module 454 is used to detect and translate one or more user inputs or interactions from one or more input devices 432.

[0071] In some embodiments, the cloud-based information push device provided in this application can be implemented in software. Figure 2 A cloud-based information push device 455 stored in memory 450 is shown. It can be software in the form of programs and plug-ins, including the following software modules: acquisition module 4551, classification module 4552, determination module 4553 and push module 4554. These modules are logical and can therefore be arbitrarily combined or further split according to the functions implemented.

[0072] In other embodiments, the cloud-based information push device provided in this application can be implemented in hardware. As an example, the cloud-based information push device provided in this application can be a processor in the form of a hardware decoding processor, which is programmed to execute the cloud-based information push method provided in this application. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0073] In some embodiments, the terminal or server can implement the cloud-based information push method provided in this application by running a computer program. For example, the computer program can be a native program or software module in an operating system; it can be a native application (APP), that is, a program that needs to be installed in the operating system to run, such as an instant messaging APP or a web browser APP; it can also be a mini-program, that is, a program that only needs to be downloaded into a browser environment to run; or it can be a mini-program that can be embedded in any APP. In short, the above-mentioned computer program can be any form of application, module, or plugin.

[0074] Based on the above description of the cloud-based information push system and electronic device provided in the embodiments of this application, the cloud-based information push method provided in the embodiments of this application is described below. In actual implementation, the cloud-based information push method provided in the embodiments of this application can be implemented by a terminal alone, or by a terminal and a server working together, so that... Figure 1 The following description uses the example of server 200 executing the cloud platform-based information push method provided in this application embodiment. See also... Figure 3 , Figure 3 This is a flowchart illustrating the information push method based on a cloud platform provided in an embodiment of this application, which will be combined with... Figure 3 The steps shown are explained.

[0075] Step 101: The server obtains asset change information of the assets included in the cloud platform in real time.

[0076] In practice, in response to various asset changes detected on the cloud platform, the server obtains real-time asset change information for all assets included in the cloud platform. Here, "various asset changes" refers to both traditionally managed hardware assets and cloud-native assets within the cloud platform. For example, hardware assets can be physical devices such as hosts, network equipment, data centers, and racks, while cloud-native assets can be various services on the cloud platform, such as pods (the carriers of applications) and services (aggregated resources of pods providing the same service). It should be noted that the process by which the server obtains asset change information for the assets included in the cloud platform differs depending on the asset type.

[0077] In some embodiments, when the asset type is a first hardware device with an agent service, the agent service receives asset change information corresponding to the first hardware device reported by the agent service; wherein, the asset change information corresponding to the first hardware device is reported by the agent service after collecting the corresponding change information when it detects that there is an information change in the first hardware device.

[0078] In actual implementation, the first hardware device here is a hardware asset such as a host that can obtain change information through self-collection mode. When the asset type is the first hardware device with a proxy service, a proxy service will be set up for each hardware asset. When the proxy service detects that there is an information change in the first hardware device, it will collect the corresponding change information and report it to the server so that the server can obtain the asset change information reported by it.

[0079] For example, refer to Figure 4 , Figure 4 This is an optional schematic diagram of information push based on a cloud platform provided in this application embodiment. The Subscription system (push system service) includes four basic functional modules: API (interface module), Handler (management module), Distributor (distribution module), and Subscriber (push module). The API provides an HTTP protocol interface, responsible for receiving user requests to change hardware asset information through the front-end interface, requests to register subscribers, and requests from the host agent (proxy service) to report machine information. The host cluster refers to the cluster of all host assets on the cloud platform, with an agent configured and running by default on each host. The Kubernetes cluster is a distributed management cluster for containerized services, containing various cloud-native assets, based on... Figure 4 By default, each host is equipped with an agent that is responsible for reporting machine information to the subscription system during installation and deployment. When the host is successfully installed or when changes to the host information are detected, such as deleting or adding a host, the agent will collect data on the local machine (including SN, IP, hard disk, network card, memory, etc.) and call the subscription system's HTTP protocol API to report it.

[0080] In some embodiments, when the asset type is a second hardware device without a proxy service, the system receives asset change information corresponding to the second hardware device sent by the management terminal corresponding to the cloud platform; wherein, the asset change information corresponding to the second hardware device is the asset change information indicated by the asset change operation when the management terminal receives the asset change operation for the second hardware device based on the presented asset information update interface.

[0081] In actual implementation, the second hardware device here refers to other hardware assets that cannot obtain change information through the self-collection mode. Therefore, when the asset type is a second hardware device without a proxy service, when the management terminal receives an asset change operation for the second hardware device, the management terminal will present an asset information update interface for the user to enter data. After receiving the user-entered data, i.e. the asset change information, the management terminal will send the received asset change information to the server.

[0082] For example, continue to refer to Figure 4 Since the second hardware device cannot obtain change information through the self-collection mode, the user actively changes the hardware asset information. That is, through the interface update, when the user purchases or removes a new hardware device, the maintenance personnel enter the data by clicking on the interface so that the server can obtain the asset change information.

[0083] In some embodiments, when the asset type is a cloud-native asset, a long connection is established with the interface service module in the asset management system corresponding to the cloud-native asset. The interface service module is used to provide an entry point for resource change operations of the cloud-native asset. Through the long connection, the system listens for asset change operations corresponding to the cloud-native asset and obtains the asset change information corresponding to the cloud-native asset when the asset change operation is detected.

[0084] In practice, the cloud-native assets here run on the corresponding asset management system, which manages them uniformly. For this type of asset information, a long connection can be established with the interface service module in the asset management system that provides an entry point for resource change operations of cloud-native assets. This allows the system to listen for asset change operations corresponding to the cloud-native assets and obtain the corresponding asset change information through the established long connection when the cloud-native assets change.

[0085] For example, continue to refer to Figure 4 The asset management system here is a Kubernetes cluster, and the interface service module is the Kubernetes API server. The cloud-native assets run on the Kubernetes platform. Here, a long-lived HTTP connection is established directly with the Kubernetes API server module for monitoring. When changes occur to the cloud-native assets, the asset change information is retrieved through the long-lived HTTP connection.

[0086] In this way, timely collection of asset change information for different asset types solves the problem that asset users cannot obtain asset change information in real time and need to develop their own asset judgment logic and actively query the CMDB to obtain the latest asset information.

[0087] Step 102: Based on the types of assets included in the cloud platform, classify the asset change information to obtain the target asset type corresponding to the asset change information.

[0088] In practice, after obtaining asset change information, the information is categorized according to the types of assets included in the cloud platform, and then directed to the target asset type corresponding to the asset change information. (See [link to relevant documentation]). Figure 5 , Figure 5This is an optional flowchart illustrating the process of determining the target asset type corresponding to the asset change information provided in this application embodiment, based on... Figure 3 Step 102 can be achieved in the following way:

[0089] Step 1021: Obtain the types of assets included in the cloud platform.

[0090] In actual implementation, the first step is to determine the types of assets included in the cloud platform. These include hardware assets and cloud-native assets. For example, hardware assets can be physical devices such as hosts, network devices, data centers, and racks, while cloud-native assets can be various services on the cloud platform, such as pods and services.

[0091] Step 1022: Analyze the asset change information to determine the asset type corresponding to the asset change information.

[0092] In practice, after obtaining asset change information, the obtained asset change information is parsed to determine the asset type corresponding to the asset change information, such as host, network device, container, etc.

[0093] Step 1023: Based on the types of assets included in the cloud platform and the asset types corresponding to the asset change information, classify the asset change information to obtain the target asset type of the asset corresponding to the asset change information.

[0094] In practice, after determining the asset type corresponding to the asset change information, the asset change information is categorized based on the types of assets included in the cloud platform and the asset type corresponding to the asset change information to obtain the target asset type corresponding to the asset change information. Specifically, after determining that the types of assets included in the cloud platform include hardware assets such as hosts, network devices, data centers, and racks, as well as cloud-native assets such as pods and services, and the asset types corresponding to the asset change information (such as hard drives, network cards, and memory), the asset change information is categorized based on the types of assets included in the cloud platform and the asset type corresponding to the asset change information. That is, the asset change information is divided into asset types such as hosts, network devices, and containers. For example, when the asset type corresponding to the asset change information is hard drive, network card, or memory, the target asset type corresponding to the asset change information can be determined to be a host asset based on the types of assets included in the cloud platform. In this way, the asset change information is categorized to obtain the target asset type corresponding to the asset change information.

[0095] Step 103: Determine the target object to be pushed the asset change information corresponding to the target asset type.

[0096] In practice, after determining the target asset type corresponding to the asset change information, the system retrieves the objects that have subscribed to the asset change information corresponding to that target asset type from the database and uses these objects as the objects to be recommended. It should be noted that the database here is a relational database used to store subscription object information and asset information. Figure 4 The relational database here can be MySQL, used to store subscriber data and asset data.

[0097] In practice, the process of retrieving the objects that have subscribed to the asset change information corresponding to the target asset type from the database can be as follows: read the identifier of the subscribed object that has subscribed to the asset change information of the target asset type from the relational database, and use the object as the object to be recommended based on the identifier of the subscribed object.

[0098] In some embodiments, after obtaining the asset change information of the assets included in the cloud platform in real time, the target asset change method indicated by the asset change information can be determined, and then the subscription object of the asset change information corresponding to the target asset change method and the target asset type can be determined from multiple asset change information subscription objects of the cloud platform as the object to be pushed.

[0099] In practice, the target asset change methods here include deleting assets, adding assets, or updating assets. Determining the target asset change method indicated by the asset change information is done by parsing the asset change information to determine the corresponding change method. After determining the target asset change method and target asset type, the object that has subscribed to the asset change information corresponding to the target asset change based on the target change method is obtained from the database of multiple asset change information subscription objects on the cloud platform, and this object is used as the object to be recommended.

[0100] It should be noted that, in some embodiments, after obtaining asset change information, the asset change information can be directly parsed to determine the asset type and change method corresponding to the asset change information. Based on the asset type and change method corresponding to the asset change information, the object that has subscribed to the asset change information corresponding to the asset type changed based on the change method can be obtained from the multiple asset change information subscription objects, i.e., the database, of the cloud platform, and the object is used as the object to be recommended.

[0101] Step 104: Push the asset change information to the terminal corresponding to the object to be pushed.

[0102] In practice, after identifying the target recipient, asset change information is pushed to the terminal corresponding to the target recipient based on the target push method, target address, and target push template. Specifically, after identifying the target recipient, the system retrieves the pre-set push method, target address, and push template based on information stored in the database. Push methods include SMS and HTTP, target addresses correspond to mobile phone numbers and URLs, and push templates correspond to SMS templates, telephone templates, or HTTP request message templates. In other words, after identifying the target recipient, the system reads the push method, target address, and push template stored in the database, uses these as the target push method, target address, and target push template, and pushes the asset change information to the terminal corresponding to the target recipient based on these target push method, target address, and target push template.

[0103] For example, when the push method for the target object is SMS, the target address is a mobile phone number, and the push template is an SMS template, the asset change information is edited according to the SMS template and pushed to the corresponding target object in text form based on the obtained mobile phone number.

[0104] In some embodiments, the push method, target address, push template, and information about the objects subscribing to the asset change information corresponding to the target asset type stored in the relational database are all entered by each subscribing object (i.e., the object to be pushed) before the asset change information of the assets included in the cloud platform is obtained in real time.

[0105] In practice, when each subscriber needs to push asset change information, they register the relevant information for the push process based on the push information registration interface provided by the asset management center. Specifically, the asset management center provides a push information registration interface on the terminal for each subscriber to register. Each subscriber enters information including the push method, target address, push template, and subscribed asset operation type (i.e., operation type plus asset type) on the push information registration interface, and stores the information in a relational database. Here, while storing the information in the relational database, the subscriber's identification information is also saved along with the information entered by the corresponding subscriber.

[0106] It's worth noting that when subscribers input the information about the changed asset type they want to receive, they can also input the corresponding operation type for that asset change, such as delete, add, or update. This allows for push notifications of asset change information based on the asset type and operation type.

[0107] In practice, once the target asset type for asset change information is determined, the identifier of the subscription object corresponding to the target asset type can be identified, thus identifying the object to be pushed to. Based on the identifier of the object to be pushed to, the corresponding push method, target address, and push template are obtained. The asset change information is then pushed to the terminal of the corresponding object based on the obtained push method, target address, and push template. This allows cloud platform asset change information to be distributed in real time from a unified data source to various subscription objects (such as other operation and maintenance management systems or personnel), thereby supporting real-time response or asset management functions and improving the overall availability of the cloud platform asset management center.

[0108] In some embodiments, see Figure 6 , Figure 6 This is a flowchart illustrating the information push method based on a cloud platform provided in an embodiment of this application. Figure 3 After step 101, the following can also be executed:

[0109] Step 201: Generate a first asset change event with a first protocol format through the management thread.

[0110] In practice, the database (such as a key-value database) stores a protocol for transmitting asset change information. After obtaining the asset change information, a management thread generates a first asset change event with a first protocol format. Here, the management thread is used to perform task parsing and generation. In some embodiments, the management thread can directly parse the obtained asset change information and generate a first asset change event with the first protocol format; in other embodiments, the management thread can obtain the asset change information from the database after receiving the asset change signal, and then parse the asset change information obtained from the database to generate a first asset change event with the first protocol format. It should be noted that the asset change signal here can be the signal generated in step 101 when the corresponding hardware asset obtains a cloud-native asset change operation.

[0111] Following the example above, see [link to example]. Figure 4 The management thread here can be Figure 4 The handler module stores the database containing the protocol for transmitting asset change information, which can be a Redis key-value database. Here, the handler module parses the asset change information and then generates a first asset change event with the first protocol format.

[0112] Step 202: Store the first asset change event to the task queue used to store asset change events on the cloud platform.

[0113] In actual implementation, after generating the first asset change event with the first protocol format, the management thread stores the first asset change event to the task queue used to store asset change events on the cloud platform.

[0114] Following the example above, refer here. Figure 7A , Figure 7A This is an optional schematic diagram of the asset change information processing flow provided in the embodiments of this application, based on Figure 7A After the management thread handler generates a first asset change event with a first protocol format based on the asset change information, it stores the first asset change event in the asset change event task queue of the storage cloud platform.

[0115] It should be noted that the first protocol format here is the format of the event protocol for the corresponding task queue, and the content of this event protocol is, for example, shown in Table 1 below:

[0116] Table 1

[0117]

[0118] In practice, the first protocol format, specifically the event protocol format of the corresponding task queue, includes the asset type, operation type, operation time, and a list of specific asset information containing both pre-change and post-change information. Here, after obtaining asset change information, based on the event protocol format of the task queue, the asset change information is parsed to generate a first asset change event with the corresponding format, and stored in the asset change event task queue of the storage cloud platform.

[0119] Thus, by using two processing threads—a management thread and a distribution thread—the management thread only needs to focus on parsing asset change information and writing to the task queue. That is, after completing the parsing and writing of the current asset change information, it can parse the asset change information corresponding to the next asset change operation. Even if a large number of asset change events occur at a certain point in time, and the management thread has a lot of information to process and its processing efficiency is slow, the events will be stored in the task queue and wait for orderly execution. This ensures the core change process and avoids the problem of combining the management thread and the distribution thread into a single thread. This single thread would need to parse each asset change event and distribute it to the time queue for push before it can parse the next asset change event. However, the core change process needs to wait for the event to be parsed before continuing to work in order to ensure the orderliness of asset changes, which would block the core change process.

[0120] Step 203: Retrieve the first asset change event from the task queue via the dispatch thread.

[0121] In practice, after the management thread stores the first asset change event in the asset change event task queue of the storage cloud platform, the distribution thread retrieves the first asset change event from the task queue. Continuing with the example above, the distribution thread here is... Figure 4 The `distributor` module is used to parse events in the task queue and distribute events from the event queue used for pushing. (Continue referring to...) Figure 7A ,based on Figure 7A The distributor thread retrieves the first asset change event from the task queue.

[0122] Step 204: Push the asset change information corresponding to the first asset change event to the terminal corresponding to the object to be pushed.

[0123] In practice, after the distribution thread retrieves the first asset change event from the task queue, it pushes the asset change information to the terminal corresponding to the target object via the push thread. See [link to relevant documentation]. Figure 8 , Figure 8 This is an optional flowchart illustrating how asset change information is pushed to the terminal corresponding to the object to be pushed, based on a push thread, according to an embodiment of this application. Figure 6 Step 204 can be achieved in the following way:

[0124] Step 2041: Determine the target push thread for the corresponding object from at least two push threads; wherein the push thread and the object to be pushed are in a one-to-one correspondence.

[0125] In practice, the push thread here is an independent push thread set up for each object to be pushed. That is, there is no strict requirement for the order of message arrival between different objects to be pushed. Therefore, in order to meet the needs of large-scale push scenarios, an independent push thread is set up for each object to be pushed, so as to execute push tasks concurrently, thereby improving the efficiency of information push.

[0126] Continue to refer to Figure 7A ,based on Figure 7A Each subscriber 1-N (i.e. the object to be pushed) is independently set up with a push process subscriber1-N. After the distributor thread retrieves the first asset change event from the task queue, it will push the asset change information to the corresponding terminal of each subscriber 1-N (i.e. the object to be pushed) based on each push thread subscriber1-N.

[0127] In some embodiments, push threads can also be set up independently based on the target asset type. Specifically, since the target asset types here are host, container, network device, and other asset types, push processes are set up separately for each asset type. See [link to relevant documentation]. Figure 7B , Figure 7B This is an optional schematic diagram of the asset change information processing flow provided in the embodiments of this application, based on Figure 7B For each asset type, a push thread (subscriber1-N) is set up. After the distribution thread (distributor) retrieves the first asset change event from the task queue, it will push the asset change information to the terminal corresponding to the object to be pushed based on the push thread (subscriber1-N).

[0128] It should be noted that in some embodiments, when a target object subscribes to asset update information for one asset type, the target object corresponds to the asset type of the asset change information, meaning the target object can only receive asset update information for one asset type. In other embodiments, when a target object subscribes to asset update information for multiple asset types, the multiple asset types are divided into corresponding asset types included in the cloud platform based on the asset types included in the cloud platform, and the target object is pushed the corresponding asset update information based on the divided asset types.

[0129] In practice, the target object can subscribe to asset change information based on asset change type, or simultaneously based on both asset change type and asset type. For example, in the information registration process of step 104, the subscribing object (i.e., the target object) can enter the target asset change type it needs to receive, or the target asset type that needs to be changed based on the target asset change type, on the push information registration interface. Thus, when the target object subscribes to asset change information based on asset change type, a push thread can be independently set up based on the asset change type to push the information to the corresponding target object. This embodiment of the application does not limit the process of setting up a push thread to push the information to the corresponding target object.

[0130] Step 2042: Send the first asset change event to the target push thread, and push the asset change information to the terminal corresponding to the object to be pushed through the target push thread.

[0131] In actual implementation, after determining the target push thread for the corresponding object to be pushed, the distribution thread will send the first asset change event obtained from the task queue to the target push thread, and then push the asset change information to the terminal corresponding to the object to be pushed through the target push thread. Specifically, the distribution thread first converts the format of the first asset change event to generate a second asset change event with a second protocol format; the second asset change event is stored in the event queue corresponding to the target push thread; and the target push thread retrieves the asset change information from the event queue and pushes the asset change information to the terminal corresponding to the object to be pushed.

[0132] In actual implementation, the second protocol format here is the format of the event protocol corresponding to the event queue, and the content of the event protocol is, for example, shown in Table 2 below:

[0133] Table 2

[0134]

[0135] In actual implementation, the second protocol format is the event protocol format corresponding to the event queue, specifically including asset type, operation type, operation time, a list of specific asset information containing information before and after the change, push method, subscriber address (i.e., the address of the party to be pushed to), and sending template (i.e., push template). Here, the process of the distribution thread converting the format of the first asset change event obtained from the task queue to the target push thread to generate a second asset change event with the second protocol format is specifically as follows: based on the push registration information pre-registered by the object to be pushed, relevant information corresponding to the push registration information is selected from the content of the event protocol of the event queue for format conversion.

[0136] It should be noted that, in the process of generating a second asset change event with a second protocol format for the first asset change event, the first asset change event includes all the contents of the event protocol corresponding to the task queue, while the second asset change event does not completely include all the contents of the event protocol corresponding to the event queue. For example, the first asset change event includes the asset type, operation type, operation time, and a list of specific asset information including information before and after the change. The second asset change event, however, may not necessarily include the asset type, operation type, operation time, list of specific asset information including information before and after the change, push method, subscriber address, and sending template. For instance, if the operation time of the asset change operation is not required by the subscriber, the second asset change event may only include the asset type, operation type, list of specific asset information including information before and after the change, push method, subscriber address, and sending template, excluding the operation time. Alternatively, if there is no information before the change, the second asset change event may only include the asset type, operation type, operation time, push method, subscriber address, and sending template, excluding the list of specific asset information including information before and after the change. Thus, generating a second asset change event with a second protocol format based on actual circumstances improves generation efficiency and reduces resource waste.

[0137] In actual implementation, after generating a second asset change event with a second protocol format, the second asset change event is stored in the event queue corresponding to the target push thread. Then, the target push thread retrieves the asset change information corresponding to the second change event from the event queue and pushes the asset change information to the terminal corresponding to the object to be pushed.

[0138] See also Figure 7A After generating a second asset change event with a second protocol format, the distributor module stores the second asset change event in the subscriber event queue corresponding to the target push thread. Then, the target push thread retrieves the asset change information corresponding to the second change event from the subscriber event queue and pushes it to the terminal corresponding to the corresponding push object.

[0139] In some embodiments, after receiving the corresponding push information, the terminal corresponding to the target object displays the received push information on the client's display interface. For example, after the terminal receives the push information sent by the server, it can present the push information in the form of SMS text according to a preset push method and push template, or receive the push information in the form of telephone voice. In this way, by providing a variety of flexible subscription methods, it can adapt to more subscription scenarios, realize more push scenarios, and improve the subscriber's experience.

[0140] By applying the above embodiments of this application, in the process of information push based on the asset management center, the real-time acquired asset change information is classified to determine the target to be pushed to, which corresponds to the asset type of the real-time acquired asset change information, so as to push the asset change information. In this way, by timely collecting asset change information, efficient real-time information push can be carried out, thereby enabling real-time response or asset management functions based on the pushed information, improving the availability of the overall cloud platform's asset management center.

[0141] The following will describe an exemplary application of the embodiments of this application in a real-world application scenario.

[0142] The CMDB (Asset Management Center) stores various asset data, which is aggregated by a timed synchronization module and lacks real-time automatic update and push capabilities. To obtain the latest asset information, users (other systems or maintenance personnel) need to periodically poll the CMDB and determine whether an asset has been updated based on the asset change time stored in the CMDB. However, this method of obtaining the latest asset information has drawbacks: asset users cannot obtain asset change information in real time, and they need to develop their own asset judgment logic and actively query the CMDB to obtain the latest asset information. Therefore, based on this, this application proposes a cloud platform asset subscription system based on the existing Asset Management Center CMDB. This system is responsible for monitoring and acquiring various asset changes (including hardware assets and cloud-native assets) on the cloud platform, updating the CMDB data, and sending asset change information to other systems (subscribers) that need to be aware of asset changes in real time. This achieves timely collection of asset change information, efficient real-time information push, and support for flexible subscription methods, adapting to more subscription usage scenarios.

[0143] In the above embodiments of this application, through three processes—collection of asset change information, design of distribution logic and protocol for asset change events, and management of push subscription methods and subscriber information—the change information of cloud platform assets can be distributed in real time from a unified data source to various subscribers (such as other operation and maintenance management systems or operation and maintenance personnel), thereby supporting real-time response or asset management functions and improving the overall availability of the cloud platform operation and maintenance system.

[0144] This application provides a SubscriptionSystem service comprising four basic functional modules and two databases. The four functional modules are API, Handler, Distributor, and Subscriber. The API provides an HTTP protocol interface, responsible for receiving user requests to change hardware asset information via the front-end interface, requests to register subscribers, and requests from host agents to report machine information. The Handler parses asset change information and sends events to the Redis task queue. The Distributor parses events in the task queue and distributes them to subscriber event queues. For the Subscriber, the system independently starts a subscriber process for each subscriber, responsible for listening to its own subscriber event queue, parsing tasks, and sending them via HTTP to the specific subscriber. The two databases are MySQL and Redis. MySQL is a relational database used to store subscriber and asset information. Redis is a key-value database with publish / subscribe functionality, and in this application embodiment, it is used to store the message queue between the Distributor, Handler, and Subscriber, serving as a message transmission component.

[0145] There are three ways to collect asset change information provided in the above embodiments of this application: automatically reporting and obtaining host assets in real time through an agent, listening to cloud-native asset change events by establishing a long connection with the k8s apiserver, and providing an interface for operation and maintenance personnel to update other hardware assets (such as hard drives, switches, etc.). Specifically, the process of automatically reporting and obtaining real-time host asset change information via an agent is as follows: Since each host is installed and deployed with an agent responsible for reporting machine information to the subscription system by default, when a host is successfully installed or a host information change is detected, the agent collects data on the machine (including SN, IP, hard drive, network card, memory, etc.) and calls the subscription system's HTTP protocol API to report it. The subscription system then compares the obtained data with the data stored in the database and updates accordingly. For hardware devices that cannot obtain change information through self-collection, an interface update method is designed. When a user purchases or removes a new hardware device, maintenance personnel can enter the data by clicking on the interface. For cloud-native assets running on a Kubernetes-based system and managed uniformly by Kubernetes, the process of listening for cloud-native asset change events by establishing a long connection with the Kubernetes API server involves directly establishing a long HTTP connection with the Kubernetes API server module. When cloud-native assets change, the subscription system can obtain asset change information through the long HTTP connection.

[0146] The design process of the asset change event distribution logic and protocol provided in the above embodiments of this application is based on a Redis storage protocol for transmitting asset change information, and achieves efficient distribution of asset change information through a cooperation model of handler, distributor, and subscriber. Specifically, the processing of asset change events is completed through the coordination and cooperation among the three sub-modules: handler, distributor, and subscriber. Message transmission between sub-modules relies on Redis's message queue function to ensure the orderliness of event changes. The handling process for asset change events is divided into three stages: task parsing and generation, task distribution, and task push. Specifically, after the handler receives an asset change signal, it retrieves the asset details from the MySQL database, parses the asset change information into an event format for the Redis task queue, and writes it into the queue. Then, the distributor listens for updates in the Redis task queue, retrieves the event information from the queue, parses it, and, based on the asset type (e.g., host, network device, or container) and asset operation type (e.g., add / delete / update), reads the ID of the subscriber listening for that asset and operation type from MySQL, and writes the event into the corresponding subscriber's task queue. Finally, the corresponding subscriber (the one pushing the event) receives the event, parses it, and notifies the subscriber according to the notification method set by the subscriber (e.g., sending an HTTP request / SMS). The design process for handling asset change events is divided into handler and distributor design, multi-subscriber design, and Redis queue data protocol design.

[0147] Regarding the three design processes mentioned above, the division between handler and distributor is primarily for high-concurrency scenarios. For example, if a large-scale asset change event occurs at a certain point in time, and the distributor and handler are not separated but executed by a single functional module, then this module needs to parse each event and distribute it to multiple corresponding subscriber task queues (there may be many subscribers) before it can parse the next event. However, the core change process, in order to ensure the orderly execution of asset changes, needs to wait for the event to be parsed before continuing its work, thus blocking the core change process. By dividing the process into handler and distributor, the handler only needs to focus on parsing change information and writing it to the Redis "task queue" before moving on to the next task. Even if the handler's processing speed is slower, the events will still be stored in the Redis "task queue" and await orderly execution, thus ensuring the core change process. Secondly, the multi-subscriber design is necessary because there are no strict requirements for the order of message arrival between different subscribers. Therefore, to meet the needs of large-scale subscriber scenarios, each subscriber is designed to concurrently execute push tasks for one subscriber, improving push efficiency. As for the Redis queue data protocol design, each event is written to the queue in JSON format for both the task queue and the subscriber's task queue.

[0148] Thus, based on the Redis storage protocol for transmitting asset change information, the handler-distributor-subscriber working mode enables the system to support large-scale subscriptions for efficient distribution, and also has scalability for push methods.

[0149] The push subscription method and subscriber information management process provided in this application embodiment are as follows: First, a front-end interface is provided to support subscriber registration. Currently, it supports two push modes: HTTP-based change event push and SMS push (and the existing framework supports future expansion to include more push methods). Then, subscription events are registered at the granularity of asset type (such as host / network device / container) and change type (such as add / delete / update), such as listening for "add host" and "delete host" events. Specifically, the front-end interface is first provided to subscribers to register relevant push registration information, which is then stored in a relational database MySQL. Here, the relevant push registration information includes the push method (such as SMS / HTTP), target address (such as mobile phone number / url), push template (such as SMS template / HTTP request message template), and subscription asset operation type, i.e., operation type and asset type (such as delete host / add host / update network device). In this way, by providing a front-end interface for subscribers to register relevant push registration information, flexible subscription methods are supported, adapting to more subscription use cases.

[0150] By applying the above embodiments of this application, in the process of information push based on the asset management center, the real-time acquired asset change information is classified to determine the target to be pushed to, which corresponds to the asset type of the real-time acquired asset change information, so as to push the asset change information. In this way, by timely collecting asset change information, efficient real-time information push can be carried out, thereby enabling real-time response or asset management functions based on the pushed information, improving the availability of the overall cloud platform's asset management center.

[0151] The following continues to describe the exemplary structure of the cloud platform-based information push device 455 provided in the embodiments of this application as a software module. In some embodiments, such as Figure 2 As shown, the software modules stored in the cloud-based information push device 455 in the memory 440 may include:

[0152] The acquisition module 4551 is used to acquire asset change information of the assets included in the cloud platform;

[0153] The classification module 4552 is used to classify asset change information according to the types of assets included in the cloud platform, and obtain the target asset type of the asset corresponding to the asset change information;

[0154] The determination module 4553 is used to determine the object to be pushed corresponding to the asset change information of the target asset type;

[0155] The push module 4554 is used to push asset change information to the terminal corresponding to the object to be pushed.

[0156] In some embodiments, the acquisition module 4551 is further configured to receive asset change information corresponding to the first hardware device reported by the proxy service when the asset type of the asset is a first hardware device with a proxy service; wherein, the asset change information corresponding to the first hardware device is reported by the proxy service after collecting the corresponding change information when it detects that there is an information change in the first hardware device.

[0157] In some embodiments, the acquisition module 4551 is further configured to receive asset change information corresponding to the second hardware device sent by the management terminal corresponding to the cloud platform when the asset type of the asset is a second hardware device without a proxy service; wherein, the asset change information corresponding to the second hardware device is the asset change information indicated by the asset change operation when the management terminal receives the asset change operation for the second hardware device based on the presented asset information update interface.

[0158] In some embodiments, the acquisition module 4551 is further configured to establish a long connection with the interface service module in the asset management system corresponding to the cloud-native asset when the asset type of the asset is a cloud-native asset; wherein, the interface service module is configured to provide an entry point for resource change operations of the cloud-native asset; through the long connection, it listens for asset change operations corresponding to the cloud-native asset, and when the asset change operation is listened to, it acquires the asset change information corresponding to the cloud-native asset.

[0159] In some embodiments, the classification module 4552 is further configured to obtain the types of assets included in the cloud platform; wherein the types of assets included in the cloud platform include hardware assets and cloud-native assets; parse the asset change information to determine the asset type corresponding to the asset change information; classify the asset change information based on the types of assets included in the cloud platform and the asset type corresponding to the asset change information to obtain the target asset type of the asset corresponding to the asset change information.

[0160] In some embodiments, the device further includes a storage module, which is configured to generate a first asset change event having a first protocol format through a management thread; store the first asset change event in a task queue for storing asset change events of the cloud platform; the push module 4554 is further configured to retrieve the first asset change event from the task queue through a distribution thread; and push the asset change information corresponding to the first asset change event to the terminal corresponding to the object to be pushed.

[0161] In some embodiments, the push module 4554 is further configured to determine a target push thread corresponding to the object to be pushed from at least two push threads; wherein the push thread and the object to be pushed are in a one-to-one correspondence; send the first asset change event to the target push thread, and push the asset change information to the terminal corresponding to the object to be pushed through the target push thread.

[0162] In some embodiments, the push module 4554 is further configured to convert the format of the first asset change event through a distribution thread to generate a second asset change event with a second protocol format; store the second asset change event in the event queue corresponding to the target push thread; and retrieve the asset change information from the event queue through the target push thread and push the asset change information to the terminal corresponding to the object to be pushed.

[0163] In some embodiments, the device further includes a second determining module, which is used to determine the target asset change method indicated by the asset change information; the determining module 4553 is also used to determine, from multiple asset change information subscription objects of the cloud platform, the subscription object corresponding to the target asset change method and the target asset type as the object to be pushed.

[0164] This application provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the cloud-based information push method described in this application.

[0165] This application provides a computer-readable storage medium storing executable instructions. When these executable instructions are executed by a processor, they cause the processor to execute the cloud-based information push method provided in this application. For example... Figure 3 The method for pushing information based on a cloud platform is shown.

[0166] In some embodiments, the computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a variety of devices including one or any combination of the above-mentioned memories.

[0167] In some embodiments, executable instructions may take the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0168] As an example, executable instructions may, but do not necessarily, correspond to files in a file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a Hyper Text Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple collaborating files (e.g., a file that stores one or more modules, subroutines, or code sections).

[0169] As an example, executable instructions can be deployed to execute on a single computing device, or on multiple computing devices located in one location, or on multiple computing devices distributed across multiple locations and interconnected via a communication network.

[0170] In summary, the following technical effects can be achieved through the embodiments of this application:

[0171] (1) By classifying the asset change information obtained in real time, the target to be pushed is determined according to the asset type of the asset change information obtained in real time, so as to push the asset change information. In this way, by timely collecting asset change information, efficient real-time information push is carried out, thereby enabling real-time response or asset management functions based on the pushed information, and improving the availability of the asset management center of the overall cloud platform.

[0172] (2) Timely collection of asset change information for different asset types solves the problem that asset users cannot obtain asset change information in real time and need to develop their own asset judgment logic and actively query CMDB to obtain the latest asset information.

[0173] (3) By using two processing threads, namely the management thread and the distribution thread, the core change process is guaranteed. This avoids the problem of the management thread and the distribution thread being executed by a single thread. This single thread needs to parse each asset change event and distribute it to the time queue for push before it can parse the next asset change event. In order to ensure the orderly nature of asset changes, the core change process needs to wait for the event to be parsed before continuing to work, which would block the core change process.

[0174] (4) A push thread is set up independently for each object to be pushed, so that the push task is executed concurrently. In this way, the scenario of large-scale push is satisfied and the efficiency of information push is improved.

[0175] (5) By providing a variety of flexible subscription methods, we can adapt to more subscription scenarios, realize more push scenarios, and improve the subscriber experience.

[0176] (6) Based on the Redis storage protocol for transmitting asset change information, the system can support large-scale subscriptions for efficient distribution through the handler-distributor-subscriber working mode, and has the scalability of push method.

[0177] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A cloud platform-based information push method, characterized in that, The method includes: The system acquires real-time asset change information for assets included in the cloud platform. The types of assets included in the cloud platform include hardware assets and cloud-native assets. The acquisition method for asset change information differs depending on the type of asset. The asset change information is parsed to determine the asset type corresponding to the asset change information. Based on the types of assets included in the cloud platform and the asset type corresponding to the asset change information, the asset change information is classified to obtain the target asset type of the asset corresponding to the asset change information. Identify the target objects to be pushed to corresponding asset change information of the target asset type; The asset change information is pushed to the terminal corresponding to the object to be pushed.

2. The method as described in claim 1, characterized in that, The real-time acquisition of asset change information for assets included in the cloud platform includes: When the asset type of the asset is a first hardware device with an agent service, the asset change information corresponding to the first hardware device reported by the agent service is received. The asset change information corresponding to the first hardware device is the information collected and reported by the agent service when it detects that there is an information change in the first hardware device.

3. The method as described in claim 1, characterized in that, The real-time acquisition of asset change information for assets included in the cloud platform includes: When the asset type of the asset is a second hardware device without an agent service, the asset change information corresponding to the second hardware device sent by the management terminal corresponding to the cloud platform is received. Wherein, the asset change information corresponding to the second hardware device is the asset change information indicated by the asset change operation when the management terminal receives the asset change operation for the second hardware device based on the presented asset information update interface.

4. The method as described in claim 1, characterized in that, The real-time acquisition of asset change information for assets included in the cloud platform includes: When the asset type is a cloud-native asset, a long connection is established with the interface service module in the asset management system corresponding to the cloud-native asset; wherein, the interface service module is used to provide an entry point for resource change operations of the cloud-native asset; The system uses the long connection to monitor asset change operations corresponding to the cloud-native assets, and when the asset change operation is detected, it obtains the asset change information corresponding to the cloud-native assets.

5. The method as described in claim 1, characterized in that, After obtaining the asset change information of the assets included in the cloud platform in real time, the method further includes: A first asset change event with a first protocol format is generated through the management thread; The first asset change event is stored in a task queue used to store asset change events of the cloud platform; The step of pushing the asset change information to the terminal corresponding to the object to be pushed includes: The first asset change event is retrieved from the task queue by the distribution thread; The asset change information corresponding to the first asset change event is pushed to the terminal corresponding to the object to be pushed.

6. The method as described in claim 5, characterized in that, The step of pushing the asset change information corresponding to the first asset change event to the terminal corresponding to the object to be pushed includes: From at least two push threads, determine the target push thread corresponding to the object to be pushed; wherein, the push thread and the object to be pushed are in a one-to-one correspondence. The first asset change event is sent to the target push thread, and the asset change information is pushed to the terminal corresponding to the object to be pushed through the target push thread.

7. The method as described in claim 6, characterized in that, Sending the first asset change event to the target push thread includes: The first asset change event is converted into a format by the distribution thread to generate a second asset change event with a second protocol format. Store the second asset change event in the event queue corresponding to the target push thread; The step of pushing the asset change information to the terminal corresponding to the target object through the target push thread includes: The target push thread retrieves the asset change information from the event queue and pushes the asset change information to the terminal corresponding to the object to be pushed.

8. The method as described in claim 1, characterized in that, After obtaining the asset change information of the assets included in the cloud platform in real time, the method further includes: Determine the method of change of the target asset indicated by the asset change information; The process of determining the target asset type and the corresponding object to be pushed information includes: From the multiple asset change information subscription objects of the cloud platform, the subscription object corresponding to the target asset change method and the target asset type is determined as the object to be pushed.

9. An information push device based on a cloud platform, characterized in that, The device includes: The acquisition module is used to acquire asset change information of assets included in the cloud platform; the types of assets included in the cloud platform include hardware assets and cloud-native assets, and the acquisition method of the asset change information is different for different types of assets; The classification module is used to parse the asset change information, determine the asset type corresponding to the asset change information, classify the asset change information based on the types of assets included in the cloud platform and the asset type corresponding to the asset change information, and obtain the target asset type of the asset corresponding to the asset change information. The determination module is used to determine the target object to be pushed with the asset change information of the target asset type; The push module is used to push asset change information to the terminal corresponding to the object to be pushed.

10. The apparatus according to claim 9, characterized in that, The acquisition module is also used for: When the asset type of the asset is a first hardware device with an agent service, the asset change information corresponding to the first hardware device reported by the agent service is received. The asset change information corresponding to the first hardware device is the information collected and reported by the agent service when it detects that there is an information change in the first hardware device.

11. The apparatus according to claim 9, characterized in that, The acquisition module is also used for: When the asset type of the asset is a second hardware device without an agent service, the asset change information corresponding to the second hardware device sent by the management terminal corresponding to the cloud platform is received. Wherein, the asset change information corresponding to the second hardware device is the asset change information indicated by the asset change operation when the management terminal receives the asset change operation for the second hardware device based on the presented asset information update interface.

12. The apparatus according to claim 9, characterized in that, The acquisition module is also used for: When the asset type is a cloud-native asset, a long connection is established with the interface service module in the asset management system corresponding to the cloud-native asset; wherein, the interface service module is used to provide an entry point for resource change operations of the cloud-native asset; The system uses the long connection to monitor asset change operations corresponding to the cloud-native assets, and when the asset change operation is detected, it obtains the asset change information corresponding to the cloud-native assets.

13. The apparatus according to claim 9, characterized in that, The information push device of the cloud platform further includes a storage module, used for: generating a first asset change event with a first protocol format through a management thread; and storing the first asset change event to a task queue for storing asset change events of the cloud platform. The push module is further configured to retrieve the first asset change event from the task queue through a distribution thread; and push the asset change information corresponding to the first asset change event to the terminal corresponding to the object to be pushed.

14. The apparatus according to claim 13, characterized in that, The push module is also used for: From at least two push threads, determine the target push thread corresponding to the object to be pushed; wherein, the push thread and the object to be pushed are in a one-to-one correspondence. The first asset change event is sent to the target push thread, and the asset change information is pushed to the terminal corresponding to the object to be pushed through the target push thread.

15. The apparatus according to claim 14, characterized in that, The push module is also used for: The first asset change event is converted into a format by the distribution thread to generate a second asset change event with a second protocol format. Store the second asset change event in the event queue corresponding to the target push thread; The target push thread retrieves the asset change information from the event queue and pushes the asset change information to the terminal corresponding to the object to be pushed.

16. An electronic device, characterized in that, The electronic device includes: Memory is used to store executable instructions or computer programs. The processor, when executing computer-executable instructions or computer programs stored in the memory, implements the information push method based on a cloud platform as described in any one of claims 1 to 8.

17. A computer-readable storage medium storing computer-executable instructions or a computer program, characterized in that, When the computer-executable instructions or computer program are executed by a processor, the information push method based on a cloud platform as described in any one of claims 1 to 8 is implemented.

18. A computer program product comprising computer-executable instructions or a computer program, characterized in that, When the computer-executable instructions or computer program are executed by a processor, the information push method based on a cloud platform as described in any one of claims 1 to 8 is implemented.

Images