1

在面向服务的架构 (SOA) 下，我对服务是否应该拥有自己的数据这一问题感兴趣。

其中一个限制是，如果任何时候发生任何故障，我们需要能够将整个系统的状态回滚到先前的状态，以便我们可以重试或恢复操作。

如果每个服务都拥有自己的数据，那么从程序员的角度来看，这是否意味着系统可以更好地处理变化？

但是，如果每个服务都拥有自己的数据，是否有任何机制可以将整个系统回滚到之前的状态，以便可以恢复或重试失败的操作？

4

4 回答 4

2

听起来您所谓的服务的粒度可能是错误的。单个服务可以有多个端点（使用相同或不同的协议），如果在一个端点上接收到的消息需要回滚在另一个端点上接收到的状态，它仍然是服务边界内的内部事务。

如果我们考虑订单和客户服务的简单示例。订单服务可能与与整个订单或订单行相关的消息签订合同，取消订单将撤消受两者影响的状态。通常，客户服务中的地址更改不会因此而回滚。

有时服务操作在较长的业务流程中捆绑在一起，继续上面的示例，让我们还添加一个发票服务。所以当我们取消订单时，我们也想取消发票。然而，重要的是要注意发票服务领域内的业务规则可以表现不同，例如，而不是“回滚”，例如延迟取消订单可能需要取消费用。这种长期运行的交互就是我所说的传奇（您可以在此处查看该模式的草稿）

另请注意，服务之间的分布式事务通常不是一个好主意，原因有几个（例如为您不一定信任的外部方持有锁），您可以在此处阅读更多相关信息

于 2013-09-09T21:01:58.043 回答
1

SOA system defines more services within one system. This can provide more autonomous services in order to every service can be hosted on different machine.

But it does not mean that you can not provide unified persistent layer for all (domain) models which can point into one storage => simple business transaction when the whole system is spread into more computers or transaction for one system.

Autonomous domain model is useful besides other things during refactoring to avoid situation where a change in one model causes a change in another service => global changes in the whole application.

于 2013-09-06T19:53:16.210 回答
1

您在这里提出的问题（部分）由两阶段提交协议解决（参见维基百科文章）

为了避免实现这种复杂的算法，您可以将架构的一项服务专用于数据管理。如果需要不同数据库之间的数据同步，尽量在最底层（即系统或DBMS）做。

于 2013-09-06T16:19:23.697 回答
1

简而言之：不。服务不“拥有”数据。

数据是关于世界的真相，并且隐含地持久和共享。逻辑服务 (API) 并不总是以 1-1 的方式映射到现实世界的数据。物理服务（代码）是非常可重构的实现，它反对数据的持久性。

当您对数据进行分区时，您将失去描述能力和分析洞察力。但它真正杀死你的是诚信。随着规模的扩大，数据无法跨孤岛保持一致。对于复杂的数据，您需要那些外键。

换句话说：一个平台只有一个“逻辑”数据库（每个环境），因为只有一个宇宙。拆分数据库有很多正当理由，例如硬件限制、性能、协调、复制和合规性。但是把它们当作需要的罪恶，只在需要的时候使用。

但我想你可能会问一个不同的问题：“长期运行的、基于数据的事务是否应该由单一的权威服务管理？” 通常，这个答案是：是的。该事务服务可以实现多个步骤以按其认为合适的方式对流进行排序，例如两阶段提交。您的所有其他服务都应使用该事务服务来执行事务。

但！该事务服务必须仅使用原子语义作为共享资源与数据库进行交互。这包括所有事务状态（意图、动作、结果），因此可以进行恢复和回滚。必须授权数据库在发生故障时保持完整性。这一点我怎么强调都不为过：如果你想要容错，一切都必须分解为原子数据库操作。

于 2014-12-19T00:32:06.790 回答