Non-intrusive message queue fault proxy method based on service grid

Abstract

The invention discloses a non-intrusive message queue fault proxy method based on a service grid. The method comprises the following steps: hijacking flow of message sending of a micro-service through a message proxy component of a Sidecar; the message proxy component of the Sidecar transfers the message to a message proxy service or directly sends the message to a message queue; the failed messages are stored and orderly sent through a specific logic method of the message proxy service; and finally, all the messages when the message queue fails and after the failure is recovered are orderly sent to the message queue through the cooperative work of the message proxy component and the message proxy service in the Sidear. According to the method, the micro-service only needs to pay attention to core business logic and does not need to pay attention to a message sending result, and persistence and retransmission of failure messages of the whole distributed system are completed by combining a service grid with a message proxy service. The method is applied to the scene that the message is failed to be sent from the producer to the message queue, solves the problem of message sending failure and loss, and avoids the problem that service rollback is complex and time-consuming when the micro-service message is failed to be sent.

Description

Technical Field

[0001] The present invention belongs to the technical field of application software and artificial intelligence, and in particular relates to a non-intrusive message queue fault proxy method based on a service grid. Background Art

[0002] Message Queuing (MQ) is a communication mode for delivering messages between applications, usually for asynchronous communication. It plays an important role in distributed microservice architecture, such as decoupling services, asynchronous communication, peak load shaving and valley load filling, thereby improving the reliability and scalability of the system.

[0003] However, in some special cases, such as network failure, storage and other hardware resource failure, server failure, etc., MQ failure may occur, resulting in the failure of the producer to successfully deliver the message. In the business logic of the message production end, if the message fails to be sent, the message will be lost if it is not processed, which may lead to distributed state inconsistency. If the previous operation is rolled back after the message fails to be sent, the failure rate of business actions will increase, but the failure of some core businesses has a greater impact on the entire system; at the same time, for some operations involving hardware resources, rolling back is more complex and time-consuming. Therefore, improving the reliability of message delivery from the producer to MQ is crucial to the stability and reliability of the entire microservice system.

[0004] In a microservice architecture based on service mesh, business services only need to focus on business logic, while non-functional requirements such as service governance and service communication are met by the service mesh, such as load balancing, service discovery, monitoring and tracing, traffic management, fault management and other functions.

[0005] Currently, there is no solution for handling failed messages based on a service grid for message queue failures. Existing message proxy solutions have the following problems: 1. Most of them are intrusive proxy solutions, which require the perception of the result of sending messages to the message queue. 2. When a message queue fails, the switching of message sending directions is not agile, that is, after a queue fails, each message still needs to be sent to the message queue first, and then resent to the message proxy service after failure is detected. 3. The orderliness of messages cannot be guaranteed. After the failure is recovered, it cannot be guaranteed that the historical messages of the message proxy service will be sent to the message queue first before the new messages. Summary of the invention

[0006] To solve the problems in the prior art, one of the purposes of the present invention is to provide a non-intrusive message queue fault proxy method based on a service grid, which is characterized by comprising:

[0007] Hijack the message traffic sent by microservices through the Sidecar message proxy component;

[0008] The message broker component of Sidecar forwards the message to the message broker service or directly sends it to the message queue;

[0009] The failed messages are saved and sent in order through the message broker service-specific logic method;

[0010] The message proxy component in the Sidecar and the message proxy service work together to send all messages in order to the message queue when the message queue fails and after the failure is recovered.

[0011] Furthermore, the timing when the Sidecar message proxy component sends the message to the proxy service is as follows:

[0012] After the proxy component hijacks the traffic, it fails to resend the message to the message queue multiple times or the message queue maintained by the proxy component is in an unavailable state.

[0013] Furthermore, the data format characteristics sent to the message broker service include:

[0014] Timestamp with millisecond or higher precision, marking the time when the message was produced;

[0015] The source service name and message subject;

[0016] Original message.

[0017] Furthermore, the message proxy service message sending method includes:

[0018] The proxy service sends the message to the message queue by retrying and checks the status of the message queue;

[0019] After the failure is restored, the proxy service classifies the messages according to the message topics and sends the messages to the message queue in batches and in order according to the timestamps;

[0020] After the proxy service has sent all messages, it stops retrying.

[0021] Furthermore, the timing when the Sidecar message proxy component sends a message to the message queue includes:

[0022] After the Sidecar proxy component hijacked the traffic last time, it was able to successfully send the message to the message queue;

[0023] The Sidecar proxy component calls the proxy service to send a message, and through the return status, it recognizes that the fault has been restored and subsequent messages can be sent to the message queue.

[0024] Furthermore, the status returned by the proxy component when calling the message proxy service includes:

[0025] Queue status, indicating whether the next message can be sent directly to the message queue;

[0026] Message reception status, that is, whether the message sent to the proxy service is successfully saved or sent to the message queue.

[0027] Furthermore, the queue status returned by the message proxy service is True when the fault is recovered and the proxy service has no unsent messages, otherwise it is False.

[0028] Furthermore, the implementation logic or method of the message storage and forwarding process to the MQ in the proxy service can be directly embedded in the service in the form of service business logic in the SDK mode.

[0029] Furthermore, the workflow of the Sidecar message proxy component includes:

[0030] Step 1: Hijack the message traffic of the business service and add cache data; after identifying that the current egress traffic of the business service is the message traffic, obtain the message and add the message in the cache as the content of this transmission;

[0031] Step 2: Determine the sending direction based on the queue status object maintained by the proxy component; if the message queue is available, send the message directly to the message queue, otherwise send it to the proxy service;

[0032] Step 3: According to the execution result of step 2, update the MQ status and process the data; if sending to the message queue fails, update the MQ status to unavailable, and call the message proxy service to transfer the message; if the call to the message proxy service is successful, update the MQ status and process the data according to Table 1; if the call to the message proxy service fails, the message is stored in the cache.

[0033] Furthermore, the message proxy service workflow includes:

[0034] Step 1: Transfer the message to the message queue;

[0035] Step 2: Receive upstream messages and obtain cache data and MQ status;

[0036] Step 3: Process the current data based on the cache data, MQ status, and the number of unsent messages in the database;

[0037] Step 4: Return the specific status of the Sidecar proxy component based on the execution result of step 3 and the current database and cache data status;

[0038] If the upstream message in step 3 is successfully sent to the message queue and there is no data in the database and cache, MQOK is returned as True, otherwise it is False;

[0039] If the upstream message in step 3 is not successfully sent to the message queue and the message is not stored in the cache or database, return ACCEPT as False, otherwise return True.

[0040] Compared with the prior art, the present invention has the following beneficial effects:

[0041] (1) A non-intrusive proxy solution based on service grid. Microservices only need to focus on the core business logic without having to perceive the message sending results and the proxy process after the sending fails.

[0042] (2) The message proxy and the normal path to the message queue can switch quickly. When Sidecar detects a message queue failure, all subsequent messages are sent directly to the proxy service; after the failure is restored, the messages are sent to the message queue.

[0043] (3) A highly reliable message proxy solution that ensures message order. The order of messages is ensured through cache design, the cooperation between the Sidecar proxy component and the proxy service. After the fault is recovered, the Sidecar detects that all historical messages in the message proxy service have been sent to the message queue before sending new messages to the message queue. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] Figure 1 It is a schematic diagram of the relationship between the core components of the present invention;

[0045] Figure 2 The core process of the service grid proxy component of the present invention;

[0046] Figure 3 This is the core process of the message proxy service of the present invention. DETAILED DESCRIPTION

[0047] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0048] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art of the present invention. The terms used in the specification of the present invention herein are only for the purpose of describing specific embodiments and are not intended to limit the present invention.

[0049] The core components and component relationships of the message proxy method of the present invention are as follows:

[0050] The core components involved in the present invention include the proxy component in Sidecar and the proxy module in the proxy service; the proxy component in Sidecar is responsible for hijacking the traffic of the business service sending messages, obtaining the message queue status by calling the message queue or the proxy service, and deciding whether to send subsequent messages to the message queue or the proxy service. After receiving the message, the message proxy service saves the message persistently and sends the message to the message queue in a retry, batch, and orderly manner until all messages are sent.

[0051] The core work of the proxy component in the Sidecar of the present invention is:

[0052] 1. The proxy component in the Sidecar maintains a message queue state and decides whether to send the message to the proxy service or message queue based on the state.

[0053] 2. The proxy component in the Sidecar contains a cache to save messages that failed to be forwarded to the proxy service or temporary messages before the sending path is switched. For example, when the fault has been restored and the proxy service is sending messages in its own cache to the message queue, when the Sidecar proxy component calls the message proxy service, the message is not received. At this time, the message will be saved in the cache of the Sidecar proxy component and will be sent next time.

[0054] 3. The proxy component of the Sidecar returns two states when calling the proxy service, which determines whether the proxy component switches direction the next time it sends a message, as shown in Table 1:

[0055] Table 1 Proxy service return status and proxy component action description

[0056] MQOK (queue status) ACCEPT (whether this sending is successful) This action Subsequent sending direction True True / Message Queues False True / Agent Services False False cache Agent Services

[0057] The core work of the message proxy service proxy module of the present invention is:

[0058] 1. The message proxy service maintains a queue status to record message queue failures. It also maintains a cache to store messages sent by the Sidecar proxy component when failure recovery occurs but not all database messages are sent to the message queue.

[0059] 2. The message broker service will reflect two Boolean states of the upstream broker component:

[0060] ACCEPT: Returns True when the message sent by the proxy component in the Sidecar is successfully stored in the database or cache, or is directly sent to the message queue; otherwise, returns false.

[0061] MQOK: When the message sent by the proxy component in the Sidecar is sent directly to the message queue.

[0062] Example 1

[0063] like Figure 1 As shown, it is a component relationship diagram of a non-intrusive message queue fault proxy method based on a service grid in this embodiment, which is implemented as follows:

[0064] The proxy component in Sidecar is responsible for hijacking the traffic of business service messages. It obtains the message queue status by calling the message queue or proxy service, and decides whether to send subsequent messages to the message queue or the proxy service. After receiving the message, the message proxy service saves the message persistently and sends the message to the message queue in a retry, batch, and orderly manner until all messages are sent.

[0065] like Figure 2 As shown, the core workflow of the Sidecar proxy component of a non-intrusive message queue fault proxy method based on a service grid in this embodiment is implemented as follows:

[0066] Step 1: Hijack the business service message traffic and add cache data.

[0067] The proxy component in Sidecar recognizes that the current export traffic of the business service is message sending traffic, obtains the message, and adds the message in the cache as the content of this sending.

[0068] Step 2: Determine the sending direction based on the queue status object maintained by the proxy component.

[0069] If the message queue is available, the message is sent directly to the message queue, otherwise it is sent to the proxy service.

[0070] Step 3: Update the MQ status and process the data according to the execution result of step 2.

[0071] If sending to the message queue fails, update the MQ status to unavailable and call the message proxy service to transfer the message. If calling the message proxy service is successful, update the MQ status and process the data according to Table 1. If calling the message proxy service fails, the message is stored in the cache.

[0072] like Figure 3 As shown, the core workflow of the message proxy service proxy module of a non-intrusive message queue fault proxy method based on a service grid in this embodiment is implemented as follows:

[0073] Step 1: Transfer the message to the message queue.

[0074] The message broker service sends database (priority) and cached messages to the message queue in a retry, batch, and ordered manner. If the message is sent successfully, the MQ status is immediately updated to available.

[0075] Step 2: Receive upstream messages and obtain cache data and MQ status.

[0076] After receiving the message, the message broker service first identifies whether the MQ is in an available state and whether there is data in the cache.

[0077] Step 3: Process the current data based on the cache data, MQ status, and the number of unsent messages in the database. As shown in Table 2:

[0078] Table 2 Message broker service message processing description table

[0079] Serial number MQ Status Is there a cache? Does the database have data? This action 1 True True True Save to cache 2 True False True Save to cache 3 False True True This message + cache is migrated to the database 4 False False True Store in database 5 True True False / 6 True False False Send this message to the message queue 7 False True False This message + cache is migrated to the database 8 False False False Store in database

[0080] Among them, after the action shown in sequence number 6 fails, the data is saved to the database.

[0081] Step 4: Return the specific status of the Sidecar proxy component based on the execution result of step 3 and the current database and cache data status.

[0082] If the upstream message in step 3 is successfully sent to the message queue and there is no data in the database and cache, MQOK is returned as True, otherwise it is False.

[0083] If the upstream message in step 3 is not successfully sent to the message queue and the message is not stored in the cache or database, return ACCEPT as False, otherwise return True.

[0084] The technical features of the above-described embodiments may be arbitrarily combined. To make the description concise, not all possible combinations of the technical features in the above-described embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0085] The above-mentioned embodiments only express several implementation modes of the present invention, and the description thereof is relatively specific and detailed, but it cannot be understood as limiting the scope of the invention. It should be pointed out that, for a person of ordinary skill in the art, several modifications and improvements can be made without departing from the concept of the present invention, and these all belong to the protection scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the attached claims.

Claims

1. A non-intrusive message queue fault proxy method based on service grid, characterized in that: include: Hijack the message traffic sent by microservices through the Sidecar message proxy component; The message broker component of Sidecar forwards the message to the message broker service or directly sends it to the message queue; The failed messages are saved and sent in order through the message broker service-specific logic method; The message proxy component in the Sidecar and the message proxy service work together to send all messages in order to the message queue when the message queue fails and after the failure is recovered.

2. The non-intrusive message queue fault proxy method based on service grid as claimed in claim 1, characterized in that: The Sidecar message proxy component sends messages to the proxy service at the following times: After the proxy component hijacks the traffic, it fails to resend the message to the message queue multiple times or the message queue maintained by the proxy component is in an unavailable state.

3. The non-intrusive message queue fault proxy method based on service grid as claimed in claim 2, characterized in that: The format characteristics of data sent to the message broker service include: Timestamp with millisecond or higher precision, marking the time when the message was produced; The source service name and message subject; Original message.

4. The non-intrusive message queue fault proxy method based on service grid as claimed in claim 1, characterized in that: The message proxy service message sending method comprises: The proxy service sends the message to the message queue by retrying and checks the status of the message queue; After the failure is restored, the proxy service classifies the messages according to the message topics and sends the messages to the message queue in batches and in order according to the timestamps; After the proxy service has sent all messages, it stops retrying.

5. The non-intrusive message queue fault proxy method based on service grid as claimed in claim 1, characterized in that: The Sidecar message proxy component sends messages to the message queue when: After the Sidecar proxy component hijacked the traffic last time, it was able to successfully send the message to the message queue; The Sidecar proxy component calls the proxy service to send a message, and through the return status, it recognizes that the fault has been restored and subsequent messages can be sent to the message queue.

6. The non-intrusive message queue fault proxy method based on service grid as claimed in claim 5, characterized in that: The status returned by the proxy component when calling the message proxy service includes: Queue status, indicating whether the next message can be sent directly to the message queue; Message reception status, that is, whether the message sent to the proxy service is successfully saved or sent to the message queue.

7. The non-intrusive message queue fault proxy method based on service grid as claimed in claim 6, characterized in that: The queue status returned by the message broker service is True when the failure is recovered and the broker service has no unsent messages, otherwise it is False.

8. The non-intrusive message queue fault proxy method based on service grid as claimed in claim 1, characterized in that: The implementation logic or method of the message storage and forwarding to the MQ process in the proxy service can be directly embedded in the service in the form of service business logic in the SDK mode.

9. The non-intrusive message queue fault proxy method based on service grid as claimed in claim 1, characterized in that: The workflow of the Sidecar message proxy component includes: Step 1: Hijack the business service message traffic and add cache data: After identifying that the business service's current egress traffic is message traffic, obtain the message and add the cached message as the content of this transmission; Step 2: Determine the sending direction based on the queue status object maintained by the proxy component: if the message queue is in an available state, send the message directly to the message queue; otherwise, send it to the proxy service; Step 3: Update the MQ status and process the data according to the execution result of step 2: If sending to the message queue fails, update the MQ status to unavailable and call the message proxy service to transfer the message; if calling the message proxy service is successful, update the MQ status and process the data according to Table 1; if calling the message proxy service fails, the message is stored in the cache.

10. The non-intrusive message queue fault proxy method based on service grid as claimed in claim 9, characterized in that: The message proxy service workflow includes: Step 1: Transfer the message to the message queue; Step 2: Receive upstream messages and obtain cache data and MQ status; Step 3: Process the current data based on the cache data, MQ status, and the number of unsent messages in the database; Step 4: Return the specific status of the Sidecar proxy component based on the execution result of step 3 and the current database and cache data status; If the upstream message in step 3 is successfully sent to the message queue and there is no data in the database and cache, MQOK is returned as True, otherwise it is False; If the upstream message in step 3 is not successfully sent to the message queue and the message is not stored in the cache or database, return ACCEPT as False, otherwise return True.

Images