比来几年，在DDD的范畴，我们经常会看到CQRS架构的概念。我小我也写了一个ENode框架，专门用来实现这个架构。CQRS架构本身的思惟其实异常简单，就是读写分别。是一个很好懂得的思惟。就像我们用MySQL数据库的主备，数据写到主，然后萌芽大年夜备来查，主备数据的同步由MySQL数据库本身负责，这是一种数据库层面的读写分别。关于CQRS架构的介绍其实已经异常多了，大年夜家可以自行百度或google。我今上帝要想总结一下这个架构相对于传统架构（三层架构、DDD经典四层架构）在数据一致性、扩大性、可用性、伸缩性、机能这几个方面的异同，欲望可以总结出一些长处和缺点，为大年夜家在做架构选型时供给参考。

媒介

CQRS架构因为本身只是一个读写分别的思惟，实现方法多种多样。比如数据存储不分别，仅仅只是代码层面读写分别，也是CQRS的表现；然后数据存储的读写分别，C端负责数据存储，Q端负责数据萌芽，Q端的数据经由过程C端产生的Event来同步，这种也是CQRS架构的一种实现。今天我评论辩论的CQRS架构就是指这种实现。别的很重要的一点，C端我们还会惹人Event Sourcing+In Memory这两种架构思惟，我认为这两种思惟和CQRS架构可以完美的结合，发挥CQRS这个架构的最大年夜价值。

数据一致性

传统架构，数据一般是强一致性的，我们平日会应用数据库事务包管一次操作的所稀有据修改都在一个数据库事务里，大年夜而包管了数据的强一致性。在分布式的场景，我们也同样欲望数据的强一致性，就是应用分布式事务。然则众所周知，分布式事务的难度、成本是异常高的，并且采取分布式事务的体系的吞吐量都邑比较低，体系的可用性也会比较低。所以，很多时刻，我们也会放弃数据的强一致性，而采取最终一致性；大年夜CAP定理的角度来说，就是放弃一致性，选择可用性。

CQRS架构，则完全秉持最终一致性的理念。这种架构基于一个很重要的假设，就是用户看到的数据老是旧的。对于一个多用户操作的体系，这种现象很广泛。比如秒杀的场景，当你下单前，也许界面上你看到的商品数量是有的，然则当你下单的时刻，体系提示商品卖完了。其实我们只要细心想想，也确切如斯。因为我们在界面上看到的数据是大年夜数据库掏出来的，一旦显示到界面上，就不会变了。然则很可能其他人已经修改了数据库中的数据。这种现象在大年夜部分体系中，尤其是高并发的WEB体系，尤其常见。

所以，基于如许的假设，我们知道，即便我们的体系做到了数据的强一致性，用户照样很可能会看到旧的数据。所以，这就给我们设计架构供给了一个新的思路。我们可否如许做：我们只须要确保体系的一切添加、删除、修改操作所基于的数据是最新的，而萌芽的数据不必是最新的。如许就很天然的引出了CQRS架构了。C端数据保持最新、做到数据强一致；Q端数据不必最新，经由过程C端的事宜异步更新即可。所以，基于这个思路，我们开端思虑，若何具体的去实现CQ两端。看到这里，也许你还有一个疑问，就是为何C端的数据是必须要最新的？这个其实很轻易懂得，因为你要修改数据，那你可能会有一些修改的营业规矩断定，如不雅你基于的数据不是最新的，那意味着断定就掉去意义或者说不精确，所以基于老的数据所做的修改是没有意义的。

扩大性

传统架构，各个组件之间是强依附，都是对象之间直接办法调用；而CQRS架构，则是事宜驱动的思惟；大年夜微不雅的聚合根层面，传统架构是应用层经由过程过程式的代码调和多个聚合根一次性以事务的方法完成全部营业操作。而CQRS架构，则是以Saga的思惟，经由过程事宜驱动的方法，最终实现多个聚合根的交互。别的，CQRS架构的CQ两端也是经由过程事宜的方法异步进行数据同步，也是事宜驱动的一种表现。上升到架构层面，那前者就是SOA的思惟，后者是EDA的思惟。SOA是一个办事调用另一个办事完成办事之间的交互，办事之间紧耦合；EDA是一个组件订阅另一个组件的事宜消息，根据事宜信息更新组件本身的状况，所以EDA架构，每个组件都不会依附其他的组件；组件之间仅仅经由过程topic产生接洽关系，耦合性异常低。

膳绫擎说了两种架构的耦合性，显而易见，耦合性低的架构，扩大性必定好。因为SOA的思路，当我要加一个新功能时，须要修改本来的代码；比如本来A办事调用了B,C两个办事，后来我们想多调用一个办事D，则须要改A办事的逻辑；而EDA架构，我们不须要动现有的代码，本来竽暌剐B,C两订阅┞愤订阅A产生的消息，如今只须要增长一个新的消息订阅┞愤D即可。

大年夜CQRS的角度来说，也有一个异常明显的例子，就是Q端的扩大性。假设我们本来Q端只是应用数据库实现的，然则后来体系的拜访量增大年夜，数据库的更新太慢或者知足不了高并发的萌芽了，所以我们欲望增长缓存来竽暌功对高并发的萌芽。那对CQRS架构来说很轻易，我们只须要增长一个新的事宜订阅┞愤，用来更新缓存即可。应当说，我们可以随时便利的增长Q端的数据存储类型。数据库、缓存、搜刮引擎、NoSQL、日记，等等。我们可以根据本身的营业场景，选择合适的Q端数据存储，实现快速萌芽的目标。这一切都归功于我们C端记录了所有模型变更的事宜，当我们要增长一种新的View存储时，可以根据这些事宜获得View存储的最新状况。这种扩大性在传统架构下是很难做到的。

可用性

传统架构，因为读写没有分别，所以可用性要把读写合在一路综合推敲，难度会比较更大年夜。因为传统架构，如不雅一个体系的岑岭弃的并发写入很大年夜，比如为2W，并发攫取也很大年夜，比如为10W。那该体系必须优化到能同时支撑这种高并发的写入和萌芽，不然体系就会在岑岭时挂掉落。这个就是基于同步调用思路的体系的缺点，没有一个器械去削峰填谷，保存刹时多出来的请求，而必须让体系不管碰到若干请求，都必须能及时处理完，不然就会造成雪崩效应，造成体系瘫痪。然则一个体系，不会一向处在岑岭，岑岭可能只有半小时或1小时；但为了确保岑岭时体系不挂掉落，我们必须应用足够的硬件去支撑这个岑岭。而大年夜部分时刻，都不须要这么高的硬件资本，所以会造成资本的浪费。所以，我们说基于同步调用、SOA思惟的体系的实现成本是异常昂贵的。

　　推荐阅读

　　如何阅读框架源代码

一、懂得框架解决了什愦问题不管对于那个段位的 Developer 来说，读源码都是一件好处颇多的工作，特别于初学者而言，这能敏捷的吸纳优良框架精华代码养分，敏捷成长。不巧的是，晦涩难解的>>>详细阅读

本文标题：DDD CQRS架构和传统架构的优缺点比较

地址：http://www.17bianji.com/lsqh/36067.html

 1/2    1