基于消息的分布式架构设计-转

标签: 系统架构 分布式 | 发表时间:2016-02-22 04:07 | 作者:admin
出处:http://blog.haohtml.com

背景:

随着社会的发展,经济的飞跃,传统的单系统模式(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类图:
未完待续

相关 [消息 分布 架构] 推荐:

案例分析:基于消息的分布式架构

- - 简单文本
美国计算机科学家,LaTex的作者Leslie Lamport说:“分布式系统就是这样一个系统,系统中一个你甚至都不知道的计算机出了故障,却可能导致你自己的计算机不可用. ”一语道破了开发分布式系统的玄机,那就是它的复杂与不可控. 所以Martin Fowler强调:分布式调用的第一原则就是不要分布式.

基于消息的分布式架构设计-转

- - 学习笔记
随着社会的发展,经济的飞跃,传统的单系统模式(webApp+DB)已经很难满足业务场景的需要. 企业系统开始不断演化成多个子系统并存协作的局面. 大大降低了系统间的耦合性,更重要的便于子系统的扩展、升级、维护等. 谈到系统间的协作,目前常用两种方式:. 通过客户端发起的get、post请求,服务端接收request请求,处理请求,得到响应内容,通过网络传送到客户端,由浏览器解析出一个可视化的页面.

Feed消息队列架构分析

- - Tim[后端技术]
最近一两年,大部分系统的数据流由基于日志的离线处理方式转变成实时的流式处理方式,并逐渐形成几种通用的使用方式,以下介绍微博的消息队列体系. 当前的主要消息队列分成如图3部分. 1、feed信息流主流程处理,图中中间的流程,通过相关MQ worker将数据写入cache、Redis及MySQL,以便用户浏览信息流.

分布式消息系统:Kafka

- - 标点符
Kafka是分布式发布-订阅消息系统. 它最初由LinkedIn公司开发,之后成为Apache项目的一部分. Kafka是一个分布式的,可划分的,冗余备份的持久性的日志服务. 在大数据系统中,常常会碰到一个问题,整个大数据是由各个子系统组成,数据需要在各个子系统中高性能,低延迟的不停流转. 传统的企业消息系统并不是非常适合大规模的数据处理.

kafka分布式消息系统

- - CSDN博客云计算推荐文章
Kafka[1]是linkedin用于日志处理的分布式消息队列,linkedin的日志数据容量大,但对可靠性要求不高,其日志数据主要包括用户行为(登录、浏览、点击、分享、喜欢)以及系统运行日志(CPU、内存、磁盘、网络、系统及进程状态). 当前很多的消息队列服务提供可靠交付保证,并默认是即时消费(不适合离线).

网站的分布式架构

- - 互联网的那点事
互联网的网站和大部分企业管理软件一样都是使用B/S架构模型,但是大型的公共网站B/S架构会更加复杂,对架构人员的要求更高,今天我想在自己博客里聊聊我设计的网站的B/S技术架构. 不管是B/S架构的企业管理系统还是网站技术架构可以抽象为如下简图:. 在传统B/S架构的企业管理系统里,技术架构往往就是一个工程项目,各个逻辑分层都是该工程的业务逻辑模块.

FastDFS分布式文件系统架构

- - 企业架构 - ITeye博客
FastDFS分布式文件系统架构.            FastDFS是一个开源的分布式文件系统,她对文件进行管理,功能包括:文件存储、文件同步、文件访问(文件上传、文件下载)等,解决了大容量存储和负载均衡的问题. 特别适合以文件为载体的在线服务,如相册网站、视频网站等等. 二、 FastDFS系统架构.

互联网网站架构升级----消息中间件的实现方案

- liu - ITeye论坛最新讨论
    最近一直比较忙,前面设计的架构完成了基本的实现,最近工作重心发生了点转变,偷闲来继续前面的话题;.     这一篇博客准备聊聊消息系统,消息中间件对目前大中型互联网来说是非常重要的,在业务数据流动中仅次于RPC服务调用,担负着越来越复杂的网站业务从主流程上解耦的重要责任;.     从目前互联网对消息中间件的需求来看应该分为两种类型,一种是和钱相关的需求,一种是和钱无关的需求;和钱相关的需求消息的可靠性是放在第一位的,和钱无关的需求是速度放在第一位的,但这两种需求又是矛盾的,很难设计出一种既可靠又高效的系统,除非将两套方案捏合成一个系统,通过配置来选择不同方案,但从实现上说还是两种实现.

淘宝开源分布式消息中间件Metamorphosis

- - InfoQ cn
最近,淘宝开源了分布式消息中间件 Memorphosis项目,它是Linkedin开源MQ——Kafka的Java版本,针对淘宝内部应用做了定制和优化. 据了解,Metamorphosis(以下简称Meta)的设计原则包括:. 分布式,生产者、服务器和消费者都可分布. Metamorphosis的总体 架构图如下:.

kafka:一个分布式消息系统 - 十九画生

- - 博客园_首页
最近因为工作需要,调研了追求高吞吐的轻量级消息系统Kafka,打算替换掉线上运行的ActiveMQ,主要是因为明年的预算日流量有十亿,而ActiveMQ的分布式实现的很奇怪,所以希望找一个适合分布式的消息系统. 以下是内容是调研过程中总结的一些知识和经验,欢迎拍砖. 首先,我们来看看什么是消息队列,维基百科里的解释翻译过来如下:.