The transformation idea of database layer and cache layer was mentioned before. For the transformation of business layer, the architecture scheme of centralized service to micro service was adopted. Since it is service, the large number of internal calls between the service means and service dependencies, this means that if a request call involves two or more between micro service calls, just downstream of the micro service invocation fails, we will have to take into account the rollback and guarantee the data consistency between service problems. So, today I’m going to outline possible failures and their solutions, hoping to help your team that is working on a microservice transformation.

First, we make a classification of microservice-to-service calls:

  1. There is no direct dependence between the services. The upstream service sends an asynchronous message to the downstream service after completion. The success of the downstream service has no impact on the upstream service.

  2. Upstream services are weakly dependent on the processing results of a downstream service and can be degraded. This part of the data may not be returned when demoting. Synchronous calls become asynchronous when degraded.

  3. The upstream and downstream microservices are highly dependent. The upstream service depends on the return or callback of the downstream service, and the downstream service must be executed normally. If the downstream service fails, the request is considered to have failed.

Pure asynchronous invocation between services ensures idempotency and queue retry mechanism

For Case1, only two points need to be considered: idempotence and message queue retry mechanism. Idempotence means that duplicate messages have no effect on the results of downstream services. The message queue retry mechanism ensures that the message itself will not be lost. Even if the message queue hangs before being sent to the downstream queue, the corresponding message can be sent again after being restarted.

The upstream and downstream synchronous execution failed, and an asynchronous call was made through the message

As for Case2, the scheme adopted is shown in the figure below. The main service relies on three downstream services A, B and C. In the process of synchronous invocation, service C fails to be invoked. Since service C is not strongly dependent, we can send a message to the message queue to ensure that the master service can return normally and that service C can continue to be executed to ensure data consistency.

TCC is used for submission and rollback to ensure data consistency

Case3 is the strictest case for inter-service invocation, meaning that if one of the downstream services fails, all services upstream and downstream must be rolled back. This means that the same transaction must be guaranteed between services. An accepted solution is TCC (try-confirm-Cancel) :

  1. The main business service separately calls the downstream business to perform the try operation and registers all downstream services in the activity manager. When all the downstream microservices’ try operations are called successfully, or a downstream microbusiness service’s try operation fails.

  2. The business activity manager performs confirm or Cancel based on the results of step 1. If all previous try operations were successful, the activity manager invokes all downstream microbusinesses to perform the confirm operation. Otherwise, cancel operations are invoked for all downstream microservices.

  3. If the confirm or concel operation fails in step 2, the activity manager will initiate a retry mechanism to ensure that all microservices are eventually committed or rolled back successfully.


summary

The data consistency scheme of the three cases of inter-microservice invocation is explained above:

1. Ensure interface idempotent, message queues have retry mechanism, in fact almost all MQ now support retry.

2. Transfer service invocation from synchronous to asynchronous to ensure successful execution of upstream services and data consistency between services.

3. Use TCC solution to solve the data consistency between services with strong call dependence.

Scan the QR code or manually search the wechat official account: ForestNotes

Welcome to reprint, bring the following QR code