事件朔源模式——云计算架构常用设计模式

背景

    在分布式系统当中，处理数据的主要方法是保存数据当前的状态。例如，传统的CRUD模式种，从存储器读取数据，进行修改，并更新数据库种当前的数据状态，而此过程的实现，通常需要锁定数据的事务来进行实现。因此，这个过程主要存在着一些局限性：

• CRUD系统的更新操作直接针对数据存储可能会限制性能、响应能力和拓展性，因为其必须处理锁定数据的开销；
• 高并发情况下，可能会发生更新数据冲突；
• 除非有额外的审计机制，否则会丢失每个操作的详细记录。

目的

    此模式主要是使用增存储去记录领域中一系列操作执行的事件的完整记录，而不仅仅是存储领域对象当前的状态。它可以降低一个复杂领域种任务的复杂度，可以避免同步业务模型和数据模型，增加性能、可拓展性和响应性，并且提供事务的最终一致性、审计记录、历史纪录，以便进行补偿。

解决方案

    事件朔源模式使用一系列事件处理对数据的操作，每一个事件都被记录在附加存储当中，应用程序代码发送一系列关于数据操作的事件持久化到事件存储区。而每一个事件代表一类数据的变化。
    这些事件一直存储在事件存储区，这是一切数据的源头或者是关于数据当前状态的系统记录。事件存储去通常发布这些事件以便通知消费者，如果需要处理就随时进行处理。例如，消费者可以随时启动将事件中的操作传递给其他系统的程序。
    事件存储发布事件的典型用途是维护实体的物化视图。让应用程序去改变物化视图，以及与外部系统集成。
    此模式的优点如下：

• 事件通过只增存储来存储，可以使得执行事务时不会出现争用的模式，从而大大提高程序的性能和拓展性，特别是针对表示层而言。例如，表示层程序可以继续执行，而响应事件的人物可以放在后台进行执行；
• 事件是描述一些行为发生以及描述事件行为所关联数据的简单对象。其并不直接更新数据库，而是记录过程，直到适当的时候去处理，这样可以大大简化实施和管理；
• 事件记录了数据更新的整个过程，可以提供给领域专家更有意义的信息；
• 事件的只增存储提供了一个审计的跟踪，可用于监控数据存储的执行过程，在任意时刻，利用事件重放可重新生成实体化或投影，协助测试和调试系统；
• 事件与响应事件的任何一个操作的人物解耦，提高了系统的灵活性和可拓展性；

考虑因素

• 实时性：事件的存储或重放，只会使得系统达到最终一致性，中途的事件的添加与执行，会存在一定的时延；
• 事件的不可变：事件存储是一个不可变的信息源，如果存在版本或事件格式的更新，可以通过其他手段来区分不同的事件格式，而不应该对事件存储进行更改；
• 事件发生的一致性：当多线程程序或多个程序进行事件记录时，保证事件发生的顺序是非常重要的。通常，采用增加时间戳的方式，也可以通过增加增量标识来实现；
• 事件流的长度：事件流长度会影响到管理和更新系统，因此在合适的时间间隔，创建事件流的快照；
• 结果的一致性：虽然该模式最大程度上降低了数据冲突的问题，但是应用程序也必须处理由于最终一致性而导致的不一致问题；
• 事件消费者的幂等性：由于事件的发布可能不止一次，需要保证事件的消费者必须是幂等性的。

适用情况

适用情况：

• 想要挖掘数据的“意图”、“目的”或“原因”时；
• 最小化或完全避免数据更新冲突的发生时；
• 需要事件的记录来对数据进行回滚或审计时；
• 当使用CQRS并且在读模型更新替代时能接受最终一致性，能忽略从事件流中复原数据所带来的性能影响时；

不适用情况：

• 简单的领域或系统，良好的与传统CRUD数据管理操作结合的非域系统；
• 需要数据的实时一致性的系统；
• 不需要审计、历史记录及回滚重放功能的系统；
• 数据更新而引起的冲突非常少的系统，如主要添加数据而不更新数据的系统。