ACID 如何在宁静的微服务架构中工作

Posted 2023-03-08

【中文标题】ACID 如何在宁静的微服务架构中工作

【英文标题】：How ACID works in a restful micro-service architecture

【发布时间】：2019-02-01 12:31:33

【问题描述】：

我在实现微服务架构方面还很陌生，这个问题让我大吃一惊

微服务架构如何解决不同端点调用之间的事务机制。

一个例子是基于微服务架构的银行服务 基本上，银行操作是针对不同的服务调用不同的服务来完成一笔交易，如果其中一个失败，那么就没有办法消除部分流程，不知道有没有什么机制可以解决这个问题

创建付款

POST /payments/customer/10/payment/100/

从帐户中扣款

PUT /customers/10/accounts/20

发送客户通知

发布 /alerts/customers/10

【问题讨论】：

最终的一致性和和解。 （在这种特定情况下，第一类记录可能是发布到日志的事务，然后消费者负责更新下游记录，如客户余额和发送警报。）

我觉得你提到的诉诸抵抗而不是取消案例的观点很有趣

【参考方案1】：

答案是您的 API 不会公开任何让您创建无效状态的方法。

每个方法都必须完成一个完整且有效的事务。例如，您拥有在账户之间转移资金的方法，而不是从账户中添加和移除资金的方法。转账时必须进行的任何记录保存或通知也必须通过这些方法完成（或至少排队）。

有时这需要您为您可能认为不完整的交易创建特殊的“有效”状态。例如，当您在剧院预订座位时，有一种状态是您的座位被保留到您没有支付费用的一段时间（5 分钟左右）。

【讨论】：

我明白你的意思，但是在不同的服务器上运行不同的微服务的场景中会发生什么，每个微服务都与一个或多个存储系统交互，如果这些微服务之一失败，因为应该处理这种情况我的意思是回到已经开始的过程

大体相同的答案——一个微服务应该只能完成完整且有效的交易。跨多个微服务的操作可以通过事务消息队列或在事务存储中交换信息进行编排。这再次创建了新的“有效状态”。如果服务 1 执行操作 A 导致服务 2 执行操作 B，那么除了持久的“A 和 B 完成”状态外，您可能还需要一个“A 完成，B 持久排队并保证很快完成”状态。跨度>