axon 4.5.4 jdk 1.8
建议使用xstream,否则很容易出问题,不会对aggregate和saga中的bean进行序列化,但是在upcaster中会比较难处理
如果使用jackson,该序列化方式依赖于entry的get/set函数,那么在saga、aggregate、event中引入的相关bean 不能设置get和set函数,否则会报序列化失败。该序列化方便的地方在于upcaster过程中,可以使用jsonNode的数据结构直接修改event的数据
使用axon.amqp.enable=true/false axon.kafka.enable=true/false来进行切换
建议使用nacos,将readme.md中的配置上传,并适当修改nacos中的name配置
建议discovert的ip/port一定要配置正确,这代表了server互相调用时的地址,否则会报no handler found
建议一定谨慎修改系统的messageConverter以及objectmapper,该问题会影响组件springcloud的restTemplate处理body,处理不当会报objectType cannot be null
前者不能被replay,后者可以,这是主要区别,目前已经确定amqp正常,kafka的tracking还未确认
两者一定不能混用,后者还未集成,不知是否能集成mybatis
在框架使用过程中,调优的方向有缓存和快照 缓存:相关event进行内存型缓存处理,加快load和存储速度 快照:使用最近快照进行rebuild
在具体的项目开发中,由于axon的异步特性,我们需要提供的功能有
-
- springcloud分布式命令总线集成
-
- mq-amqp集成
-
- mq-kafka集成(streamingMessageSource未验证)
-
- saga集成(带deadline的向前重试和向后回滚)
-
- listener集成
-
- 命令拦截器
-
- admin端-replay
-
- upcaster特性,用户可以针对任何命令的版本升级进行链式处理
-
- 事件的历史,以及事件的处理状态(目前使用了sent字段来标注,可能还需要更多信息)
-
- 查询用户事件历史
-
- 单服务多实例运行时,processor的调优处理tuning-event-processing
-
- 用户端:查询command的简单处理
-
- 用户端:stream聚合类复杂查询command处理
-
- 组件端:使用cache类组件,加快相关event/replay的速度
-
- codeGenerator组件
-
- metrics处理
-
- ideaPlugin(官方插件已经长久失修,无法使用)