Method, device and system for processing data consistency among micro-services

Abstract

The invention discloses a data consistency processing method, device and system between micro-services. The method comprises the following steps: splicing a message with a corresponding queue name to obtain a message byte string; calling an API (Application Program Interface), and sending the message byte string to a message table; the message platform is the micro service obtained by packaging the MQ; when a message confirmation identifier returned by the message middle station is received, judging whether the message byte string is successfully sent or not according to the message confirmation identifier; and if yes, writing back the message confirmation identifier to the database. According to the method, the MQ and the self-defined message confirmation identifier are jointly packaged into a micro-service to serve as a message middle table, the independent micro-service is called through an API, a message confirmation mechanism of the MQ is not used, the self-defined message confirmation identifier is used, the number of steps of a call chain is reduced, call chain logic is simplified, response is more timely, and the service quality is improved. According to the method, data loss is avoided, micro-service data consistency is guaranteed, accumulation and consumption capacity of a large number of service messages is achieved, low delay and high throughput are achieved, and high concurrency is supported.

Description

Technical Field

[0001] The present application relates to a method, device and system for processing data consistency between microservices. Background Art

[0002] In the distributed microservice architecture project, when using RabbitMQ (hereinafter referred to as MQ) to transmit data, the MQ code and business code are mixed together and highly coupled. After the message is sent to MQ, the message confirmation mechanism (Acknowledgement, ack) provided by MQ may have a message return delay or even no message return due to data and network reasons. When the callback (ConfirmCallback) function receives the message confirmation mechanism to return a success mark, it will write back to the database. Since the message confirmation mechanism provided by MQ has a message return delay or even no message return, the data cannot be written back, resulting in data loss. According to statistics, the amount of data lost in the project is about 0.02%. Summary of the invention

[0003] In order to better ensure the consistency of data between microservices, the embodiments of the present application provide a method, device and system for processing data consistency between microservices.

[0004] In a first aspect, an embodiment of the present application provides a method for processing data consistency between microservices, which is applied to a message producer. The method includes:

[0005] Concatenate the message with the corresponding queue name to get the message byte string;

[0006] Call the API interface to send the message byte string to the message middle station; the message middle station is a microservice obtained by encapsulating MQ;

[0007] When receiving the message confirmation identifier returned by the message center, judging whether the message byte string is sent successfully according to the message confirmation identifier;

[0008] If so, the message confirmation identifier is written back to the database.

[0009] In an optional implementation of the embodiment of the present application, when receiving the message confirmation identifier returned by the message center, judging whether the message byte string is sent successfully according to the message confirmation identifier includes:

[0010] When receiving the message confirmation identifier returned by the message center, determining whether the message confirmation identifier is a preset identifier;

[0011] If yes, the message byte string is sent successfully;

[0012] If not, the message byte string fails to be sent.

[0013] In an optional implementation manner of the embodiment of the present application, after the message byte string fails to be sent, the method further includes:

[0014] Resend the message byte string to the message center until the message byte string is successfully sent or reaches a preset number of sending times.

[0015] In a second aspect, an embodiment of the present application provides a method for processing data consistency between microservices, which is applied to a message middle station. The method includes:

[0016] When receiving a message byte string sent by a message producer, a message confirmation identifier is returned to the message producer through an API interface; the message byte string includes the message and the corresponding queue name;

[0017] According to a preset algorithm, routing the message byte string to a message queue switch based on producer load balancing;

[0018] According to the queue name in the message byte string, the message in the message byte string is routed to the corresponding queue through the message queue switch.

[0019] In an optional implementation of the embodiment of the present application, it also includes:

[0020] When a failure occurs in the message middle station, the message byte string is temporarily stored in a preset manner until the message middle station returns to normal, and the message byte string is restored to the message middle station.

[0021] In a third aspect, an embodiment of the present application provides a method for processing data consistency between microservices, the method comprising:

[0022] The message producer concatenates the message with the corresponding queue name to obtain a message byte string;

[0023] The message producer calls the API interface to send the message byte string to the message middle station;

[0024] The message center receives the message byte string and returns a message confirmation identifier to the message producer through an API interface;

[0025] When the message producer receives the message confirmation identifier, it determines whether the message byte string is sent successfully according to the message confirmation identifier;

[0026] If so, the message producer writes the message confirmation identifier back to the database.

[0027] In a fourth aspect, an embodiment of the present application provides a device for processing data consistency between microservices, which is applied to a message producer, and the device includes:

[0028] The concatenation module is used to concatenate the message with the corresponding queue name to obtain a message byte string;

[0029] A sending module is used to call the API interface and send the message byte string to the message center;

[0030] A judgment module, configured to judge whether the message byte string is sent successfully according to the message confirmation identifier returned by the message center when receiving the message confirmation identifier;

[0031] The write-back module is used to write the message confirmation mark back to the database if the message byte string is sent successfully.

[0032] In a fifth aspect, an embodiment of the present application provides a device for processing data consistency between microservices, which is applied to a message middle station, and the device includes:

[0033] A receiving module, configured to return a message confirmation identifier to the message producer through an API interface upon receiving a message byte string sent by the message producer; the message byte string includes the message and the corresponding queue name;

[0034] A routing module, configured to route the message byte string to a message queue switch based on producer load balancing according to a preset algorithm;

[0035] The switching module is used to route the message in the message byte string to the corresponding queue through the message queue switch according to the queue name in the message byte string.

[0036] In a sixth aspect, an embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the data consistency processing method between microservices as described above.

[0037] In a seventh aspect, an embodiment of the present application provides a computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the method for processing data consistency between microservices as described above is implemented.

[0038] In an eighth aspect, an embodiment of the present application provides a computer program product comprising instructions, which, when the computer program product is run on a computer device, enables the computer device to execute the data consistency processing method between microservices as described above.

[0039] In a ninth aspect, an embodiment of the present application provides a chip, the chip including a processor and a communication interface, the communication interface and the processor are coupled, and the processor is used to run a computer program or instruction to implement the data consistency processing method between microservices as described above.

[0040] In a tenth aspect, an embodiment of the present application provides a system for processing data consistency between microservices, the system comprising:

[0041] The message producer is used to concatenate the message with the corresponding queue name to obtain a message byte string; call the API interface to send the message byte string to the message middle station; when receiving the message confirmation identifier returned by the message middle station, determine whether the message byte string is sent successfully according to the message confirmation identifier; and if so, write the message confirmation identifier back to the database;

[0042] The message middle station is used to return a message confirmation identifier to the message producer through an API interface when a message byte string sent by a message producer is received; the message byte string includes a message and a corresponding queue name; according to a preset algorithm, the message byte string is routed to a message queue switch based on producer load balancing; and according to the queue name in the message byte string, the message in the message byte string is routed to the corresponding queue through the message queue switch.

[0043] The beneficial effects of the above technical solution provided by the embodiment of the present application include at least:

[0044] The data consistency processing method between microservices provided in the embodiment of the present application sends the message and the corresponding queue name to the message middle station by calling the API interface, and then judges whether the message is sent successfully according to the message confirmation identifier returned by the message middle station, and writes back to the database in time. In this method, MQ and the custom message confirmation identifier are encapsulated together into a microservice as a message middle station, and an independent microservice is called through an API. The message confirmation mechanism (ack) provided by MQ is not used, and a custom message confirmation identifier is used to reduce the call chain steps, simplify the call chain logic, and respond more promptly, ensuring that data is not lost and the consistency of microservice data; it realizes the decoupling and separation of business, high reliability and persistence of messages, high performance, high real-time performance, high stability, and high scalability; it realizes the accumulation and consumption capacity of a large number of business messages, low latency and high throughput, and supports high concurrency.

[0045] Other features and advantages of the present application will be described in the following description, and partly become apparent from the description, or be understood by practicing the present application. The purpose and other advantages of the present application can be realized and obtained by the structures specifically pointed out in the written description, claims, and drawings.

[0046] The technical solution of the present application is further described in detail below through the accompanying drawings and embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] The accompanying drawings are used to provide a further understanding of the present application and constitute a part of the specification. Together with the embodiments of the present application, they are used to explain the present application and do not constitute a limitation of the present application. In the accompanying drawings:

[0048] Figure 1 A schematic diagram of the steps of applying the data consistency processing method between microservices provided in an embodiment of the present application to a message producer;

[0049] Figure 2 A schematic diagram of the steps of applying the data consistency processing method between microservices provided in an embodiment of the present application to the message middle station;

[0050] Figure 3 A schematic diagram of the steps of the method for processing data consistency between microservices provided in an embodiment of the present application;

[0051] Figure 4 A schematic diagram of the process of message transmission between microservices provided in an embodiment of the present application;

[0052] Figure 5 A schematic diagram of the structure of a device for processing data consistency between microservices of a message producer provided in an embodiment of the present application;

[0053] Figure 6 A schematic diagram of the structure of a device for processing data consistency between microservices applied to a message middle station provided in an embodiment of the present application;

[0054] Figure 7 A schematic diagram of the structure of a data consistency processing system between microservices provided in an embodiment of the present application. DETAILED DESCRIPTION

[0055] In the following description, specific details such as specific system structures, technologies, etc. are provided for the purpose of illustration rather than limitation, so as to provide a thorough understanding of the embodiments of the present application. However, it should be clear to those skilled in the art that the present application may also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to prevent unnecessary details from obstructing the description of the present application.

[0056] It should be understood that when used in the present specification and the appended claims, the term "comprising" indicates the presence of described features, integers, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or combinations thereof.

[0057] It should also be understood that the term “and / or” used in the specification and appended claims refers to any and all possible combinations of one or more of the associated listed items, and includes these combinations.

[0058] As used in the specification and appended claims of this application, the term "if" can be interpreted as "when" or "uponce" or "in response to determining" or "in response to detecting", depending on the context. Similarly, the phrase "if it is determined" or "if [described condition or event] is detected" can be interpreted as meaning "uponce it is determined" or "in response to determining" or "uponce [described condition or event] is detected" or "in response to detecting [described condition or event]", depending on the context.

[0059] In addition, in the description of the present application specification and the appended claims, the terms "first", "second", "third", etc. are only used to distinguish the descriptions and cannot be understood as indicating or implying relative importance.

[0060] References to "one embodiment" or "some embodiments" etc. described in the specification of this application mean that one or more embodiments of the present application include specific features, structures or characteristics described in conjunction with the embodiment. Therefore, the statements "in one embodiment", "in some embodiments", "in some other embodiments", "in some other embodiments", etc. that appear in different places in this specification do not necessarily refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in other ways. The terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized in other ways.

[0061] It should be understood that the size of the serial numbers of the steps in the following embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0062] In order to illustrate the technical solution of the present application, a specific embodiment is provided below for illustration.

[0063] The inventor found that in the prior art, when using MQ to transmit data, due to its own message confirmation mechanism (ack), there will be a delay in message return or even no message return due to data or network reasons, resulting in the inability to write back data, thereby causing data loss and the inability to ensure data consistency between distributed microservices, which does not meet the inventor's expectations. Based on this, the inventor has made this application after further research and development, providing a method, device and system for processing data consistency between microservices.

[0064] Embodiment 1

[0065] The embodiment of the present application provides a method for processing data consistency between microservices. This method can be used in the SpringCloud distributed microservice architecture project by isolating RabbitMQ and encapsulating it into a microservice, called a message middle platform. Other microservices can call the message middle platform to send messages through the API interface. This method makes the code purer, reduces the degree of coupling, and achieves decoupling; and, because it is an independently encapsulated module, an API interface is provided to support multi-language calls; when calling the API interface to send a message, it is processed asynchronously, and the message confirmation return value is customized. When the API interface returns a message confirmation mark as a success mark, it is immediately written back to the database, ensuring that data is not lost, solving the problem of data loss between distributed microservices, and ensuring data consistency between microservices.

[0066] The following is a detailed introduction to the implementation process of the data consistency processing method between the message producer and the message center microservice:

[0067] In the present application, refer to Figure 1 As shown, the message producer will perform the following steps:

[0068] S101: Concatenate the message with the corresponding queue name to obtain a message byte string.

[0069] In the above step S101, when the consumer producer generates a message to be consumed (hereinafter referred to as a message), the message queue name corresponding to the message (hereinafter referred to as the queue name) is determined according to the business information of the message, and the message and the corresponding queue name are concatenated into a byte string to obtain a message byte string.

[0070] S102: Call the API interface to send the message byte string to the message middle station; the message middle station is a microservice obtained by encapsulating MQ.

[0071] Messages to be consumed need to be consumed by corresponding message consumers. However, in some message peak scenarios, such as flash sales, there are too many messages to be consumed in the same period, which can easily cause server crashes. Therefore, MQ can be used as a transit station to receive messages sent by message producers, and then consumed by message consumers.

[0072] However, the inventors found that when a message is sent to MQ, the message confirmation mechanism (ack) of MQ may be delayed in returning the message or even fail to return the message due to data, network and other reasons. Therefore, the inventors separated MQ and encapsulated it into a microservice, called a message middle station, to receive messages sent by message producers.

[0073] In the embodiment of the present application, the message producer sends a message byte string containing the message and its queue name to the message middle station by calling the API interface.

[0074] S103: When receiving the message confirmation identifier returned by the message center, determine whether the message byte string is sent successfully based on the message confirmation identifier. If so, execute S104; if not, execute S105.

[0075] S104: Writing the message confirmation identifier back to the database.

[0076] S105: Output error log.

[0077] In an embodiment of the present application, after the message producer sends the message byte string to the message middle station through the API interface, it determines whether the sending is successful based on the message confirmation identifier returned by the message middle station.

[0078] In the scenario where MQ is usually used, the inventors found that due to data, network and other reasons, its own message confirmation mechanism has message return delays or no return, resulting in failure to write back data normally and causing data loss.

[0079] In the embodiment of the present application, the inventors separated MQ, encapsulated it into a microservice, and customized the message confirmation identifier instead of using the message confirmation mechanism provided by MQ. When the message byte string is sent to the message middle station, the message middle station will promptly return the message confirmation identifier through the API interface, recorded as data.

[0080] In the embodiment of the present application, when receiving the message confirmation identifier returned by the message center, judging whether the message byte string is sent successfully according to the message confirmation identifier specifically includes:

[0081] When receiving the message confirmation identifier returned by the message center, determining whether the message confirmation identifier is a preset identifier;

[0082] If yes, the message byte string is sent successfully;

[0083] If not, the message byte string fails to be sent.

[0084] In the embodiment of the present application, when the message producer receives the message confirmation identifier data returned by the message center, it determines whether the message byte string is sent successfully by judging whether the data is a preset identifier. For example, the preset identifier for successful message sending can be set to 200. When the value of the data returned by the message center is 200, the successful sending identifier or the message confirmation identifier is immediately written back to the database. The data written back here can be defined by yourself, indicating that the message byte string is sent successfully; and when the value of the data returned by the message center is not equal to 200, it means that the message byte string fails to be sent, and the error log is printed out.

[0085] In the embodiment of the present application, after the message byte string fails to be sent, the method further includes:

[0086] Resend the message byte string to the message center until the message byte string is successfully sent or reaches a preset number of sending times.

[0087] In an embodiment of the present application, for a message byte string that fails to be sent for the first time, it can be resent after outputting the error log until it is successfully sent or reaches a preset number of sending times. For example, the preset number of sending times can be set to 3 times, and the message byte string that failed to be sent can be resent until it is successful or the total number of sending times reaches three times. If it is not sent successfully after three times, the message byte string will no longer be processed.

[0088] In the present application, refer to Figure 2 As shown, the message center will perform the following steps:

[0089] S201: When a message byte string sent by a message producer is received, a message confirmation identifier is returned to the message producer through an API interface; the message byte string includes a message and a corresponding queue name.

[0090] In the embodiment of the present application, when the message middle station receives a message byte string sent by a message producer through an API interface, it indicates that the message byte string has been sent successfully. At this time, the message middle station immediately returns a message confirmation identifier to the message producer, and then the message producer writes back to the database.

[0091] S202: According to a preset algorithm, the message byte string is routed to a message queue switch based on producer load balancing.

[0092] In the embodiment of the present application, the message middle station includes producer load balancing (Producer Proxy Cluster), message queue service process (MQ Broker) and consumer load balancing (Consumer Proxy Cluster). Among them, the message queue service process includes a message queue switch (Exchange) and a queue (Queue).

[0093] When the message middle station receives the message, it is distributed to the message queue switches in different MQ Brokers through reverse proxy software nginx or proxy based on producer load balancing and through a preset algorithm. In order to ensure that the data volume of each MQBroker is not much different, the most commonly used algorithm is the polling algorithm, which evenly distributes multiple tasks to the proxy server, that is, each server takes turns to get an equal share.

[0094] S203: Routing the message in the message byte string to a corresponding queue through a message queue switch according to the queue name in the message byte string.

[0095] In the embodiment of the present application, after receiving the message byte string sent by the producer, the message queue switch filters the message, that is, according to the routing key (Routing Key) carried in the message byte string, that is, the queue name, it determines to send the message to be consumed in the message byte string to the corresponding queue. After the message enters the queue, it will be monitored by the message consumer subscribed to the queue and consumed. Among them, the queue can store multiple messages, arranged in sequence, and according to the first-in-first-out feature, the message sent to the queue first will be consumed first.

[0096] In the embodiment of the present application, it also includes:

[0097] When a failure occurs in the message middle station, the message byte string is temporarily stored in a preset manner until the message middle station returns to normal, and the message byte string is restored to the message middle station.

[0098] In an embodiment of the present application, the message queue in the message center can be manually monitored through a monitoring system, and a text message warning can be set when the number of messages in the message queue exceeds a preset threshold. After receiving the warning text message, the message center can be manually intervened to restore it to normal.

[0099] Since microservices are highly available, that is, the message center is highly available, when a queue in the message center fails, the message center uses a preset method to temporarily store the existing messages to be consumed in the queue, and restores the message byte string to the message center after the message center returns to normal. The preset method can be the NoDB method.

[0100] In the embodiment of the present application, the data consistency processing method between microservices implemented by the interaction between the message producer and the message middle station is as follows: Figure 3 As shown, the overall execution steps are as follows:

[0101] S301: The message producer concatenates the message with the corresponding queue name to obtain a message byte string.

[0102] S302: The message producer calls the API interface to send the message byte string to the message middle station.

[0103] S303: The message center receives the message byte string and returns a message confirmation identifier to the message producer through an API interface.

[0104] S304: When the message producer receives the message confirmation identifier, it determines whether the message byte string is sent successfully based on the message confirmation identifier. If so, execute S305; if not, execute S306.

[0105] S305: The message producer writes the message confirmation identifier back to the database.

[0106] S306: Output error log.

[0107] In the embodiment of the present application, the specific implementation process of the above steps S301 to S302 and S304 to S306 can refer to the detailed description of the above steps S101 to S105 about the message producer sending messages to the message middle station and writing back data; the specific implementation process of the above step S303 can refer to the detailed description of the above step S201 about the message middle station receiving the message and returning the message confirmation mark. The repeated parts of the above processes will not be repeated here.

[0108] like Figure 4 As shown in the figure, in the complete process from generation to consumption of messages generated by the user end, in addition to the interaction process between the message producer and the message middle station (i.e. RabbitMQ in the figure) implemented in the above steps, it also includes the interaction process between the message consumer and the message middle station. The specific implementation process is as follows:

[0109] The message consumer continuously monitors the message center to see if there are messages to be consumed. If the message consumer monitors that there are messages in the corresponding queue of the message center, it automatically obtains the message for consumption. After the message is consumed, the message is stored in the database. Among them, there is a preset mapping relationship between the message consumer and each queue in the message center. One message queue can correspond to multiple consumer instances. Therefore, when consuming messages, the message center can evenly distribute messages to the corresponding message consumers for consumption through consumer load balancing and reverse proxy software.

[0110] In the embodiment of the present application, the message producer, the message middle station and the message consumer are three microservices, and each microservice has multiple instances, which realizes the decoupling and separation of business. The method provided by the present application solves the problem of data loss between microservices and ensures the data consistency between microservices. The message middle station is a microservice encapsulated as MQ, which encapsulates the stateless MQ into a stateful MQ. Due to the use of cluster load balancing, it can process a large number of requests in parallel, has the ability to accumulate and consume a large number of business messages, has low latency and high throughput, and supports high concurrency. Among them, stateful refers to the customized message confirmation identifier returned by the message middle station.

[0111] In addition, the data consistency processing between microservices provided by this application is not limited to encapsulating RabbitMQ as a message middle station for message transmission. Other message queues such as ActiveMQ and RocketMQ can be encapsulated and used with reference to this method. In addition, since the message middle station is an independently encapsulated module, an API interface is provided, which can support multi-language calls, including PHP, Java, Go and Python.

[0112] In a specific embodiment, after an information platform project used the data consistency processing method between microservices provided by the embodiment of the present application, the platform has been running smoothly since it was launched, and the problem of data loss caused by delayed or non-returned MQ messages has been solved.

[0113] The data consistency processing method between microservices provided in the embodiment of the present application sends the message and the corresponding queue name to the message middle station by calling the API interface, and then judges whether the message is sent successfully according to the message confirmation identifier returned by the message middle station, and writes back to the database in time. In this method, MQ and the custom message confirmation identifier are encapsulated together into a microservice as a message middle station, and an independent microservice is called through an API. The message confirmation mechanism (ack) provided by MQ is not used, and a custom message confirmation identifier is used to reduce the call chain steps, simplify the call chain logic, and respond more promptly, ensuring that data is not lost and the consistency of microservice data; it realizes the decoupling and separation of business, high reliability and persistence of messages, high performance, high real-time performance, high stability, and high scalability; it realizes the accumulation and consumption capacity of a large number of business messages, low latency and high throughput, and supports high concurrency.

[0114] Embodiment 2

[0115] Based on the same inventive concept, the embodiment of the present application also provides a data consistency processing device between microservices, which is applied to message producers, referring to Figure 5 As shown, the device comprises:

[0116] The concatenation module 101 is used to concatenate the message with the corresponding queue name to obtain a message byte string;

[0117] The sending module 102 is used to call the API interface and send the message byte string to the message middle station;

[0118] The judgment module 103 is used to judge whether the message byte string is sent successfully according to the message confirmation identifier when receiving the message confirmation identifier returned by the message center;

[0119] The write-back module 104 is configured to write the message confirmation identifier back to the database if the message byte string is sent successfully.

[0120] Embodiment 3

[0121] Based on the same inventive concept, the embodiment of the present application also provides a data consistency processing device between microservices, which is applied to the message middle station, referring to Figure 6 As shown, the device comprises:

[0122] The receiving module 201 is used to return a message confirmation identifier to the message producer through an API interface when receiving a message byte string sent by the message producer; the message byte string includes the message and the corresponding queue name;

[0123] A routing module 202, configured to route the message byte string to a message queue switch based on producer load balancing according to a preset algorithm;

[0124] The switching module 203 is used to route the message in the message byte string to the corresponding queue through the message queue switch according to the queue name in the message byte string.

[0125] Embodiment 5

[0126] Based on the same inventive concept, the embodiment of the present application also provides a data consistency processing system between microservices, referring to Figure 7 As shown, the system includes a message producer 1 and a message middle station 2, wherein:

[0127] The message producer 1 is used to concatenate the message with the corresponding queue name to obtain a message byte string; call the API interface to send the message byte string to the message middle station 2; when receiving the message confirmation identifier returned by the message middle station 2, it is determined whether the message byte string is sent successfully according to the message confirmation identifier; and if so, the message confirmation identifier is written back to the database;

[0128] The message middle station 2 is used to return a message confirmation identifier to the message producer 1 through an API interface when a message byte string sent by the message producer 1 is received; the message byte string contains the message and the corresponding queue name; according to a preset algorithm, the message byte string is routed to a message queue switch based on producer load balancing; and according to the queue name in the message byte string, the message in the message byte string is routed to the corresponding queue through the message queue switch.

[0129] In the embodiment of the present application, the above system also includes a message consumer 3, which is used to continuously monitor whether there is a message to be consumed in the message center 2. If so, the message is automatically obtained for consumption, and after the message is consumed, the message is stored in the database.

[0130] It should be noted that the information interaction, execution process, etc. of the message producer 1, the message middle station 2, and the message consumer 3 in the above-mentioned system are based on the same concept as the method embodiment of the present application. Their specific functions and technical effects can be found in the method embodiment part and will not be repeated here.

[0131] Embodiment 6

[0132] Based on the same inventive concept, an embodiment of the present application also provides a computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, the method for processing data consistency between microservices as described in the above embodiment 1 is implemented.

[0133] Embodiment 7

[0134] Based on the same inventive concept, an embodiment of the present application also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the method for processing data consistency between microservices as described in the above embodiment 1 is implemented.

[0135] Embodiment 8

[0136] Based on the same inventive concept, an embodiment of the present application also provides a computer program product comprising instructions. When the computer program product is run on a computer device, the computer device executes the method for processing data consistency between microservices as described in the above embodiment 1.

[0137] Embodiment 9

[0138] Based on the same inventive concept, an embodiment of the present application also provides a chip, the chip includes a processor and a communication interface, the communication interface and the processor are coupled, and the processor is used to run a computer program or instruction to implement the data consistency processing method between microservices as described in the above embodiment one.

[0139] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage and optical storage, etc.) that contain computer-usable program code.

[0140] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0141] These computer program instructions may also be stored in a computer readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0142] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0143] Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.

Claims

1. A method for processing data consistency between microservices, characterized in that: Applicable to message producers, including: Concatenate the message with the corresponding queue name to get the message byte string; Call the API interface to send the message byte string to the message middle station; the message middle station is a microservice obtained by encapsulating MQ; When receiving the message confirmation identifier returned by the message center, judging whether the message byte string is sent successfully according to the message confirmation identifier; If so, the message confirmation identifier is written back to the database.

2. The method according to claim 1, characterized in that When receiving the message confirmation identifier returned by the message center, judging whether the message byte string is sent successfully according to the message confirmation identifier includes: When receiving the message confirmation identifier returned by the message center, determining whether the message confirmation identifier is a preset identifier; If yes, the message byte string is sent successfully; If not, the message byte string fails to be sent.

3. The method according to claim 2, characterized in that After the message byte string fails to be sent, it also includes: Resend the message byte string to the message center until the message byte string is successfully sent or reaches a preset number of sending times.

4. A method for processing data consistency between microservices, characterized in that: Applied to the message center, including: When receiving a message byte string sent by a message producer, a message confirmation identifier is returned to the message producer through an API interface; the message byte string includes the message and the corresponding queue name; According to a preset algorithm, routing the message byte string to a message queue switch based on producer load balancing; According to the queue name in the message byte string, the message in the message byte string is routed to the corresponding queue through the message queue switch.

5. The method according to claim 4, characterized in that Also includes: When a failure occurs in the message middle station, the message byte string is temporarily stored in a preset manner until the message middle station returns to normal, and the message byte string is restored to the message middle station.

6. A method for processing data consistency between microservices, characterized in that: include: The message producer concatenates the message with the corresponding queue name to obtain a message byte string; The message producer calls the API interface to send the message byte string to the message middle station; The message center receives the message byte string and returns a message confirmation identifier to the message producer through an API interface; When the message producer receives the message confirmation identifier, it determines whether the message byte string is sent successfully according to the message confirmation identifier; If so, the message producer writes the message confirmation identifier back to the database.

7. A device for processing data consistency between microservices, characterized in that: Applicable to message producers, including: The concatenation module is used to concatenate the message with the corresponding queue name to obtain a message byte string; A sending module is used to call the API interface and send the message byte string to the message center; A judgment module, configured to judge whether the message byte string is sent successfully according to the message confirmation identifier returned by the message center when receiving the message confirmation identifier; The write-back module is used to write the message confirmation mark back to the database if the message byte string is sent successfully.

8. A device for processing data consistency between microservices, characterized in that: Applied to the message center, including: A receiving module, configured to return a message confirmation identifier to the message producer through an API interface upon receiving a message byte string sent by the message producer; the message byte string includes the message and the corresponding queue name; A routing module, configured to route the message byte string to a message queue switch based on producer load balancing according to a preset algorithm; The switching module is used to route the message in the message byte string to the corresponding queue through the message queue switch according to the queue name in the message byte string.

9. A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method for processing data consistency between microservices as described in any one of claims 1-3 or 4-5.

10. A computer device, characterized in that: It includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the method for processing data consistency between microservices as described in any one of claims 1 to 3 or 4 to 5 is implemented.

11. A computer program product comprising instructions, which, when executed on a computer device, enables the computer device to execute the method for processing data consistency between microservices as described in any one of claims 1-3 or 4-5.

12. A chip, comprising a processor and a communication interface, wherein the communication interface and the processor are coupled, and the processor is used to run a computer program or instruction to implement the data consistency processing method between microservices as described in any one of claims 1-3 or 4-5.

13. A data consistency processing system between microservices, characterized in that: include: Message producers and message middleware: The message producer is used to concatenate the message with the corresponding queue name to obtain a message byte string; call the API interface to send the message byte string to the message middle station; when receiving the message confirmation identifier returned by the message middle station, determine whether the message byte string is sent successfully according to the message confirmation identifier; and if so, write the message confirmation identifier back to the database; The message middle station is used to return a message confirmation identifier to the message producer through an API interface when a message byte string sent by a message producer is received; the message byte string includes a message and a corresponding queue name; according to a preset algorithm, the message byte string is routed to a message queue switch based on producer load balancing; and according to the queue name in the message byte string, the message in the message byte string is routed to the corresponding queue through the message queue switch.

Images