我正在设计一个解决方案，并想仔细检查这是否符合微服务架构。
我们有客户、账户和交易，就像普通银行账户一样。 客户拥有姓名和地址等基本数据。 账户可能用于储蓄或经常账户 交易是两个账户之间的资金转移
所以我是这样设计的：
1 个管理客户端数据的微服务（仅管理客户端基本数据及其地址）
1个管理账户数据的微服务（将管理账户基础，客户端ID是账户数据的一部分）
1 个用于管理资金数据的微服务（将拥有账户余额和所有转账）
请告诉我这是不是按照微服务架构，如果你有另外的理解。
【问题讨论】：
标签： rest microservices software-design
据我了解，微服务架构的主要目标是支持大型系统不同部分的更快和持续发布，而无需相互等待。设计新系统有两种方法，微服务优先方法和微服务后方法。在第一种方法中，系统从头开始设计以遵循微服务架构，系统本身最初被分解为服务，并且服务通常通过 HTTP 和 REST 相互通信。在另一种方法中，系统最初不是作为微服务构建的，所有模块都在单个应用程序下。这两种方法各有利弊，这是一个单独的讨论。
在您的情况下，您采用第一种方法，为每个功能设计具有单独服务的新系统。我不是银行领域的专家，但据我了解，客户（客户）系统绝对可以是一个单独的服务，负责维护客户主数据。账户服务可以负责维护账户数据并提供账户相关信息。但是，账户余额是账户不可分割的属性，它应该始终与账户相关联。最后，转账可以是一个单独的服务，可以记录账户之间的转账。每当有转账时，可以查询账户当前余额，如果转账有效，则记录转账。
但是，由于这涉及金融交易，您必须确保每笔交易都遵循 ACID 规则。在分布式系统中维护 ACID 属性很棘手，有几种方法可以缓解这种情况，例如只在最关键的区域使用 ACID 事务，而在其他区域保持最终的一致性。例如，银行不会立即向客户反映所有交易“已完成”，而是显示“待处理”（最终一致性）消息，以便客户了解确切状态。
【讨论】：