问题背景:
在DDD的架构设计中最难以解决的就是一致性问题,所以我采纳是BASE的最终一致性的方式,至于最终一致性的概念,不在本博客中阐述,设计理念,不外乎就是弥补的方式。
可用性,无论是传统架构还是CQRS架构,都可以做到高可用,只要我们做到让我们的系统中每个节点都无单点即可。但是,相比之下,我觉得CQRS架构在可用性方面,我们可以有更多的回避余地和选择空间。
传统架构,因为读写没有分离,所以可用性要把读写合在一起综合考虑,难度会比较更大。因为传统架构,如果一个系统的高峰期的并发写入很大,比如为2W,并发读取也很大,比如为10W。那该系统必须优化到能同时支持这种高并发的写入和查询,否则系统就会在高峰时挂掉。这个就是基于同步调用思路的系统的缺点,没有一个东西去削峰填谷,保存瞬间多出来的请求,而必须让系统不管遇到多少请求,都必须能及时处理完,否则就会造成雪崩效应,造成系统瘫痪。但是一个系统,不会一直处在高峰,高峰可能只有半小时或1小时;但为了确保高峰时系统不挂掉,我们必须使用足够的硬件去支撑这个高峰。而大部分时候,都不需要这么高的硬件资源,所以会造成资源的浪费。所以,我们说基于同步调用、SOA思想的系统的实现成本是非常昂贵的。
而在CQRS架构下,因为CQRS架构把读和写分离了,所以可用性相当于被隔离在了两个部分去考虑。我们只需要考虑C端如何解决写的可用性,Q端如何解决读的可用性即可。C端解决可用性,我觉得是更加容易的,因为C端是消息驱动的。我们要做任何数据修改时,都会发送Command到分布式消息队列,然后后端消费者处理Command->产生领域事件->持久化事件->发布事件到分布式消息队列->最后事件被Q端消费。这个链路是消息驱动的。相比传统架构的直接服务方法调用,可用性要高很多。因为就算我们处理Command的后端消费者暂时挂了,也不会影响前端Controller发送Command,Controller依然可用。从这个角度来说,CQRS架构在数据修改上可用性要更高。不过你可能会说,要是分布式消息队列挂了呢?呵呵,对,这确实也是有可能的。但是一般分布式消息队列属于中间件,一般中间件都具有很高的可用性(支持集群和主备切换),所以相比我们的应用来说,可用性要高很多。另外,因为命令是先发送到分布式消息队列,这样就能充分利用分布式消息队列的优势:异步化、拉模式、削峰填谷、基于队列的水平扩展。这些特性可以保证即便前端Controller在高峰时瞬间发送大量的Command过来,也不会导致后端处理Command的应用挂掉,因为我们是根据自己的消费能力拉取Command。这点也是CQRS C端在可用性方面的优势,其实本质也是分布式消息队列带来的优势。所以,从这里我们可以体会到EDA架构(事件驱动架构)是非常有价值的,这个架构也体现了我们目前比较流行的Reactive Programming(响应式编程)的思想。
然后,对于Q端,应该说和传统架构没什么区别,因为都是要处理高并发的查询。这点以前怎么优化的,现在还是怎么优化。但是就像我上面可扩展性里强调的,CQRS架构可以更方便的提供更多的View存储,数据库、缓存、搜索引擎、NoSQL,而且这些存储的更新完全可以并行进行,互相不会拖累。理想的场景,我觉得应该是,如果你的应用要实现全文索引这种复杂查询,那可以在Q端使用搜索引擎,比如ElasticSearch;如果你的查询场景可以通过keyvalue这种数据结构满足,那我们可以在Q端使用Redis这种NoSQL分布式缓存。总之,我认为CQRS架构,我们解决查询问题会比传统架构更加容易,因为我们选择更多了。但是你可能会说,我的场景只能用关系型数据库解决,且查询的并发也是非常高。那没办法了,唯一的办法就是分散查询IO,我们对数据库做分库分表,以及对数据库做一主多备,查询走备机。这点上,解决思路就是和传统架构一样了。
相关推荐
DDD-分布式微服务系统架构脑图
在分布式系统中,分布式事务需要特别注意,因为它涉及到多个服务的数据一致性问题,这通常通过两阶段提交、三阶段提交或者最终一致性等技术来解决。高并发设计关注的是如何在系统中处理大量同时发生的请求,常见做法...
其分层架构模型是DDD的核心设计模式,它将系统分为用户接口层、应用层、领域层和基础层,旨在清晰界定各层职责,促进模块化和可维护性。本文将深入探讨这四个层次的职责与功能,并结合微服务代码模型,展示如何在...
不同于其它的架构方法,领域驱动设计DDD(DomainDrivenDesign)提出了从业务设计到代码实现一致性的要求,不再对分析模型和实现模型进行区分。也就是说从代码的结构中我们可以直接理解业务的设计,命名得当的话,非...
Eric Evans 在《领域驱动设计-软件核心复杂性应对之道》这本书中提出了传统的四层架构模式,如下图所示: 1. User Interface 为用户界面层(或表示层),负责向用户显示信息和解释用户命令。这里指的用户可以是另...
, 《实现领域驱动设计》分别从战略和战术层面详尽地讨论了如何实现DDD,其中包含了大量的最佳实践、设计准则和对一些问题的折中性讨论。《实现领域驱动设计》共分为14 章,在DDD 战略部分,《实现领域驱动设计》向...
业务架构设计是指对企业的业务进行整体规划和设计,以确保业务的连续性和发展。领域驱动设计(Domain-Driven Design,DDD)是指一种基于领域模型的软件开发方法,它强调业务领域的理解和分析,并将其转化为软件设计...
领域驱动设计(DDD)架构的实践 如何让DDD落地 淘宝应用架构升级 - 反应式架构的探索与实践 微服务的容器化实践 物联网平台的反应式设计 演进式架构的平台化落地 用状态机封装领域逻辑 在一个实际复杂业务中落地DDD...
8.1.行业架构设计_设计方法.pptx 8.2.行业架构设计_设计过程.pptx 9.行业架构设计_核心技术.pptx 10.分布式系统设计实战.pptx 11.系统实战需求物料.pptx 另还有企培专家课程:设计理念和开发,面向企业架构师和中层...
领域驱动设计(DDD)是一种软件开发方法,由Eric Evans在其同名著作《领域驱动设计》中提出。...对于希望提升软件质量、增强业务灵活性和适应性的团队来说,DDD是一个值得深入研究和实践的设计方法。
8.1.行业架构设计_设计方法.pptx 8.2.行业架构设计_设计过程.pptx 9.行业架构设计_核心技术.pptx 10.分布式系统设计实战.pptx 11.系统实战需求物料.pptx 另还有企培专家课程:设计理念和开发,面向企业架构师和中层...
8.1.行业架构设计_设计方法.pptx 8.2.行业架构设计_设计过程.pptx 9.行业架构设计_核心技术.pptx 10.分布式系统设计实战.pptx 11.系统实战需求物料.pptx 另还有企培专家课程:设计理念和开发,面向企业架构师和中层...
8.1.行业架构设计_设计方法.pptx 8.2.行业架构设计_设计过程.pptx 9.行业架构设计_核心技术.pptx 10.分布式系统设计实战.pptx 11.系统实战需求物料.pptx 另还有企培专家课程:设计理念和开发,面向企业架构师和中层...
8.1.行业架构设计_设计方法.pptx 8.2.行业架构设计_设计过程.pptx 9.行业架构设计_核心技术.pptx 10.分布式系统设计实战.pptx 11.系统实战需求物料.pptx 另还有企培专家课程:设计理念和开发,面向企业架构师和中层...
8.1.行业架构设计_设计方法.pptx 8.2.行业架构设计_设计过程.pptx 9.行业架构设计_核心技术.pptx 10.分布式系统设计实战.pptx 11.系统实战需求物料.pptx 另还有企培专家课程:设计理念和开发,面向企业架构师和中层...
8.1.行业架构设计_设计方法.pptx 8.2.行业架构设计_设计过程.pptx 9.行业架构设计_核心技术.pptx 10.分布式系统设计实战.pptx 11.系统实战需求物料.pptx 另还有企培专家课程:设计理念和开发,面向企业架构师和中层...
8.1.行业架构设计_设计方法.pptx 8.2.行业架构设计_设计过程.pptx 9.行业架构设计_核心技术.pptx 10.分布式系统设计实战.pptx 11.系统实战需求物料.pptx 另还有企培专家课程:设计理念和开发,面向企业架构师和中层...
总的来说,DDD是一种以业务为中心的开发方法论,它强调领域建模的重要性,提倡分析设计的融合,以及通过DCI架构实现业务逻辑的清晰表达。通过DDD,开发者能够更好地应对复杂系统的挑战,构建出更符合业务需求、更...
最新领域驱动设计(DDD)资料合集,共23份。 金融支付系统的改造之路 化繁为简--DDD驱动复杂业务软件架构的演进 基于DDD的领域建模中的模版和工具实践 基于FP的DDD实践 架构分层模型适配 可视化的遗留系统微服务...