Consumer management system

Abstract

The invention discloses a consumer management system, and belongs to the technical field of middleware, the consumer management system comprises a console and a client, the console comprises a service management module, a communication module, a monitoring module, an identity authentication module and a current limiting module; the service management module is used for registering services, managing subscription relations of the services and grouping subscription records of the services according to consumer groups; the communication module is used for realizing communication between the console and the client; the monitoring module is used for monitoring the health condition and subscription relationship of the consumer group; the identity authentication module is used for authenticating the group identity; the flow limiting module is used for limiting user writing according to writing flow limitation in subscription configuration; and the client is used for interacting with the console. According to the system provided by the invention, the subscription relationship of the service is uniformly managed at the console, and when a developer directly modifies the subscription configuration of the service at the console, the client service can immediately and dynamically update the consumer information of all the nodes without restarting the service.

Description

Technical Field

[0001] The present invention relates to the technical field of middleware, and in particular to a consumer management system. Background Art

[0002] RocketMQ is an open source distributed messaging middleware developed by Alibaba, designed for trillion-level ultra-large-scale message processing. It occupies an important position in the messaging middleware field with its high throughput, low latency, massive accumulation and sequential sending and receiving. RocketMQ decouples producers and consumers through topics, realizes a flexible messaging mechanism, and is widely used in various business scenarios, such as order processing on e-commerce platforms and transaction settlement in financial systems.

[0003] RocketMQ mainly involves the following concepts: 1) Message, which is the most basic data unit in RocketMQ and can be any form of data, such as text, JSON or XML. Messages are sent and received asynchronously in RocketMQ, realizing decoupling and asynchronous communication between systems; 2) Topic, which is the basic unit of message classification and is used to distinguish different business messages. Producers send messages to specific topics, and consumers subscribe to topics to receive messages; 3) Tags, which is a mechanism for further classification of messages, provides more fine-grained message filtering and processing capabilities, so that consumers can subscribe to specific messages under topics according to specific business logic; 4) Message Key, which is the unique identifier of each message, used for indexing and querying during the message delivery process to ensure the accuracy and traceability of the message; 5) Group, which is used to isolate consumers and producers to implement different business logic and permission control; 6) Service ID, which is the unique identifier of each service, used to ensure that each service can be accurately identified and distinguished in the network and computing environment.

[0004] In JAVA applications, docking with RocketMQ usually involves steps such as introducing dependencies, creating producers and consumers, etc. By instantiating DefaultMQProducer and DefaultMQConsumer, setting relevant configuration information such as producer group name, consumer group name, subscribed topics and tags, and constructing Message objects to send and receive messages. This docking method enables JAVA applications to fully utilize RocketMQ's messaging mechanism to achieve efficient asynchronous communication and data exchange.

[0005] However, although RocketMQ provides a powerful messaging mechanism, there are some problems with using its client directly: 1) Subscription configuration management is inconvenient. Specifying subscription configuration in configuration files or code makes it difficult to manage subscription configuration in a unified manner in the case of multiple services; 2) Single permission control. The RocketMQ native client only supports global permission control and cannot meet the needs of fine-grained permission management; 3) No support for rate limiting. In the case of a surge in message volume, directly using the RocketMQ client may cause system overload or crash; 4) Configuration updates are difficult. Updating consumer configuration requires changing the subscription relationship in the code or configuration and restarting the service, which not only increases operation and maintenance costs, but may also affect the availability and stability of the system.

[0006] In summary, although using the RocketMQ client directly can achieve basic messaging functions, it still has shortcomings in subscription configuration management, permission control, current limiting, and configuration updates, and urgently needs improvement. Summary of the invention

[0007] The purpose of the present invention is to provide a consumer management system to solve the problems of inconvenient subscription configuration management, single authority control, no support for current limiting, and configuration update requiring service restart brought about by directly using RocketMQ client in the prior art.

[0008] To achieve the above objectives, this application adopts the following technical solutions:

[0009] A consumer management system of the present application, the system comprises a console and a client, wherein the console comprises a service management module, a communication module, a monitoring module, an identity authentication module and a current limiting module;

[0010] The service management module is used to register services, manage service subscription relationships, and group service subscription records according to consumer groups;

[0011] The communication module is used to realize the communication between the console and the client, and to issue subscription configuration, issue instructions and report heartbeat information through the fixed message topic built into the message queue;

[0012] The monitoring module is used to monitor the health status and subscription relationship of consumer groups, and to display all consumer groups and online consumer instances in an interface;

[0013] The identity authentication module is used to authenticate the group identity and return a key used to encrypt and verify the authentication string;

[0014] The flow limiting module is used to limit user writing according to the write flow limit in the subscription configuration;

[0015] The client is used to interact with the console to achieve automatic subscription, heartbeat reporting, command issuance, identity authentication and write current limiting.

[0016] Preferably, the service management module comprises:

[0017] A service registration unit, used to receive a service name, service identifier, and optional service description input by a developer to complete service registration, and to perform uniqueness verification on the service identifier;

[0018] The subscription management unit is used to receive and store the service subscription relationship configured by the developer, wherein the service subscription relationship includes the service identifier, message topic, message tag, group, write traffic limit and identity authentication.

[0019] Preferably, the fixed message topic includes a first message topic for subscription relationship interaction, a second message topic for issuing operation instructions, and a third message topic for receiving heartbeat information.

[0020] Preferably, the operation instructions include a consumption pause instruction and a consumption resume instruction.

[0021] Preferably, when performing the monitoring function, the monitoring module comprises the following steps:

[0022] Determine whether a heartbeat message sent by the client through the third message topic is received within a preset time, where the message tag in the third message topic is the corresponding consumer group;

[0023] If heartbeat information is received, the heartbeat information of each consumer group is parsed to obtain the IP and subscription relationship of the online consumer instance;

[0024] If no heartbeat information is received, the client is automatically determined to be in an offline state;

[0025] The interface displays the IP and subscription relationships of all consumer groups and their online consumer instances.

[0026] Preferably, when performing identity authentication, the identity authentication module comprises the following steps:

[0027] receiving an authentication request from a client, the authentication request carrying a group identifier, request content, and a first signature, where the first signature is obtained by encrypting the request content using the key;

[0028] Searching for a corresponding key in the subscription management unit according to the group identifier, and if found, encrypting the request content using the found key to obtain a second signature;

[0029] Compare the first signature and the second signature to see if they are the same. If they are the same, the group identity authentication passes; otherwise, it fails.

[0030] Preferably, when the current limiting module performs current limiting, the following steps are included:

[0031] Receive a message writing request including a group identifier sent by a client;

[0032] Searching for a corresponding flow limiting configuration in the subscription management unit according to the group identifier, and if found, counting the accumulated flow according to the sliding window algorithm;

[0033] When the accumulated traffic is greater than the current limiting threshold, the message writing request is rejected.

[0034] Preferably, the sliding window algorithm comprises the following steps:

[0035] Divide the fixed time into several time periods. At the end of each time period, record the number of message write requests received by the current service, and calculate the cumulative number of requests to determine whether it exceeds the current limiting threshold.

[0036] Preferably, the client comprises:

[0037] An initialization unit, used to call the init(Prop prop) method of the AbstractConsume interface for initialization, wherein the initialization process includes starting the heartbeat reporting scheduler, creating a built-in message producer, a built-in subscription configuration consumer, and a built-in instruction consumer;

[0038] Message processing unit, used to use consumeMsg(List <messageext>list) method to process the messages received from the specified message topic;

[0039] The message sending unit is used to call the ProducerClient class to encapsulate the message writing process to send the message to the specified message topic, and perform identity authentication and current limit verification before writing the message.

[0040] Preferably, the Prop parameters include a service identifier, a message queue NameServer address, and a group name.

[0041] This application has the following beneficial effects:

[0042] The consumer management system provided in this application manages the subscription relationship of services in a unified manner in the console. When the developer directly modifies the subscription configuration of the service in the console, the client service can dynamically update the consumer information of all nodes in real time without restarting the service. After the consumer initialization is completed, in addition to stopping the project process, you can also choose to pause the service, thereby realizing the start and stop control of consumer consumption. At the same time, the client also encapsulates the initialization logic of consumers and producers, making the application side code more concise. In addition, it also realizes the monitoring of group instances, producer current limiting and more fine-grained permission control, thereby improving the user experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0044] Figure 1 It is a structural diagram of a consumer management system provided by an embodiment of the present application;

[0045] Figure 2 It is a structural diagram of the service management module in an embodiment of the present application;

[0046] Figure 3 is a heartbeat information analysis flow chart provided in an embodiment of the present application;

[0047] Figure 4 It is an identity authentication flow chart provided in an embodiment of the present application;

[0048] Figure 5 is a write request restriction flow chart provided in an embodiment of the present application;

[0049] Figure 6 This is an example diagram of interaction when the client initializes a message in an embodiment of the present application. DETAILED DESCRIPTION

[0050] To make the technical solution of the present application clearer, the present invention is further described in detail below in conjunction with the accompanying drawings and specific embodiments. The terms "first", "second", etc. in the claims and specification of the present application are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the terms used in this way can be interchangeable under appropriate circumstances. This is only to describe the distinction method used when describing objects with the same attributes in the embodiments of the present application. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, so that a process, method, system, product or device containing a series of units is not necessarily limited to those units, but may include other units that are not clearly listed or inherent to these processes, methods, products or devices.

[0051] like Figure 1 As shown, the present application provides a consumer management system, which includes a console and a client, wherein the console includes a service management module, a communication module, a monitoring module, an identity authentication module and a current limiting module.

[0052] Specifically, the service management module is used to register services, manage service subscription relationships, and group service subscription records according to consumer groups.

[0053] In some embodiments, Figure 2 As shown, the service management module includes:

[0054] The service registration unit is used to receive the service name, service ID and optional service description input by the developer to complete the service registration, and to verify the uniqueness of the service ID;

[0055] The subscription management unit is used to receive and store the service subscription relationships configured by developers. The service subscription relationships include service identifiers, message topics, message tags, groups, write traffic limits, and identity authentication.

[0056] The service management module is mainly responsible for connecting with developers to realize service registration and maintenance of service subscription relationships. Furthermore, the service management module includes a service registration unit and a subscription management unit. Developers enter the service name and service identifier, namely, service ID, in the service registration unit through the input box. They can also optionally enter the service description. Because the service description is not a required item when registering a service, developers can choose to fill it in or not according to actual needs. At the same time, after receiving the service ID entered by the developer, the service registration unit will perform a uniqueness check on the service ID. For example, when the developer registers service A, the service ID entered is "ServiceA". After receiving the service ID, the service registration unit will immediately determine whether the service ID is unique, that is, whether there is a service with the same ID in the successfully registered services. If so, the service ID already exists and is not unique. In this case, the input box will prompt a duplicate and refuse to create service A. Through this method, the uniqueness of the service ID can be guaranteed, which helps to maintain the accuracy of the subscription relationship.

[0057] Developers will also sort out the subscription relationship of the service according to the system business they are responsible for, and then configure the subscription in the subscription management unit. The configured subscription relationship mainly includes service ID, message topic, message tag, group, write traffic limit and identity authentication. The service ID here is obtained by selecting using the drop-down box, and its value range is the ID of all services that have been successfully registered in the service registration unit. The message tag is also optional, that is, the developer can not specify a specific tag under the subscription message topic, so that all information under the message topic is subscribed. The group can refer to the consumer group ID that receives the message or the producer group ID that produces the message. The producer is the creator and provider of the service, who is responsible for designing and implementing the service to ensure that it meets the needs and expectations of consumers. Consumers are the purchasers and users of the service and they can customize the service according to their needs. The sum expectation chooses to subscribe to the corresponding service. At the same time, one service can correspond to multiple subscription records. In different subscription relationships, the generator and the consumer can be converted to each other. Therefore, the group here is a consumer group or a producer group. However, it should be noted that when different services use the same group as a consumer, their subscription relationships must be the same. Without message tags, they must subscribe to the same message topic. With message tags, the message topics and message tags they subscribe to must be the same. Write traffic limit and identity authentication are also optional. Among them, write traffic limit is used to limit the user's write request traffic. When it is decided to limit the write traffic, a flow limit threshold will be set. Identity authentication is used to authenticate the group identity. The specific operation process is completed by the flow limit module and the identity authentication module. Here we only decide whether to limit the write traffic and whether to enable identity authentication.

[0058] After all configurations are completed, the console will group the subscription records of the service according to the consumer group. Each consumer group corresponds to one or more consumer instances.

[0059] Specifically, the communication module is used to realize the communication between the console and the client, and to issue subscription configurations, issue instructions, and report heartbeat information through the fixed message topics built into the message queue.

[0060] In some embodiments, the fixed message topics include a first message topic for subscription relationship interaction, a second message topic for issuing operation instructions, and a third message topic for receiving heartbeat information.

[0061] The communication module uses a message queue to implement communication between the console and the client. The message queue has multiple different fixed message topics built in, and each fixed message topic corresponds to one or more messages. Preferably, the fixed message topics include a message topic named %CONSOLE_SERVICE_SUB% for subscription relationship interaction, i.e., a first message topic, a message topic named %CONSOLE_COMMAND% for issuing operation instructions, i.e., a second message topic, and a message topic named %CONSOLE_HEART% for receiving heartbeat information, i.e., a third message topic. Among them, the %CONSOLE_SERVICE_SUB% message topic has two functions, one is for the client to notify the console to issue the subscription configuration, and the other is for the console to issue the latest subscription configuration, which specifically corresponds to two different message tags under one message topic. For example, the client needs the subscription configuration of the console when initializing, so it will actively notify the console to issue the subscription configuration, that is, send a message to the %CONSOLE_SERVICE_SUB% message topic, and the message tag is "CONSOLE_N "OTIFY", the message body is the service ID, and "CONSOLE_NOTIFY" here is a special business tag. Marking this tag means notifying the console to issue the subscription configuration; when the console issues the subscription configuration to the client, it also sends a message to the %CONSOLE_SERVICE_SUB% message topic. The message tag is the service ID involved, and the message body is the subscription configuration content; developers can also issue a pause consumption instruction or a resume consumption instruction to the corresponding service in the console. At this time, the console will send a message to the %CONSOLE_COMMAND% message topic. The message tag is the service ID involved, and the message body is the operation instruction information to be executed, that is, the pause consumption instruction or the resume consumption instruction. After receiving the corresponding instruction, the client will suspend or resume consumption for the initialized consumer instance; when the client sends a heartbeat message to the console, it will send a message to the %CONSOLE_HEART% message topic. The message tag is the consumer group involved, and the consumer body is the client IP and subscription relationship. Among them, the subscription relationship is sent when the subscription configuration is initialized or changed.

[0062] Specifically, the monitoring module is used to monitor the health status and subscription relationships of consumer groups, and to display all consumer groups and online consumer instances in an interface.

[0063] In some embodiments, Figure 3 As shown, when the monitoring module performs the monitoring function, the following steps are included:

[0064] Determine whether a heartbeat message sent by the client through a third message topic is received within a preset time, where the message tag in the third message topic is the corresponding consumer group;

[0065] If heartbeat information is received, the heartbeat information of each consumer group is parsed to obtain the IP and subscription relationship of the online consumer instance;

[0066] If no heartbeat information is received, the client is automatically determined to be offline;

[0067] The interface displays the IP and subscription relationships of all consumer groups and their online consumer instances.

[0068] After the client is successfully initialized, it periodically sends heartbeat information to the corresponding built-in fixed message topic named %CONSOLE_HEART%, which is the fourth message topic, and uses the corresponding consumer group name as the message tag. The monitoring module determines whether it has received the heartbeat information sent by the client through the fourth message topic within the preset time. If so, it is assumed that all consumer instances under the consumer group are online, and the heartbeat information corresponding to each consumer group is parsed to obtain the IP and subscription relationship of the online consumer instance. If the heartbeat information is not received within the preset time, it is automatically determined that the client has been disconnected and is in an offline state. It should be noted here that the health status actually refers to the online status. Online means healthy, and offline means unhealthy. Then all consumer groups and the IP and subscription relationship of the corresponding online consumer instances are displayed on the interface.

[0069] Specifically, the identity authentication module is used to authenticate the group identity and return a key used to encrypt and verify the authentication string.

[0070] In some embodiments, Figure 4 As shown, when the identity authentication module performs identity authentication, the following steps are included:

[0071] Receiving an authentication request from a client, the authentication request carrying a group identifier, request content, and a first signature, where the first signature is obtained by encrypting the request content using the key;

[0072] Searching for a corresponding key in the subscription management unit according to the group identifier, and if found, encrypting the request content using the key found to obtain a second signature;

[0073] Compare the first signature and the second signature to see if they are the same. If they are the same, the group identity authentication passes, otherwise it fails.

[0074] When the developer sets the authentication of the group in the subscription configuration, the authentication of the group can be enabled in the authentication module. After the authentication is enabled, a key SecretKey will be returned. The key is used to encrypt the authentication string and verify the authentication string. After the authentication is enabled, both the subscription message request and the message writing request will be authenticated. The specific process is: when the client initiates a subscription or message writing request containing the group identifier GroupId, if the subscription or writing request carries the SecretKey, the client will use the SecretKey to encrypt the request content according to the preset signature algorithm to obtain the first signature Signature, and then concatenate the request content and the Signature to obtain the authentication request and send the authentication request to the console. After receiving the authentication request, the console will first search for the corresponding SecretKey in the subscription management unit according to the GroupId in the request content. If the corresponding SecretKey is not found, it means that the authentication is not enabled and it is executed normally. If the corresponding SecretKey is found, the request content is encrypted again according to the preset signature algorithm using the found SecretKey to obtain the second signature. The first signature and the second signature are compared. If they are consistent, it means that the group authentication is passed, otherwise it means that it is not passed.

[0075] This embodiment provides a more fine-grained group-level permission authentication to ensure data security.

[0076] Specifically, the flow limiting module is used to limit user writing according to the write flow limit in the subscription configuration.

[0077] In some embodiments, Figure 5 As shown, when the current limiting module performs current limiting, the following steps are included:

[0078] Receive a message writing request including a group identifier sent by a client;

[0079] Search the subscription management unit for the corresponding flow limiting configuration based on the group ID. If found, the accumulated flow is counted based on the sliding window algorithm.

[0080] When the accumulated traffic is greater than the current limiting threshold, the message writing request is rejected.

[0081] The client initiates a write request, which carries a group identifier GroupId. The console receives the message write request sent by the client, extracts the GroupId contained therein, and searches the subscription management unit for the GroupId to see if there is a current limiting configuration. If not, the message write process is executed normally. If so, the traffic is counted according to the sliding window algorithm, wherein the specific steps of the sliding window algorithm are: dividing a fixed time into several time periods, recording the number of message write requests received by the current service at the end of each time period, and calculating the cumulative number of requests to determine whether it exceeds the current limiting threshold. Preferably, in this embodiment, 1 second is divided into 4 segments, each grid is 250 milliseconds, and moves once every 250 milliseconds. Each movement records the number of requests received by the current service within these 250ms, and always maintains 4 segments. As the movement progresses, the front segment is deleted in turn, and all segments are looped. If the accumulated count value is greater than the current limiting threshold, the message write request is rejected, otherwise it is executed normally.

[0082] Specifically, the client is used to interact with the console to implement automatic subscription, heartbeat reporting, command issuance, identity authentication, and write current limiting.

[0083] In some embodiments, Figure 6 As shown, the client includes:

[0084] The initialization unit is used to call the init(Prop prop) method of the AbstractConsume interface for initialization. The initialization process includes starting the heartbeat reporting scheduler, creating a built-in message producer, a built-in subscription configuration consumer, and a built-in instruction consumer;

[0085] Message processing unit, used to use consumeMsg(List <messageext>list) method to process the messages received from the specified message topic;

[0086] The message sending unit is used to call the ProducerClient class to encapsulate the message writing process to send the message to the specified message topic, and perform identity authentication and current limit verification before writing the message.

[0087] The client interacts with the console, mainly including an initialization unit, a message processing unit and a message sending unit. The initialization unit implements the AbstractConsume interface and calls the init(Propprop) method of the AbstractConsume interface for initialization. The init(Prop prop) method of the AbstractConsume interface is mainly used to initialize the client. In this process, the method reads and parses the configuration properties in the passed Prop object, and then configures and sets various parameters and behaviors of the client according to these properties. In this embodiment, the initialization step specifically includes:

[0088] A. Initialize the built-in message producer for communication with the console;

[0089] B. Initialize the built-in subscription configuration consumer, which subscribes to the configuration message under the CONSOLE_SERVICE_SUB message topic, receives the subscription configuration sent by the console, and generates a specific business consumer instance based on the configuration;

[0090] C. Initialize the built-in command consumer, which subscribes to the command message under the %CONSOLE_COMMAND% message topic to receive the operation command issued by the console, namely, the pause consumption command and the start consumption command;

[0091] D. Use the built-in message producer to notify the console to send the configuration. After the configuration is sent, the subscription configuration consumer in B will receive the subscription configuration information sent by the console and consume it;

[0092] E. Enable the heartbeat reporting scheduler to perform periodic heartbeat reporting.

[0093] Among them, the Prop parameter includes necessary items such as service identifier, message queue NameServer address and group name, and also includes non-essential items such as consumption mode, consumption starting point, concurrent consumption / sequential consumption, number of callback thread pool threads and key. The specific attribute list is shown in Table 1. Among them, the message queue NameServer address refers to the network address of the NameServer component in the message queue system, which is used for the client or other service components to communicate with the NameServer. This embodiment realizes the automatic reading of subscription configuration and reduces the complexity of business code.

[0094] Table 1 Prop parameter attribute list

[0095] The message receiving unit implements consumeMsg(List <messageext>list) method, consumeMsg(List <messageext>The consumeMsg(List) method is usually used to consume messages, that is, to receive and process messages from the message queue as a consumer. This method will traverse the incoming message list and process each message, which may include decoding, parsing, executing business logic, etc. In this embodiment, consumeMsg(List) is used. <messageext>list) method to process the messages received by specifying the message topic, where the Message parameter includes necessary items such as service ID, message queue nameServer address, group name, message topic, and message body, as well as non-essential items such as keys and message tags. The specific attribute list is shown in Table 2.

[0096] Table 2 Message parameter attribute list

[0097] The message sending unit calls the ProducerClient class to encapsulate the message writing process and sends the encapsulated message to the specified message topic. The ProducerClient class is usually used to send messages, that is, as a producer, it delivers messages to the message queue. It encapsulates the underlying details of interacting with the message queue system and provides a simple interface for users to send messages. In this embodiment, the encapsulated message is sent to the specified message topic of the console, and before the message is written, it is determined whether identity authentication and write current limiting are enabled. If identity authentication is enabled, the client will generate a signature and complete the comparison in the console. If write current limiting is enabled, it is checked whether the accumulated traffic exceeds the current limiting threshold.

[0098] The consumer management system provided in this application manages the subscription relationship of services in a unified manner in the console. When the developer directly modifies the subscription configuration of the service in the console, the client service can dynamically update the consumer information of all nodes in real time without restarting the service. After the consumer initialization is completed, in addition to stopping the project process, you can also choose to pause the service, thereby realizing the start and stop control of consumer consumption. At the same time, the client also encapsulates the initialization logic of consumers and producers, making the application side code more concise. In addition, it also realizes the monitoring of group instances, producer current limiting and more fine-grained permission control, thereby improving the user experience.

[0099] The above-mentioned embodiments only express several implementation methods of the present invention, and the description thereof is relatively specific and detailed, but it cannot be understood as limiting the scope of the patent of the present invention. It should be pointed out that, for ordinary technicians in this field, several variations and improvements can be made without departing from the concept of the present invention, which all belong to the protection scope of the present invention. Therefore, the protection scope of the patent of the present invention shall be subject to the attached claims.< / messageext> < / messageext> < / messageext> < / messageext> < / messageext>

Claims

1. A consumer management system, characterized in that: The system includes a console and a client, wherein the console includes a service management module, a communication module, a monitoring module, an identity authentication module and a current limiting module; The service management module is used to register services, manage service subscription relationships, and group service subscription records according to consumer groups; The communication module is used to realize the communication between the console and the client, and to issue subscription configuration, issue instructions and report heartbeat information through the fixed message topic built into the message queue; The monitoring module is used to monitor the health status and subscription relationship of consumer groups, and to display all consumer groups and online consumer instances in an interface; The identity authentication module is used to authenticate the group identity and return a key used to encrypt and verify the authentication string; The flow limiting module is used to limit user writing according to the write flow limit in the subscription configuration; The client is used to interact with the console to achieve automatic subscription, heartbeat reporting, command issuance, identity authentication and write current limiting.

2. A consumer management system according to claim 1, characterized in that: The service management module includes: A service registration unit, used to receive a service name, service identifier, and optional service description input by a developer to complete service registration, and to perform uniqueness verification on the service identifier; The subscription management unit is used to receive and store the service subscription relationship configured by the developer, wherein the service subscription relationship includes the service identifier, message topic, message tag, group, write traffic limit and identity authentication.

3. A consumer management system according to claim 1, characterized in that: The fixed message topics include a first message topic for subscription relationship interaction, a second message topic for issuing operation instructions, and a third message topic for receiving heartbeat information.

4. A consumer management system according to claim 3, characterized in that: The operation instructions include a consumption pause instruction and a consumption resume instruction.

5. A consumer management system according to claim 4, characterized in that: When the monitoring module performs the monitoring function, the following steps are included: Determine whether a heartbeat message sent by the client through the third message topic is received within a preset time, where the message tag in the third message topic is the corresponding consumer group; If heartbeat information is received, the heartbeat information of each consumer group is parsed to obtain the IP and subscription relationship of the online consumer instance; If no heartbeat information is received, the client is automatically determined to be in an offline state; The interface displays the IP and subscription relationships of all consumer groups and their online consumer instances.

6. A consumer management system according to claim 1, characterized in that: When performing identity authentication, the identity authentication module includes the following steps: receiving an authentication request from a client, the authentication request carrying a group identifier, request content, and a first signature, where the first signature is obtained by encrypting the request content using the key; Searching for a corresponding key in the subscription management unit according to the group identifier, and if found, encrypting the request content using the found key to obtain a second signature; Compare the first signature and the second signature to see if they are the same. If they are the same, the group identity authentication passes; otherwise, it fails.

7. A consumer management system according to claim 1, characterized in that: When the current limiting module performs current limiting, the following steps are included: Receive a message writing request including a group identifier sent by a client; Searching for a corresponding flow limiting configuration in the subscription management unit according to the group identifier, and if found, counting the accumulated flow according to the sliding window algorithm; When the accumulated traffic is greater than the current limiting threshold, the message writing request is rejected.

8. A consumer management system according to claim 7, characterized in that: The sliding window algorithm comprises the following steps: Divide the fixed time into several time periods. At the end of each time period, record the number of message write requests received by the current service, and calculate the cumulative number of requests to determine whether it exceeds the current limiting threshold.

9. A consumer management system according to claim 1, characterized in that: The client comprises: An initialization unit, used to call the init(Prop prop) method of the AbstractConsume interface for initialization, wherein the initialization process includes starting the heartbeat reporting scheduler, creating a built-in message producer, a built-in subscription configuration consumer, and a built-in instruction consumer; Message processing unit, used to use consumeMsg(List <messageext> list) method to process the messages received from the specified message topic;< / messageext> The message sending unit is used to call the ProducerClient class to encapsulate the message writing process to send the message to the specified message topic, and perform identity authentication and current limit verification before writing the message.

10. A consumer management system according to claim 9, characterized in that: The Prop parameters include a service identifier, a message queue NameServer address, and a group name.

Images