在面向服务的架构 (SOA) 下，我对服务是否应该拥有自己的数据这一问题很感兴趣。
其中一个限制是，如果在任何时候出现任何故障，我们需要能够将整个系统的状态回滚到之前的状态，以便我们可以重试或恢复操作。
如果每个服务都拥有自己的数据，那么这是否意味着从程序员的角度来看，系统可以更好地处理变化？
但是，如果每个服务都拥有自己的数据，是否有任何机制可以将整个系统回滚到之前的状态，以便恢复或重试失败的操作？
最佳答案
听起来您所说的服务的粒度可能是错误的。单个服务可以有多个端点(使用相同或不同的协议(protocol))，如果在一个端点上收到的消息需要回滚在另一个端点上收到的状态，它仍然是服务边界内的内部事务。
如果我们考虑订单和客户服务的简单示例。订单服务可能与与整个订单或订单行相关的消息有契约(Contract)，取消订单将撤消受两者影响的状态。通常客户服务中的地址更改不会随之回滚。
有时，服务操作会在较长的业务流程中捆绑在一起，为了继续上面的示例，我们还要添加一个发票服务。所以当我们取消订单时，我们也想取消发票。然而，重要的是要注意发票服务领域内的业务规则可以有不同的行为，例如，而不是“回滚”，例如延迟取消订单可能需要取消费用。这种长时间运行的交互就是我所说的 saga (你可以看到那个模式的草稿 here )
另请注意，服务之间的分布式事务通常不是一个好主意，原因有几个(例如为您不一定信任的外部方持有锁)您可以阅读更多相关信息 here
关于c# - 在面向服务的架构 (SOA) 中，每个服务都应该拥有自己的数据吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/18662025/