背 景 前端
2004年，Eric Evans发表了Domain Driven Design（领域驱动设计，DDD)这一著做，并在书中对领域驱动做出了开创性的理论阐述，至今领域驱动设计已问世十几年。web
近几年来随着微服务盛行， ES (Event Sourcing)事件溯源和CQRS (Command Query Responsibility Segregation)读写分离也成为了一个愈来愈流行的概念，使用ES和CQRS好处在此不作赘述，可是也存在颇多弊端，好比事件数量巨大、回溯状态须要提早预热、缺乏成熟的框架支撑等。在这种状况下，2009年Allard Buijze在JVM平台开源了Axon Framework用来解决此问题，简单说来Axon就是集成了DDD、ES和CQRS于一身，落地实现的一套框架方案，并成立了一家公司Axon IQ，专门与Axon产品合做。数据库
爱奇艺号技术团队，在实施微服务化过程当中，应用领取驱动思想，采用Axon框架落地了多个服务，下面是实施过程当中的经验总结。后端
技术选型安全
爱奇艺号合同中台面向用户提供签约功能，从发起签约到运营审核、供应商、采购单、扫描件、归档等流程漫长，状态颇多，业务较为复杂，同第三方系统交互较多，对于有问题数据须要进行定位和回溯。项目初期为了更好的知足这些需求，咱们调研了一下比较成熟的框架，包括Cola、Axon、Activiti、Spring StateMachine等，图1-1是框架的一些对比：微信
图1-1架构
从对比中能够看出，Axon支持事件回溯，排查历史问题较为方便，而且官方文档完善，一直处于更新维护中。StateMachine较为轻量，流程变动对于历史数据兼容性良好。综合考虑采用Axon+StateMachine相结合，实现简版工做流引擎。并发
Axon框架介绍框架
Axon框架的程序遵循基于领域驱动设计（DDD）、命令查询责任隔离 （CQRS）、事件驱动架构（Event Driven Architecture，EDA）的体系结构模式，这些原则的结合，使基于Axon的程序更加健壮、适应性更强。图1- 2是基于Axon框架程序的典型体系结构：分布式
图1-2
基于Axon框架程序的典型体系结构图特性以下：
-
领域驱动模型：可使业务实体不会“贫血”，更加饱满，实现高内聚、低耦合； -
命令查询责任隔离：命令模型和查询模型的分离，使得每一个模型更容易理解，更易开发维护，自然适合高并发场景； 事件驱动架构：支持事件溯源，方便对历史事件重放，记录数据变化完整过程，便于BI分析、线上问题排查、还原系统状态到任意时间点等。
Axon系统调用链如图1-3所示：
图1-3
Spring StateMachine介绍
Spring StateMachine是使用 Spring框架下的状态机概念建立的一种应用程序开发框架。它使得状态机结构层次化，简化了配置状态机的过程。拥有有现状态机的特性功能：现态、条件、动做、次态，支持触发器、状态转移器、保护机制、状态转移动做和状态事件监听器，可基于Zookeeper实现分布式状态机，可配置多层次、结构复杂的状态机。图1-4是简单配置效果图：
图1-4
爱奇艺号合同中台服务实践
【项目介绍】
用户入驻爱奇艺号后发表做品会得到分红收益，帐号知足必定条件后能够申请提现，提现以前须要跟公司签约电子合同。为了保证合同安全有效，线上签约流程比较漫长，包括用户填写信息、运营审核、采购单申请审核、合同审核、合同附件盖章邮寄、做品关联等等，累计20+状态，业务逻辑较为复杂，需求迭代变动频繁，对数据一致性要求较高。
项目1.0版本采用的是Activiti工做流做为引擎设计实现的，基于Activiti特性，能够严格控制每一步状态的流转，历史操做事件都会记录到系统数据库中，对于线上问题排查有必定的优点。可是学习成本较大，须要开发人员了解框架系统的二十多张表功能、使用BMPN进行流程定义设计等。图1-5是最第一版本的流程设计图：
图1-5
图1-6
用户接口层：主要是MQ消息、UI和API接口，接收用户请求、运营审批命令、第三方系统交互通知等；
应用层：接口参数校验、组装业务参数，转换成Axon Command进行命令分发；
领域层：接收到领域事件，转换成状态机Event，驱动状态机进行状态更迭，触发对应业务逻辑处理；
-
基础服务层：提供底层存储服务，第三方服务等。
系统调用流程以下图1-7：
图1-7
Axon+StateMachine结合，实现简版工做流引擎功能，相比于Activiti更加轻量级。以合同对象多为领域对象，系统操做命令使用状态机进行控制流转。全部对系统的修改操做均以Axon的Command进行，Axon会记录全部对领域对象操做过的事件，能够还原合同生命周期内每一步的状态，对于问题排查，统计分析有着很大的帮助；snapshot机制对事件进行预热，解决事件过多加载慢的问题；sage对系统失败操做进行补偿事件，保证系统间数据状态的一致性；StateMachine特性，能够修改状态之间流转走向及流转条件，新增状态对于历史数据或者进行中的数据没有影响，对系统的迭代开发有很大的效率提高，自然适合互联网性质工做流。
价 值
一、 开发方面的优点
转换思惟：Java语言开发一直提倡面向对象开发，可是不少业务开发人员的思惟仍是面向过程开发的思惟，按照MVC分层进行业务代码的堆叠。Axon思惟更倾向于面向对象，以领域对象为核心，因为领域对象有明确的领域边界，因此容易促进开发人员思惟模式的转变。
提高开发效率：项目基于命令模型开发，可让熟悉业务的开发人员专一于领域层开发，接口和应用层开发则能够由对业务比较陌生的开发人员负责，两者经过命令发送消息机制进行通讯。这种职责分离的优点在于不须要全部的开发人员都对业务很是熟悉，减小了熟悉具体业务的时间，且每一个开发人员都职责明确，可显著提高开发效率。
二、 运行维护时的优点
便于问题排查：事件溯源机制使得领域对象的每次操做变动状态都有记录，对于排查线上问题有很大的帮助，能够按照前后顺序还原对象的每一步状态。snapshot机制有很好的解决了ES事件预热的问题。对于BI的分析也有着更好的支撑。
支持系统高吞吐量：CQRS的支持，自然适合高并发场景，若是系统有高并发的需求，使用Axon框架能够获得更好的支持。
便于维护和拓展：Axon框架的代码层次清晰，易维护，使用的事件机制让系统更具可扩展性。
难 点
-
分布式事务一致性问题，saga虽然能保证分布式事务的最终一致性，可是实施起来困难很大，须要开发各类补偿机制来实现。并且没有考虑到服务的宕机、幂等、重试支持等问题 批量事务处理能力较弱，对于一些批量功能，目前只能转换成单独的命令进行处理，没有提供很好的批处理能力。
与Spring cloud整合问题，Axon支持与Spring Cloud结合，使用分布式消息队列来实现分布式系统间命令的分发，可是目前没有比较良好的实现，中文文档较少，须要进一步研究实施。
Axon的充血模型虽然是一大特点，可是实施起来比较繁琐，对于简单的业务实现，贫血模型更加适合。
中文文档少，上手难度较高，国内使用人少，遇到问题可请教或讨论的人少。
将来规划
从4.0版本开始，Axon已经不止是个框架，而是一个由Axon Framework和Axon Server组成的平台。目前官方发布的最新Axon版本已是v4.3.3，本文中的项目基于Axon框架v3.04进行开发，而且是基于单机事件传播，对于Axon Server机制还未深刻研究使用。另外对于一些高级特性如：与Spring Cloud整合、分布式命令、分布式事件、分布式事务等须要进一步实践和总结。Axon命令分发支持与配置AMQP协议的MQ（Message Queue）绑定，MQ用于把Event分发到MQ中，采用这种机制能够针对性的对服务进行更细粒度的拆分，命令分发和处理能够配置成不一样的模块，按照各自吞吐量进行服务部署。此外，分布式事务一直是个使人头疼的问题，对于saga的优雅实现须要花费更多的时间进行深刻研究。
领域思想的转变对面向对象开发语言有着重大的帮助，成熟的架构支持及持久的维护性对于技术选型有着很大的影响，流行的Axon, Akka, Cola等框架势头正猛，相信领域思想将来会更深刻人心。
本文分享自微信公众号 - 爱奇艺技术产品团队（iQIYI-TP）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。