Discussion on data consistency in Spring Cloud micro-service system

I think this question needs to be discussed separately according to own system concrete structure, this side takes a car to connect the system example.

Removing the GPS interface requires several steps (omitting the steps that do not involve data updates):

① Changing GPS Device status (Device Management Service)

② Change Ticket status (Work Order management Service)

Assuming the call to remove the GPS interface, for various reasons ② can not work.

Architecture 1: A common microservices architecture

Work Order Management Service to invoke the capabilities of the device Management Service, with Spring Cloud's own resttemplate, this is simple, plus ordinary transactions.

Schema 2: Introduction of Message Middleware

This time, the service between calls to add a layer of message middleware (take ACTIVEMQ as an example), it does not matter, ACTIVEMQ has a message acknowledgement mechanism ACK, you can specify Ack_mode for session_transacted=0 transaction commit

, and then with the original database transaction, can also be implemented. And ACTIVEMQ also has a failure to re-send the mechanism, you can try to retry the N-time after the failure to roll back.

Schema 3: Using the sub-Library

That involves multiple data sources, and spring can also integrate Atomiko to implement distributed transactions.

Discussion on data consistency in Spring Cloud micro-service system