blocks|key|2176293|text|您可以确保在整个调用序列中启用了@Transactional。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2176294|考虑将来自M1的所有微服务调用为单个事务。|ordered-list-item|2176295|以下列方式公开回滚：|2176296|在更新M2、M3和M4中的DB时，将值与DB放在Spring缓存中。|unordered-list-item|2176297|在M2、M3或M4中调用M3时，从Spring获取值并从DB中撤消它们。|2176298|2176299|​|2176300|在hysterix命令的fallbackMethod中，当M1用错误或某些默认输出应答时，调用其他服务的/rollback。|2176301|这可能不是一个完美的解决方案，因为它引入了另一个故障点作为/rollback处理，但最快的一个可以实现。|2176302|entityMap^0|0|0|1|1|1|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|V|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|W|8|@]|9|@]|A|$]]|$1|G|3|H|5|I|7|X|8|@]|9|@]|A|$]]|$1|J|3|K|5|I|7|Y|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|10|8|@]|9|@]|A|$]]|$1|O|3|P|5|D|7|11|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|12|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|13|8|@]|9|@]|A|$]]]|T|$]]

You can make sure that you have @Transactional enabled in this entire sequence of Invocation.

<ol>
<li>Consider invocation of all microservices from M1 as single transaction.</li>
<li>Expose a rollback in following way:

<ul>
<li>While updating DB in M2, M3 and M4, place the values in Spring cache as well along 
with DB.</li>
<li>Upon invoking /rollback in M2, M3 or M4, get the values from Spring Cache and undo 
them from DB.</li>
</ul></li>
<li>In the fallbackMethod of hysterix command, when M1 replies with error or some default output, invoke /rollback of other services.</li>
</ol>

This may not be a perfect solution, as it introduces another fault point as /rollback handling, but fastest one that can be implemented.

blocks|key|157121|text|据我所知，传奇是你要找的东西。这样做的目的是为每个状态改变操作提供一个撤销操作，如果情况恶化，就必须调用撤销操作。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|157122|entityMap|0|LINK|mutability|MUTABLE|url|https://microservices.io/patterns/data/saga.html^0|5|2|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

From what I understand, a <a href="https://microservices.io/patterns/data/saga.html" rel="noreferrer">Saga</a> is what you are looking for.
The idea is to provide for every state altering operation an undo-operation, that has to be called if things went bad down stream.

blocks|key|2176388|text|要回答您的问题，请添加一些业务要求。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2176389|案例1。M1是根据一个事件与其他微服务进行所有交互，例如订单。|offset|length|style|BOLD|2176390|在这种情况下M2+..。M5更新，|2176391|需求1:如果它们都是相互独立的.|2176392|首先从一个事件创建5个事件，然后|2176393|在这种情况下，可以将此事件添加到表中，将此事件标记为未处理的事件，一些计时器读取未处理的事件，并尝试以幂等方式执行所有任务，还可以在此类任务失败时进行报告，并且您的团队可以检查这些任务并手动解决它们。|2176394|(您可以使用故障转移队列来实现类似的逻辑-在一段时间后将相同的事件发送回原始队列)|2176395|需求2:如果都不是独立的|2176396|使用单个事件，并且仍然使用相同的解决方案。|2176397|在上面的解决方案中，主要的好处是即使您的系统在事务之间重新启动，您最终也会拥有一致的系统。|2176398|案例2.+--如果调用了M1+api，而M1需要从多个微服务执行所有任务，然后给用户响应。|2176399|我们可以在M1微服务DB+(sync_event_table)中创建一个已启动的事件，尝试在所有微服务中执行更新，在所有完成之后更新同步事件表。|2176400|对于那些尚未完成的情况-运行一个计时器，检查在>X分钟内未完成的作业，然后执行撤消操作或任何所需的操作，。|2176401|精华：|2176402|因此，如果您看到所有的解决方案，建议您的系统，以扭转所有差异。微服务更新|2176403|通过创造工作|2176404|检查作业状态|2176405|编写撤消/重做作业功能|2176406|entityMap^0|0|0|3|0|0|0|G|0|0|0|0|0|C|0|0|0|0|4|0|0|0|0|3|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1G|8|@$D|1H|E|1I|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|1J|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|1K|8|@$D|1L|E|1M|F|G]]|9|@]|A|$]]|$1|L|3|M|5|6|7|1N|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1O|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1P|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1Q|8|@$D|1R|E|1S|F|G]]|9|@]|A|$]]|$1|T|3|U|5|6|7|1T|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|1U|8|@]|9|@]|A|$]]|$1|X|3|Y|5|6|7|1V|8|@$D|1W|E|1X|F|G]]|9|@]|A|$]]|$1|Z|3|10|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|11|3|12|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|13|3|14|5|6|7|20|8|@$D|21|E|22|F|G]]|9|@]|A|$]]|$1|15|3|16|5|6|7|23|8|@]|9|@]|A|$]]|$1|17|3|18|5|6|7|24|8|@]|9|@]|A|$]]|$1|19|3|1A|5|6|7|25|8|@]|9|@]|A|$]]|$1|1B|3|1C|5|6|7|26|8|@]|9|@]|A|$]]|$1|1D|3|-4|5|6|7|27|8|@]|9|@]|A|$]]]|1E|$]]

to answer your question lets add some business requirements

Case 1. M1 is doing all interaction with other microservices based on an event recieved like Order Placed 

Now in this case M2 ... M5 update , 

requirement 1: if all of them are independent of each other.

first create 5 event from one event and then

in such a case you could add this event in a table mark this event as unprocessed and some timer reads unprocessed event and tries to do all the tasks in a Idempotent way, also you could have reporting if such tasks are failing and your team can check them and manually resolve them. 

(you could implement a similar logic by using a failover queue - which sends the same event back to the original queue after some time)

requirement 2: if all are not independent 

use a single event and still the same solution.

in the above solution the main benefit is even if your system restart in between the transactions you will alwayss eventually have the consistent system

Case 2. if the M1 api is invoked and M1 needs to do all tasks from multiple microservice and then give response to user.

we could create a started event in M1 microservice DB (sync_event_table) 
try to do update in all microservice
after all complete , update the sync event table with completed 

for those cases which are not completed - run a timer which checks for job which are not completed for > X min and then do the undo actions or whatever required,.

Essence:

So if you see all solutions suggests your system to turn all the diff. microservice update 

by creating a job

checking job status

writing a undo/redo job feature

blocks|key|157294|text|这是分布式事务的典型情况。不管您对数据库使用不同的技术，或者在不同的服务器上使用相同的技术，您都会执行一个事务性操作。为了处理该类型事务的回滚，您不能在数据库技术机制上中继事务和回滚。你得自己去做。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|157295|Saga模式|offset|length|style|BOLD|157296|微服务体系结构中分布式事务场景的常见解决方案是Saga模式。分布式sagas是一种用于管理方案中的失败的模式，正如您所描述的那样。|157297|Saga是基于业务流程创建的，例如“在网上商店购买产品”。此过程可能涉及多个微服务上的多个操作。Saga将控制和管理此流程执行，如果其中一个步骤失败，它将触发操作以恢复失败操作之前所做的操作。|157298|实现sagas有多种方法。这取决于您的体系结构以及您的微服务之间的通信方式。您使用命令和/或事件吗？|157299|示例|157300|“网上购物”业务流程。假设这个业务流程有3个简单的步骤，由3个不同的微服务完成：|157301|行动1-产品储备.库存.微型服务|unordered-list-item|157302|行动2-验证付款方式-小额服务|157303|行动3-按订单订购产品.微型服务|157304|使用事件的：|157305|您可以发布事件来执行某些操作(或操作)，如果其中一个操作失败，则可以发布该事件的还原(或删除)事件。对于上面的业务流程，假设1.操作成功，2.操作失败。在这种情况下，为了回滚1..action，您将发布一个类似于"RemoveReservationFromProduct“的事件，以便删除保留，并将状态还原回该业务流程的事务开始之前的状态。该事件将由事件处理程序接收，该事件处理程序将在数据库中恢复该状态。因为它是一个事件，所以您可以为失败实现重试机制，或者在代码中有一些错误时重新应用它。|157306|使用命令的：|157307|如果您使用某种rest命令直接调用您的微服务，您可以运行一些删除或更新端点来恢复您所做的更改。对于上面的业务流程，假设1.操作成功，2.操作失败。在这种情况下，为了回滚1..action，您将调用delete+api来删除特定产品的保留，以便删除保留，并将状态还原回该业务流程的事务开始之前的状态。|157308|您可以查看如何实现Saga模式的这示例。|157309|entityMap|0|LINK|mutability|MUTABLE|url|https://microservices.io/patterns/data/saga.html|1|https://blog.bernd-ruecker.com/saga-how-to-implement-complex-business-transactions-without-two-phase-commit-e00aa41a1b1b^0|0|0|6|0|N|6|0|0|0|0|0|2|0|0|0|0|0|5|1|0|0|5|1|0|0|G|1|1|0^^$0|@$1|2|3|4|5|6|7|1I|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1J|8|@$D|1K|E|1L|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|1M|8|@]|9|@$D|1N|E|1O|1|1P]]|A|$]]|$1|J|3|K|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1R|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1S|8|@$D|1T|E|1U|F|G]]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1V|8|@]|9|@]|A|$]]|$1|R|3|S|5|T|7|1W|8|@]|9|@]|A|$]]|$1|U|3|V|5|T|7|1X|8|@]|9|@]|A|$]]|$1|W|3|X|5|T|7|1Y|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1Z|8|@$D|20|E|21|F|G]]|9|@]|A|$]]|$1|10|3|11|5|6|7|22|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|23|8|@$D|24|E|25|F|G]]|9|@]|A|$]]|$1|14|3|15|5|6|7|26|8|@]|9|@]|A|$]]|$1|16|3|17|5|6|7|27|8|@]|9|@$D|28|E|29|1|2A]]|A|$]]|$1|18|3|-4|5|6|7|2B|8|@]|9|@]|A|$]]]|19|$1A|$5|1B|1C|1D|A|$1E|1F]]|1G|$5|1B|1C|1D|A|$1E|1H]]]]

This is a typical case of distributed transaction. Regardless of the fact that you use separate technology for your database or the same on different server you perform an operation which is transactional.
In order to handle a rollback on that type of transaction you can not relay on the database technology mechanism for transactions and rollbacks. You have to do it on your own.

Saga Pattern

Common solution for distributed transaction scenarios in micro-service architecture is the <a href="https://microservices.io/patterns/data/saga.html" rel="noreferrer">Saga pattern</a>.
Distributed sagas is a pattern for managing failures in scenarios as the one that you have described.

Saga are created based on business process for example "Buy a Product in online shop". This process can involve multiple actions on multiple micro-services. Saga will control and manage this process execution and if one of the steps fail it will trigger actions to revert the actions done before the failing action.

There are multiple ways to implement sagas. It depends on your architecture and the way your micro-services communicate with each other. Do you use Commands and/or Events? 

<hr>

Example

"Buy a Product in online shop" business process. Lets say this business process has 3 simple steps done by 3 different micro-services:

<ul>
<li>Action 1 - Reserve Product in products-inventory-micro-service </li>
<li>Action 2 - Validate payment in payment-micro-service</li>
<li>Action 3 - Order a product in orders-micro-service</li>
</ul>

Using Events:

You can publish events to perform some action(or actions) and if one of the action fails you can publish a revert(or delete) event for that event. For the above business process lets say the 1. Action succeeded and the 2. Action failed. In this case in order to rollback the 1. Action you would publish an event like "RemoveReservationFromProduct" in order to remove the reservation and revert the state back to the state as it was before the transaction for that Business process started. This event would be picked up by a event handler which would go and revert that state in your database. Since it is an event you can implement retry mechanism for failures or just reapply it later if there is some bug in the code.

Using commands:

If you have direct calls to your micro-services as commands using some kind of rest api you could run some delete or update endpoints to revert the changes that you have done. For the above business process lets say the 1. Action succeeded and the 2. Action failed. In this case in order to rollback the 1. Action you would call the delete api to delete the reservation for a particular product in order to remove the reservation and revert the state back to the state as it was before the transaction for that Business process started. 

You can take a look at <a href="https://blog.bernd-ruecker.com/saga-how-to-implement-complex-business-transactions-without-two-phase-commit-e00aa41a1b1b" rel="noreferrer">this</a> example how to implement the Saga pattern.

I have doubt related to MicroServices. Suppose there are 5 Micro-Services, lets say M1, M2, M3, M3, M4 and M5. There are 4 databases which are connected/accessed by 4 micro-services.
For example, M2 connected to MySQL, M3 connected to Cassandra, M4 connected to MongoDB and M5 connected to Oracle.
Now
Step-1: M1 making a call to M2 to update some user data in MySQL and it updated successfully then finally it got success response from M2
Step-2: M1 making a call to M3 to update some data in Cassandra and it updated successfully then finally it got success response from M3
Step-3: M1 making a call to M4 to update some data in MongoDB and it failed due to some DB server problem or any other problem.
Here my requirement is, I want to rollback DB changes that happened to previous micro-services(M2 and M3)
What should we need to do to achieve this kind of rollback scenario?

How to rollback MicroServices

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我对MicroServices有疑问。假设有5个微服务，比如M1、M2、M3、M3、M4和M5.有4个数据库由4个微服务连接/访问.例如，M2连接到MySQL，M3连接到卡桑德拉，M4连接到MongoDB，M5连接到甲骨文。现在步骤1： M1调用M2更新MySQL中的一些用户数据，并成功地进行了更新，最后获得了M2的成...

问如何回滚MicroServices
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何回滚MicroServicesEN