Cqrs

1. CQRS架构分享
作者：汤雪华
个人博客：http://www.cnblogs.com/netfocus

2. 概要
DDD(Domain-driven Design)聚合介绍
Event Sourcing(ES)介绍
最终一致性，Saga介绍
数据存储与水平扩展
CQRS架构介绍
并发、数据一致性、性能

3. CQRS架构图

4. CQRS架构的优点
CQ两端架构分离、相互不受束缚，各自独立设计、扩展
C端通常结合DDD，解决复杂的业务逻辑；Q端轻量级查
询，多种不同的查询视图通过订阅事件来更新
C端通过分布式消息队列水平扩展，天然支持削峰
EDA架构，整个系统各个部分松耦合，可扩展性好
架构层面做到无并发，实现Command的高吞吐
技术架构和业务代码完全分离，程序员不用关心技术问题
更方便的分工合作

5. CQRS架构的缺点
不是强一致性，而是面向最终一致性
强依赖高性能可靠的分布式消息队列
必须有强大可靠的CQRS框架，从头做起成本高、风险大
必须结合Event Sourcing模式，否则CQ分离意义不大
Event Sourcing模式的缺点
一些CQRS的最佳原则提高了开发人员的门槛

6. C端如何获取Command的执行结果
框架可以支持异步同步化
C端执行完成后立即返回结果
Q端处理完成后才返回结果
不返回结果，通过发送Email或短信等方式通知用户
不返回结果，通过将用户重定向到显示结果的页面
一些后台系统，不需要返回任何结果

7. CQRS代码示例 – Command, Event

8. CQRS代码示例 – Command Handler

9. CQRS代码示例 – Domain Aggregate

10. CQRS代码示例 – Event Handler

11. DDD基本Building Block介绍

12. DDD Aggregate Consistency

13. Event Sourcing (ES)介绍
通过事件溯源(ES)得到对象最新状态
不保存对象的最新状态，而是保存对象产生的事件

14. Event Sourcing VS CRUD
CRUD：DB的记录可变，可以增删改
ES：没有更新、删除，只有Append Event，不可变

15. Command Sourcing VS Event Sourcing
CS：保存Command, 通过Command重造历史
ES：保存Event, 通过Event还原历史

16. Event Sourcing的优点
记录了数据完整变化过程，最详细的日志
可以将系统还原到任何一个时间点的状态
Domain Event有业务价值，BI分析事件能预测业务未来
发展情况
可以有效解决线上的数据问题，线下重演一遍，就能知道
哪里出问题
不再需要用到ORM，所以没有O/R阻抗失衡的问题，领
域模型的设计可以更OO
将Command、Event串联起来，可以分析聚合根的整个
变化过程，有助于排查分析问题
由于所有变化都转变为事件，所以框架层面可以做到自动
的检测并发冲突，并自动重试；因为每个事件都有版本号

17. Event Sourcing的缺点
这么多事件如何存储？
如果单个聚合根事件多，则重演会造成性能问题
事件丢失了一个怎么办？
应对业务变化难度加大，事件的修改必须兼容以前的结构
数据库订正不在有效
聚合根降级为实体或者实体升级为聚合根的情况怎么办？
历史 = Domain Event + Aggregate Event Handler
聚合根状态必须由事件驱动更改，思维转变难

18. CQRS - 并发问题

19. CQRS - Command分布式路由

20. CQRS - 分布式消息队列(EQueue)

21. CQRS - Command单服务器内部路由

22. Actor Model

23. CQRS – Command Side性能
聚合根In-Memory，避免每次操作聚合根时
要用ES还原聚合根
路由Command，确保对聚合根的修改无并
发
需要高性能分布式队列
需要高性能的Event Store, Command Store
需要将生命周期已结束的聚合根从内存移除
Group Commit Domain Events

24. CQRS – Saga介绍
概念：
Saga是CQRS架构中的一个重要概念，它是一个由事件驱动的流程，
用于解决一些会涉及多个聚合根修改的复杂业务场景（如订单处
理） ，实现数据的最终一致性，目的和long-running process类似。
组成部分：
 流程管理器（Process Manager），无状态，负责整个流程的流
程控制逻辑；监听Domain Event，产生Command
 有一个维护流程状态的聚合根，封装业务逻辑；
 其他一些参与流程的聚合根，封装业务逻辑；
交互模式：
Process Manager监听聚合根产生的Domain Event，决定接下来该
发出什么Command，然后该Command的目标聚合根产生其他的
Domain Event，然后Process Manager再响应，以此下去，直到最
后流程结束

25. CQRS – Saga例子

26. CQRS – Command Store设计
Command Store的主要目的用于对Command的存储及幂等检测
可以用key/value的NoSQL来存储，也可以用关系型DB
根据CommandId来sharding，实现水平拆分、扩容

27. CQRS – Event Store设计
通过AggregateRootId + Version的唯一索引，检测并发冲突
AggregateRootTypeCode实现垂直拆分，AggregateRootId实现水平拆分
Sequence，自增字段，用于动态扩容时为迁移数据提供帮助
也可以用key/value的NoSQL来存储，key为aggId+version的组合

28. CQRS – Query Side 数据一致性问题
关键问题：必须确保C端的事件的存储的顺序与
Q端事件响应的顺序相同
例子：
C端的事件保存顺序：+1,*2,-1 => 1
Q端的事件响应顺序：+1,-1,*2 => 0

29. CQRS – Query Side 数据一致性解决
框架在收到Event后，判断当前聚合根已经响应的事件的version，如果为10，则下
一个只能响应version=11的事件，其他后续的事件都只能等待。
框架在调用每一个Event Handler时，判断该事件是否被该Handler处理过。

30. CQRS – Query Side 存储与性能
用关系型数据存储查询数据
按照第三范式设计表结构
尽可能减少并发冲突，框架会做最大限度的并发
控制，但还需要开发人员配合做好并发控制
通过消息队列异步更新统计信息
单个Master DB多个Slave DB的方式
Master DB根据Domain Event更新
所有查询面向Slave DB
设计其他的NoSQL，提供更多的查询支持，
NoSQL也根据Domain Event更新

31. Thanks
Q/A