Axon 3.0.x 框架简介官方文档

因为需要用到，但是在网上对应的资料实在是很少，只有迎着头皮看官网文档并配合翻译器。如有误导多多包涵。

Axon

什么是 Axon

Axon Framework 通过支持开发人员应用命令查询责任隔离（CQRS）架构模式来帮助构建可扩展和可维护的应用程序。它通过提供最重要的构建块（例如聚合，存储库和事件总线（事件的分发机制））的实现来实现。此外 Axon 提供注释支持，它使您可以构建聚合和事件侦听器，而无需将代码与 Axon 特定的逻辑绑定在一起。这使您可以专注于业务逻辑而不是管道，并可以使您的代码更易于独立测试。

并非每个应用程序都会从 Axon 中受益。不期望扩展的简单 CRUD 应用程序可能不会从 CQRS 或 Axon 中受益。然而，有各种各样的应用程序确实受益于 Axon。
可能受益于 CQRS 和 Axon 的应用:

1. (系统功能需要频繁迭代新功能)应用程序很可能在很长一段时间内使用新功能进行扩展。例如，在线商店可能从订单模块进度的系统开始。在稍后阶段，这可以通过库存信息进行扩展，以确保库存在出售时得到更新。甚至在以后，会计可以要求记录销售的财务统计，等等。虽然很难预测软件项目在未来将如何发展，但大多数这类应用程序都是这样的。
2. (频繁读写的应用)应用程序具有高的读写比。这意味着数据只写几次，并多次读。由于查询的数据源与用于命令验证的数据源不同，因此可以优化这些数据源以实现快速查询。重复数据不再是问题，因为数据更改时会发布事件。
3. 应用程序以多种格式显示数据。现在，许多应用程序在网页上显示信息时不会停止。例如，一些应用程序每月发送电子邮件，通知用户可能发生的与其相关的更改。搜索引擎是另一个例子。它们使用的数据与应用程序使用的数据相同，但以一种为快速搜索而优化的方式。报表工具将信息聚合到显示数据随时间演变的报表中。同样，这也是同一数据的不同格式。使用 Axon，可以在实时或计划的基础上独立地更新每个数据源。
4. 当应用程序明显地将组件与不同的对象分开时，它也可以从 Axon 中受益。这种应用程序的一个例子是在线商店。员工将在网站上更新产品信息和可用性，而客户则会发出订单并查询其订单状态。使用 Axon，这些组件可以部署在不同的机器上，并使用不同的策略进行缩放。它们使用事件保持最新状态，无论部署在哪台机器上，Axon 都会将这些事件分派给所有订阅的组件。
5. 与其他应用程序集成可能是一项繁琐的工作。使用命令和事件严格定义应用程序的 API 可以使其更容易与外部应用程序集成。任何应用程序都可以发送命令或侦听应用程序生成的事件。

架构概述

CQRS 本身是非常简单的模式。它只规定处理命令的应用程序的组件应该与处理查询的组件分离。虽然这种分离本身非常简单，但是当与其它模式结合时，它提供了许多非常强大的特征。

axon 提供构建块，使得能够更容易地实现可以与 CQRS 组合使用的不同模式。下图显示了基于CQRS的事件驱动架构的扩展布局的示例。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ae30iIc6-1570778817749)
左侧显示的 UI 组件以两种方式与应用程序的其余部分交互：它向应用程序发送命令 Command(在顶部显示)，并查询应用程序以获取信息(在底部显示)。

命令通常由简单和直接的对象表示，对象包含命令处理程序执行该命令所需的所有数据。命令以其名称表示其意图。在 Java 术语中，这意味着使用类名称来找出需要完成的操作，并且命令的字段提供执行该操作所需的信息。命令总线接收命令并将它们路由到命令处理程序。每个命令处理程序响应特定类型的命令并基于命令的内容执行逻辑。但是，在某些情况下，您还希望执行逻辑，而不管实际的命令类型，例如验证、日志记录或授权。命令处理程序从存储库中检索域对象(聚合)，并对其执行方法以更改其状态。这些聚合通常包含实际的业务逻辑，因此负责保护它们自己的不变量。

聚合的状态变化导致生成域事件。域事件和聚合都形成域模型。存储库负责提供对聚合的访问。通常，这些存储库被优化用于仅通过其唯一标识符来查找聚合。一些存储库将存储聚合本身的状态(例如，使用对象关系映射)，而其他存储库存储聚合已在事件存储中经历的状态更改。存储库还负责持久存储在其备份存储中对聚合进行的更改。

Axon 为持久聚合的直接方式（例如使用对象关系映射）和事件来源提供支持。事件总线将事件分派给所有感兴趣的事件侦听器。这可以同步地或异步地完成。异步事件调度允许命令执行返回并将控制移交给用户，而在后台调度和处理事件。不必等待事件处理才能完成应用程序的响应。另一方面，同步事件处理更简单，是明智的默认处理。默认情况下，同步处理将处理同样处理该命令的同一事务中的事件侦听器。事件侦听器接收事件并处理它们。一些处理程序将更新用于查询的数据源，而另一些处理程序将消息发送到外部系统。正如您可能注意到的，命令处理程序完全不知道它们所做的更改感兴趣的组件。这意味着将应用扩展到新的功能是非常非侵入性的。您只需添加另一个事件侦听器。这些事件将应用程序中的所有组件松散地耦合在一起。在某些情况下，事件处理需要向应用程序发送新命令。

这是当接收到订单时的示例。这可能意味着客户的账户应借记购买的金额，并且必须告知装运准备装运所购买的货物。在许多应用中，逻辑会变得更加复杂：如果客户没有及时付款怎么办？您将立即发货，还是先等待付款？Saga 是负责管理这些复杂业务交易的 CQRS 概念。用户接口和数据源之间的薄数据层提供了与所使用的实际查询实现的明确定义的接口。此数据层通常将只读DTO 返回到包含查询结果的对象。这些 DTO 的内容通常由用户接口的需要来驱动。在大多数情况下，它们直接映射到 UI 中的特定视图(也称为表视图)。Axon 不能为该部分的应用提供任何构建块。主要原因是这非常简单，与分层体系结构不同。

模块结构

AxonFramework 由多个模块组成，这些模块针对 CQRS 的特定问题区域。根据项目的确切需求，您需要包含一个或多个这些模块。

1. core: 模块包含 Axon 的核心组件。如果使用单节点设置，则此模块可能会提供所需的所有组件。所有其他 Axon 模块都依赖于这个模块，因此它必须始终在类路径上可用。
2. test: 测试模块包含测试工具，可以用来测试基于 Axon 的组件，例如命令处理程序、Aggregates 和 Sagas。通常在运行时不需要这个模块，只需要在测试期间添加到类路径中。
3. Distributed: 分布式 CommandBus 模块包含可用于在多个节点上分发命令的实现。它附带了用于连接这些节点的JGroups 和 SpringCloud 连接器。
4. AMQP: AMQP 模块提供的组件允许您使用基于 AMQP 的消息代理作为分发机制来构建 EventBus。这允许保证交付，即使事件处理程序节点暂时不可用。
5. Spring: Spring 模块允许在 SpringApplication 上下文中配置 Axon 组件.它还提供了许多特定于 Spring 框架的构建块实现，例如在 Spring 消息通道上发布和检索 Axon 事件的适配器。
6. MongoDB: 是一个基于文档的 NoSQL 数据库.Mongo 模块提供事件和 Saga Store 实现，这些实现将事件流和 sagas 存储在 MongoDB 数据库中。 几个 Axon Framework 组件提供监控信息。度量模块提供了基于 Codehale 的基本实现来收集监控信息。

Spring 支持

Axon Framework 为 Spring 提供了广泛的支持，但不需要您使用 Spring 即可使用 Axon。 所有组件都可以通过编程方式配置，并且不需要在类路径上使用 Spring。 但是，如果确实使用 Spring，则通过使用 Spring 的注释支持可以简化许多配置。

消息传递

Axon 的核心概念之一是消息传递。组件之间的所有通信都是使用消息对象完成的。这为这些组件提供了必要的位置透明性，以便在必要时能够扩展和分发这些组件。尽管所有这些消息都实现了消息接口，但不同类型的消息与如何处理它们之间有着明显的区别。所有消息都包含有效负载、元数据和唯一标识符。消息的有效负载是对消息含义的功能描述。这个对象的类名和它所携带的数据的组合，描述了应用程序对消息的意义。元数据允许您描述发送消息的上下文。例如，您可以存储跟踪信息，以允许跟踪邮件的来源或原因。您还可以存储信息来描述执行命令的安全上下文。

Command

Command 描述更改应用程序状态的意图。它们被实现为(最好是只读) POJO，它们使用一个 CommandMessage 实现包起来。 命令总是有一个目的地。虽然发送方不关心哪个组件处理命令或该组件所在的位置，但了解它的结果可能会很有趣。这就是为什么通过命令总线发送的命令消息允许返回结果的原因。

Event

Event 是描述应用程序中发生的事情的对象。事件的一个典型来源是聚合。当聚合中发生重要事件时，它将引发一个事件。在Axon 框架中，事件可以是任何对象。我们非常鼓励您确保所有事件都是可序列化的。当事件被分派时，Axon 会将它们封装在EventMessage 中。实际使用的消息类型取决于事件的起源。当事件由聚合引发时，它被包装在 DomainEventMessage (扩展 EventMessage)中。所有其他事件都封装在 EventMessage 中。除了通用消息属性(如唯一标识符)外，EventMessage 还包含时间戳。DomainEventMessage 还包含引发事件的聚合的类型和标识符。它还包含聚合的事件流中事件的序列号，这允许复制事件的顺序。

Unit of Work

工作单元是 Axon 框架中的一个重要概念，尽管在大多数情况下，您不太可能直接与它交互。消息的处理被看作是一个单一的单元。工作单位的目的是协调在处理消息(命令或事件)期间所执行的行动。组件可以注册在工作单元的每个阶段执行的操作。

例如 onPrepareCommit 或 onCleanup。你不太可能需要直接访问工作单元。它主要由 Axon 提供的构建块使用。如果您确实需要访问它，无论出于什么原因，有几种方法可以获得它。

1. Handler 通过 Handle 方法中的参数接收工作单元。如果使用注释支持，则可以将 UnitOfWork 类型的参数添加到带注释的方法中。
2. 在其他位置，可以通过调用 CurrentUnitOfWork.get() 检索绑定到当前线程的工作单元。注意，如果没有绑定到当前线程的工作单元，此方法将引发异常。使用 CurrentUnitOfWork.isStarted() 查找是否可用。要求访问当前工作单元的原因之一是，附加在消息处理过程中需要多次重复使用的资源，或者在工作单元完成时是否需要清理创建的资源。在这种情况下，unitOfWork.getOrComputeResource() 和生命周期回调方法(如 onRollback()、postCommit() 和onCleanup() 允许您注册资源并声明在此工作单元处理过程中要采取的操作。

请注意，工作单元只是变更的缓冲，而不是事务的替代。虽然所有分阶段的更改都是在提交工作单元时才提交的，但它的提交并不是原子的。这意味着，当提交失败时，一些更改可能会持久化，而其他更改则不会。最佳实践规定，命令不应包含多个操作。如果你坚持这种做法，一个工作单位将包含一个单一的行动，使它安全地使用原样。如果工作单元中有更多的操作，那么可以考虑将事务附加到 Work 的提交。 使用 unitOfWork.onCommit(…) 注册在提交工作单元时需要执行的操作。

处理程序可能会由于处理消息而引发异常。默认情况下，未经检查的异常将导致 UnitOfWork 回滚所有更改。Axon提供了一些开箱即用的回滚策略：

1. RollbackConfigurationType.NEVER 将始终提交工作单元
2. RollbackConfigurationType.ANY_THROWABLE 发生异常时将始终回滚
3. RollbackConfigurationType.UNCHECKED_EXCEPTIONS 将回滚错误和运行时异常
4. RollbackConfigurationType.RUNTIME_EXCEPTION 将回滚运行时异常但是不包括 Error

当使用 Axon 组件处理消息时，将自动管理工作单元的生命周期。如果选择不使用这些组件，而是自己实现