微服务和分布式数据管理问题
- 每个微服务所拥有的数据对当前微服务来说是私有的，只能通过其提供的 API 进行访问。封装数据可确保微服务松耦合、独立演进。如果多个服务访问相同的数据，当模式（schema）更新时，需要耗时协调更新所有服务。
- 不同的微服务常常使用不同类型的数据库。现代应用存储和处理着各种数据，而关系型数据库并不一定是最佳选择。在某些场景，某些 NoSQL 数据库可能有更方便的数据模型，提供了更好的性能和可扩展性。例如，存储和查询文本的服务适合使用文本搜索引擎（如 Elasticsearch）。类似地，存储社交图数据的服务可以使用图数据库，例如 Neo4j。因此，基于微服务的应用通常混合使用 SQL 和 NoSQL 数据库，即所谓的混合持久化（polyglot persistence）方式。
第一个挑战是如何实现业务的事务在多个服务之间保持一致性。维护服务和数据库之间的数据一致性至关重要，因此我们需要另一套解决方案。
第二个挑战是如何实现从多个服务中检索数据。
例子：
Customer Service （顾客服务）维护客户相关的信息，包括信用额度。Order Service （订单）负责管理订单，并且必须验证新订单没有超过客户的信用额度。
事件驱动架构
事件驱动的架构有几个优点与缺点。
它能够实现跨越多服务并提供最终一致性的事务。另一个好处是它还使得应用能够维护物化视图。
一个缺点是其编程模型比使用 ACID 事务更加复杂。通常，你必须实现事务补偿以从应用级别的故障中恢复。例如，如果信用检查失败，你必须取消订单。此外，应用必须处理不一致的数据。因为未提交的事务所做的更改是可见的。如果从未更新的物化视图中读取，应用依然可以看到不一致性。另一个缺点是订阅者必须要检测和忽略重复的事件。
实现原子性
在事件驱动架构中，同样存在着原子更新数据库和发布事件相关问题。例如，Order Service 必须在 ORDER 表中插入一行数据，并发布 Order Created 事件。这两个操作必须原子完成。
使用本地事务发布事件
实现原子性的一种方式是应用使用仅涉及本地事务的多步骤过程来发布事件。诀窍在于存储业务实体状态的数据库中有一个用作消息队列的 EVENT 表。应用开启一个（本地）数据库事务，更新业务实体状态，将事件插入到 EVENT 表中，之后提交事务。有一个单独的应用线程或进程查询 EVENT 表，将事件发布到 Message Broker，然后使用本地事务将事件标记为已发布。
Order Service 将一行记录插入到 ORDER 表中，并将一个 Order Created 事件插入到 EVENT 表中。Event Publisher（事件发布者）线程或进程从 EVENT 表中查询未发布的事件，之后发布这些事件，最后更新 EVENT 表将事件标记为已发布。
这种方法有好有坏。好处是它保证了被发布的事件每次更新都不依赖于 2PC。此外，应用发布业务级事件，这些事件可以消除推断的必要。这种方法的缺点是它很容易出错，因为开发人员必须要记得发布事件。这种方法的局限性在于，由于其有限的事务和查询功能，在使用某些 NoSQL 数据库时，实现起来将是一大挑战。
挖掘数据库事务日志
不依靠 2PC（ 两阶段提交）来实现原子性的另一种方式是用一个线程或进程来挖掘数据库的事务或提交日志来发布事件。当应用更新数据库时，更改信息被记录到数据库的事务日志中。事务日志挖掘器（Transaction Log Miner） 线程或进程读取事务日志并向 Message Broker 发布事件。
事务日志挖掘有各种好处与坏处。一个好处是它能保证被发布的事件每次更新都不依赖于 2PC。事务日志挖掘还可以通过将事件发布从应用业务逻辑分离出来简化应用。一个主要的缺点是事务日志的格式对于每个数据库来说都是特有的，有些甚至在不同数据库版本之间格式就有了改变。而且，记录在事务日志中的低级别更新可能难以逆向到高级业务事件。
使用事件溯源
- 事件溯源通过使用不同于之前的、以事件为中心的方式来持久化业务实体，实现无 2PC 原子性。应用不用存储实体的当前状态，而是存储一系列状态改变事件。应用通过回放事件来重建实体的当前状态。无论业务实体的状态何时发生变化，其都会将新事件追加到事件列表中。由于保存事件是单一操作，因此是原子性。
- 事件溯源有几个好处。它解决了实现事件驱动架构的关键问题之一，可以在状态发生变化时可靠地发布事件。因此，它解决了微服务架构中的数据一致性问题。此外，由于它持久化的是事件，而不是领域对象，所以它主要避免了对象关系阻抗失配问题。事件溯源还提供了一个 100％ 可靠的审计日志，其记录了对业务实体的变更。此外，它可以在任何时间点对实体进行查询以确定状态。事件溯源的另一个好处是你的业务逻辑包括松耦合的交换事件业务实体，从单体应用迁移到微服务架构将变得更加容易。
- 事件溯源同样有缺点。这是一种陌生的编程风格，因此存在学习曲线。事件存储仅支持通过主键查找业务实体。你必须使用命令查询责任分离（CQRS）来实现查询。因此，应用必须处理最终一致的数据。
Original: https://www.cnblogs.com/l-926/p/16592724.html
Author: 小新超人
Title: 五、《微服务：从设计到部署》–事件驱动数据管理
原创文章受到原创版权保护。转载请注明出处：https://www.johngo689.com/570217/
转载文章受原作者版权保护。转载请注明原作者出处！