事件溯源教程

近半个世纪以来，ACID事务（满足原子性，一致性，隔离性和持久性的特性）一直是确保数据存储系统一致性的首选。众所周知的原子性属性：在发生故障时，可确保事务写入的全部或全部都不会; 隔离防止同时运行的事务干扰; 和持久性确保在发生故障时不会丢失已提交事务所做的写入。虽然事

目的当客户端想要订阅事件时，具有大量对象的系统可能导致复杂性。客户端必须单独查找和注册每个对象，如每个对象有多个事件，则每个事件都需要单独订阅。事件聚合器充当许多对象的单个事件源。它注册了许多对象的所有事件，允许客户端只注册聚合器。

由于我们公司的技术体系基本是 Spring 全家桶，而 Java 界似乎 Axon 又是比较流行的 Event Sourcing 框架，本着对新技术的尝试以及某些业务也确实有这方面的需求的出发点，对 Axon 做了一些尝试。这一系列文章将会以 Spring Cloud 作为背景，探讨 Axo

这是Kafka的KIP-500提案，目前，Kafka使用ZooKeeper存储有关分区和代理的元数据，并选择其作为Kafka控制器的代理。我们想要删除对ZooKeeper的这种依赖。这将使我们能够以更具可扩展性和可靠性的方式管理元数据，从而支持更多分区。它还将简化Kafka的部署和配置。

Zeebe是一种全新的工作流/编排引擎，适用于云原生和云规模应用。本文介绍如何使用Zebee进入云规模的工作流程自动化的新时代。Zeebe是一个真正的分布式系统，没有任何中心组件，根据一流的分布式计算概念设计，符合

点击标题进入项目，CommandHandler代码

这是一篇EventSourcing/CQRS实现的教程文章，从原理模式到具体技术产品选型都阐述得比较详细。以下是架构图：

在过去一年左右的时间里，我们一直在构建一个具有事件源架构的新系统。事件溯源非常适合我们的需求，因为我们的组织希望保留系统

目的不只是在域中存储数据的当前状态，而是使用只追加存储来记录对该数据所采取的全部操作。存储作为记录系统，可用于实现域对象。这可以简化复杂域中的任务，避免同步数据模型和业务域，同时提高性能，可伸缩性和响应能力。它还可以为事务数据提供一致性，并维护完整的审计流程和历史记录以支持修正操作。

事件驱动的体系结构和事件采购在过去几年中尤其受到关注。这种趋势是由于我们在构建具有弹性和可扩展性的模块化系统之后努力的结果。微服务是经常在这种情况下使用的术语。在我看来，微服务只是实现有界上下文的一种方式。模块化系统的核心是模块的边界，如何识别这些边界的最有前途的想法是Eric Evans的

在这篇文章中，我介绍了一个名为“Beenion”的开源项目背后的架构。它使用Event Sourcing和CQRS模式构建，并使用TypeScript编写。 简而言之，Beenion是一种“类似Twitter”的服务，您可以在其中发布数据并

在第一部分中，我分享了在Nordstrom一直在探索和实施事件溯源作为一种架构模式。在第二部分中，我们将分享一些我们见过的常见生产者模式。

会计学涉及账户和交易的分离和划分，以减少这些账户之间的耦合并增加这些账户的凝聚力。这是一个高度创造性的学科，取决于系统思考。会计师用微小的细节填写这些帐户(banq注：明细账)，每个细节都是必要的，每个细节都各不相同，每个细节都是更大的整体。管理所有细节是一项艰巨的任务，需要严格的纪

奥卡姆剃刀原理是如无必要，勿增加实体，只有必要情况下才选择复杂的架构，复杂的架构应对的是复杂的业务。1. 默认是通常顺序编程，如有必要使用Reactive响应式编程。2. 最新状态默认采取状态模式，如果有必要使用事件溯源。3. 默认采取ACID，如果有必要采取BASE

在典型的CQRS / ES系统中，由投射处理的事件具有至少一次交付保证。因此，通常需要实施重复数据删除以实现（感知）幂等性。 1. 基于事件ID每个投射对应一个重复数据删除表在单独的表中存储已处理的事件ID，并以事务方式读取当前余额

在Nordstrom，我们一直在探索一种特定类型的近实时数据流，称为事件溯源/事件采购，通过结合开源项目和过去四年运维生产的功能。在此过程中，我们学到了很多东西，并希望分享我们所看到的一些机会。 什么是事件溯源，我为什么要关心？</