使用CQRS重新考虑架构

09-12-24 banq
                   

命令查询的责任分离Command Query Responsibility Segregation (简称CQRS)模式是一种架构体系模式,能够使改变模型的状态的命令和模型状态的查询实现分离。这属于DDD应用领域的一个模式,主要解决DDD在数据库报表输出上处理方式。

来自Rethinking architecture with CQRS一文对CQRS进行详细描述。

很多应用都需要持久层保存状态,因为这些状态不能丢失,如果只是放在内存中,而不是持久到磁盘上。状态是在领域模型中,每当模型保存到数据库以后,会有更多复杂的查询,都是使用复杂且慢的SQL语句实现的。比如如下复杂SQL语句:

queryBuilder.append(
  "m.*, " +
  "m.origin_participant_id as message_origin_participant_id, " +
  "po.first_name as message_origin_participant_first_name, " +
  "po.avatar as message_origin_participant_avatar, " +
  "po_ua.username as message_origin_participant_username, " +
  "CASE WHEN !isnull(po.fieldworker_project_id) THEN 'fieldworker' WHEN !isnull(po_ap.project_id) THEN 'fundraiser' ELSE 'player' END AS message_origin_participant_type, " +
  "po.city as message_origin_participant_city, " +
  "c.name as message_origin_participant_country, " +
  "pd.first_name as message_destination_participant_first_name, " +
  "pd.avatar as message_destination_participant_avatar, " +
  "pd_ua.username as message_destination_participant_username, " +
  "CASE WHEN !isnull(pd.fieldworker_project_id) THEN 'fieldworker' WHEN !isnull(pd_ap.project_id) THEN 'fundraiser' ELSE 'player' END AS message_destination_participant_type, " +
  "m.destination_participant_id as message_destination_participant_id " +
  "from internal_message m  " +
  "left join player po on m.origin_participant_id = po.id " +
  "left join (select player_id, project_id from ambassador_project where enabled = true group by player_id) po_ap on po_ap.player_id =  po.id " +
  "left join user_account po_ua on po.user_account_id = po_ua.id " +
  "left join country c on po.country_id = c.id " +
  "left join player pd on m.destination_participant_id = pd.id " +
  "left join (select player_id, project_id from ambassador_project where enabled = true group by player_id) pd_ap on pd_ap.player_id =  pd.id " +
  "inner join user_account pd_ua on pd.user_account_id = pd_ua.id " +
  "where m.destination_participant_id = ? "
);
<p>

如此复杂的SQL语句为什么不能用一句简单SQL完成呢?

SELECT * FROM messages WHERE receiving_participant = ?
<p>

如果你要这么做,就必须使用到CQRS模式。

Greg Young在infoQ的采访中“State Transitions in Domain-Driven Design”谈到了CQRS,Greg 解释了把领域模型分为两种:状态校验,以及状态转换,维持当前状态的一个视图。

CQRS架构如下图:

在客户端就将数据的新增修改删除等动作和查询进行分离,前者称为Command,走Command bus进入Domain对模型进行操作,而查询则从另外一条路径直接对数据进行操作,比如报表输出等。

当一个Command进来时,从仓储Repository加载一个聚合aggregate对象群,然后执行其方法和行为。这样,会激发聚合对象群产生一个事件,这个事件可以分发给仓储Repository,或者分发给Event Bus事件总线,比如JavaEE的消息总线等等。事件总线将再次激活所有监听本事件的处理者。当然一些处理者会执行其他聚合对象群的操作,包括数据库的更新。

因为领域对象操作和数据库保存持久这两个动作分离,因此,数据表结构可以和领域对象松耦合(JiveJdon源码可展示领域对象和数据表不再是一对一对应依赖,这也是使用Hibernate 等ORM框架容易造成的问题),你可以优化数据表结构专门用于查询。

再者,由于事件驱动了领域模型的状态改变,如果你记录这些事件audit ,将可以将一些用户操作进行回放,从而找到重要状态改变的轨迹,而不是单纯只能依靠数据表字段显示当前状态,至于这些当前状态怎么来的,你无法得知。当你从数据库中获得聚合体时,可以将相关的事件也取出来,这些叫Event Sourcing,事件源虽然没有何时何地发生,但是可以清楚说明用户操作的意图。

虽然这种架构有些复杂,但是好处却很多,主要的是实现透明的分布式处理Transparent distributed processing,当使用事件作为状态改变的引擎时,你可以通过实现多任务并发处理,比如通过JVM并行计算或事件消息总线机制,事件能够很容易序列化,并在多个服务器之间传送,(EJB提倡贫血失血模型,实际就是为解决胖模型在多个服务器之间传送时序列化耗费性能,现在我们不序列化模型,而是改变模型数据的事件)。

你可以让聚合体(胖模型)一直驻留在特定服务器中,这样可以为不同的应用选择不同的SLA。

由于事件处理是异步的,用户就不必等待所有操作完成(同步则是所有操作完成后才返回操作结果界面给用户,异步架构符合Jdon一直提倡的异步架构),CQRS实际可以利用BASE原理(CAP定律和BASE思想),实现最终一致,取得高可伸缩性,尽管最终一致使很多程序员有些恐慌,但是分布式ACID 事务却也让他们产生怨恨,其实最终一致其实最多是几个毫秒的延迟,但是你可以充分利用这几秒的延迟做更多事情。

当你使用异步事件模式以后,可以使用Esper 等EDA工具进行事件拦截和分析,该文作者就是利用它实现 RSA Adaptive Authentication用户登录后的授权处理。

最后该文作者推荐了一个基于Spring的CQRS的框架cqrs4j,这个框架是5天前刚刚推出,不过了解Jdonframework的人也许知道,Jdon框架6.2也是可以实现CQRS,不过是在同年11月上架的,且不谈两个框架比较,单理念上Jdonframework是世界同步的,说明世界不同角落里人都想到同一个问题了,本文很多理念其实在J道网站已经倡导多时,并且通过Jdonframework的Domain Events + 异步实现了。

相关CQRS 讨论

[该贴被banq于2009-12-24 14:54修改过]

                   

6
xmuzyu
2009-12-24 15:42

呵呵,不错。看来大家对DDD的认识和我们的想法逐渐吻合了。DDD+cache+Domain event+BASE==Jdonframework.

banq
2009-12-24 16:57

这篇文章其实提出了一个颠覆性的概念:分布式系统之间传输事件,把事件作为数据进行分布,当然也可以把事件作为key-value存储的数据。

目前EJB标准JavaEE6等都明显落后了,透明化out-of-box分布式架构是一个趋势。

这个概念和EJB提出的将实体数据在服务器之间传输完全相反,所以,EJB才积极倡导失血模型,就是模型没有方法(只有setter/getter方法),只有字段数据,没有行为,就是不能太胖,否则序列化性能就很差,但是没有行为的模型能称为对象模型吗?就像人失去血液能活吗?所以,失血模型是严重违背OO的,但是因为EJB把持着实现市场,所以,连同关系数据库编程思路,误导了一代程序员。

Spring作为另外一个实现市场,虽然Spring 3.0出来了,但是由于其只对组件技术架构实现支持,对模型实体不闻不问(由Hibernate掌管),没有解决模型事件和技术组件架构之间的通讯联系方式,结果,导致大部分程序员使用SSH或S2SH时,只是由服务触发模型,模型无法再触发其他服务或组件(模型最后成为事件最后终点站,这也是失血模型的一个特点,数据是被驱动的,但是模型对象不是数据,模型对象有行为,必须可以发出事件驱动其他),或者将服务或组件直接注射到模型中,导致业务模型和技术架构多点耦合。

以上矛盾也体现了EDA架构和所谓SOA架构的冲突所在。

作为一个好的框架,不对模型进行in-memory支持,而是通过Hibernate的二级缓存ehcache绕道实现,这是当前Spring+Hibernate(SSH或S2SH)的最大问题所在。另外Hibernate其实是将领域模型和关系数据库进行捆绑,反而让领域模型丧失了其为需求服务的自由,比如异步加载,即用即取lazy load等等。

所以,从DDD要求出发,一定要有一个综合将实体模型和服务组件技术架构合起来考虑的框架,比如Qi4j或Jdonframework,Spring + Hibernate这种分离思路其实是沿袭了EJB的Session Bean + Entity Bean/JPA思路,这种思路离DDD要求实在太远,可以看成是模型的汇编语言了。

[该贴被banq于2009-12-24 19:35修改过]

xmuzyu
2009-12-24 21:44

Map-reduce讲究:移动计算比移动数据更加廉价,它将大量的数据分为小的block分发给集群上的node,然后在每个集群node上面对切分后的block进行运算。

而当前Model是充血的,必然会聚合很多数据,但是通过事件,将聚合根模型中的与事件关联的模型数据或者子对象通过EDA架构分发出去,这一分发就为系统伸缩性奠定了一个良好的基础,其实这种事件分发也是一种切分,一种基于事件的切分,一种新型并行编程模式,当前jdon框架事件触发异步以后是通过线程池实现的,如果以后需要更强的运算能力和伸缩能力,可以采用JMS来对消息进行真正分布式并行计算。看来大千世界,思想的本质都是一致的。

jentrees
2009-12-26 10:05

看了banq的介绍和解释,突然有点豁然开朗的感觉。

以前的编程j2ee都是宣扬通过三层的构架方式,并且大家都在传道这样的方式符合组件化、模块化、伸缩性等都是多么多么的好。对于新手来说开始只能相信,到最后的习惯,真的是影响了一代程序员。可是在做了几年的j2ee开发以后,发现三层结构的那些优点也只是一厢情愿,君不见修改一处则动全身;发现大家一上来的是讨论po怎么建,数据库如何设计。

我们一边在说软件是对现实的抽象和模拟,一边说软件是一门艺术,那么采用这样的方式我们的艺术在哪里,且不说艺术,我们的软件和现实状况的一致性有多少距离,我想应该可以用十万八千里来形容。

我个人的理解,DDD就是用最符合现实、最符合实际运行模式的方式去编写软件。domain,repository,service,command,events这些都是现实业务流程中最真实的名词,最符合人类思考的方式和习惯,其实如果的软件能够完全符合这些特征,那么软件这个时候才真的是一门艺术了。

6Go 1 2 3 4 ... 6 下一页