所以，总体来说，机能瓶颈方面，两种架构都能克服。而只要克服了机能瓶颈，那伸缩性就不是问题了（当然，这里我没有推敲数据损掉而带来的体系弗采取的问题。这个问题是所有架构都无法躲避的问题，独一的解决办法就是数据冗余，这里不做展开了）。两者的瓶颈都在数据的持久化上，然则传统的架构因为大年夜部分体系都是要存储数据到关系型数据库，所以只能本身采取分库分表的筹划。而CQRS架构，如不雅我们只存眷C端的瓶颈，因为C端要保存的器械很简单，就是敕令和事宜；如不雅你信的过一些成熟的NoSQL（我认为应用文档性数据库如MongoDB这种比较合适存储敕令和事宜），且你也有足够的才能和经验去运维它们，那可以推敲应用NoSQL来持久化。如不雅你认为NoSQL靠不住或者没办法完全掌控，那可以应用关系型数据库。但如许你也要付出尽力，比如须要本身负责分库分表来保存敕令和事宜，因为敕令和事宜的数据量都是很大年夜的。不过今朝一些云办事如阿里云，已经供给了DRDS这种直接支撑分库分表的数据库存储筹划，极大年夜的简化了我们存储敕令和事宜的成本。就我小我而言，我认为我照样会采取分库分表的筹划，原因很简单：确保数据靠得住落地、成熟、可控，并且支撑这种只读数据的落地，框架内置要支撑分库分表也不是什么难事。所以，经由过程这个比较我们知道传统架构，我们必须应用分库分表（除非阿里这种高大年夜上可以应用OceanBase）；而CQRS架构，可以带给我们更多选择空间。因为持久化敕令和事宜是很简单的，它们都是弗成修改的只读数据，且对kv存储友爱，也可以选择文档型NoSQL，C端永远是新增数据，而没有修改或删除数据。最后，就是关于Q端的瓶颈，如不雅你Q端也是应用关系型数据库，那和传统架构一样，该怎么竽暌古化就怎么竽暌古化。而CQRS架构许可你应用其他的架构来实现Q，所以优化手段相对更多。
停止语
我认为不论是传统架构照样CQRS架构，都是不错的架构。传统架构门槛低，懂的人也多，且因为大年夜部分项目都没有什么大年夜的并发写入量和数据量。所以应当说大年夜部分项目，采取传统架构就OK了。然则经由过程本文的分析，大年夜家也知道了，传统架构确切也有一些缺点，比如在扩大性、可用性、机能瓶颈的解决筹划上，都比CQRS架构要弱一点。大年夜家有其他看法，迎接拍砖，交换才能进步，呵呵。所以，如不雅你的应用处景是高并发写、高并发读、大年夜数据，且欲望在扩大性、可用性、机能、可伸缩性上表示更优良，我认为可以测验测验CQRS架构。然则还有一个问题，CQRS架构的门槛很高，我认为如不雅没有成熟的框架支撑，很难应用。而今朝据我懂得，业界还没有很多成熟的CQRS框架，java平台有axon framework, jdon framework；.NET平台，ENode框架正在朝这个偏向尽力。所以，我想这也是为什么今朝几乎没有应用CQRS架构的成熟案例的原因之一。另一个原因是应用CQRS架构，须要开辟者对DDD有必定的懂得，不然也很难实践，而DDD本身要懂得没个几年也很难应用到实际。还有一个原因，CQRS架构的核心是异常依附于高机能的分布式消息中心件，所以要选型一个高机能的分布式消息中心件也是一个门槛（java平台有RocketMQ），.NET平台我小我专门开辟了一个分布式消息队列EQueue，呵呵。别的，如不雅没有成熟的CQRS框架的支撑，那编码复杂度也会很复杂，比如Event Sourcing，消息重试，消息幂等处理，事宜的次序处理，并发控制，这些问题都不是那么轻易搞定的。而如不雅有框架支撑，由框架来帮我们搞定则些纯技巧问题，开辟人员只须要存眷若何建模，实现范畴模型，若何更新读库，若何实现萌芽，那应用CQRS架构才有可能，因为如许才可能比传统的架构开辟更简单，且能获得很多CQRS架构所带来的好处。
【编辑推荐】
- 架构的本质，万千办法中的道
- iOS收集层架构设计分享
- 为什么 Linus Torvalds 偏爱x86而不是ARM架构
- 微办事架构：基于微办事和Docker容器技巧的PaaS云平台架构设计（微办事架构实施道理）
- 谈一下关于CQRS架构若何实现高机能
推荐阅读
一、懂得框架解决了什愦问题不管对于那个段位的 Developer 来说，读源码都是一件好处颇多的工作，特别于初学者而言，这能敏捷的吸纳优良框架精华代码养分，敏捷成长。不巧的是，晦涩难解的>>>详细阅读
地址：http://www.17bianji.com/lsqh/36067.html
1/2 1
网友点评
精彩导读
科技快报
品牌展示