微信号:infoqchina

介绍:有内容的技术社区媒体

【实战】体验构建反应式事件驱动的CQRS应用

2014-08-04 15:28 InfoQ

Duncan DeVore在一次近期的演讲中谈到,设计一个不变的领域模型并与之进行反应式(Reactive)编程对我们的新架构而言是非常重要的需求,Duncan在演讲中还对他构建分布式应用的体验进行了分享。该分布式应用基于CQRS、最终一致性 事件溯源(eventsourcing),并且是采用Akka Scala编写的,

Duncan是一家能源公司的工程副总裁,他对CommandQuery Responsibility Separation (CQRS,即命令查询职责分离)进行了描述:将命令与查询分离到两个对象中,使它们在其他方面可以进行单独的优化,根据Duncan的经验,这是一种非常常见的需求。对于命令(Commands)而言,虽然它们会改变状态,但是它们并不涉及数据的编辑,它们只是行为,是一个对执行某个任务或某个动作的请求,它们更适合作为一条消息进行传递。而查询(Queries)则是位于数据存储之上的一层很轻薄的读取层,它并不是领域的映射,相反,数据通常是基于抓取(fetch)和页面结构(screen structure)存储的,并且拥有一个可以读取所有需要数据的键。将写和读分离的一个重要挑战是最终一致性,它会使得在写发生一段时间后,读取才可能展示出相同的数据。

当今大多数的业务应用都依赖对当前状态的存储,而Duncan认为这是由于采用了关系型数据库系统(RDBMS)的副作用。相比而言,事件溯源是针对事件的捕获,这是一种贴合自然的行为,它不会保持当前的状态,它保持的是状态的根源。我们来讲一个可以阐述这种方式优势的例子,有一个这样的需求,我们需要现有的购物车能够报告所有用户在购物车(取出商品后)所产生的订单。如果一个系统只是跟踪当前的状态,那么它只能报告新的订单,而对于基于事件的系统,所有订单的事件都保留在系统里,唯一需要做的就是向系统添加报告这项功能。

在成熟的业务模型中,行为跟踪的概念很常见。举一个例子,在一个银行账户中,每一比交易事务,比如存款和提款都会被记录下来。我们之所以信任当前的状态是因为该状态可以通过重放所有前面的交易事务来重新创建,而且该状态也可以通过对账来确认有效性。

Duncan强调了与事件打交道的两个技术性影响,第一个是存储系统成为了一种只有追加操作(译者注:即没有更新)的架构,这种架构更加容易分发,第二个是水平分区变得更加容易,因为抓取数据时使用的只是一个单独的键。

Duncan最后引用了他自己的一段话进行了总结:

我相信将CQRS和事件溯源结合可以为构建遵循反应式宣言(Reactive Manifesto)的分布式应用提供一种清晰且简明的方式。

反应式宣言(Reactive Manifesto)于2013年九月发布,目前已经有6,300人签署了该宣言。

Duncan是一本即将出版的名为《构建反应式应用》(“BuildingReactive Applications”)的图书的联合作者。


 
InfoQ 更多文章 Facebook如何实现PB级别数据库自动化备份 学术派Google软件工程师Matt Welsh谈移动开发趋势 Spotify为什么要使用一些“无聊”的技术? 妹纸们放假了,汉纸们做啥? 大多数重构可以避免
猜您喜欢 ICML 2016|「Data-Efficient 机器学习」研讨会已接收论文概述:如何让机器学习更高效的利用数据 Windows 10 单机安装与升级手册 入门产品经理如何分析设计一个产品 深入分析网络编程中踩过的坑 【第562期】用 webpack 构建 node 后端代码,使其支持 js 新特性并实现热重载