背景:
随着社会的发展,经济的飞跃,传统的单系统模式(webApp+DB)已经很难满足业务场景的需要。企业系统开始不断演化成多个子系统并存协作的局面。大大降低了系统间的耦合性,更重要的便于子系统的扩展、升级、维护等。
谈到系统间的协作,目前常用两种方式:
1、基于Http协议
通过客户端发起的get、post请求,服务端接收request请求,处理请求,得到响应内容,通过网络传送到客户端,由浏览器解析出一个可视化的页面。
这种交互最大的优势是实时性,通过HTTP请求连接各个子系统,从而跨服务器来完成一个完整的业务流程。缺点协议请求头的信息较少,一般都是关键参数,完整数据由下一个子系统从数据库、文件系统来获取,从来保证前后的业务数据衔接。
2、基于消息的模式。
这种模式一个很重要前提是对实时性要求不高。优点可以有效降低模块的耦合性,减轻主干业务流程,将大量的业务交由后台任务来处理,有效缩短系统响应时间,提高系统TPS。
比如用户下单成功后发送邮件功能,属于非主干功能,完全可以从下单的主干业务逻辑剥离出来,从来提高下单的响应速度。而发送邮件的功能则由邮件服务器接收异步消息来跟踪处理,带有点分布式集群的感觉,
将一个任务有效拆分到多台服务器来完成。
所谓消息本质上是一种数据结构(当然,对象也可以看做是一种特殊的消息),它包含生产者与消费者双方都能识别的数据,这些数据需要在不同的服务器之间进行传递,并可能会被多个完全不同的客户端消费。
消息队列降低了生产者和消费者之间的耦合性,他们不会存在直接的代码依赖,方便各自的扩展,比如生产者因为业务下线,导致代码下线,而消费端不用同时跟进处理,只是队列不会有消息,这样方便于更加灵活的协调开发资源,而不必一方下线,所有的依赖全部受影响,产生较高维护成本。另外我们也可以随意对生产者和消费者扩展,引入多个消息队列,他们之间的依赖可以配置在XML文件中,通过JNDI来获取消息队列Queue,每次加载时,通过lookup服务首先通过读取配置文件来获取通道。
常见的消息模型分为:点对点模型;发布-订阅模型
点对点模型:Point to Point,消息被生产者放到一个队列中,消费者从消息队列中取走消息。消息一旦被一个消费者取走后,消息就从队列中移除。这意味着即使有多个消费观察一个队列,但一个消息只能被一个消费者取走。
发布-订阅模型:Publish/Subscribe,发布者发布一条消息可以发送给所有的订阅用户,所有的订阅用户都有处理某一条消息的机会。
对于订阅者而言,有两种处理消息的方式。一种是广播机制,这时消息通道中的消息在出列的同时,还需要复制消息对象,将消息传递给多个订阅者。例如,有多个子系统都需要获取从CRM系统传来的客户信息,并根据传递过来的客户信息,进行相应的处理。此时的消息通道又被称为Propagation通道。另一种方式则属于抢占机制,它遵循同步方式,在同一时间只能有一个订阅者能够处理该消息。实现Publisher-Subscriber模式的消息通道会选择当前空闲的唯一订阅者,并将消息出列,并传递给订阅者的消息处理方法。
目前使用较多的是广播机制的消息处理方式,且将topic与queue有效组合
一个生产消息的事件对应一个topic,topic下面可以挂多个queue,当然一个queue也可以挂在多个topic下面,每个queue都对应一个消息的消费端,唯一消费,保证消费的准确性。
如下图所示,当下单时,会将下单的相关信息封装到消息体中,发送到下单事件关联的那个topic1中,然后Topic会将消息复制发送到挂载在其下面的所有队列上,将Message复制到快照队列、成交记录统计队列中,消息端会监听队列,
如果有消息 ,则启动任务线程,来进行相关的业务处理。
在引入消息队列时重点要注意以下几点:
- 并发:选择的消息队列一定要很好地支持用户访问的并发性;
- 安全:消息队列是否提供了足够的安全机制;
- 性能伸缩:不能让消息队列成为整个系统的单一性能瓶颈;
- 部署:尽可能让消息队列的部署更为容易;
- 灾备:不能因为意外的错误、故障或其他因素导致处理数据的丢失,最好可以写入磁盘,持久化存储;
- API易用性:处理消息的API必须足够简单、并能够很好地支持测试与扩展
- 容量:队列的容量一定要大,至少可以存储千万级别的消息体
目前市场上有很多成熟的消息框架:如Active MQ,IBM 的MQ,JBoss MQ,MSMQ等,各有各的优势,在使用前一定要充分衡量是否可以满足自己的业务需求
下图是napoli的client类图:
相关推荐
分布式架构网上商城-分布式架构网上商城系统-分布式架构网上商城系统源码-分布式架构网上商城管理系统-分布式架构网上商城管理系统java代码-分布式架构网上商城系统设计与实现-基于springboot的分布式架构网上商城...
总结来说,基于云计算平台的分布式架构设计是为了更好地适应现代IT服务的需求,它通过虚拟化技术和资源的集中管理,提升了系统的灵活性和扩展性,同时保证了业务的高可用性和可靠性。企业通过这种架构模式,可以更好...
本文介绍了一个基于分布式架构管理的B2C商城系统设计与实现过程,以及关键技术的运用。在互联网和电子商务迅猛发展的背景下,本文作者提出了一个解决方案,旨在满足现代网上购物平台对于界面友好性和查询效率的需求...
Java毕业设计基于Springboot的分布式架构网上商城的实现.zipJava毕业设计基于Springboot的分布式架构网上商城的实现.zipJava毕业设计基于Springboot的分布式架构网上商城的实现.zipJava毕业设计基于Springboot的...
分布式架构网上商城-分布式架构网上商城系统-分布式架构网上商城系统源码-分布式架构网上商城管理系统-分布式架构网上商城管理系统java代码-分布式架构网上商城系统设计与实现-基于springboot的分布式架构网上商城...
《矿井胶轮车运输信号系统的分布式架构设计》一文主要探讨了矿井胶轮车运输信号系统的架构设计,提出了采用分布式架构以提高系统可靠性和实时性的必要性。作者赵立厂是中煤科工集团常州自动化研究院的研究员,文章...
在当前的研究背景下,高腾飞和陈俊强两位作者提出了基于分布式架构的NAT模块设计与实现方案。该方案利用了分布式软件架构的设计思路,将NAT功能进行分层化和模块化处理。文章中描述了如何通过转控分离来提高网络地址...
本文将深入探讨基于Hadoop、F5、Dubbo和SpringCloud的分布式架构设计及其在实际银行项目中的应用。 首先,Hadoop是大数据处理的核心组件,它提供了分布式文件系统(HDFS)和MapReduce计算框架,能够处理和存储海量...
在设计基于分布式架构的金融智能云平台时,不仅要考虑其技术架构设计,还要综合考虑非功能性需求。非功能性需求包括平台的可使用性、可管理性和安全性,这些对于金融行业尤为重要。可使用性要求云平台能够支持金融...
【标题】:“基于全分布式架构的融合媒体PaaS平台设计.pdf” 【描述】:“#资源达人分享计划#” 【标签】:“分布式 分布式系统 分布式开发 参考文献 专业指导” 本文主要探讨的是基于全分布式架构的融合媒体PaaS...
本文介绍了基于分布式架构的广西移动统一开通系统的设计方案,旨在解决传统业务开通系统存在的工单处理效率低、系统扩展性差、扩容周期长、维护难度大等问题。文章首先对统一开通系统的现状和挑战进行了分析,并基于...
分布式架构是一种将计算任务分布在多台计算机上的设计方法,与传统的集中式架构相比,其优势主要体现在以下几个方面: 1. 降低总拥有成本:通过分散资源,分布式架构可以将硬件成本、运维成本等有效降低,提高资源...
在探讨基于级联分布式架构的直流微电网协调控制方法时,首先需要了解直流微电网的背景及其在现代电力系统中的重要性。随着电力电子技术和可再生能源技术的发展,微电网作为一种新的能源供应方式,正得到广泛的重视和...
为了克服这些挑战,本文提出了一种基于自适应分数间隔均衡的分布式架构下船舶移动通信中间件设计方法,旨在提升通信链路的均衡性和路由转发控制能力,减少通信误码率。 在本文中,首先探讨了船舶移动通信技术的发展...
基于Dubbo的分布式架构设计可以有效地解决大型系统面临的复杂性和扩展性问题。通过服务化,系统被拆分成独立的服务,降低了耦合度,增强了系统的可维护性和可扩展性。Dubbo的RPC机制使得服务间的通信高效而透明。...
基于Dubbo的分布式架构设计.pdf