我建议务实并考虑设计方案的所有含义，而不是只关注领域驱动的设计。其中一个影响是微服务隔离与事务边界的对齐情况。事务仅驻留在微服务中的系统不需要上述任何解决方案。在设计系统时我们一定要考虑事务边界。在实践中，可能很难以这种方式设计整个系统，但我认为我们应该致力于最大限度地减少数据一致性挑战。

接受不一致

虽然匹配帐户余额至关重要，但有许多用例，其中一致性不那么重要。想象一下，为分析或统计目的收集数据。即使我们从系统中随机丢失了10％的数据，也很可能不会影响分析的业务价值。

与事件共享数据

选择哪种解决方案

数据的原子更新需要两个不同系统之间达成共识，如果单个值为0或1则达成协议。当涉及到微服务时，它归结为两个参与者之间的一致性问题，并且所有实际解决方案都遵循一条经验法则：

在给定时刻，对于每个数据记录，您需要找到系统信任的数据源

事实的来源可能是事件，数据库或其中一项服务。实现微服务系统的一致性是开发人员的责任。我的方法如下：

1. 尝试设计一个不需要分布式一致性的系统。不幸的是，对于复杂的系统来说，这几乎是不可能的。
2. 尝试通过一次修改一个数据源来减少不一致的数量。
3. 考虑事件驱动的架构。除了松散耦合之外，事件驱动架构的强大优势是通过将事件作为单一事实来源或由于更改数据捕获而产生事件来实现数据一致性的自然方式。
4. 更复杂的场景可能仍然需要服务，故障处理和补偿之间的同步调用。知道有时候你可能需要在之后进行调和。
5. 设计您的服务功能是可逆的，决定如何处理故障情况并在设计阶段早期实现一致性。

【编辑推荐】

1. 必备！人工智能和数据科学的七大 Python 库
2. Wikibon 2018年云市场和2019趋势报告：云移向数据
3. 世界首创3D原子级量子芯片架构！
4. 2018年度GtiHub开源项目TOP 25：数据科学&机器学习
5. 苹果 FoundationDB 开源 CloudKit 使用的数据层

（编辑：安卓应用网_ASP源码网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!