消息解耦初探
来源:互联网 发布:linux文件给用户权限 编辑:程序博客网 时间:2024/05/18 13:06
一般来说解耦有两条途径,一是远程请求,二是消息(推送)。这两种方式可以说使用的应用场景不一样,比如说远程请求这是主动方在调用方,而推送的主动权肯定是在生产方。为什么要解耦?这个。。。
如果用消息进行应用间解耦,消息将作为应用间的介质作为上下文传输。其实知道生产者和消费者就很容易明白,这样两个应用之间将不会有任何代码的依赖。
这样会有一个消息提供方和消息接收方。也可以说是消息生产方和消息消费方。两者之间并不知道彼此的存在,其实严格的讲消息消费方是知道生产方的,不过是一种非常弱的依赖。这是一种推送模式,所谓推送模式就是消费生产方一直生产消息,再推送给各个消费方,这样消费方就可以进行接收消息进行消费。
下面看一下系统调用图:
这里消息中心是对消息重新抽取出来的一层,这样保证应用层职责更加单一,另外一个不会因为消息的堆积导致服务瘫痪(一般来说消息中心都部署在新的机器上,不太会和其他应用耦合)。消息中心存放了生产方发送过来的消息然后再进行集中转发。这样可以在消息中心实现一些消息的处理逻辑以满足更多的业务需求。比如说阀值,可能生产方非常强悍,而消费方比较弱,这样长期会导致消息堆积越来越多。而解决这样的问题一般就是消费方使用集群来分摊压力。简单的应用场景消息中心的意义不大,因为这样会增加因为传输带来的网络开销,而中消息中心本身是需要接收和转发的,这中间肯定也会有资源消耗。
目前模式大概有两种,第一是点对点(p2p),就是单挑;一种是一对多,也就说所谓的发布/订阅模式。这两种方式其实本质上可以归结为一种。发布/订阅模式消费方需要在消息中心注册一个账号。让消息中心知道你的存在,到时候就会给你发送消息。
转载自:http://blog.csdn.net/luohuacanyue/article/details/7897258
- 消息解耦初探
- 消息解耦初探
- 消息中间件RabbitMQ 初探
- 消息队列 初探
- VCL中消息处理初探
- vtk消息响应初探 分享
- ASP.NET中消息队列(MSMQ)初探
- Service初探与异步消息处理机制
- WCF初探-3:WCF消息交换模式之单向模式
- 密码编码学初探——消息认证码
- Android中消息机制初探(创建一个可以接收消息的子线程)
- 初探
- ffmpeg mediacodec 硬解初探
- VB高级编程初探(子类技术SUBCLASS与消息捕获)
- WCF初探-4:WCF消息交换模式之请求与答复模式
- 基于JMS消息中间件的分布式系统初探究(二) - 服务端反射调用组件方法
- 关于即时通讯系统中消息发送、转发、展示、提示等专利初探
- Kafka剖析(一):高扩展、高吞吐的分布式消息系统初探
- 杂项
- Spring1.1.1+quartz1.8.6实现集群环境下的定时任务
- linux tar 命令
- centos更改163yum源
- IOS开发--一个控件添加后看不见 有哪些可能。
- 消息解耦初探
- Android问题集锦之三十六:com.android.dex.DexException: Multiple dex files define
- Swift语言快速入门v2.0
- ProcessEngines.getDefaultProcessEngine() 空指针异常
- 在selenium中设置html5 的hidden属性
- eclipse配置maven
- SQL基础--> 数据处理(DML、RETURNING、MERGE INTO)
- 解读《x64 deep dive》 2
- 最小堆