Message pushing method and system of Internet of Things

Abstract

The invention relates to the technical field of data processing, in particular to a message pushing method and system for the Internet of Things, and the method comprises the steps: obtaining a to-be-pushed device message; carrying out batch aggregation processing on the equipment message to obtain a processed message; based on a double-layer thread pool architecture, performing Webhook pushing on the processed message; pushing a corresponding URL (Uniform Resource Locator) on the basis of the Webhook, and determining the number of pushing failures; if the number of times of pushing failures reaches a preset number-of-times threshold value, fusing operation corresponding to Webhook pushing, and generating and outputting fusing information; and under the condition that the fusing information meets a preset time condition, continuing to carry out Webhook pushing on the processed message. Therefore, the failure times are monitored in real time based on the URL dimension, the downstream service health state is intelligently judged, the fusing strategy is automatically triggered, the overall availability is guaranteed, and the message pushing safety is improved.

Description

Technical Field

[0001] The present invention relates to the field of data processing technology, and in particular to a message pushing method and system for an Internet of Things in the field of data processing technology. Background Art

[0002] In modern, data-driven application architectures, webhooks, as a key mechanism for real-time communication between services, are responsible for efficiently, reliably, and securely pushing events or data to downstream systems. However, as business scale grows, especially in scenarios like the Internet of Things (IoT) with massive devices and frequent event triggering, traditional webhook implementations can easily lead to excessive pressure or even crashes on downstream services. When a single push fails, the retry mechanism is inefficient, easily causing repeated pressure. The exception handling mechanism and simple single-key authentication are easily cracked, and the lack of a request legitimacy verification mechanism makes it difficult to identify malicious requests. These security risks are particularly prominent in open, interconnected IoT environments. Summary of the Invention

[0003] The purpose of the present invention is to provide a message push method and system for the Internet of Things, and the technical solutions adopted are as follows:

[0004] In a first aspect, an embodiment of the present invention provides a message push method for an Internet of Things, the method comprising:

[0005] Get the device message to be pushed;

[0006] performing batch aggregation processing on the device messages to obtain processed messages;

[0007] Based on the double-layer thread pool architecture, the processed messages are pushed via Webhook;

[0008] Determine the number of push failures based on the URL corresponding to the Webhook push;

[0009] If the number of push failures reaches a preset threshold, a fuse information is generated and output;

[0010] When the fuse information meets the preset time condition, continue to push the processed message through Webhook.

[0011] In a second aspect, an embodiment of the present invention provides a message push system for an Internet of Things, the system comprising:

[0012] The acquisition module is used to obtain the device message to be pushed;

[0013] an aggregation module, configured to perform batch aggregation processing on the device messages to obtain processed messages;

[0014] A first push module is used to push the processed message through a Webhook based on a double-layer thread pool architecture;

[0015] A determination module, configured to determine the number of push failures based on the URL corresponding to the Webhook push;

[0016] A generation module is used to fuse the operation corresponding to the Webhook push if the number of push failures reaches a preset threshold, and generate and output fuse information;

[0017] The second push module is used to continue to push the processed message through Webhook when the fuse information meets the preset time condition.

[0018] In a third aspect, a computer program product is provided, which includes: a computer program code, which, when executed on a computer, causes the computer to execute the method of the first aspect.

[0019] In a fourth aspect, a computer-readable storage medium is provided, which stores a computer program code. When the computer program code is run on a computer, the computer executes the method of the first aspect.

[0020] The present invention has the following beneficial effects: after obtaining device messages to be pushed, the device messages are batch aggregated and processed so that the data volume of the processed messages is not too large, thus avoiding excessive single push data; then, a webhook push is performed on the processed messages through a double-layer thread pool architecture to ensure fast consumption and cope with sudden traffic; based on the URL corresponding to the webhook push, the number of push failures is determined; if the number of push failures reaches a preset threshold, the operation corresponding to the webhook push is fused, and fused information is generated and output; thus, fused detection is performed based on the uniform resource locator (URL) as a dimension, and when it is detected that the number of pushes reaches a preset threshold, the fused operation is triggered, the webhook push is stopped, and a fused information is output. Finally, if the fused information meets the preset time condition, the webhook push of the processed message continues. In this way, the number of failures is monitored in real time based on the URL dimension, the health status of downstream services is intelligently judged, the circuit breaker strategy is automatically triggered, and push is actively suspended when downstream abnormalities occur to avoid invalid requests. Moreover, by judging whether the circuit breaker information meets the preset time conditions, a timed self-recovery mechanism is implemented, and normal services can be restored without human intervention, effectively preventing downstream service overload and system avalanche effects, ensuring overall availability, and thus improving the security of message push. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the technical solutions and advantages of the embodiments of the present invention or the prior art, the following briefly introduces the drawings required for use in the embodiments or the prior art descriptions. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0022] Figure 1 This is a schematic diagram of the implementation process of a message push method for the Internet of Things provided by an embodiment of the present invention;

[0023] Figure 2 This is another implementation flow diagram of a message push method for an Internet of Things provided by an embodiment of the present invention;

[0024] Figure 3 This is another implementation flow diagram of a message push method for the Internet of Things provided by an embodiment of the present invention;

[0025] Figure 4 This is another implementation flowchart of a message push method for the Internet of Things provided by an embodiment of the present invention;

[0026] Figure 5 This is another implementation flow diagram of a message push method for an Internet of Things provided by an embodiment of the present invention;

[0027] Figure 6 This is another implementation flow diagram of a message push method for the Internet of Things provided by an embodiment of the present invention;

[0028] Figure 7 This is a schematic diagram of the structure of a message push system for the Internet of Things provided by an embodiment of the present invention;

[0029] Figure 8 It is a structural diagram of a computer device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0030] To further illustrate the technical means and effectiveness of the present invention to achieve its intended purpose, the following, in conjunction with the accompanying drawings and preferred embodiments, describes in detail the specific implementation, structure, features, and effectiveness of a message push method for the Internet of Things proposed by the present invention. In the following description, different references to "one embodiment" or "another embodiment" do not necessarily refer to the same embodiment. Furthermore, specific features, structures, or characteristics of one or more embodiments may be combined in any suitable manner.

[0031] In the description of the embodiments of the present invention, unless otherwise specified, " / " means or, for example, A / B can mean A or B: "and / or" in the text is only a description of the association relationship of associated objects, indicating that there can be three relationships, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in the description of the embodiments of the present invention, "multiple" refers to two or more than two.

[0032] In the following, the terms "first" and "second" are used for descriptive purposes only and should not be understood to imply or suggest relative importance or implicitly indicate the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the features.

[0033] Unless defined otherwise, 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 invention belongs.

[0034] In related technologies, webhook push typically pushes data one by one, resulting in low efficiency, significant waste of network resources, and high pressure on target services. In high-frequency event scenarios, a single push can cause a large number of concurrent requests to downstream services in a short period of time, easily leading to excessive pressure or even crashes. When a single push fails, the retry mechanism is inefficient and prone to repeated pressure. In scenarios with large amounts of device data and frequent events, it is necessary to push a large number of webhook events to downstream systems efficiently and with low latency.

[0035] When the downstream webhook service is unavailable (due to downtime, timeout, network failure, etc.), if the system continuously retries push, it will cause a large number of invalid requests, waste bandwidth and computing resources, and may cause its own threads, queues, databases and other resources to be exhausted, thus affecting the stability of the entire system. When the downstream service is unstable or unavailable, continuous push can also cause excessive pressure on the downstream service or even cause it to crash. It is necessary to automatically suspend push when downstream anomalies occur to protect itself and downstream services, and automatically resume push after a certain period of time.

[0036] Webhook implementations often lack comprehensive security protection mechanisms, exposing them to risks such as data leakage, request forgery, and replay attacks. Simple single-key authentication is easily cracked, and the lack of a request legitimacy verification mechanism makes it difficult to identify malicious requests. This is particularly true in the open, interconnected IoT environment, where security risks are particularly prominent. Furthermore, fixed Secure Sockets Layer (SSL) policies are unable to flexibly adapt to diverse deployment environments, extensive permission management leads to unauthorized access to data, and the lack of complete audit and traceability makes troubleshooting difficult. With data security and compliance becoming increasingly important, a secure transmission and authentication solution is urgently needed.

[0037] Based on this, the embodiment of the present application provides a message pushing method of Internet of Things, and the specific scheme of the message pushing method of Internet of Things provided by the present application is described in detail below in combination with the drawings. Please refer to Figure 1 , which shows the implementation flow diagram of the message pushing method of Internet of Things provided by an embodiment of the present application, and the method comprises the following steps:

[0038] 101, obtaining a device message to be pushed.

[0039] Here, the device message to be pushed can be any type of message of Internet of Things device. For example, the message pushed based on the Webhook of Internet of Things.

[0040] 102, performing batch aggregation processing on the device message to obtain a processed message.

[0041] Here, the processed message is obtained by using a multi-level message batch aggregation mechanism on the device message.

[0042] In some possible implementation manners, the step 102 can be implemented by the following process:

[0043] Firstly, the Kafka partition of the device message is determined; then, based on the Kafka partition of the device message, batch aggregation processing is performed on the device message to obtain a processed message. For example, the device message is specified by the device SN modulo operation, the Kafka partition is specified, it is ensured that the same device message (i.e. the message of the same device) is processed by the same consumer, and the sequence is guaranteed. Then, the message event aggregation is automatically implemented by batch message listening, and the double trigger strategy (1000 ms time window or 200 messages) is used to batch consume messages.

[0044] In some possible implementation manners, after the Kafka partitioning of the device message, the mapping relationship between the device to which the device message belongs and the application is established in each Kafka partition; then, based on the mapping relationship, the device message is grouped according to the dimension of the application to obtain a plurality of groups of device messages; and the plurality of groups of device messages are processed by multiple times of sharding to obtain the processed message.

[0045] Here, after being consumed by the message center, device messages are handed over to the business layer for further grouping and webhook push. First, the relationship between the device and the application is queried, and a device-to-application mapping relationship is established. For example, if the user has pre-created the application and device (each uniquely identified by the application's unique identifier (ID) and the device's unique ID), the application is bound to the device (the application and device have a one-to-many relationship), and the binding relationship is stored in a relational database (MySQL). Under this premise, the system queries the database for device-bound application data based on a batch of device identifiers (IDs). The specific mapping is constructed using a Map data structure in the programming language (Java), where the key is the device ID and the value is a list of application IDs. Then, device messages are grouped by application dimension, and large batch events under the application are secondary sharded according to the configured threshold to avoid pushing too much data at a time. For example, when a large number of device messages need to be pushed, the system first performs a primary sharding process based on the application dimension. Based on the preset batch value, for example, every ten applications are sequentially divided into a group of processing units. The ten applications in the group use a thread pool to push webhook data in parallel. This is the first application-level sharding. Secondary sharding involves secondary sharding the webhook data pushed in batches under each application to prevent push messages from being affected by excessively large data packets. Based on the preset value, webhook messages under each application are sequentially sharded into batches of 50 messages, meaning that each message body for each application can contain a maximum of 50 messages.

[0046] 103. Based on the double-layer thread pool architecture, Webhook push is performed for processed messages.

[0047] Here, a two-tier thread pool architecture is used, including a message consumption thread pool and a message push thread pool. The message consumption thread pool is dedicated to event monitoring and preliminary processing, with a zero queue capacity to ensure fast consumption, while the message push thread pool is dedicated to concurrently pushing Hypertext Transfer Protocol (HTTP) requests, with a large queue capacity to cope with sudden traffic bursts.

[0048] In some possible implementations, the above step 103 can be performed by Figure 2 The process shown in the figure is to first collect and partition events (events pushed by Webhook); secondly, monitor events in batches; thirdly, process events in groups; thirdly, perform application-level concurrent processing; thirdly, perform batch segmentation within the application, and push in batches so that the downstream system can receive them. The specific implementation process can be as follows: Figure 3As shown in the figure: First, the device reports data (i.e., receives device messages). Second, a message partitioning strategy is used to partition device messages. This message partitioning strategy includes: entering device messages into a Kafka message queue and partitioning them by SN modulo to ensure message ordering. Message consumers use a dual-trigger strategy (e.g., a 1000ms time window or 200 messages) to batch consume messages. Afterwards, multi-level message aggregation is performed on these batched messages. For example, a consumer thread pool is used to control queue capacity, query device-application relationships, establish device-application mappings, and group device messages by application ID. Applications are then partitioned into 10 shards and processed in parallel at the application level. This parallelized data is then processed asynchronously, followed by secondary sharding of in-application events. This includes: increasing the queue capacity of the webhook push pool, in-application event aggregation, event partitioning, and event-level sharding. Finally, the webhook push processing logic is triggered. In this process, device events are pushed to the message center buffer based on the message queue and partitioned by device SN modulo to ensure event ordering. The message center consumer then monitors and aggregates events according to time windows or quantity thresholds to form batched event sets. After grouping these events by application dimension, they are serialized into JSON arrays and pushed in batches through concurrent processing and batch sharding strategies. Combined with asynchronous fault-tolerance mechanisms (such as asynchronous programming tools (CompletableFuture) non-blocking requests and failure retries), this significantly improves throughput efficiency and reduces HTTP connection overhead.

[0049] 104. Determine the number of push failures based on the URL corresponding to the Webhook push.

[0050] Here, the number of push failures is counted based on the URL dimension corresponding to the Webhook push. When the number of push failures reaches the preset threshold, the circuit breaker operation is automatically executed to stop the Webhook push.

[0051] In some possible implementations, when a URL request failure is detected, an inspection setting operation in a preset database is determined; and based on the inspection device operation, the number of URL request failures is recorded to obtain the number of push failures.

[0052] Here, when the system detects that a URL request fails, it records the number of push failures through the check setting (setnx) operation with an expiration time provided by the database (Redis). When the number of push failures reaches the threshold, the circuit breaker is triggered.

[0053] 105. If the number of push failures reaches a preset threshold, the operation corresponding to the Webhook push is fused, and fusion information is generated and output.

[0054] Here, if the number of push failures reaches a preset threshold, the webhook push is stopped by triggering a circuit breaker operation. The start time of the circuit breaker operation is recorded to generate circuit breaker information.

[0055] In some possible implementations, step 105 may be implemented through the following process:

[0056] First, if the number of push failures reaches the preset threshold, a fuse operation is triggered.

[0057] Here, the preset number threshold can be a custom threshold. After detecting that the URL request fails, it is determined whether the number of push failures reaches the preset number threshold. If the preset number threshold is reached, the circuit breaker operation is triggered to stop the Webhook push.

[0058] Secondly, in response to the fuse operation, the Webhook push for the processed message is stopped within a preset time period.

[0059] Here, the preset duration can be a custom duration, and it is determined whether the time from the start time of the circuit breaker operation to the current time is less than the preset duration. If it is less than the preset duration, the Webhook push for the processed message is stopped. In some possible implementations, after the circuit breaker is triggered, the URL is recorded as having been fused, that is, the URL is recorded as having been fused through Redis setnx, and the key value is a unique key name derived from the URL; the next time the Webhook push is triggered, Redis is retrieved based on the URL to obtain whether the key value exists. If it exists, it means that the circuit breaker has been triggered, and the Webhook is pushed again until the key value expires (i.e., it expires).

[0060] Finally, based on the preset duration and the starting time of the fusing operation, the fusing information is generated and output.

[0061] Here, the preset duration and the starting time of the fuse operation are combined to generate a key value, the key value is used as the fuse information, and the fuse information is output.

[0062] In the above process, the dimension of circuit breaker isolation is the URL, and the Webhook push operation is isolated. When the circuit breaker is triggered, the system stops initiating push to the Webhook to reduce invalid resource requests. After the circuit breaker, the Webhook message push to the URL will be stopped within the specified time, and a circuit breaker message notification will be triggered, that is, the circuit breaker information will be output.

[0063] 106. When the fuse information meets the preset time condition, continue to push the processed message through Webhook.

[0064] Here, by determining whether the fuse information has expired, it is determined whether the fuse information meets the preset time condition. If the fuse information has expired, it is determined that the fuse information meets the preset condition, then the push instruction is responded to and the webhook push of the processed message is continued. If the fuse information has not expired, it is determined that the fuse information does not meet the preset condition, then the triggered push instruction is not responded to and the push of the processed message is stopped.

[0065] In some possible implementations, the MQTT status is pushed immediately after the webhook push to avoid blocking the main process. This can be achieved through the following process:

[0066] MQTT topics are uniquely identified by user and application to ensure message isolation. Webhook push notifications immediately push MQTT status, allowing the frontend to update the UI in real time. MQTT messages are sent asynchronously without blocking the main process. The frontend subscribes to MQTT messages to obtain the real-time status of webhook messages. Upon receiving a push notification, it promptly refreshes the latest webhook message push history, enabling real-time MQTT notifications.

[0067] In some possible implementations, first, determine the fuse duration between the start time of the fuse operation corresponding to the fuse information and the current time; here, the fuse duration can be recorded by the key value. Secondly, if the fuse duration reaches the preset duration, determine that the fuse information meets the preset time condition; here, determine whether the fuse duration represented by the key value has timed out, that is, whether it has reached the preset duration, so as to determine whether the fuse information meets the preset time condition. Finally, when a triggering operation of a Webhook push is detected, continue to perform a Webhook push on the processed message. Here, if the fuse duration reaches the preset duration, it means that the fuse duration represented by the key value has timed out, then the Webhook push on the processed message can continue in response to the triggering operation of the Webhook push.

[0068] In some possible implementations, you can also dynamically set the retry interval for webhook pushes to facilitate timely and uncomplicated push retries. This can be achieved through the following process:

[0069] First, get the retry interval of the webhook push;

[0070] The retry interval doubles with the number of retries. An exponential backoff algorithm is used, with the retry interval starting from 2000ms and increasing by 2 times each time to avoid retry storms.

[0071] Secondly, when the moment of the Webhook push reaches the retry duration interval corresponding to the current retry count, determine whether the current retry count reaches the preset retry count threshold, and whether the fuse information corresponding to the Webhook push meets the preset time condition.

[0072] Here, in response to the triggered Webhook push operation, it is determined whether the time of the Webhook push reaches the corresponding retry time interval. If the retry time interval has been reached, it is further determined whether the current number of retries has reached the preset retry time threshold, and whether the fuse information corresponding to the Webhook push has timed out.

[0073] Finally, if the current number of retries does not reach the preset retry threshold, and the fuse information corresponding to the Webhook push meets the preset time condition, the Webhook push is performed again.

[0074] Here, if the current number of retries does not reach the preset retry threshold and the fuse information corresponding to the Webhook push has expired, then the Webhook push is performed again.

[0075] In some possible implementations, Webhook push relies on http / https requests, and network requests may be subject to network fluctuations, resulting in unstable requests. Setting a retry interval is mainly to minimize the impact of downstream uncontrollable factors such as network fluctuations. The specific implementation is achieved through the @Retryable annotation provided by the Spring framework, which can specify exceptions, number of retries, and backoff strategies.

[0076] exist Figure 3 After triggering the Webhook push processing logic based on the above automatic circuit breaker process, Figure 4 The process shown is implemented as follows:

[0077] First, get the Webhook push processing logic; second, query the application's Webhook configuration to obtain the configuration; third, determine whether the URL is broken (that is, determine whether it is currently in a broken state based on the URL, for example, determine whether the breaking time represented by the key value in the breaking information has timed out; third, if yes (that is, the breaking time has not timed out and it is currently in a broken state), skip the Webhook push; if not (that is, the breaking time has timed out and it is not currently in a broken state), try the Webhook push. After that, construct a signed request and transmit it to the third-party receiving system (that is, Figure 6The third-party receiving system shown in the figure); again, the status code is returned by the third-party receiving system to determine whether the circuit breaker condition is triggered, that is, whether the number of URL failures is greater than or equal to the threshold; if the number of URL failures is greater than or equal to the threshold, the circuit breaker automatic recovery mechanism is started, the circuit breaker status is set (including: Redis key: url; expiration time: reset Timeout), and the circuit breaker Webhook notification is sent at the same time (that is, the circuit breaker information is generated and output), and the push record is saved; again, the Redis key automatically expires (after reset Timeout seconds, the Redis key automatically expires, that is, the circuit breaker information has expired), the circuit breaker status is automatically cleared, and the service is restored. In this way, the number of push failures is counted in real time based on the URL dimension, and the circuit breaker is automatically triggered when the threshold is reached, pausing the push to isolate the fault; the circuit breaker status interception mechanism actively skips invalid requests, and automatically handles transient faults in combination with the timed recovery strategy and retry annotations; all failure records are persistently stored and logs are output to ensure push reliability and anomaly traceability, avoiding resource exhaustion and cascading failures.

[0078] If the number of URL failures is less than the threshold, determine whether a retry is needed; if a retry is needed, use the exponential backoff algorithm, start with a retry interval of 2000ms, and double the time, perform intelligent retries, and save the push record. If a retry is not needed, save the push record directly. Figure 4 As shown, push records can be saved in a push history database (this database includes: URL / content / status / time). During the implementation of front-end display and monitoring, the front-end application first enables the history record and queries the push status, and at the same time publishes MQTT messages through the MQTT topic (for example, sending MQTT messages by user / application ID); secondly, the push history API is queried, a paged query is performed in the push history database, the query results (i.e., MQTT messages) are obtained, and the MQTT message is published. In this way, after the user turns on the Webhook history switch, they can view the message content, request time, and message push status (for example, whether the push was successful) pushed by the specified Webhook address in pages.

[0079] In some possible implementations, after the Webhook push, MQTT real-time notification can be performed by Figure 5The process shown is implemented as follows: First, an event is generated (an event pushed by a Webhook); second, the Webhook configuration is obtained; third, whether the event subscription permission is checked is determined; if not, the event is discarded; if it is subscribed, a security header is constructed, and a security signature is generated by generating a timestamp and a random number; then, an HTTP request is constructed using a key-related hashing message authentication code (Hash-based Message Authentication Code, HMAC) algorithm, and an identity and signature are added to determine the SSL verification mode; if it is standard verification, HTTPS secure transmission is performed through a standard SSL client; if verification is bypassed, HTTPS secure transmission is performed through a non-verifying SSL client; finally, the request response is recorded and MQTT status synchronization is performed. In this way, the front end obtains the real-time status of the Webhook message by subscribing to the MQTT message. After receiving the push, it can promptly refresh and obtain the latest Webhook message push record. In this way, the timestamp, random number and HMAC algorithm are innovatively combined to generate a one-time signature to prevent replay attacks; it supports dual-channel strategies of standard and bypassing SSL verification, flexibly adapting to different deployment environments; it implements refined event-level subscription permission control to ensure data is pushed on demand, and establishes a complete security audit chain and MQTT real-time status synchronization mechanism to enhance monitoring capabilities.

[0080] In an embodiment of the present invention, the acquired device messages are batch aggregated to ensure that the data volume of the processed messages is not too large, thus avoiding excessive single push data. Subsequently, a Webhook push is performed on the processed messages through a two-tier thread pool architecture to ensure rapid consumption and cope with sudden traffic. The number of push failures is determined based on the URL corresponding to the Webhook push. If the number of push failures reaches a preset threshold, the operation corresponding to the Webhook push is fused, and fused information is generated and output. In this way, fused detection is performed based on the URL dimension. When it is detected that the number of pushes reaches the preset threshold, the fused operation is triggered, the Webhook push is stopped, and a fused information is output. Finally, if the fused information meets the preset time condition, the Webhook push continues to be performed on the processed messages. In this way, the number of failures is monitored in real time based on the URL dimension, the health status of downstream services is intelligently judged, the circuit breaker strategy is automatically triggered, and push is actively suspended when downstream abnormalities occur to avoid invalid requests. Moreover, by judging whether the circuit breaker information meets the preset time conditions, a timed self-recovery mechanism is implemented, and normal services can be restored without human intervention, effectively preventing downstream service overload and system avalanche effects, ensuring overall availability, and thus improving the security of message push.

[0081] In some embodiments, before performing a webhook push, the webhook push is configured, which can be achieved through the following process:

[0082] First, obtain the original configuration information corresponding to the Webhook push; for example, create a Webhook configuration through the API interface, which includes the following key information: application ID (unique identifier of the associated application), Webhook UUID (Universally Unique IDentifier) ​​(for example, a unique identifier automatically generated by the system), key (security key for signature verification), callback URL (target address for receiving push).

[0083] Secondly, the URL, fuse information and message status corresponding to the Webhook push are associated with the original configuration information to obtain associated configuration information.

[0084] Here, after fully recording the pushed URL, content, result status and other complete information, the URL, fuse information and message status corresponding to the Webhook push are bound to the original configuration information to obtain the associated configuration information.

[0085] Finally, based on the associated configuration information, the webhook push is tracked.

[0086] Here, the webhook ID is associated with the original configuration to facilitate problem tracking, thereby making it easier to distinguish between success and failure states and support subsequent analysis and replay.

[0087] In the above process, Webhook configuration creation and reception are prerequisites for Webhook push. If device messages need to be pushed to the target Webhook, the user needs to configure the URL address corresponding to the target Webhook on the platform and set up the Webhook message receiver downstream.

[0088] In some possible implementations, a one-time signature generated by the webhook push timestamp, random number, and HMAC algorithm is used to implement a secure and tamper-proof verification mechanism for the webhook. This can be achieved through the following process:

[0089] First, a one-time signature is generated based on the timestamp, random number and HMAC algorithm pushed by the webhook.

[0090] Here, the third-party system needs to implement a standard receiving interface to receive batch event arrays in JSON format, verify the UUID, timestamp, random number, and signature in the request header, and implement efficient processing logic for push messages.

[0091] Secondly, based on the one-time signature, an identity identifier and an independent key for the webhook push are generated. Finally, based on the identity identifier and the independent key, the processed message is pushed to the webhook.

[0092] Here, basic authentication is achieved through UUID identity identification and independent key management; a one-time signature is generated using a timestamp, random number, and HMAC algorithm to effectively prevent replay attacks; combined with a flexible SSL verification strategy, it ensures data security while also taking into account system compatibility. Figure 6 As shown, in Figure 3 On this basis, after triggering the Webhook push processing logic, first, a Webhook push is initiated, and a request header with a signature is constructed through HTTP POST; wherein, the request header construction includes: security header construction, by generating a timestamp, generating a random number, and generating a security signature; constructing an HTTP request through the HMAC algorithm, and adding an identity identifier and a signature; judging the SSL verification mode; if it is standard verification, then sending an HTTPS request through a standard SSL client; if it is bypassing verification, then sending an HTTPS request through a non-verifying SSL client. Afterwards, the HTTPS request is transmitted over the network to a third-party receiving system. In the third-party receiving system, the request header (including: UUID / timestamp / random number / signature) is verified through the standard receiving interface, the signature is verified, and the JSON data is parsed. Afterwards, batch events are processed and the status code is returned to determine the HTTP response status; finally, the request result is received and the request response is recorded. In this way, the above process implements Webhook security and anti-tampering verification, and realizes basic authentication through UUID identity identification and independent key management; uses timestamp, random number and HMAC algorithm to generate one-time signature to effectively prevent replay attacks; combines with flexible SSL verification strategy to ensure data security while taking into account system compatibility; all request records are persisted to form a complete security audit chain.

[0093] In some embodiments, the system can also provide a test interface to verify the validity of the configuration: provide the Webhook UUID and the test URL; the system attempts to send a test message to the specified Webhook URL to verify the validity status of the URL; in this way, if the user configures the Webhook on the platform and there is not necessarily a device to trigger the Webhook push event immediately, a Webhook test message can be triggered to verify whether the sending process is smooth.

[0094] In an embodiment of the present invention, after obtaining device messages to be pushed, the device messages are batch aggregated to ensure that the data volume of the processed messages is not too large, thereby avoiding excessive data being pushed at a single time. Subsequently, a Webhook push is performed on the processed messages through a two-tier thread pool architecture to ensure rapid consumption and cope with sudden traffic. The number of push failures is determined based on the URL corresponding to the Webhook push. If the number of push failures reaches a preset threshold, the operation corresponding to the Webhook push is fused, and fused information is generated and output. In this way, fused detection is performed based on the URL dimension. When it is detected that the number of pushes reaches the preset threshold, the fused operation is triggered, the Webhook push is stopped, and a fused information is output. Finally, if the fused information meets the preset time condition, the Webhook push of the processed message continues. In this way, the number of failures is monitored in real time based on the URL dimension, the health status of downstream services is intelligently judged, the circuit breaker strategy is automatically triggered, and push is actively suspended when downstream abnormalities occur to avoid invalid requests. Moreover, by judging whether the circuit breaker information meets the preset time conditions, a timed self-recovery mechanism is implemented, and normal services can be restored without human intervention, effectively preventing downstream service overload and system avalanche effects, ensuring overall availability, and thus improving the security of message push.

[0095] The embodiment of the present invention provides a message push system for the Internet of Things. Figure 7 , which shows a schematic diagram of the composition structure of a message push system for the Internet of Things provided by one embodiment of the present invention. The system 700 includes:

[0096] Acquisition module 701, used to obtain the device message to be pushed;

[0097] Aggregation module 702, configured to perform batch aggregation processing on the device messages to obtain processed messages;

[0098] The first push module 703 is used to push the processed message through Webhook based on a double-layer thread pool architecture;

[0099] A determination module 704 is configured to determine the number of push failures based on the URL corresponding to the Webhook push;

[0100] A generating module 705 is configured to, if the number of push failures reaches a preset threshold, fuse the operation corresponding to the Webhook push, and generate and output fuse information;

[0101] The second push module 706 is configured to continue to perform Webhook push on the processed message when the fuse information meets a preset time condition.

[0102] In some possible implementations, the aggregation module 702 is further configured to determine the Kafka partition of the device message; and perform batch aggregation processing on the device messages based on the Kafka partition of the device message to obtain processed messages.

[0103] In some possible implementations, the aggregation module 702 is also used to establish a mapping relationship between the device and the application to which the device message belongs in each Kafka partition of the message device; based on the mapping relationship, the device messages are grouped according to the dimension of the application to obtain multiple groups of device messages; and the multiple groups of device messages are sharded multiple times to obtain the processed messages.

[0104] In some possible implementations, the determination module 704 is further configured to determine an inspection setting operation in a preset database when a URL request failure is detected; and obtain the number of push failures based on the number of URL request failures recorded by the inspection device operation.

[0105] In some possible implementations, the generation module 705 is also used to trigger a circuit breaker operation if the number of push failures reaches the preset threshold; in response to the circuit breaker operation, stop initiating Webhook push for the processed message within a preset time period; and generate and output the circuit breaker information based on the preset time period and the start time of the circuit breaker operation.

[0106] In some possible implementations, the second push module 706 is also used to determine the fuse duration between the start time of the fuse operation corresponding to the fuse information and the current time; if the fuse duration reaches the preset duration, it is determined that the fuse information meets the preset time condition, and when the trigger operation of the Webhook push is detected, the Webhook push of the processed message continues.

[0107] In some possible implementations, the second push module 706 is also used to obtain the retry time interval of the Webhook push; wherein, the retry time interval doubles with the number of retries; when the moment of the Webhook push reaches the retry time interval corresponding to the current number of retries, it is determined whether the current number of retries reaches the preset retry time threshold, and whether the fuse information corresponding to the Webhook push meets the preset time condition; if the current number of retries does not reach the preset retry time threshold, and the fuse information corresponding to the Webhook push meets the preset time condition, the Webhook push is performed again.

[0108] In some possible implementations, the second push module 706 is further used to obtain the original configuration information corresponding to the Webhook push; associate the URL, fuse information and message status corresponding to the Webhook push with the original configuration information to obtain associated configuration information; and track the Webhook push based on the associated configuration information.

[0109] In some possible implementations, the second push module 706 is further used to generate a one-time signature based on the timestamp and a preset random number pushed by the Webhook; based on the one-time signature, generate an identity identifier and an independent key pushed by the Webhook; and based on the identity identifier and the independent key, perform a Webhook push on the processed message.

[0110] Optionally, the transmission medium can be a wired link (for example, but not limited to, coaxial cable, optical fiber and digital subscriber line (DSL)) or a wireless link (for example, but not limited to, wireless Internet (WIFI), Bluetooth and mobile device network). It should be noted that the system provided in the above embodiment is only illustrated by the division of the above functional modules. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the computer device can be divided into different functional modules to complete all or part of the functions described above. In addition, the method embodiments provided in the above embodiments belong to the same concept. The specific implementation process is detailed in the method embodiments, which will not be repeated here.

[0111] Figure 8 FIG. 1 is a schematic diagram of the structure of a computer device provided by an embodiment of the present invention. For example, Figure 8 As shown, the computer device 800 includes: a memory 801, a processor 802, and a computer program 803 stored in the memory 801 and running on the processor 802, wherein when the processor 802 executes the computer program 803, the computer device can execute any one of the IoT message push methods described above.

[0112] In addition, an embodiment of the present invention also protects a system, which may include a memory and a processor, wherein an executable program code is stored in the memory, and the processor is used to call and execute the executable program code to perform a message push method of the Internet of Things provided by an embodiment of the present invention. This embodiment can divide the system into functional modules according to the above method example. For example, it can correspond to each functional module, or two or more functions can be integrated into one processing module. The above integrated module can be implemented in the form of hardware. It should be noted that the division of modules in this embodiment is schematic, which is only a logical function division. There may be other division methods in actual implementation. It should be noted that all relevant contents of each step involved in the above method embodiment can be referred to the functional description of the corresponding functional module, and will not be repeated here.

[0113] It should be understood that the system provided in this embodiment is used to execute the above-mentioned message push method of the Internet of Things, and therefore can achieve the same effect as the above-mentioned implementation method. In the case of an integrated unit, the system may include a processing module and a storage module. Among them, when the system is applied to a device, the processing module can be used to control and manage the actions of the device. The storage module can be used to support the device to execute mutual program codes, etc. Among them, the processing module can be a processor or a controller, which can implement or execute the various exemplary logic blocks, modules and circuits described in conjunction with the contents disclosed in the present invention. The processor can also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of digital signal processing (DSP) and a microprocessor, etc., and the storage module can be a memory.

[0114] In addition, the system provided by the embodiments of the present invention may specifically be a chip, component, or module. The chip may include a connected processor and memory; the memory is used to store instructions. When the processor calls and executes the instructions, the chip can execute the message push method for the Internet of Things provided by the above embodiment. This embodiment also provides a computer-readable storage medium, which stores computer program code. When the computer program code is executed on a computer, it causes the computer to execute the above-mentioned method steps to implement the message push method for the Internet of Things provided by the above embodiment.

[0115] This embodiment also provides a computer program product. When the computer program product is run on a computer, it causes the computer to execute the above-mentioned related steps to implement a message push method for the Internet of Things provided in the above embodiment. Among them, the system, computer-readable storage medium, computer program product or chip provided in this embodiment are all used to execute the corresponding method provided above. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects of the corresponding method provided above, and will not be repeated here. Through the description of the above embodiments, those skilled in the art can understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual application, the above-mentioned functions can be distributed to different functional modules as needed, that is, the internal structure of the system is divided into different functional modules to complete all or part of the functions described above. In the embodiments provided by the present invention, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative. For example, the division of modules or units is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not performed. On the other hand, the mutual coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interface, system or unit, which may be electrical, mechanical or other forms.

[0116] It should be noted that the above-mentioned order of the embodiments of the present invention is for description only and does not represent the advantages and disadvantages of the embodiments. The processes depicted in the accompanying drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multi-task processing and parallel processing are also possible or may be advantageous. The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referenced to each other. Each embodiment focuses on the differences from other embodiments. The above content is only a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any technician familiar with the technical field can easily think of changes or replacements within the technical scope disclosed by the present invention, which should be covered within the scope of protection of the present invention.

Claims

1. A message push method for the Internet of Things, characterized in that: The message push method of the Internet of Things includes: Get the device message to be pushed; performing batch aggregation processing on the device messages to obtain processed messages; Based on the double-layer thread pool architecture, the processed messages are pushed via Webhook; Determine the number of push failures based on the URL corresponding to the Webhook push; If the number of push failures reaches a preset threshold, the operation corresponding to the Webhook push is fused, and fused information is generated and output; When the fuse information meets the preset time condition, continue to push the processed message through Webhook.

2. The message push method of the Internet of Things according to claim 1, characterized in that: The batch aggregation processing of the device messages to obtain processed messages includes: Determine the Kafka partition for the device message; Based on the Kafka partition of the device message, the device message is batch aggregated to obtain processed messages.

3. The message push method of the Internet of Things according to claim 2, characterized in that: The Kafka partition based on the device message, performing batch aggregation processing on the device message to obtain processed messages, includes: In each Kafka partition of the message device, a mapping relationship between the device to which the device message belongs and the application is established; Based on the mapping relationship, the device messages are grouped according to the application dimension to obtain multiple groups of device messages; The multiple groups of device messages are subjected to multiple fragmentation processing to obtain the processed messages.

4. The message push method of the Internet of Things according to claim 1, characterized in that: Determining the number of push failures based on the URL corresponding to the Webhook push includes: In the case of detecting that the URL request fails, determining the check setting operation in the preset database; The number of push failures is obtained based on the number of times the URL request fails recorded by the inspection device operation.

5. The message push method of the Internet of Things according to claim 1, characterized in that: If the number of push failures reaches a preset threshold, the operation corresponding to the Webhook push is fused, and fused information is generated and output, including: If the number of push failures reaches the preset threshold, a fuse operation is triggered; In response to the circuit breaker operation, stop initiating Webhook push for the processed message within a preset time period; The fusing information is generated and output based on the preset duration and the starting time of the fusing operation.

6. The message push method of the Internet of Things according to claim 1, characterized in that: When the fuse information meets the preset time condition, continuing to push the processed message through Webhook includes: Determine the duration of the fusing operation between the start time of the fusing operation corresponding to the fusing information and the current time; If the fuse duration reaches the preset duration, it is determined that the fuse information meets the preset time condition, and when a triggering operation of Webhook push is detected, Webhook push is continued for the processed message.

7. The message push method of the Internet of Things according to claim 1, characterized in that: The method further comprises: Get the retry interval pushed by the Webhook; wherein the retry interval doubles with the number of retries; When the time when the Webhook pushes reaches the retry time interval corresponding to the current retry number, determine whether the current retry number reaches the preset retry number threshold, and whether the fuse information corresponding to the Webhook push meets the preset time condition; If the current number of retries does not reach the preset retry threshold, and the fuse information corresponding to the Webhook push meets the preset time condition, the Webhook push is performed again.

8. The message push method of the Internet of Things according to claim 1, characterized in that: The method further comprises: Get the original configuration information corresponding to the Webhook push; Associating the URL, fuse information, and message status corresponding to the Webhook push with the original configuration information to obtain associated configuration information; Based on the associated configuration information, the webhook push is tracked.

9. The message push method of the Internet of Things according to claim 1, characterized in that: The method further comprises: Generate a one-time signature based on the timestamp pushed by the webhook and a preset random number; Based on the one-time signature, generate the identity identifier and independent key pushed by the Webhook; Based on the identity identifier and the independent key, a Webhook push is performed on the processed message.

10. A message push system for the Internet of Things, characterized in that: The system comprises: The acquisition module is used to obtain the device message to be pushed; an aggregation module, configured to perform batch aggregation processing on the device messages to obtain processed messages; A first push module is used to push the processed message through a Webhook based on a double-layer thread pool architecture; A determination module, configured to determine the number of push failures based on the URL corresponding to the Webhook push; A generation module is used to fuse the operation corresponding to the Webhook push if the number of push failures reaches a preset threshold, and generate and output fuse information; The second push module is used to continue to push the processed message through Webhook when the fuse information meets the preset time condition.

Images