广州手机网站建设哪家好,软件外包合同模板,丰台网站开发联系电话,南县做网站多少钱在日常工作中#xff0c;你是否也遇到过下面几种情况#xff1a; 使用一个已有接口进行业务开发#xff0c;上线后出现严重的性能问题#xff0c;被老板当众质疑#xff1a;“你为什么不使用缓存接口#xff0c;这个接口全部走数据库#xff0c;这怎么能抗住#xff01…在日常工作中你是否也遇到过下面几种情况 使用一个已有接口进行业务开发上线后出现严重的性能问题被老板当众质疑“你为什么不使用缓存接口这个接口全部走数据库这怎么能抗住” 开发一个后台管理功能业务反馈说数据一直不对对比后发现缓存与数据库不一致为什么要使用缓存接口呢你陷入沉思 产品要求在 xxx 上增加新功能编码、测试、上线一气呵成最后发现另外一个流程被躺枪出现异常不得不进行回滚 在一个高并发的场景DB 成为了系统瓶颈不加索引查询扛不住加索引更新扛不住又该如何处理 随着数据量的激增系统变得越来越慢特别是后台管理复杂的查询场景下复杂的 Join 让 DB 不堪重负 ……
为什么会出现这种现象其本质仍旧是代码组织结构不合理我们将不同的复杂性揉在一起从而造成了更大的复杂性然后如此往复不知不觉中陷入巨大的复杂性旋涡不可自拔。 1. CQRS 是什么
CQRS 是 Command Query Responsibility Segregation 得简称简单理解就是对 “写”Command 和 “读” Query操作进行分离。反应快的同学会说“也不是什么高深技术吗不就是数据库的读写分离吗”
是的数据库的读写分离也算是一种 CQRS但 CQRS 的含义要比这复杂的多。 CRQS 既是一种流行的业务架构又是一种设计思维。 CQRS 的核心是“拆分”将复杂系统拆分为 Command 和 Query 两个部分针对不同的场景使用不同的模式选择最合适的技术落地最佳解决方案避免两者相互掣肘相互影响。
CQRS的目的是降低整个系统的复杂性那它背后的逻辑是什么
假设在一个系统中 Command 的复杂性为 M Query 的复杂性为 N
如果使用同一套模型来处理 Command 和 Query那在极端情况下系统的复杂性为 M * N因为两者相互影响调整一方的同时要时刻关注对另一方的影响。
这种“你中有我我中有你”的设计方式“两者的相互影响”成为系统最为复杂之处大量精力消耗在“排查影响”而非最有价值的设计和编码。
如果将 Command 和 Query 彻底分离系统的复杂性变成 M N。Command 的变更不会影响 Query而 Query 的修改也不会影响 Command。
当然以上两个极端在实际工作中也很少见通常系统的复杂性介于两者之间。
这只是从理论进行推导在实际工作中随处可见的“冲突”也是对“拆分”的一种暗示。 2. 分层架构中的冲突
以最常见的分层架构进行介绍具体如下 如图所示将系统分成5层每层的含义如下 Web 接入层。主要用于处理系统输入对输入信息进行验证调用应用服务完成业务操作对结果进行转换最终返回给调用方 应用服务层。主要处理业务流程编排从仓库中获取领域对象执行领域模型的业务操作将最新的对象状态通过仓库同步到数据存储引擎并对外发布领域事件 领域层。业务逻辑的承载点是业务价值的集中体现通常构建于面向对象设计之上基于封装、继承、多态等特性保障业务逻辑的复用性和扩展性 仓库层。主要用于数据访问向上为应用服务提供数据操作服务向下屏蔽各类存储引擎的差异 数据层。主要用于数据保存和检索常见的数据存储引擎全部属于这一层比如 MySQL、Redis、ES 等
其实分层架构本身也是一种“拆分”将不同的关注点封装在不同的层次。但除了横向分层还可以基于 CQRS 对其进行纵向拆分也就是将每个层的组件拆分为 Command 和 Query 两部分。 由于接入层冲突较小本身拆分的意义不大在此不做要求但从严格意义上讲仍旧建议进行拆分。 3. 应用服务层冲突与拆分
应用服务层拆分就是将一个应用服务拆分为 CommandService 和 QueryService 两组。 这样做可以避免很多不必要的麻烦Command 和 Query 存在较大的区别具体如下
CommandServiceQueryService依赖组件不同ValidateService 验证服务LazyLoaderFactory 延迟加载服务CommandRepository 不带缓存的仓库EventPublisher 事件发表器QueryRepository 带缓存功能的仓库JoinService 数据聚合服务Converter 数据转换服务核心流程不同验证、加载、业务操作、同步、发布事件验证、加载、数据组装、转换功能加强不同主要是事务管理器主要是缓存组件
回想开篇时提到的场景完成应用层拆分就不在为使用错组件而烦恼 CommandService 的 Repository 不使用缓存仅操作数据库 QueryService 的 Repository 可以使用缓存以提升访问性能
除此之外针对统一的操作流程还可以进一步抽象来消除重复的“模板代码”比如 引入“模板方法设计模式” 以达到核心逻辑的复用 抽象出 BaseCommandService 和 BaseQueryService 两个父类用于统一核心流程 子类实现 BaseCommandService 和 BaseQueryService 的抽象方法完成功能扩展 基于“约定优于配置” 使用 Proxy 模型只定义接口不写实现代码 按规范定义 CommandService 和 QueryService 接口通过注解完成相关配置 自动生成 Proxy 实现类完成流程编排 4. 模型层冲突与拆分
模型层是系统的核心它的设计直接影响整个系统的质量。作为承接业务逻辑的核心比较流程的实现策略包括 DDD 领域驱动设计其核心是使用面向对象的高级特性封装、继承、多态、组合等来进行设计非常适合复杂的业务场景。其体现就是存在很多高内聚低耦合的对象组聚合根业务逻辑由这些小对象相互协作共同完成 事务脚本使用过程式思维将数据操作编织到流程中比较适合并不复杂的业务场景。其体现就是存在很多“上帝 Service”Service 中存在很多非常长的方法业务逻辑由这些方法完成
关于哪个才是最优解网上已经争论多年最终也没有结论。但我始终认为“没有业务场景就讨论方案就是在耍流氓”。
从不同应用场景出发便可得到如下结论 Command 场景需要保障严谨的业务逻辑通常复杂性偏高所以DDD 是最优解 Query 场景需要更灵活的数据组装能力作为支持通常比较简单所以 事务脚本 是最优解 我经常说“最简单的“写”也是复杂最复杂的“读”也是简单”其背后逻辑是基于对 Command 和 Query 的场景判断。 将模型拆分为 Command 和 Query具体如下 完成模型拆分后新模型具有以下特征 Agg 也就是 DDD 中聚合根主要用于处理复杂的 Command 逻辑由具有大量业务操作的富对象构成 View 是标准的 POJO主要充当 Query 结果对象典型的“贫血对象”仅作为数据的载体根据展示需求对数据进行组装 View 没有自己的 Repository只能依赖 CommandRepository 获取数据Converter 组件负责将 Agg 模型转换为 View 模型
这块是拆分的重点为了方便理解简单举个例子
比如在电商的订单模块 生单流程由 Order 作为聚合根对内部 OrderItem 和 PayInfo 进行统一协调 订单列表页只需展示 Order 和 User 信息 订单详情需要展示Order、User、Address、OrderItem、PayInfo、Product等信息
如果让一个模型同时支持着三个场景那模型自己就变的非常复杂很难判断某个方法、某个字段究竟属于哪个场景。
此时应该根据场景对模型进行拆分 OrderBO 以 DDD 方式进行建模对外提供统一的业务操作对内协调 OrderItem 和 PayInfo 等多个实体对象 OrderListVO 以 POJO 方式进行建模属性中包含 Order 和 User 信息 OrderDetailVO 以 POJO 方式进行建模属性中包括 Order、User、Address、OrderItem、PayInfo、Product 等信息
三个模型相互独立互不影响。
当然由于使用统一的 Repository 还需提供对应 VO 的 Converter OrderListVOConverter 将 OrderBO 转换为 OrderListVO 对象 OrderDetailVOConverter 将 OrderBO 转化为 OrderDetailVO 对象 5. 仓库层冲突与拆分
仓库层拆分也是非常有必要的在这一层主要有几项冲突
CommandRepositoryQueryRepository底层实现不同主要基于 DB 实现基于 DB、Redis、ES 等多种存储引擎方法复杂性不同提供仅有的少量方法并足以支持大多数场景比如 save、update、getById 等根据业务场景进行定制方法多种多样单条、批量、分页、排序、统计等维度多种多样id、user、status返回值不同直接返回装配完整的富对象根据业务场景定制返回值
仓库拆分后整体架构如下 仓库拆分具有以下特点 View 不在需要 Converter 组件完成数据转换 View 的数据来自于自己的 Repository可以根据展示需求进行灵活定制 Command 和 Query 仍旧使用同一套数据库、同一套数据表 6. 数据层冲突与拆分
数据层拆分是最重要的拆分提到分离第一反应也是“数据库主从分离”。
数据层拆分的本质是各种数据存储引擎的最佳应用场景相差巨大读 和 写 优化往往存在矛盾。
仍旧以最常见的数据库为例 提升查询性能建议为各种查询维度建立索引 提升写入性能需要让表上的索引越来越少 为了加速更新性能建议使用三范式设计表结构减少冗余信息 为了加速查询性能建议使用反范式设计尽量冗余数据避免数据表间的 Join 操作
鱼和熊掌不可兼得在数据库层展示的淋漓尽致
数据层拆分后架构如下 该模型具有以下特点 数据存储进行了彻底拆分Command 和 Query 都可以灵活的选择最合适的存储引擎 Command 与 Query 需要引入一套同步机制以完成两者的数据同步常见的同步机制有 工作在应用层基于领域事件的数据同步如图所示 工作在数据层基于log的数据同步如 MySQL 的主从同步、Canal2XX 等
数据层拆分是大型系统最终的归宿仍旧以订单系统为例 订单作为一致性要求极高的系统Command 侧首选仍旧为具有 ACID 的关系型数据库哪怕是分库分表底层存储仍旧不变 为了满足高性能查询需求需要在 Query 侧引入 Redis 作为分布式缓存对访问进行加速 为了满足后台复杂且多维度的业务查询需要在 Query 侧引入 ES 为全文检索进行加速 为了满足各种实时报表需求需要在 Query 侧引入 TiDB 以满足海量数据的实时检索 这就是我们面临的现状“数据密集型系统”越来越多的应用程序有着各种严格而广泛的要求单个工具不足以满足所有的数据处理和存储需求。取而代之的是总体工作被拆分成一系列能被单个工具高效完成的任务并通过应用代码将它们缝合起来通过 API 的方式对外提供服务屏蔽内部的复杂性。 7. 关系型数据库性能提升方法
提升关系数据库性能是许多大型应用程序和网站面临的重要挑战之一。以下是两种常见的提升关系数据库性能的方式
读写分离Read-Write Separation 概念读写分离是一种将数据库的读操作和写操作分开处理的策略。通常应用程序的读操作远远多于写操作因此可以将读操作分配给一个或多个只负责读取数据的数据库服务器而将写操作发送到主数据库服务器。 工作流程 主数据库写数据库负责处理写操作包括插入、更新和删除数据。从数据库读数据库负责处理读操作包括查询数据。从数据库通常是主数据库的复制以确保数据的一致性。 优势 提高读操作的性能因为它们可以并行处理。减轻主数据库的负载使其更专注于写操作。提高数据库的可伸缩性通过添加更多的从数据库来支持更多的读操作。 注意事项 数据复制可能导致一些延迟因此读操作可能不会立即反映最新的写操作。需要考虑数据一致性和同步策略。 分库分表Sharding 概念分库分表是一种将数据库拆分成多个独立的子数据库或数据表的策略。每个子数据库或表负责存储特定范围或条件下的数据。这样查询和写入可以分布到不同的数据库节点减轻单一数据库的负载。 工作流程 数据库表水平分片根据数据的某个字段例如用户ID或时间戳将数据分布到不同的表中。数据库库水平分片根据数据的某个属性例如地理位置或业务类型将数据分布到不同的数据库中。 优势 提高数据库的扩展性因为数据可以分布在多个节点上。减轻单一数据库的负载提高性能。使数据库更容易维护和备份因为数据分散存储。 注意事项 需要设计良好的分片策略以确保数据均匀分布。需要跨分片执行查询时可能需要复杂的查询计划。
这些方法可以单独或结合使用根据应用程序的需求和性能要求来选择。例如一个大型电子商务网站可以使用读写分离来提高产品搜索的性能并使用分库分表来处理订单数据的存储和检索。综合考虑这些策略可以帮助应对不同层面的数据库性能挑战。 8. 小结
“拆分”是“分离关注点”的重要手段之一。拆分的目的是将问题进行归类然后采取有针对性的手段更好的解决问题。
CQRS 作为一种架构将业务系统不同部分进行归类接下来需要为 Command 和 Query 寻找最优解决方案 Command以 DDD 作为理论基础将战术模型中最佳实战进行落地包括 聚合设计 仓库设计 LazyLoad Context 模式 业务验证 领域事件 … Query以数据检索和组装作为核心能力设计留给开发人员实现留给框架包括 QueryObject 查询对象模式 内存 Join 模式 宽表冗余表模式
