本人属于业内萌新，应业务学习需求对Axon框架进行学习，全篇以机翻为基础，自己凭着浅薄的理解逐句对用语进行了整理，如专业用语有误或理解有问题，请大家多多指正。

本篇是Axon4.4框架的翻译文档，按原文档分为六个部分，第一部分为第一章，主要是Axon及相关知识介绍；第二部分为第二章，主讲快速入门；第三部分为Axon主体框架Axon Framework介绍，包括第三章到第12章的全部内容，囊括了Axon的C端、Q端、ED/ES、saga，调整测试及springboot支持等知识介绍；第四部分为13章到17章的内容，囊括了Axon server服务器搭建调试的知识；第五部分是18章，讲了Axon对其他框架的支持；最后一部分是19章，为附录。

欢迎使用Axon手册！             

Axon提供了Axon框架和Axon服务器，以帮助构建以三个核心概念为中心的应用程序—CQRS（命令查询责任分离）/事件溯源和DDD（域驱动设计）。             

虽然可以使用Axon构建许多类型的应用程序，但事实证明它在微服务体系结构中非常流行。Axon在微服务体系结构中提供了一种创新的、强大的感性进化方式，使之成为事件驱动的微服务。             

请访问AxonIQ网站了解更多关于AxonIQ和Axon社区的信息。在那里，您将找到有关Axon培训、支持选项、即将发生和过去的事件的信息。

如何使用本指南

参考指南分为4个部分

名称

目的

快速启动

详细介绍Axon提供的快速入门工具包，以轻松熟悉Axon Framework和Axon Server的基本概念

axon框架

详细介绍基于Axon Framework的应用程序的构建。

axon服务器

详细介绍Axon服务器（SE / EE）的安装/设置和维护。

axon框架扩展

详细介绍Axon Framework提供的与现有企业基础结构集成的扩展。

基于Axon的应用程序应遵循一种架构模式，该架构基于领域驱动设计（DDD），命令查询责任隔离（CQRS）和事件驱动架构（EDA）的原理。这些原则的结合使基于Axon的应用程序更加健壮，而且可以适应我们业务领域的变化所要求的变化。

Axon既可用于大型整体应用，也可用于内部整体结构，以保持整体的适应性；而微服务则可用于系统的分布式性质，从而增加了复杂性。

以下各节描述了不同原理之间的关系以及Axon如何使用这些原理来帮助您构建更可维护，性能更高且更可靠的软件。

Axon旨在为不断增加的意外复杂性找到解决方案。应用领域驱动设计中的概念将在很大程度上有所帮助，即使是设计最出色的模型也无法在生产中自行运行。

尽管Axon对如何与领域模型进行交互提出了方案，但它努力避免限制建模的自由。即使您的意见与Axon的意见不同，也有足够的挂钩、配置选项和触发器来更改Axon某些方面的行为。您可以在参考指南中找到这些内容。

域驱动设计（DDD）描述了一种构建软件的方法，该方法非常重视模型的设计，并利用了普适性的语言。域模型是软件的核心，应该正确地构建，同时也需要处理域的基本复杂性。

命令查询责任隔离（CQRS）是一种体系或者说结构模式，它描述了应用程序中处理命令（请求更改应用程序状态）的部分与回答查询部分（请求有关应用程序状态的信息）之间的区别。

在把DDD和CQRS组合在一起时，我们实际上是将一个应用程序划分为多个组件，其中每个组件要么提供有关应用程序状态的信息，要么更改应用程序的状态。每个组件都有一个专注于这些职责的模型。

下图显示了基于Axon的应用程序的典型体系结构。

在这样的体系结构中，UI（或API）可以发送命令以请求更改应用程序的状态。这些命令由命令处理组件处理，该组件使用模型来验证命令并决定要顺带触发哪些边缘行为（如果有）。

这些顺带的边缘行为是通过“事件”引发的命令来产生的。这些事件由采取适当操作的一个或多个事件处理组件来拾取。其中一个典型的操作是更新视图模型，这允许UI呈现应用程序的状态。其他操作可能是向外部组件发送消息，甚至可能通过新命令触发其他副作用。

命令模型和查询模型（也称为视图模型或投影）的分离使这些模型仅专注于应用程序的特定方面。这使得各个单独的模型更容易理解，因此从长期来看更易于维护。

在基础结构和业务逻辑混在一起时，很容易就会一不留神出现意外的错误。Axon的当务之急是将其进行严格的区分。Axon的设计使以下两点有了明显的区别：你想做的事（如发布的事件）和这件事实际上是怎么做的（如发布事件的实施方法）。

这使Axon可以根据您的特定情况进行配置和调整。更重要的是，它可以将复杂性降至最低。例如，尽管Axon使实现事件源聚合变得容易，但绝不将聚合强制为事件源，Repository接口就完全践行了这一决策。同样，决定通过命令总线发送命令的组件不会去管如何将该消息传输到处理程序。

Axon不仅通过为组件提供清晰的接口来进行这种分离，而且还结合了Configuration API中的基础结构选择，那里的业务逻辑组件与应用程序的基础结构部分是分开配置的。

Axon强烈建议使用显式消息对象。这意味着基于Axon的应用程序中的每个消息通常将由该应用程序中的特定Java类表示。尽管这样做确实会在编写基于Axon的应用程序时带来一些开销，但它确实具有一些优点：

1.使用显式消息可以更轻松地将它们透明地分发到远程组件。

2.显式消息的使用强调消息设计，事实证明，消息设计对应用程序的长期可维护性很重要。

3.显式消息可以轻松存储以供以后处理

虽然消息传递是Axon的核心概念，但并非所有消息都是一样的。不同的意图需要不同的路由模式。例如，对于某些消息，一个人会期望结果，而其他消息天生就是一劳永逸的。

Axon将消息大致分为三类：

命令; 表达改变应用程序状态的意图。命令被路由到单个目的地，并且可以提供响应。

查询; 表达对信息的渴望。根据调度策略，查询可能会同时路由到一个或多个目的地。

日志; 表示发生了相关事件的通知。事件将发布到任何感兴趣的组件，并且不提供任何形式的返回值。

4.位置透明

使用显式消息的最大好处是，相互交互的组件不需要知道其对应对象的位置。实际上，在大多数情况下，发送组件甚至对消息的实际目的地都不感兴趣。我们称此为“位置透明度”。

与将服务放在逻辑URL后面相比，Axon使位置透明性进一步提高。在Axon中，发送消息的组件不需要为该消息指定目的地。根据消息的构造型（命令，查询或事件）和消息携带的有效负载类型来路由消息。Axon使用应用程序的功能自动为邮件找到合适的目的地。

由位置透明组件组成的系统使该系统具有高度的适应性。例如，由单独使用命令，事件和查询进行通信的，分隔良好的组件构成的整体系统可以轻松拆分为单独部署的单元，而不会影响功能。

通过位置透明度实现微服务演进

这使Axon非常适合微服务环境。逻辑可以轻松地在已部署的组件之间来回移动，而不会影响整个系统的功能。然后，可以根据该系统每个单独组件的非功能性需求来主要确定逻辑的位置。例如，可以将具有明显不同的性能特征的组件或需要不同发布周期的组件从整体应用程序中分离出来，以减少对该组件进行更改的影响。

在许多系统中，事件得到了很多额外的关注。尽管Axon明确承认并非每条消息都是一个事件（还有命令和查询），但事件还是有一些特殊之处。

事件存在价值。当命令和查询触发边缘行为或提供结果时，其价值会显着降低，而事件代表已发生的事情，这对于在事件发生后的很长时间内了解可能很有用。

事件为审核跟踪提供了非常好的粒度。但是，要使审核跟踪具有100％的可靠性，它不仅应作为边缘行为而产生，还必须确保审核跟踪正确反映了所有决策。

事件回溯是一个过程，其中事件不仅作为命令的边缘行为而产生，而且还导致了当前对象的状态。尽管应用程序的当前状态未明确存储在数据库中，但它可以作为一系列事件隐式存储，可用于导出当前状态。收到命令后，将从存储在数据库中的事件中动态得出应用程序的状态，然后确定要应用哪些边缘行为。

实施事件回溯可能非常复杂。Axon提供了使构建命令模型变得非常容易甚至更为自然的方法所必需的API。Axon的测试功能有助于确保正确遵循某些准则和要求。

拥有可靠的回溯不仅加强了系统的可验证性，而且还提供了构建新视图模型，进行数据分析并为机器学习算法提供坚实基础。

Axon很大程度上基于域驱动设计（DDD）和命令查询责任隔离的原则。尽管对这些概念的完整解释超出了本参考指南的范围和意图，但我们确实希望提供有关Axon应用程序上下文中最重要概念的摘要。

战略概念是相对较高的概念，它们在体系结构级别上影响系统的设计。它提供了设计组件边界及其之间相互作用的概念。尽管它们不直接影响单个Axon应用程序的设计，但此类概念通常会影响此类应用程序的边界。

在DDD上下文中，领域的正式定义是：

知识、影响或活动的范围，用户在这个范围内会运行一个以软件为主体的程序。

这个定义可能看起来很模糊，但确实很好地抓住了本质。域基本上是构建软件的环境。该环境由法律，最佳实践，期望，约定等组成，它们定义了什么是重要的，什么不是重要的。

域可能非常大，并且域内的不同区域可能会产生不同的影响。例如，在银行领域，个人银行，企业银行和理财产品销售之间存在明显的区别。

有很多技术可以帮助您探索一个域。事件风暴就是其中特别有趣的一种。它具有研讨会的形式，用于快速探索复杂的业务领域。

一个模型是：

一种描述领域选定方面的抽象系统，可用于解决与该领域相关的问题；

换句话说，模型捕获了对于我们解决领域内特定问题的重要信息。这个定义本身表明一个应用程序应该包含多个模型，因为每个问题都有一个不同的理想模型来解决。

有关基于Axon的应用程序中模型的某些构造块的更多信息，请参见战术概念。

上下文是：

用单词或陈述出现的设置来确定其含义。

换句话说，相同的领域概念对不同的人可能具有不同的含义。

例如，考虑一次飞行的概念。对于乘客而言，飞行是指从飞机起飞到到达目的地之间的时间段。但是，地勤人员关心航班到达登机口的次数，要登上飞机的饭菜，枕头等的数量，这些事情在航班离开登机口后就完成了。对他们来说，出发时间是最后期限，而不是起点。

因此，对于模型和上下文有许多规则：

有界的上下文永远不会独立出现。来自不同上下文的信息最终将被同步。对这个交互显式建模是很有用的。域驱动设计列出了上下文之间的一些关系，这些关系决定了它们之间的交互方式：

在基于Axon的应用程序中，上下文定义事件在其中携带价值的边界。有些事件可能仅在其发布的上下文中才有价值，而其他事件甚至在外部也可能有价值。发布事件（或任何消息，就此而言）的范围越广，最终有更多的组件耦合到发送者。

为了构建模型，DDD（在某种程度上还包括CQRS）提供了许多有用的构建块。下面是一些在基于Axon的应用程序中很重要的构建块。

1.2.6.1聚合

聚合是始终保持一致状态（在单个ACID事务内）的实体或实体组。聚合根是聚合中负责维护此一致状态的实体。这使聚合成为在任何基于CQRS的应用程序中实现命令模型的主要构建块。

DDD的正式定义是：

关联对象的群集，出于数据更改的目的，它们被视为一个聚合。外部引用仅限于聚合的一个对外成员，这个成员称为根。整组一致性规则适用于聚合的边界。

在基于CQRS的应用程序中，聚合在命令模型中非常明确地存在，因为这是启动更改的地方。但是，查询模型/映射也是由聚合建立的。但是，通常，查询模型中的聚合要简单得多，因为状态一致性在这些模型中通常不那么严格。

1.2.6.2 Saga

并非每个命令都能在单个原子事务中完全执行。汇款是交易中经常出现的一个非常常见的例子。人们通常认为，绝对必要的原子交易是将钱从一个帐户转移到另一个帐户。好吧，不是。相反，这是完全不可能的。如果资金从银行A上的一个帐户（总计A的实例）转移到银行B上的另一个帐户（总计B的实例），该怎么办？银行A是否获得银行B数据库的锁？如果转帐正在进行中，银行A扣除了这笔金额，但银行B尚未存入，这很奇怪吗？不完全是，它正在进行中。另一方面，如果在将钱存入银行B的帐户时出了点问题，银行A的客户会希望退回他的钱。因此，我们确实希望最终会有某种形式的一致性。另一个示例可能是在下订单后开始的示例。它将确保成功兑换礼品卡后，在另一侧确认订单。

尽管在某些情况下ACID交易不是必需的，甚至是不可能的，但仍需要某种形式的交易管理。通常，这些事务称为BASE事务：基本可用，软状态，最终一致性。与ACID相反，BASE事务无法轻松回滚。要回滚，需要采取补偿措施以还原在事务中发生的任何事情。在礼品卡示例中，如果兑换失败，将拒绝付款。

在CQRS中，可以使用Saga来管理这些BASE事务。它们响应事件并可以调度命令，调用外部应用程序等。在域驱动设计的上下文中，通常将Saga用作不同聚合（或聚合实例）之间的协调机制，以实现最终一致性。

视图模型或投影

在CQRS中，视图模型（也称为投影或查询模型）用于有效地公开有关应用程序状态的信息。与命令模型不同，视图模型着重于数据而不是行为。视图模型通常是为适应特定受众的信息需求而建模的。这些模型应清楚地呈现在目标受众前，以防止“分心”和范围模糊，最终导致可维护性甚至性能的损失。

传统的存储应用程序状态的方式，是我们捕获当前状态并将其存储在某些关系数据库或NoSQL数据库中。尽管此方法确实非常简单，但它并未提供一种推断我们如何达到当前状态的方法。当然，有人可能会争辩说，我们可以有一个单独的模型来保存导致当前状态的动作的历史记录，但是除了额外的复杂性之外，这两个模型可能很容易走不同的道路并开始变得不一致

事件回溯是一种通过过去发生的事件的历史记录存储应用程序状态的方法。当前状态是根据事件的全部历史记录重建的，其中每个事件代表我们应用程序中的更改或事实。事件为我们提供了有关应用程序中发生的情况的唯一事实来源。在需要向外部审阅者提供完整审核日志的应用程序中，这特别有益。在某些资源中，当前状态称为实现状态。

事件是构建状态的来源

让我们看一个示例，事件回溯与传统存储有何不同（见图2）。在传统存储系统中，我们仅知道我们已订购比萨饼和可乐。在“事件采购”中，我们看到用户选择了一个比萨饼，一个可乐，一个冰淇淋并取消了一个冰淇淋。传统存储中不存在有关冰淇淋选择/取消选择的信息。借助事件采购，我们可以推断用户为什么取消选择冰淇淋，价格太高或其他原因。关键是我们不会丢失这些信息，我们可以通过各种方式从中受益。稍后我们可以看到用户确认了订单。

事件回溯需要一个事件存储来存储事件。由于事件是不可修改的（事件是确实发生的且不能被修改的事实），因此应针对附件优化事件存储。事件排序在基于事件的系统中起着非常重要的作用-在我们重构对象状态的过程中，我们希望获得相同的结果。

Axon服务器是在axon中默认的选择，它提供了企业级的专用事件存储，其高度用于存储/检索的事件进行了优化。该服务器有标准版或企业版。

另外，Axon框架提供对RDBMS或NoSQL数据库作为事件存储的支持。

事件回溯与CQRS天生的契合。通常，我们不存储基于CQRS的体系结构中的命令模型，而是存储其事件序列。基于这些相同的事件，查询模型将不断更新以包含当前状态的特定表示形式。

与其重建整个命令模型状态（这将是一个漫长的过程），我们将模型分成多个聚合；模型中需要高度一致的部分。聚合中的这种分离使模型更易于推理，更易于更改，更重要的是，它使应用程序更具可伸缩性。

好处

下面列出了事件回溯的好处

为了遵守某些规定，软件系统需要提供完整的审核日志。基于事件的系统为我们提供了完整的审核日志，而且我们不必向审阅者提供任何其他信息。根据事件流生成一份报告就行了。

与我们的应用程序交互的完整历史记录存储在事件存储中。我们可以应用各种机器学习算法来从这些对我们的业务至关重要的交互中提取信息。

③设计灵活性

构建软件系统的敏捷方法要求我们应该能够适应此过程中发生的任何变化。能够从一开始就使用新的业务逻辑重播事件流，这意味着我们不必担心自己做出的决定（除了哪些事件对于存储很重要），我们以后可以随时修复行为。在事件流中引入新的视图意味着向解决方案中添加一个带有事件侦听器的新组件。

④ 时间报告

我们都知道调查生产中发生的事件有多么困难。它需要大量日志来挖掘和推理系统当时的状态。事件回溯提供了一种方法，可以将事件回滚到某个时间点，并在事件发生的状态下调试应用程序。我们不必担心我们设置正确的日志级别还是我们是否记录了所有必要的路径以找出事件。

事件回溯是一种避免我们重蹈覆辙的自然的解决方案。事件回溯的主要优势还有它增加了软件系统的可扩展性-当我们发现需要添加的新报告组件时，我们可以将其编写，回滚历史事件并使其运行。这对于零停机的蓝绿部署非常有用。

它还可以使用事件与外部系统集成。在这种情况下，事件是我们的API，外部系统必须了解它们。当然，我们可能不会将所有事件都发布到集成事件中心，而仅将那些重要的事件发布到集成事件中心。

*如果我们正在应用CQRS（命令查询责任隔离）实践，那么我们也可以重建命令模型和查询模型

Axon服务器提供了一种简单的方法来启动和规模化事件来源的Java应用程序。

在设计和创建（事件驱动）微服务系统时，DDD和CQRS概念一章中描述的概念非常适用。在本章中，我们将明确列出在此类环境中应用Axon的几种常见策略。

在AxonIQ，我们相信系统会逐渐发展为微服务，而不是尝试从头开始构建微服务系统。主要原因是探索合理的上下文边界（请参阅Bounded Context）和模型需要时间。与在整体系统中相比，在分布式系统中更改这些边界要困难得多。

Axon利用组件的分离并在它们之间使用显式消息传递，这使这些组件的位置透明。与使用服务发现不同，Axon用于消息传递的方法完全不需要组件知道消息的目的地。它们会自动路由到一个广告组件，以宣传处理此类消息的功能。这使得这些系统比“常规”基于微服务的系统更灵活地进行更改。

在微服务环境中应用Axon有不同的策略。可以在系统级别采用Axon哲学，并使用Axon构建所有服务。但是，仅在单个应用程序/服务中应用Axon时，它也已经很有用。最后，我们还将讨论在多语言环境中使用Axon时的特定策略。为此，Axon在构建时就考虑了集成。

在系统级别使用Axon时，这意味着有多个服务在运行Axon（或兼容的API），一个人可以最大程度地使用消息传递概念。应用程序可以简单地利用不同的消息总线来发送和接收来自其他组件的消息。在更改组件的部署策略时，这使系统非常灵活。

在现有的微服务系统中构建单个基于Axon的服务时，您可能希望使用“传统”的休息端点公开您的API。在这种情况下，基于Axon的应用程序将需要一个小的API层，它将REST调用转换为命令，然后将其分派到内部的命令总线。但是请务必考虑到，请求可能不会被一致地路由，并且用于同一聚合的命令可能会被路由到不同的实例。

如果基于Axon的服务已部署了多个实例，则仍可以使用总线的分布式实现来受益，以允许这些实例在它们之间适当地平衡消息处理。

实际上，许多基于微服务的系统都在多语言环境中运行。不同的服务将在不同的技术堆栈上运行。在这些环境中，更重要的是要确保适当地保护上下文边界并在适用的情况下提供体面的反腐败层。

所有使用过的技术堆栈都不太可能遵循与Axon应用程序相同的基于消息传递的方法。但是，这并不意味着需要放弃这些概念。您仍然可以从显式消息传递的许多优点中受益。在这样的环境中，反腐败层可以实现为处理命令，事件和查询，并执行对外部服务的其他类型的调用（例如REST调用）的组件。这样，使用显式消息传递的组件就不必担心轮询外部服务是否发生更改，也不必担心由不同类型的API引起的技术挑战。

Axon支持不同类型的连接器，这些连接器允许将事件（在某些情况下还包括其他消息类型）发布到第三方消息代理。默认情况下，Axon将对这些外部事件的格式进行假设，但始终可以覆盖它们。

在消息驱动的微服务环境中，服务之间的通信高效，可靠且易于管理和监视非常重要。消息路由不需要任何手动配置，添加新服务应该很容易。

使用Axon Framework，对于应用程序开发人员而言，内部通信是隐藏的。Axon Server在分布式环境中提供了相同的体验。它是一个易于使用，易于管理的平台，可以处理所有事件，命令和查询。

Axon Server知道有关正在交换的消息及其类型的信息：从一种服务发送到一项或多项其他服务的事件，以通知服务某些事情已经发生；命令，发送到一项服务以执行某件事；可能等待结果查询，发送到一个或多个服务以检索信息。

这些消息中的每条消息都需要不同的策略，Axon Server均支持所有策略。

应用程序连接到消息传递平台并注册其功能。一个应用程序可能能够执行一组特定的命令，另一个应用程序可以处理许多查询。同一应用程序可能有多个实例连接到消息传递平台，每个实例具有相同的功能。

客户端或应用程序将请求发送到消息传递平台。平台找到适当的已连接应用程序以将请求发送到该应用程序，然后转发该请求。它接收一个或多个答复，并将其转发给呼叫者。命令总是发送到恰好一个应用程序。相同聚合的命令始终发送到同一应用程序实例，以避免聚合的并发更新出现问题。查询将发送到所有能够回答查询的应用程序。如果同一应用程序有多个实例，则查询仅发送到实例之一。事件则存储在事件存储中，并发送给所有注册的监听器。

Axon Server可以在群集模式下运行。群集中的每个节点都是活动的，并且应用程序在节点上动态地进行负载均衡。同一应用程序的实例将连接到同一消息传递节点以优化性能。不同应用程序的实例分布在节点上以分散负载。

Axon Server控制发送到消息处理程序的消息流。消息处理程序向消息传递平台发送了许多许可，指示消息传递平台可以发送的消息数。一旦处理程序准备好进行更多请求，它就会发送另一条带有大量附加许可的消息。如果没有允许的处理程序，则Axon Server会将消息排队。当仍然有排队的消息断开处理程序时，这些消息将重新路由到另一个处理程序（如果可能）。

客户可以指示其请求的优先级。这样，例如，与在线请求相比，可以以较低的优先级执行源自批处理过程的命令。

需要授予应用程序对消息传递平台的访问权限。这避免了随机客户端可以开始向系统发送命令的风险。

Axon Server已在Spring Boot的基础上完全用Java开发。它作为单个jar文件分发，其中包含通过着色使用的所有库。

Axon Server的配置信息存储在小型h2数据库中。这包含有关消息传递平台节点和具有访问权限的应用程序的信息。此信息将自动在群集中的节点之间复制。

消息传递平台具有两种类型的接口：

标准Axon Framework Axon Server客户端和消息传递平台之间的通信使用gRPC。

目录

前言

一、axon简介

1.1框架概述

1.1.1处理复杂性

1.1.2DDD和CQRS

1.1.3业务逻辑和基础架构分离

1.1.4显式消息

1.1.5事件回溯

1.2DDD和CQRS

1.2.1战略概念

1.2.2领域和子域

1.2.3模型

1.2.4有界上下文

1.2.5上下文映射

1.2.6战术概念

1.3事件回溯

1.3.1事件存储

1.3.2事件回溯和CQRS

1.3.3结论

1.4事件驱动的微服务

1.4.1进化微服务

1.4.2应用Axon的策略

1.4.3基于Axon的微服务

1.4.4仅在单一服务中使用Axon

1.4.5混合/多语种环境

1.5 Axon服务器

1.5.1讯息模式

1.5.2高可用

1.5.3流量控制

1.5.4QoS消息

1.5.5访问控制

1.5.6实施技术