蓝盟IT小贴士，来喽！
出现在开头
随着业务的发展，软件系统的体系结构也越来越复杂，但无论多么复杂的业务最终在系统中实现，也不过是读写操作而已。 用户根据业务规则写入业务数据，然后根据查询规则获得所需的结果。 这些读写的数据通常存储在一个数据库中，并在一个模型中读写。 由于在大型系统中，查询操作远远多于写入操作，因此考虑分别定义读取操作和写入操作的模型，并提供不同的通道供用户使用。 cqrs (命令- Queryresponsibilitysegregation )是基于这一思想提供的模式读写分离模型，今天我们围绕它谈以下内容
CQRS的发展和体系结构
事件源的原理及应用
事件源和CQRS的完美结合
CQRS示例
CQRS的发展和体系结构
cqrs (命令- Queryresponsibilitysegregation )是读写分离的模型，命令是命令的意思，意味着写入操作。 Query是查询的意思，表示查询操作。 该模式的主要思想是将数据写入操作和查询操作分开。
来源于Bertrand Mayer设计的命令查询分离(CQS )原理。 CQS声明类只有两种方法：更改状态并返回void和返回状态。 Greg Young是负责将该模型命名为CQRS并将其推广的人。
传统的系统请求从最左侧的客户端开始，沿着红线向右通过应用程序服务请求系统。 在这里，应用程序服务可以理解为系统的门面，或控制器层负责接收客户端的请求。 在这种情况下，请求的内容基本上与数据库中的信息一致，因此在此使用数据传输对象(dto )直接请求。 DTO经过Domain Model直接到达数据库，沿着蓝线返回客户端。 传统的请求方式的部分读取和写入操作使用相同的数据模型和域模型组相同的数据库。
从以往的操作来看，客户端的要求经过应用服务器，用户的意图全部被分解为CRUD操作，但在Domain Model中没有出现。 保证DTO的完整性和一致性，将无关信息嵌入到DTO中，查询和创建操作共享一个DTO，弱化了域模型的业务流程。 为了同时适应查询和制作操作，DTO的设计面很齐全，很臃肿。 传输过程中存在不必要的现场传输。另外，通过一次操作，在DTO和区域对象之间进行了多次变换，增加了系统的复杂性。 另外，读写操作以相同的数据模型为中心展开，在读写少的系统中效率不高，特别是在以读取操作为中心的高并发系统中缺点明显。
由于传统的系统架构存在上述问题，CQRS根据读写的作用，将域模型分为命令侧和查询侧两部分，如图2所示，红线部分为命令侧，其对应关系为域名模式
Query端作为查询操作，用蓝线表示，通过Query Model向数据库获取信息，在黑色的左前方将结果返回给客户端。 命令端和查询端都通过应用服务器进入系统，共享相同的数据库，但命令端只写入状态，查询端只读取状态。
虽然现在读写操作是分离的，但两种操作仍然共享一个数据库，所以为了提高读写效率，数据库的分离成为了必然的选择。 如图3所示，将原数据库分离为writer数据库和reader数据库，分别用于写入操作和读取操作。 为了确保读写操作的数据完整性，需要在两个数据库之间进行数据同步。
由于数据同步具有时效性，写入端为命令端，读取端为查询端，因此系统智能可以保证最终的一致性。 那么，如何保证两个库之间的同步呢？ 需要引入事件源的概念。
事件源的原理及应用
Event Sourcing也被称为事件跟踪，是Martin Fowler提出的架构模型。 其设计思想是系统中的业务全部由事件驱动进行。 系统中记录的是表示信息状态的事件。 业务数据可以是事件生成的视图，不需要保存在数据库中。
文/上海蓝盟 IT外包专家
中文
电话咨询
微信咨询
公众号
