目前，我正在做一个以微服务为主要概念的项目。
为了看得更清楚，我举个例子:
我得到了 Service A，它有自己的模型和 Controller 。
基本上，服务 A 只包含数据库 A 的基本 CRUD 操作。
其次，我得到了服务B，与服务A 相同但数据库不同(数据库B)。
现在，我创建了 1 个服务来使用服务 A 和服务 B。目前我正在使用 TransactionScope 来“包装”交易，但它没有用。
代码如下:
//This is the service to call Service A and Service B
using (TransactionScope ts = new TransactionScope())
{
callServiceAMethod(); // works good
callServiceBMethod(); // something happened, and failed
//from here I don't know what should I do
//What I'm expecting is : if one of the service i just called didn't work as expected,
//the transaction will be rolled back else will committed
}
任何帮助将不胜感激:)
最佳答案
Currently I'm using TransactionScope for 'wrap' the transaction, but it didn't work
在事务范围内包装对物理外部资源的调用仅在非常精确配置(有些人会说人为)的条件下有效。
在您的示例中(假设服务和数据库位于彼此和调用者不同的物理主机上)，您将从调用者主机到服务主机，跨越服务边界，到数据库主机，进入数据库，返回到服务主机，返回到服务边界，然后返回到调用方主机。
为了将分布式事务从您的客户端传播到数据库，调用链中每一步的每个中介都必须加入该事务。
为了做到这一点:
- 必须在每个参与主机上正确启用和配置 MSDTC，
- 必须使用支持 WS-AtomicTransaction 的绑定(bind)(如 wsHttpBinding)进行服务调用，并且
- 服务必须是专门为支持交易行为而构建的。
因此，除非所有这些都已完成，否则您连续进行两次服务调用这一事实在这种情况下没有任何区别。单个服务调用将无法将事务向下传播到数据库并再次传播回来。
即使您已经了解上述内容并已完成所有这些步骤以支持跨多个服务调用的分布式事务支持，我仍然不建议您这样做。交易成本高昂，并鼓励对解决方案共享环境依赖性。当您计划采用微服务风格的方法时尤其如此。
必须更简单的是让每个服务公开恢复或回滚操作，以便调用者可以采取适当的操作并将之前对失败的调用进行的任何调用回滚。这种方法被称为 compensation pattern .
关于c# - 如何为多个服务创建事务 'Wrapper'？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/38629237/