浅析CQRS的应用部署

CQRS,中文翻译命令和查询职责分离,它是一种架构,不仅可以从数据库层面实现读写分离,在代码层面上也是推荐读写分离的。在接口上可以更为简单

命令端定义

ICommandResult Execute(ICommand command)

查询端定义

IQueryResult Fetch(IQuery query)

它的好处是CQ每端对外只有一个接口,职责单一。带来的不便就是要定义好多命令(Command)和查询(Query)对象。但相比定义好多个接口个人觉得还是这样的方式更好。

CQRS不是一个特别炫丽的架构,我觉得他更多的是为了解决数据显示的复杂性。在实际项目中,往往是要查询的数据非常复杂和多样性(也许你并不认同),这样就可以针对查询定义相对需要的ReadModel,也可以设计多个有针对性的读库。

当我们的应用程序开发完之后就需要发布部署了,在部署之前你的应用程序需要有个宿主可以对外提供服务,它可以是WebService,Wcf,WebApi等等。

单机

单机是一个最简单的部署方式,优点是维护和部署起来很方便, 缺点是一旦宕机你的整个服务将不可用,处理能力有限,更新应用程序可能要停止服务。

集群

最简单的方式是部署多个单机,利用DNS轮询就可以实现简单的负载均衡,这种方案的缺点就是存在会话丢失,这是因为上一次的会话是在服务器1上,可能下一次的会话DNS就会将域名指向服务器2上,可以采用Cookie或者其他方案解决这一问题。还有就是这一集群方式在处理并发上难度较大,当然也可以采用乐观锁和数据库的悲观锁机制,不过这会带来性能问题。

上图只是对单机集群的一种扩展,Connection Manager负责管理与客户端的连接及请求,然后将具体的命令和查询转发到具体的Server,以达到负载均衡的目的,同时它可以将处理相同命令的请求路由到同一个服务器上,可以初步解决并发问题。这种方案也有点类似ngixn,缺点就是带宽压力较大

分布式

上图的部署方式将命令和查询服务严格区分开来,利用消息队列达到流量削锋、应用解藕和异步处理的目的。命令服务接收到命令后将其发送到Kafka,将相同类型的命令发送到同一topic中,再根据Key分发到不同的partition上,利用Kafka的Rebalance动态添加消费服务,这样的话就可以当请求过多时增加服务,闲时减少服务,非常灵活。

个人觉得这样的部署有类似微服务,在此基础上还可以分离出ValidationService和AuthenticationService等,如CommandService接收到命令后通过验证服务后再发送到Kafka中,同时也是将软件层面的AOP替换成服务层面,每个CommandConsumer像是一个黑盒,外部无法访问。

简单的示例可以参考 https://github.com/imyounghan/umizoo/tree/master/src/Samples

上图是对图2和图3的一个整合,利用了各自的优点。还有一种方案就是Connection Manager提供给客户端一个可用的CommandService或QueryService与客户端进行直连,这样可以避免所有的请求都要经过Connection Manager,减轻Connection Manager的带宽压力,可以参照P2P的思路。

采用了分布式后会导致服务增多,问题也会增多,管理起来也会变得复杂,可以借助Zookeeper来管理监控这些服务。总之分布式情况下要考虑的问题会有很多,本文也无逐一续清,需要掌握的知识点也较多。

时间: 2024-11-05 12:20:23

浅析CQRS的应用部署的相关文章

Web应用部署结构浅析

要成功部署一个Web应用,则必须遵循以下标准(参考)目录结构. 2.目录说明 1)WEB-INF目录:必须直接放在Web应用上下文之下(即一级目录). 2)class目录:必须直接放在WEB-INF目录下.所有类文件(普通bean.servlet.监听器.过滤器.辅助类及标志处理器等)的包结构都必须直接放在class目录下,里面存放编译后的.class文件. 3)lib目录:必须直接放在WEB-INF目录下,用于存放第三行类库文件. 4)web.xml文件:必须直接放在WEB-INF目录下,是W

javaWeb应用部署结构浅析

要成功部署一个Web应用,则必须遵循以下标准(参考)目录结构. 2.目录说明 1)WEB-INF目录:必须直接放在Web应用上下文之下(即一级目录). 2)class目录:必须直接放在WEB-INF目录下.所有类文件(普通bean.servlet.监听器.过滤器.辅助类及标志处理器等)的包结构都必须直接放在class目录下,里面存放编译后的.class文件. 3)lib目录:必须直接放在WEB-INF目录下,用于存放第三行类库文件. 4)web.xml文件:必须直接放在WEB-INF目录下,是W

C# CLR及程序集部署浅析

摘 要 .NET Framework 到底是什么?公共语言运行时和 .NET Framework 类库分别指的是什么东西?CLR. CLS. CTS.FCL等这些又是什么?为什么出现程序集的概念?它与动态链接库的区别是什么?什么是强命名程序集?如何签名及部署程序集?这一章将帮助您学习和了解其中的秘密. 第一节 .NET Framework是什么? .NET Framework(.NET框架),是由微软提出并实施的一个集成在Windows中的组件.它基于虚拟机技术实现的平台无关性的软件开发平台,它

Spring Boot 部署浅析(jar or war)

对于传统的 ssm 或者 ssh 项目的部署,一般会打包成war包,或者是一个编译好的文件夹,再放到 tomcat 的 webapps 目录下,如果是 war 包,会自动解压出来.而 Spring Boot 默认会内嵌一个 Tomcat,因此即便是 web 项目也可以直接打包成 jar 包,直接 java -jar 运行就可以了. 用 Spring Initialzr 创建的 web 项目(选择打包成 jar),只会有一个 spring-boot-starter-web 依赖. <depende

浅析vanish

浅析 VANISH --一种cache 第一部分:理解vanish的准备工作 1.对CDN的小剖析 CDN  content  delivery  network  内容分发(推送)网络,是在现有的Internet中增加一层新的网络架构,将网络内容发布到最接近用户的网络边缘(边缘服务器),使用户最近取得所需内容,解决网络拥挤状态,提高用户访问网站的速度. CDN网络架构主要有两部分组成,中心和边缘两部分,中心指CDN网管中心和DNS重定向解析中心,负责全局负载均衡.边缘主要指异地节点,CDN分发

Mosquitto pub/sub服务实现代码浅析-主体框架

Mosquitto 是一个IBM 开源pub/sub订阅发布协议 MQTT 的一个单机版实现(目前也只有单机版),MQTT主打轻便,比较适用于移动设备等上面,花费流量少,解析代价低.相对于XMPP等来说,简单许多. MQTT采用二进制协议,而不是XMPP的XML协议,所以一般消息甚至只需要花费2个字节的大小就可以交换信息了,对于移动开发比较有优势. IBM虽然开源了其MQTT消息协议,但是却没有开源其RSMB服务端程序,不过还好目前有比较稳定的实现可用,本文的Mosquitto是其中比较活跃的实

【Spark Core】任务运行机制和Task源代码浅析1

引言 上一小节<TaskScheduler源代码与任务提交原理浅析2>介绍了Driver側将Stage进行划分.依据Executor闲置情况分发任务,终于通过DriverActor向executorActor发送任务消息. 我们要了解Executor的运行机制首先要了解Executor在Driver側的注冊过程.这篇文章先了解一下Application和Executor的注冊过程. 1. Task类及其相关 1.1 Task类 Spark将由Executor运行的Task分为ShuffleMa

【Spark Core】任务执行机制和Task源码浅析1

引言 上一小节<TaskScheduler源码与任务提交原理浅析2>介绍了Driver侧将Stage进行划分,根据Executor闲置情况分发任务,最终通过DriverActor向executorActor发送任务消息. 我们要了解Executor的执行机制首先要了解Executor在Driver侧的注册过程,这篇文章先了解一下Application和Executor的注册过程. 1. Task类及其相关 1.1 Task类 Spark将由Executor执行的Task分为ShuffleMap

【Spark Core】TaskScheduler源码与任务提交原理浅析1

引言 上一节<Stage生成和Stage源码浅析>中,我介绍了Stage生成划分到提交Stage的过程,分析最终归结到submitStage的递归提交Stage,其中要通过submitMissingTasks函数创建task集合来实现任务的创建和分发. 在接下来的几篇文章中,我将具体介绍一下任务创建和分发的过程,为了让逻辑更加清楚,我将分成几篇文章进行介绍,好保证简明清晰,逻辑连贯,前后统一. TaskScheduler介绍 TaskScheduler的主要任务是提交taskset到集群运算并