拓冰建站拓冰建站
首页 / 资讯中心 / 正文

从零跑通 Axon Framework 的第一条事件:CQRS 与事件溯源实战入门

从零跑通 Axon Framework 的第一条事件CQRS 与事件溯源实战入门【免费下载链接】AxonFrameworkFramework for Evolutionary Message-Driven Microservices on the JVM项目地址: https://gitcode.com/gh_mirrors/ax/AxonFrameworkAxon Framework 是跑在 JVM 上的事件驱动框架用 CQRS 和事件溯源构建可演化微服务。适合想摆脱一个 Service 干所有事、要处理订单、任务流转这类频繁变更状态、且会写 Maven 项目的 Java 开发者。它替你解决了什么做过订单系统的人大概都踩过这个坑创建订单这个动作既要校验库存、又要落库、还要通知积分和风控。把它们塞进一个事务方法改一处就要回归一大片更糟的是历史状态只剩 UPDATE 出来的当前值线上出问题时你查不到当时到底发生了什么。Axon Framework 的解法是把意图和事实拆开你发一条命令表达意图CreateOrder处理器决策后以事件OrderCreated的形式把事实追加进事件存储读侧订阅事件构建查询视图。命令、事件、查询各走各的总线天然解耦也天然留痕。这张图是事件侧的三层结构事件处理器定义业务逻辑处理组决定并发与顺序策略事件处理器负责拉取和调度。把这张图看懂后面遇到的配置项基本都能对上号。三步搭好本地环境环境要求JDK 21 加 Maven 3.6 就够了Axon Framework 5.x 的源码按 Java 21 编译。不需要先装任何中间件——默认全部内存实现先把流程跑通再谈分布式。建议顺手把仓库拉下来官方文档和示例都在一起本地通读比在线翻快得多git clone https://gitcode.com/gh_mirrors/ax/AxonFramework引入依赖在 pom.xml 里先导入 BOM 统一锁版本再按需引模块。最小集是消息层和事件溯源层两个 artifactdependencyManagement dependencies !-- BOM 统一锁定全部 axon 模块版本避免模块间版本漂移 -- dependency groupIdorg.axonframework/groupId artifactIdaxon-framework-bom/artifactId version5.4.0/version typepom/type scopeimport/scope /dependency /dependencies /dependencyManagement dependencies dependency groupIdorg.axonframework/groupId artifactIdaxon-messaging/artifactId /dependency dependency groupIdorg.axonframework/groupId artifactIdaxon-eventsourcing/artifactId /dependency /dependencies依赖声明里刻意不写 version版本交给 BOM 兜底模块之间永远配套升级。写最小可运行程序主流程就四步创建配置器、注册处理器、启动、取命令网关。public class OrderApplication { public static void main(String[] args) { // 内存实现起步不依赖任何外部服务 AxonConfiguration configuration EventSourcingConfigurer.create() .componentRegistry(registry - registry .registerComponent(OrderHandler.class, builder - builder)) .start(); CommandGateway gateway configuration.getComponent(CommandGateway.class); gateway.sendAndWait(new CreateOrder(ORD-001, 129.00)); configuration.shutdown(); } }为什么用 sendAndWait它同步等命令处理完成方便你在 main 里立刻看到结果生产环境里换成 send 做异步派发即可。处理器才是 Axon 的核心味道——命令处理器负责决定事件处理器负责消费public class OrderHandler { CommandHandler void handle(CreateOrder command, EventAppender eventAppender) { // 命令侧只做校验和决策不直接写库 eventAppender.append(new OrderCreated(command.id(), command.amount())); } EventHandler public void track(OrderCreated event) { System.out.println(订单 event.id() 已创建金额 event.amount()); } }注意 EventHandler 放在独立的投影类里而不是聚合里写侧只追加事件读侧消费事件这正是 CQRS职责分离的落点。场景演练创建一笔订单你做了什么main 里调用gateway.sendAndWait(new CreateOrder(ORD-001, 129.00))就一行代码。系统发生了什么命令网关把 CreateOrder 投递到命令总线OrderHandler 上的 CommandHandler 方法被调用向事件存储追加一条 OrderCreated同一时刻EventHandler 所在的事件处理器从存储里消费到这条事件。命令和事件全程走各自通道互不阻塞。你看到什么约两秒内依赖下载时间另算控制台打出订单 ORD-001 已创建金额 129.00。此时事件存储里 OrderCreated 的载荷完整保留——把时间拨回三个月后你也能精确还原这笔订单当时的每个决定。仓库里的 university-demo 就是这个结构的完整教学版每个命令一个包事件类独立成包读模型单独放 read 目录照着它拆自己的领域会省不少弯路。三个高频坑及解法 ⚠️忘了 BOM模块版本打架原因axon-messaging 和 axon-eventsourcing 是独立 artifact手写版本号时很容易一高一低启动时抛莫名其妙的 NoSuchMethodError。解法永远用 axon-framework-bom 管依赖依赖声明里不出现 version。两个 EventHandler 抢同一条事件原因默认情况下同一处理组内的多个事件处理器方法会并发执行两个方法都更新同一份读模型时状态直接错乱。解法给方法显式指定EventHandler(processingGroup xxx)归组或者干脆拆成两个投影各管各的状态。一上来就连 Axon Server原因示例工程里看到 axon-server-connector 依赖就想照抄本地没起 Axon Server 就启动连接直接失败。解法最小演示走内存实现上面 EventSourcingConfigurer 的默认配置确需分布式时先跑 examples/ 下的 docker-compose.yaml 把 Axon Server 拉起来再改配置去连。学习路线就在这个仓库里参考指南源码docs/reference-guide/命令、事件、查询、测试每个章节都配了可编译的 Java 示例上手教程docs/getting-started/从建项目到配置 Axon Server 的分步图文示例工程全集examples/university-demo 是最佳入口university-demo-kotlin 给 Kotlin 用户5.x 设计与变更清单axon-5/API 变更、迁移基线、模块化说明都收在这里监控与分布式追踪docs/reference-guide/modules/monitoring/【免费下载链接】AxonFrameworkFramework for Evolutionary Message-Driven Microservices on the JVM项目地址: https://gitcode.com/gh_mirrors/ax/AxonFramework创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
分享:

看完干货,该让你的企业上线了

免费需求沟通 · 48 小时内出具建站方案 · 河南本地可上门