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

  • Jan Stenberg
  • 谢丽

2018 年 9 月 29 日

话题:语言 & 开发架构

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

语言 & 开发架构