跨REST微服务的事务？
假设我们有一个用户、Wallet REST微服务和一个将事情粘合在一起的API网关。当Bob在我们的网站注册时，我们的API网关需要通过用户微服务创建一个用户，通过钱包微服务创建一个钱包。
下面是一些可能出错的场景：
>
用户Bob创建失败：没关系，我们只需向Bob返回一个错误消息。我们使用的是SQL事务，所以没有人在系统中看到Bob。一切都很好：）
创建了用户Bob，但在创建钱包之前，我们的API网关硬崩溃。我们现在有一个用户没有钱包（数据不一致）。
或者，我知道REST可能不适合这个用例。处理这种情况的正确方法是完全放弃REST并使用不同的通信协议（如消息队列系统）吗？或者我应该在我的应用程序代码中强制一致性（例如，通过有一个后台作业来检测不一致性并修复它们，或者通过在我的用户模型上有一个带有“creating”、“created”值的“state”属性，等等）？
共有1个答案
说不通的：
- 使用REST服务的分布式事务。根据定义，REST服务是无状态的，因此它们不应该是跨越多个服务的事务边界的参与者。您的用户注册用例场景是有意义的，但是使用REST微服务来创建用户和钱包数据的设计并不好。
什么会让你头疼：
- 具有分布式事务的EJB。这是一种理论上可行但实践上不行的东西。现在，我正在尝试使分布式事务在JBoss EAP6.3实例之间为远程EJB工作。我们已经和RedHat支持人员谈了几个星期了，但还没有奏效。
- 一般的两阶段提交解决方案。我认为2PC协议是一个很棒的算法（很多年前我用RPC用C实现了它）。它需要全面的故障恢复机制，包括重试、状态存储库等。所有的复杂性都隐藏在事务框架中（例如：JBoss Arjuna）。然而，2PC并不是失败的证明。有些情况下事务无法完成。然后您需要手动识别和修复数据库的不一致性。如果你幸运的话，它可能在一百万个交易中发生一次，但是根据你的平台和场景，它可能在每100个交易中发生一次。
- 传奇（补偿交易）。有创建补偿操作的实现开销，以及在结束时激活补偿的协调机制。但赔偿也不是失败的证明。你最后可能还是会有前后矛盾。
最好的选择是：
-
null
但如果需要同步响应呢？
- 重新建模微服务。如果带有队列的解决方案不能工作，因为服务使用者需要立即响应，那么我宁愿将用户和钱包功能重新建模，以便将其配置在同一服务中（或者至少配置在同一VM中，以避免分布式事务）。是的，它离微服务更远了一步，离整体服务更近了一步，但会让你免于一些头疼的事情。
-
第1步：我想有一个
-
我知道最好使用 Saga 模式，但想想还是很有趣的： < Li > 2PC/XA分布式事务是否提供了仅从一个应用程序和一个TM与多个RM进行事务的可能性？ < li >如果没有-如果每个微服务只能访问自己的数据库，如何在多个微服务之间使用2PC/XA分布式事务来提供使用2PC的能力？我很乐意看到一个例子 < li >我们是否需要将TransactionManager服务作为一个独立的微服务，在多个
-
我正在计划一个使用事件源的微服务模型。为了实现高可伸缩性和高吞吐量处理能力，我将使用Kafka作为微服务的消息代理。 在这一点上，我有问题的实现模型，以能够拥有Kafka主题和分区的好处。我的模型需要满足一些要求： 微服务必须从message broker获取数据(post/patch/put/delete) 数据一致性是强制性的，如果实体A需要实体B的先前存在，则必须只存在实体A的指向实体B的有
-
虽然每个微服务通常都有自己的数据，但某些实体需要在多个服务之间保持一致。 对于高度分布式环境（如微服务体系结构）中的这种数据一致性要求，设计的选择是什么？当然，我不想要共享数据库体系结构，即单个数据库管理所有服务的状态。这违反了孤立和不共享的原则。 我明白，微服务可以在创建、更新或删除实体时发布事件。对该事件感兴趣的所有其他微服务可以相应地更新各自数据库中的链接实体。 这是可行的，但是它会导致跨服
-
我有两个微服务和调用来更新数据，然后插入另一个数据，但让我们考虑一下 失败，然后我们需要回滚由 更新的数据，否则我们将处于不一致的状态。 我也经历了佐贺patterns.will它满足了这种矛盾 谁能为此提出更好的解决方案？
-
我有两个django REST API项目，我将它们解耦为微服务架构，其中一个服务是（SSO），它处理身份验证（我使用的是基于JWT令牌的身份验证）并管理用户信息，另一个是工资单服务。 问题是与工资单服务中的某个模型有关系。具体来说，我在工资单服务中有一个类，它有一个字段。这是我将添加用户的地方，我将从查询SSO服务中获得。 考虑到每个服务都有自己的数据库，我如何跨微服务共享数据库。