问微观服务的事务管理

EN

微服务领域中的分布式数据管理是需要解决的最复杂的问题之一。然而，有一些模式和准则有助于解决分布式数据的问题。下面列出了其中一些

1. 定义了微服务的有界上下文--每个微服务必须拥有其域数据和逻辑。在这里，您需要打破外键依赖关系，并确定您将拥有哪个表，以及如果有两个服务目录和篮，您将使用reference.
2. Eventual一致性而不是ACID语义。目录包含产品详细信息，篮子包含用户当前购买的商品。产品价格的任何变化都应反映在篮子中的项目中。但是，由于产品数据和篮子项目存储在两个不同的数据库中，因此价格更新是异步进行的。这可以通过发布订阅服务器模式进行。例如，在消息总线上发布一个价格变化事件，并在它接收到事件时对其进行订阅和更新。
3. 只使用物化视图读取数据存储--这是CQRS模式的一种形式，来自多个服务的数据以非规范化的形式存储在只读数据存储中。使用上述方法异步更新数据。使用者无需查询多个服务就可以快速访问数据。

因此，总之，对于CAP定理，微服务世界更喜欢高性能、高可伸缩性和可用性，而不是强一致性。最终使用异步通信解决一致性问题。

https://learn.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/distributed-data-management

在我看来，你正试图用酸液标准来处理最终一致的世界。通常，拥有微服务的原因是因为ACID不会扩展，否则为什么要有多个数据库？此时，您应该有点忘记事务，并且非常清楚每个微服务的责任以及它处理的数据。尝试使用非常清晰的键，即键在逻辑上是服务之间的外键，但它不是强制的。

例如，您有两个服务: StudentsService处理学生的操作，ScheduleService处理学生的日程安排。

StudentsService将有学生数据库，允许对学生进行多次搜索等。这个服务应该为每个学生分配一个重要的字段-唯一的id。至少StudentsService应该提供以下API：

• 通过电子邮件检索学生id
• 通过电话检索学生id
• 通过id检索学生身份。

现在，所有其他服务都必须使用学生id作为学生的标识符。他们不了解这个领域。他们不知道它是真的还是假的(外键意味着检查它是真实的，但它真的很重要吗？)

现在你有了你的外键，但不是真的。

考虑到学生独特的身份永远不能改变--永远也没有理由改变它。而且，由于它从来没有被删除(存储现在很便宜)，你有一个完美的外键。

事务是很棘手的，如果你想扩大规模的话，应该不惜一切代价避免。你为什么要交易？您能有一个小的idempotant操作流程，客户可以重试或快速失败吗？继续上面的示例，编辑或创建学生将是一种操作，而创建或编辑学生日程则可能是另一种操作。两者之间不需要交易。