对CQRS涉及架构的简单学习笔记

对CQRS涉及架构的简单学习笔记

一. CQRS的基础Event Sourcing

了解CQRS涉设计模式之前，需要先了解Event Sourceing的思想。

1. Event Sourceing是通过每一个原子事件来记录发展流向(改变)，同时对每一个事件都记录下来，而不是只关心最终结果。
2. 事件对象是自己响应，并更新自身状态，过程中不断持久化各阶段。
3. 利用空对象和上述的持久化过程，能够快速恢复数据和业务流程。
4. 事件不可修改的属性，有效避免了并发的问题。事件只有不断的新增。

CQRS其实就是在vent Sourcing的基础之上，分离出读写和视图。

二. CQRS作为DDD的一种解决档案

由于传统的分层模型无法较好满足DDD(设计过于复杂)，因此诞生了CQRS模型。

//最为简单的一个DDD模型
//单一数据源导致设计过程中偏向于数据模型而不是行为模型、设计阶段都基于数据库结构设计
var acc = new Account();
var acc2 = new Account();
acc.Balance+=10;acc2.Balance-=10;
//贫血模型
public class Account {
    public decimal Balance
    {
        get;
        set;
    }
}

CQRS代表“Command Query Responsibility Segregation”,也就是我们常说的读写隔离，这意味着你应该将读写分成应用程序的两个不同部分。分别为command和query

**下图表示CQRS的读写分离的操作** [](https://imgchr.com/i/sPLjN6) command： 1. 写的过程使用命令，基于事件驱动。 2. 命令处理程序将该命令应用于领域类 3. 领域类发送一个发生的事件 4. 事件处理程序捕获这些事件并保存这些更改 5. 事件持久化

query：

1. 保存事件的最终状态
2. 直接调用读取查询视图(类似于缓存)

• 在写的过程中引入多个service层，但时每个service职责单一
• 命令处理程序唯一做的就是接受命令并找到正确的实体（或者如果我们用DDD的术语叫做aggregate聚合）以应用命令。
• 事件处理程序仅负责将更改应用于数据库。

命令发布到同一个队列，同一个队列总是被一台固定的机器消费，保证消息的顺序以及并发过程中数据的一致性。

三. CQRS优缺点

优点：

1. 读写分离提高了系统的可用性。
2. 事件机制，能提高系统的可用性，可以有效避免雪崩事件。通过中间件解耦，也提高了扩展性。
3. 相比较接口直接调用，利用中间件的方式可以提高数据传输的可靠性。
4. 记录过程日志，可以还原数据各阶段状态(保证代码逻辑的向前兼容)
   缺点：
5. 大数据量的存储和查询
6. 数据库的数据订正较难产生效果

四. 使用场景

1. 当我们的应用的写模型和读模型差别比较大时；
2. 当我们希望实践DDD时；因为CQRS架构可以让我们实现领域模型不受任何ORM框架带来的对象和数据库的（O/R）阻抗失衡的影响；
3. 当我们希望对系统的查询性能和写入性能分开进行优化时，尤其是读/写比非常高的系统，CQ分离是必须的；
4. 希望我们的系统同时满足高并发的写、高并发的读的时候；因为CQRS架构可以做到C端最大化的写，Q端非常方便的提供可扩展的读模型；

参考目录：
https://www.imooc.com/article/40858
https://blog.csdn.net/quguang65265/article/details/93596884
https://www.cnblogs.com/netfocus/p/4150084.html