A cloud-native-based message notification system implementation method and system

Abstract

The application relates to the field of cloud native technology, in particular to a cloud native-based message notification system implementation method and system, which comprises the following steps: message receiving, preprocessing, route matching, timing notification, retry function and modular design; short message, email, instant messaging software and API calling mode are supported; cloud native characteristics are used, including a Kubernetes custom resource definition mechanism and a ListWatch mechanism, so that rule configuration of a program is more flexible and efficient; the cloud native-based message notification system implementation method and system have the beneficial effects that the application provides a simpler application access mode, supports multiple notification modes, can have good performance in a high-concurrency scene, utilizes cloud native characteristics, relies on a NATS message queue, simplifies a program architecture and provides good maintainability and scalability.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of cloud native technology, in particular to a cloud native-based message notification system implementation method and system. BACKGROUND

[0002] In a cloud native environment, a large number of microservice applications are often running, the calling relationship between the applications is complex, and one function can involve multiple applications. In order to fully understand the running status of the applications, and to timely and accurately locate the applications when the applications are abnormal, a complete and reliable observability system needs to be built. In order to know the abnormal status of the applications in a timely manner, the observability system needs to support an alarm notification function, and when an alarm rule is triggered, real-time notification is performed through short message, email and other ways.

[0003] At present, in the field of cloud native, the commonly used alarm notification component is Alertmanager, which supports functions such as grouping, suppression and silence of alarms, and supports multiple notification methods. In actual use, Alertmanager is usually used in combination with Prometheus; Prometheus collects monitoring indicators and sets a series of alarm rules, and when the indicator data triggers the alarm rule, Alertmanager is called to send a notification.

[0004] However, not all programs running in a cloud native environment are connected to the Prometheus monitoring system, and some applications have their own monitoring alarm modules and cannot directly use Alertmanager for alarm notification, which is very common for applications migrated from a traditional architecture to a cloud native environment. Therefore, a message notification system that is not in the Prometheus ecosystem is needed, which is more easily connected to the notification of the application's own alarm module. SUMMARY

[0005] The present application aims to provide a cloud native-based message notification system implementation method and system to solve the problems raised in the background.

[0006] To achieve the above-mentioned purpose, the present application provides the following technical scheme: a cloud native-based message notification system implementation method, the method comprising the following steps:

[0007] Message receiving, preprocessing, routing matching, timing notification, retry function, modular design; support for short message, email, instant messaging software, API calling method;

[0008] Use cloud native features, including Kubernetes custom resource definition mechanism, ListWatch mechanism, so that the rule configuration of the program is more flexible and efficient, and can realize real-time sensing of the change of configuration data;

[0009] Using multiple inter-associated NATS message queues, the modules of the system are decoupled, so that each module can be processed asynchronously, and the high concurrency capability of the system is improved;

[0010] Using the traffic peak clipping function of the NATS message queue, the system has good support for horizontal expansion, and good high concurrency capability.

[0011] Preferably, when receiving the message, an HTTP API is provided to receive the notification request of the user program, and the request includes user-defined tags in addition to the notification content. According to a series of tag matching rules configured by the user in advance, the template, notification type, and receiver of the message are determined. The receiver is a specific notification target configured by the user in the message notification system, such as a mobile phone number, an email recipient, an instant messaging software group chat robot, or an external API interface.

[0012] Message preprocessing, including template variable replacement, message splitting, and keyword filtering.

[0013] Route matching, if the message is an instant notification type, read the tags and route the message to the corresponding receiver program according to the user-configured route matching rules, such as SMS, email, etc. The route matching rule supports sending a message to multiple receivers. If the message is a timed notification type, the message is sent to the timed notification module.

[0014] Timed notification, processing messages that require timed notification, reading tags, and generating instant notification messages according to the user-configured timing rules, and sending them to the route matching module.

[0015] Retry, when the notification sending program fails, the retry module will temporarily store these messages. After a certain retry waiting time, an instant notification message is generated and sent to the route matching module. The user needs to set the maximum number of retries.

[0016] Preferably, the specific operation of the NATS message queue is as follows:

[0017] Preprocessing queue: the producer of the queue is the message receiving module, and the consumer is the preprocessing module.

[0018] Route matching queue: the producers of the queue are the preprocessing module, the timed notification module, and the retry module, and the consumer is the route matching module.

[0019] Instant notification queue: the producer of the queue is the route matching module, and the consumer is the sending module of the notification sending program. Each notification method has an instant notification queue, which is listened to by the respective notification sending program.

[0020] Timing notification queue: the producer of the queue is the routing matching module, and the consumer is the timing notification module;

[0021] Retry queue: the producer of the queue is the sending module of the notification sending program, and the consumer is the retry module.

[0022] Preferably, it also includes message flow, specifically:

[0023] a) When the user's program triggers an alarm, call the notification management program HTTP API to send the notification content;

[0024] b) After the receiving module of the notification management program receives the message, the message is directly sent to the preprocessing queue of NATS;

[0025] c) The preprocessing module listens to the preprocessing queue of NATS, and after receiving the message, it performs preprocessing and then sends the message to the routing matching queue of NATS;

[0026] d) The routing matching module listens to the routing matching queue of NATS, and after receiving the message, it checks the label in the message. If the message type is instant notification, it is sent to the corresponding NATS instant notification queue according to the routing matching rule, and if the type is timing notification, it is sent to the NATS timing notification queue;

[0027] e) The sending module of the notification sending program listens to the NATS instant notification queue of the notification type, and after receiving the message, it performs sending. If the sending fails, a retry message is generated and sent to the NATS retry queue;

[0028] f) The retry module listens to the NATS retry queue, and after receiving the message, it performs timing according to the retry rule. After the timing ends, an instant notification message is generated and sent to the NATS routing matching queue, and step d) is continued;

[0029] g) For the timing module, it listens to the NATS timing queue, and after receiving the message, it generates an instant notification message according to the timing rule configured by the user, and sends it to the NATS routing matching queue, and continues step d).

[0030] Preferably, it also includes data storage, specifically:

[0031] The receiver, rule, and configuration class data created by the user are stored in the Kubernetes custom resource. The Kubernetes API server listens to the creation, editing, and deletion of resources, and updates the cache in memory in real time. Since the data is stored in Kubernetes, in addition to the front-end page provided by the message notification system, it can also be operated in the cluster through tools such as kubectl;

[0032] For sending records such log data, select to store in relational database, such as MySQL, PostgreSQL database, or store in file, with certain period timing cleaning, to avoid data's continuous growth.

[0033] A cloud-based message notification system implementation system, the system is composed of message module, data configuration module, NATS message queue module and NATS message queue application module;

[0034] Message module, message receiving, preprocessing, routing matching, timing notification, retry function, modular design; Support SMS, email, instant messaging software, API call mode;

[0035] Data configuration module, using cloud native features, including Kubernetes custom resource definition mechanism, ListWatch mechanism, so that the program's rule configuration is more flexible and efficient, and can real-time sense the change of configuration data;

[0036] NATS message queue module, using multiple interrelated NATS message queues, decoupling the system modules, so that each module can be processed asynchronously, and improve the system's high concurrency ability;

[0037] NATS message queue application module, using the traffic peak shaving function of NATS message queue to support horizontal expansion, so that the system has good high concurrency ability.

[0038] Preferably, the message module, when receiving messages, provides HTTP API, responsible for receiving user program notification requests, in addition to notification content, also includes user-defined tags, according to a series of user pre-configured tag matching rules, to determine the message template, notification type, receiver; The receiver is the specific notification target configured by the user in the message notification system, such as mobile phone number, email recipient, instant messaging software group chat robot, external API interface;

[0039] Message preprocessing, including template variable replacement, message splitting, keyword filtering;

[0040] Routing matching, if the message is instant notification type, read the label, according to the user's configuration of routing matching rules, route the message to the corresponding receiver program, such as SMS, email; Routing matching rules support sending a message to multiple receivers, if the message is timing notification type, send the message to timing notification module;

[0041] Timing notification, processing messages that need timing notification, reading tags, generating instant notification messages according to the timing rules configured by the user, and sending to the routing matching module;

[0042] Retry, when the notification sending program fails to send, the retry module will temporarily store these messages, and after a certain retry waiting time, generate an instant notification message and send it to the routing matching module. The user needs to set the maximum number of retries.

[0043] Preferably, the NATS message queue module includes a preprocessing queue, wherein the producer of the queue is the message receiving module, and the consumer is the preprocessing module.

[0044] The routing matching queue includes a preprocessing module, a timing notification module, and a retry module as the producer of the queue, and the routing matching module as the consumer of the queue.

[0045] The instant notification queue includes the routing matching module as the producer of the queue, and the sending module of the notification sending program as the consumer of the queue. Each type of notification has an instant notification queue, which is listened to by the respective notification sending program.

[0046] The timing notification queue includes the routing matching module as the producer of the queue, and the timing notification module as the consumer of the queue.

[0047] The retry queue includes the sending module of the notification sending program as the producer of the queue, and the retry module as the consumer of the queue.

[0048] Preferably, the NATS message queue module further includes:

[0049] a) When the user's program triggers an alarm, call the notification management program HTTP API to send the notification content;

[0050] b) The receiving module of the notification management program receives the message and sends it directly to the preprocessing queue of NATS;

[0051] c) The preprocessing module listens to the preprocessing queue of NATS, collects the message, performs preprocessing, and then sends the message to the routing matching queue of NATS;

[0052] d) The routing matching module listens to the routing matching queue of NATS, receives the message, checks the tags in the message, and if the message type is instant notification, sends it to the corresponding NATS instant notification queue according to the routing matching rules, and if the type is timing notification, sends it to the NATS timing notification queue;

[0053] e) The sending module of the notification sending program listens to the NATS instant notification queue of the notification type, receives the message, and sends it. If the sending fails, a retry message is generated and sent to the NATS retry queue;

[0054] f) The retry module listens to the NATS retry queue, and after receiving a message, according to the retry rule, timing is performed, and after the timing is over, an instant notification message is generated and sent to the NATS routing matching queue, and step d) is continued;

[0055] g) For the timing module, it listens to the NATS timing queue, and after receiving a message, according to the timing rule configured by the user, an instant notification message is generated and sent to the NATS routing matching queue, and step d) is continued.

[0056] Preferably, the NATS message queue module, the receiver, rule, and configuration class data created by the user are all stored in the Kubernetes custom resource, the creation, editing, and deletion of the resource are listened to through the Kubernetes API server, and the cache in the memory is updated in real time. Since the data is stored in Kubernetes, in addition to the front-end page provided by the message notification system, it can also be operated in the cluster through kubectl and other tools;

[0057] For the log type data such as sending records, it is stored in a relational database such as MySQL and PostgreSQL database, or stored in a file, and cleaned at a certain period of time to avoid continuous growth of data.

[0058] Compared with the prior art, the beneficial effects of the present application are:

[0059] The message notification system implementation method and system based on cloud native provided by the present application provide a simpler application access mode, support multiple notification modes, and can also have good performance in a high-concurrency scenario. The cloud native features are utilized, and the NATS message queue is relied on to simplify the program architecture, and good maintainability and scalability are provided. For applications that have not accessed the Prometheus monitoring system and have self-developed monitoring and alarm modules, only a little modification is needed to access the system to provide alarm notification capabilities for the application. BRIEF DESCRIPTION OF DRAWINGS

[0060] Figure 1 The method flowchart of the present application. DETAILED DESCRIPTION

[0061] In order to make the purpose, technical scheme of the present application clear, complete and more clear and understandable, the embodiments of the present application are further described in detail below in combination with the drawings. It should be understood that the specific embodiments described herein are part of the embodiments of the present application, not all embodiments, and are only used to explain the embodiments of the present application, and do not limit the embodiments of the present application. All other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the present application.

[0062] Embodiment one

[0063] Please refer to Figure 1 The present application provides a technical solution: a message notification system implementation method based on cloud native, the method comprises the following steps:

[0064] 1) Development language

[0065] Go is selected as the development language. Go has the characteristics of high development efficiency, fast compilation speed, and support for high concurrency. Many cloud native infrastructure and middleware use Go as the development language.

[0066] 2) Running environment

[0067] Cloud native environment.

[0068] 3) Cloud native features used

[0069] The message notification system needs to rely on some cloud native features to simplify the implementation process and improve the robustness of the program.

[0070] a) Custom Resource Definition. The core component of cloud native, Kubernetes, provides a custom resource definition mechanism, which opens the resource management capabilities of the Kubernetes API server. Users can manage custom resources as if they were provided by Kubernetes.

[0071] b) List Watch mechanism. Kubernetes API server provides List Watch mechanism, relying on http long connection, real-time monitoring of related events of specified resources, when resources are created, modified, deleted, listeners can timely receive events and handle them. The client-go library provided by Kubernetes provides List Watch code.

[0072] 4) Dependent components

[0073] NATS. The core component of the message notification system is the NATS message queue, which is an open source lightweight high-performance distributed message middleware that implements multiple message delivery models. It can improve application decoupling, asynchronous message, traffic peak shaving and other functions for the message notification system, and provides protection for high concurrency.

[0074] 5) Overall architecture

[0075] The message notification system is divided into two parts: notification management program and notification sending program.

[0076] a) Notify Manager: responsible for receiving, preprocessing, routing matching, timing notification, retry, etc. Modular design, each module is only responsible for its own function.

[0077] b) Notify Sender: responsible for message notification, supporting SMS, email, instant messaging software, API calling, etc. Different notification methods are responsible for different programs and run independently to expand horizontally according to actual conditions.

[0078] 6) Module division

[0079] Notify Manager:

[0080] a) Message receiving module: provides HTTP API and is responsible for receiving notification requests from user programs. In addition to notification content, the request also includes a series of user-defined tags. Other modules will match the template, notification type (instant notification, timing notification, etc.), receiver, etc. according to the user's pre-configured tag matching rules. The receiver is a specific notification target configured by the user in the message notification system, such as a mobile phone number, an email recipient, an instant messaging software group chat robot, or an external API interface.

[0081] b) Preprocessing module: pre-processes the message. Including template variable replacement, message splitting, keyword filtering, etc.

[0082] i. Template variable replacement: The template is the notification content defined by the user in the message notification system, and variables can be defined in the template. When the user's program triggers an alarm, the variable value is sent to the message notification system, and then the preprocessing module reads the template and replaces the variable value.

[0083] ii. Message splitting: If the message content is too long, the user can configure the message splitting function according to needs, split the message into multiple sub-messages, and send each sub-message independently.

[0084] iii. Keyword filtering: Users can configure keywords according to needs, supporting white list mode and black list mode, and matching keywords in notification content to determine whether the message should be sent.

[0085] c) Routing matching module: If the message is an instant notification type, read the tags and route the message to the corresponding receiver program such as SMS, email, etc. according to the user's configured routing matching rules. Routing matching rules support sending a message to multiple receivers. If the message is a timing notification type, send the message to the timing notification module.

[0086] d) Timing notification module: This module processes messages that need to be sent with a timing rule, reads the tags, and generates instant notification messages according to the user's configured timing rule, and sends them to the routing matching module.

[0087] e) Retry module: When the notification sending program fails, the retry module will temporarily store these messages, generate instant notification messages after a certain retry waiting time, and send them to the routing matching module. The user needs to set the maximum number of retries.

[0088] Notification sending program:

[0089] a) Sending module: responsible for sending messages to the corresponding receiver, such as SMS, email, instant messaging software, API call, etc. Each notification method is handled by a separate program.

[0090] 7) NATS message queue

[0091] The above modules communicate through the NATS queue. The specific NATS queue is as follows:

[0092] a) Preprocessing queue: the producer of the queue is the message receiving module, and the consumer is the preprocessing module.

[0093] b) Routing matching queue: the producers of the queue are the preprocessing module, the timing notification module, and the retry module, and the consumer is the routing matching module.

[0094] c) Instant notification queue: the producer of the queue is the routing matching module, and the consumer is the sending module of the notification sending program. Each notification method has an instant notification queue, which is listened to by the respective notification sending program.

[0095] d) Timing notification queue: the producer of the queue is the routing matching module, and the consumer is the timing notification module.

[0096] e) Retry queue: the producer of the queue is the sending module of the notification sending program, and the consumer is the retry module.

[0097] 8) Message flow process

[0098] a) When the user's program triggers an alarm, call the notification management program HTTP API to send notification content.

[0099] b) After the receiving module of the notification management program receives the message, it sends the message directly to the preprocessing queue of NATS.

[0100] c) The preprocessing module listens to the preprocessing queue of NATS, collects messages, performs preprocessing, and then sends the messages to the routing matching queue of NATS.

[0101] d) The routing matching module listens to the NATS routing matching queue. After receiving the message, it checks the label in the message. If the message type is instant notification, it is sent to the corresponding NATS instant notification queue according to the routing matching rule. If the type is timing notification, it is sent to the NATS timing notification queue.

[0102] e) The sending module of the notification sending program listens to the NATS instant notification queue of the notification type. After receiving the message, it sends it. If the sending fails, a retry message is generated and sent to the NATS retry queue.

[0103] f) The retry module listens to the NATS retry queue. After receiving the message, it counts according to the retry rule. After the counting is over, an instant notification message is generated and sent to the NATS routing matching queue to continue step d).

[0104] g) For the timing module, it listens to the NATS timing queue. After receiving the message, it generates an instant notification message according to the timing rule configured by the user and sends it to the NATS routing matching queue to continue step d).

[0105] 9) Data storage

[0106] a) The receiver, rule (including notification type rule, template matching rule, routing matching rule, timing rule, retry rule, etc.) and other configuration data created by the user are stored in the Kubernetes custom resource. The modules that need to use these data listen to the creation, editing and deletion of resources through the Kubernetes API server and update the cache in the memory in real time. Since these data are stored in Kubernetes, in addition to the front-end page provided by the message notification system, they can also be operated in the cluster through kubectl and other tools.

[0107] b) As for the log type data such as sending record, it can be stored in a relational database such as MySQL and PostgreSQL database or stored in a file. It is cleaned at a certain period to avoid continuous growth of data.

[0108] Embodiment two

[0109] On the basis of embodiment one, a cloud native-based message notification system implementation system is proposed, which is composed of a message transceiver module, a data configuration module, a NATS message queue module and a NATS message queue application module.

[0110] Message receiving module, message receiving, preprocessing, routing matching, timing notification, retry function, modular design; Support SMS, email, instant messaging software, API call mode; When receiving messages, provide HTTP API, responsible for receiving notification requests from user programs, in addition to notification content, also includes user-defined tags, according to a series of tag matching rules configured by the user in advance, to determine the template, notification type and receiver used by the message; The receiver is a specific notification target configured by the user in the message notification system, such as mobile phone number, email recipient, instant messaging software group chat robot, external API interface;

[0111] Message preprocessing, message preprocessing includes template variable replacement, message splitting and keyword filtering;

[0112] Routing matching, if the message is an instant notification type, read the tags and route the message to the corresponding receiver program according to the user's configured routing matching rules, such as SMS, email; The routing matching rule supports sending a message to multiple receivers, and if the message is a timing notification type, the message is sent to the timing notification module;

[0113] Timing notification, processing messages that require timing notification, reading tags, and generating instant notification messages according to the user's configured timing rules and sending them to the routing matching module;

[0114] Retry, when the notification sending program fails, the retry module will temporarily store these messages, after a certain retry waiting time, generate an instant notification message and send it to the routing matching module, the user needs to set the maximum number of retries.

[0115] Data configuration module, using cloud native features, including Kubernetes custom resource definition mechanism and ListWatch mechanism, making the program's rule configuration more flexible and efficient, and being able to real-time sense the changes of configuration data;

[0116] NATS message queue module, using multiple interrelated NATS message queues, decoupling the system modules, allowing each module to be processed asynchronously, and improving the system's high concurrency capability; Preprocessing queue: the producer of the queue is the message receiving module, and the consumer is the preprocessing module;

[0117] Routing matching queue: the producer of the queue is the preprocessing module, timing notification module and retry module, and the consumer is the routing matching module;

[0118] Instant notification queue: the producer of the queue is the routing matching module, and the consumer is the sending module of the notification sending program, each notification method has an instant notification queue, which is listened to by the respective notification sending program;

[0119] Timing notification queue: the producer of the queue is the routing matching module, and the consumer is the timing notification module;

[0120] Retry queue: the producer of the queue is the sending module of the notification sending program, and the consumer is the retry module.

[0121] The NATS message queue module further comprises:

[0122] a) When the user's program triggers an alarm, the notification management program HTTP API is called to send the notification content;

[0123] b) After the receiving module of the notification management program receives the message, the message is directly sent to the preprocessing queue of NATS;

[0124] c) The preprocessing module listens to the preprocessing queue of NATS, collects the message, performs preprocessing, and then sends the message to the routing matching queue of NATS;

[0125] d) The routing matching module listens to the routing matching queue of NATS, checks the label in the message after receiving the message, and if the message type is instant notification, sends it to the corresponding NATS instant notification queue according to the routing matching rule, and if the type is timing notification, sends it to the NATS timing notification queue;

[0126] e) The sending module of the notification sending program listens to the NATS instant notification queue of the notification type, receives the message after receiving the message, and performs sending. If the sending fails, a retry message is generated and sent to the NATS retry queue;

[0127] f) The retry module listens to the NATS retry queue, receives the message after receiving the message, and according to the retry rule, performs timing. After the timing ends, an instant notification message is generated and sent to the NATS routing matching queue, and step d) is continued;

[0128] g) For the timing module, it listens to the NATS timing queue, receives the message, and according to the timing rule configured by the user, generates an instant notification message and sends it to the NATS routing matching queue, and continues step d).

[0129] The NATS message queue module, the receiver, rule, and configuration class data created by the user are stored in the Kubernetes custom resource. The Kubernetes API server listens to the creation, editing, and deletion of resources and updates the cache in memory in real time. Since the data is stored in Kubernetes, in addition to the front-end page provided by the message notification system, kubectl and other tools are also used to operate in the cluster;

[0130] For sending record this kind of log data, select to store in relational database, such as MySQL, PostgreSQL database, or store in file, with certain period timing clean up, to avoid the continuous growth of data.

[0131] The NATS message queue application module uses the traffic peak shaving function of the NATS message queue to support horizontal expansion, so that the system has good high concurrency capability.

[0132] Although embodiments of the present application have been shown and described, it is to be understood that various modifications, substitutions, replacements and changes can be made to these embodiments without departing from the principles and spirit of the present application, and the scope of the present application is defined by the appended claims and their equivalents.

Claims

1. A method for implementing a cloud-native message notification system, characterized in that: The method includes the following steps: It features message receiving, preprocessing, routing matching, timed notifications, and retry functions, with a modular design; it supports SMS, email, instant messaging software, and API calls. By leveraging cloud-native features, including Kubernetes' custom resource definition mechanism and ListWatch mechanism, the program's rule configuration becomes more flexible and efficient, and it can detect changes in configuration data in real time. By using multiple interconnected NATS message queues, the system modules are decoupled, enabling asynchronous processing and improving the system's high concurrency capabilities. By leveraging the traffic shaping capabilities of NATS message queues to provide excellent support for horizontal scaling, the system achieves strong high concurrency capabilities. When receiving messages, an HTTP API is provided to receive notification requests from user programs. In addition to the notification content, the request also includes user-defined tags. Based on a series of tag matching rules pre-configured by the user, the template, notification type, and receiver for the message are determined. The receiver is a specific notification target configured by the user in the message notification system. Furthermore, the Kubernetes API server provides a List Watch mechanism, which relies on long-lived HTTP connections to monitor relevant events for specified resources in real time. When a resource is created, modified, or deleted, the listener can receive the event and process it promptly. The client-go library provided by Kubernetes contains the code for List Watch.

2. The method for implementing a cloud-native message notification system according to claim 1, characterized in that: When receiving messages, an HTTP API is provided to receive notification requests from user programs. In addition to the notification content, the request also includes user-defined tags. Based on a series of tag matching rules pre-configured by the user, the template, notification type, and receiver for the message are determined. The receiver is a specific notification target configured by the user in the message notification system. Message preprocessing involves preprocessing messages, including template variable replacement, message splitting, and keyword filtering. For routing matching, if the message is an instant notification type, the tag is read and the message is routed to the appropriate receiver program, including SMS and email, according to the routing matching rules configured by the user. The routing matching rules support sending a message to multiple receivers. If the message is a timed notification type, it will be sent to the timed notification module. Scheduled notifications: Process messages that require scheduled notifications, read tags, generate instant notification messages according to user-configured timing rules, and send them to the routing matching module. Retry: When the notification sending program fails to send, the retry module will temporarily store these messages. After the retry waiting time, an immediate notification message will be generated and sent to the routing matching module. Users need to set the maximum number of retries.

3. The method for implementing a cloud-native message notification system according to claim 1, characterized in that: The specific operations of the NATS message queue are as follows: Preprocessing queue: The producer of the queue is the message receiving module, and the consumer is the preprocessing module; Routing matching queue: The producers of the queue are the preprocessing module, the timed notification module, and the retry module, and the consumers are the routing matching module. Instant notification queue: The producer of the queue is the routing matching module, and the consumer is the sending module of the notification sending program. Each notification method has an instant notification queue, which is listened to by its respective notification sending program. Scheduled notification queue: The producer of the queue is the routing matching module, and the consumer is the scheduled notification module; Retry queue: The producer of the queue is the sending module of the notification sending program, and the consumer is the retry module.

4. The method for implementing a cloud-native message notification system according to claim 3, characterized in that: This also includes message flow, specifically: a) When a user's program triggers an alarm, it calls the notification management program's HTTP API to send notification content; b) After receiving the message, the receiving module of the notification management program sends the message directly to the preprocessing queue of NATS; c) The preprocessing module listens to the NATS preprocessing queue, receives a message, performs preprocessing, and then sends the message to the NATS route matching queue. d) The route matching module listens to the NATS route matching queue. After receiving a message, it checks the tag in the message. If the message type is an immediate notification, it sends it to the corresponding NATS immediate notification queue according to the route matching rules. If the type is a timed notification, it sends it to the NATS timed notification queue. e) The sending module of the notification sending program listens to the NATS instant notification queue for this notification type. After receiving the message, it sends it. If the sending fails, a retry message is generated and sent to the NATS retry queue. f) The retry module listens to the NATS retry queue. After receiving a message, it starts timing according to the retry rules. After the timing is completed, it generates an instant notification message and sends it to the NATS route matching queue to continue to step d). g) For the timing module, it listens to the NATS timing queue. Upon receiving a message, it generates an instant notification message according to the user-configured timing rules and sends it to the NATS route matching queue, then continues to step d).

5. The method for implementing a cloud-native message notification system according to claim 4, characterized in that: It also includes data storage, specifically: User-created receivers, rules, and configuration data are all stored in custom Kubernetes resources. The creation, editing, and deletion of resources are monitored through the Kubernetes API server, and the cache in memory is updated in real time. Since the data is stored in Kubernetes, in addition to the front-end page provided by the message notification system, operations are also performed in the cluster through the kubectl tool. For log-type data such as sending records, choose to store it in a relational database, including MySQL and PostgreSQL, or store it in a file and clean it up regularly to prevent the data from growing continuously.

6. A cloud-native message notification system, applied to the method described in any one of claims 1-5, characterized in that: The system consists of a message sending and receiving module, a data configuration module, a NATS message queue module, and a NATS message queue application module. The message sending and receiving module performs message reception, preprocessing, routing matching, timed notification, and retry functions, and features a modular design; it supports SMS, email, instant messaging software, and API calls. The data configuration module utilizes cloud-native features, including Kubernetes' custom resource definition mechanism and ListWatch mechanism, making the program's rule configuration more flexible and efficient, and enabling it to perceive changes in configuration data in real time. The NATS message queue module uses multiple interconnected NATS message queues to decouple the various modules of the system, enabling asynchronous processing and improving the system's high concurrency capabilities. The NATS message queue application module utilizes the traffic shaping function of the NATS message queue to provide excellent support for horizontal scaling, enabling the system to have good high concurrency capabilities.

7. The cloud-native message notification system according to claim 6, characterized in that: The message sending and receiving module provides an HTTP API to receive notification requests from user programs. In addition to the notification content, the request also includes user-defined tags. Based on a series of tag matching rules pre-configured by the user, the module determines the template, notification type, and receiver of the message. The receiver is a specific notification target configured by the user in the message notification system, including mobile phone numbers, email recipients, instant messaging group chat robots, and external API interfaces. Message preprocessing involves preprocessing messages, including template variable replacement, message splitting, and keyword filtering. For routing matching, if the message is an instant notification type, the tag is read and the message is routed to the appropriate receiver program, including SMS and email, according to the routing matching rules configured by the user. The routing matching rules support sending a message to multiple receivers. If the message is a timed notification type, it will be sent to the timed notification module. Scheduled notifications: Process messages that require scheduled notifications, read tags, generate instant notification messages according to user-configured timing rules, and send them to the routing matching module. Retry: When the notification sending program fails to send, the retry module will temporarily store these messages. After the retry waiting time, an immediate notification message will be generated and sent to the routing matching module. Users need to set the maximum number of retries.

8. The cloud-native message notification system according to claim 6, characterized in that: NATS message queue module, preprocessing queue: The producer of the queue is the message receiving module, and the consumer is the preprocessing module; Routing matching queue: The producers of the queue are the preprocessing module, the timed notification module, and the retry module, and the consumers are the routing matching module. Instant notification queue: The producer of the queue is the routing matching module, and the consumer is the sending module of the notification sending program. Each notification method has an instant notification queue, which is listened to by its respective notification sending program. Scheduled notification queue: The producer of the queue is the routing matching module, and the consumer is the scheduled notification module; Retry queue: The producer of the queue is the sending module of the notification sending program, and the consumer is the retry module.

9. The cloud-native message notification system according to claim 8, characterized in that: The NATS message queue module also includes: a) When a user's program triggers an alarm, it calls the notification management program's HTTP API to send notification content; b) After receiving the message, the receiving module of the notification management program sends the message directly to the preprocessing queue of NATS; c) The preprocessing module listens to the NATS preprocessing queue, receives a message, performs preprocessing, and then sends the message to the NATS route matching queue. d) The route matching module listens to the NATS route matching queue. After receiving a message, it checks the tag in the message. If the message type is an immediate notification, it sends it to the corresponding NATS immediate notification queue according to the route matching rules. If the type is a timed notification, it sends it to the NATS timed notification queue. e) The sending module of the notification sending program listens to the NATS instant notification queue for this notification type. After receiving the message, it sends it. If the sending fails, a retry message is generated and sent to the NATS retry queue. f) The retry module listens to the NATS retry queue. After receiving a message, it starts timing according to the retry rules. After the timing is completed, it generates an instant notification message and sends it to the NATS route matching queue to continue to step d). g) For the timing module, it listens to the NATS timing queue. Upon receiving a message, it generates an instant notification message according to the user-configured timing rules and sends it to the NATS route matching queue, then continues to step d).

10. The cloud-native message notification system according to claim 9, characterized in that: The NATS message queue module stores user-created receivers, rules, and configuration data in custom Kubernetes resources. It listens for resource creation, editing, and deletion through the Kubernetes API server and updates the cache in memory in real time. Since the data is stored in Kubernetes, it can be operated on in the cluster through the kubectl tool in addition to the front-end page provided by the message notification system. For log-type data such as sending records, choose to store it in a relational database, including MySQL and PostgreSQL, or store it in a file and clean it up regularly to prevent the data from growing continuously.

Images