CQRS 和事件源框架 Axon 的基本概念和未来

Axon Framework 的应用正在迅速增加，最近达到了 100 万的下载量。在最近的阿姆斯特丹事件驱动微服务大会上， Allard Buijze 在演讲中介绍了 Axon 的基本概念、历史和未来。该框架面向以 DDD 、事件源和 CQRS 为基础的系统。

Buijze 一开始就指出，事件非常特殊；它们描述了发生过的事情，并且是系统历史的一部分。我们可以从过去中发现问题，我们可以设定对未来的期望。在 Buijze 看来，就是这点推动了事件源实践——使用事件作为应用程序的事实来源，而不仅仅是作为意外结果。

Buijze 还指出，重要的是，服务在消费自己的事件——这在事件源中非常重要。如果服务是基于内部数据而不是事件进行决策，那么你所做的就不是完全的事件源。你有一个事件驱动的架构，但是你不能保证事件是服务中发生的事情的真实表示。

根据 Buijze 的经验，有很多基于实体服务的微服务架构，他将这种设计技术称为“名词驱动设计（noun-driven design）”。其思想是在描述新系统的文档中找出所有的名词，它们将成为服务，而所有的动词将成为API 调用。这种技术很可能会导致分布式的大泥球，所有的服务都相互依赖。如果一个服务宕机，整个系统将无法使用。

Buijze 希望我们从单体而不是微服务入手。尽管更难扩展，但它们更容易部署和重构。他指出，我们不应该将好的单体与大泥球混为一谈。他建议的策略是从单体入手，但要确保内部结构明确定义。随着时间的推移，当过多的人不得不使用代码的相同部分时，就应该提取出一些组件，最好不要修改其他部分。随着时间的推移和需求的增加，会有越来越多的组件被提取出来。

为了帮助提取组件，位置透明性非常重要，Buijze 指出，Axon 的主要特性不是 CQRS，而是应用程序中组件之间的位置透明性。如果两个组件不知道它们各自的位置，那么你就可以修改那个位置。这还意味着，你不必知道某个操作在哪个服务中——你只需发送一条消息，它自己会找到它的目的地。

组件既不应该知道也不应该对与它交互的组件的位置做出任何假设。

事件很重要，但 Buijze 指出，组件发送的消息有三种类型，并强调，事件与消息不是一回事：

• 事件就是已发生的事情。它们被分发给所有处理程序，不返回任何结果。

• 命令是你希望系统执行的操作。它们会被路由到单个处理程序并返回一个结果。

• 查询用于你想知道什么的时候。它们会返回一个结果。

为了兑现位置透明的承诺，并使用这些不同类型的消息， AxonHub 于 2017 年（在去年的大会上）发布。Buijze 将其描述为一个消息传递平台，它能够理解不同类型的消息，而不是内容，并能够将不同的类型路由到正确的目的地。他指出，“集线器（hub）”的概念与微服务的智能端点和哑管道概念类似，虽然在本例中管道知道消息类型。

展望未来，Buijze 相信，微服务将继续发展演化，他也相信，Axon 组件的工作和通信方式在无服务器环境中会非常有用。他们朝这个方向迈出的第一步将是提供 SaaS 解决方案，但他也指出，他们还有更多的东西需要学习，为了有效地使用无服务器环境，他们还有更多的工作要做。

今年早些时候，Axon 团队发布了 AxonDB ，这是一个专门设计的事件存储。AxonHub 使用该存储存储事件，为此，他们已经决定将这两个产品合并到此次大会期间宣布的 Axon Server 中。该服务器既有开源版本，也有企业版本。

Axon 的下一个版本 4 正在开发，第一个里程碑已于最近发布。产品发布预计在10 月18 日。

Axon Framework 是面向 JVM 平台的开源产品，由Allard Buijze 在2009 年创建。2017 年7 月，一家单独的公司 AxonIQ 成立，专门从事 Axon 产品开发。

查看英文原文： Basic Concepts and the Future of Axon, a CQRS and Event Sourcing Framework