使用基于消息的系统有什么动机?
我看到很多关于服务总线,如NServiceBus和Mass Transit,我想知道底层方法的好处是什么.
使用基于消息的系统有许多优点.
消息在应用程序之间形成明确定义的技术中立接口
实现应用程序的松散耦合.
有很多性能,调整和缩放选项:
在不同的硬件上部署请求者和服务进程
多个请求者共享单个服务器
多个请求者共享多个服务器
各种消息传递中间件独立于您的应用程序实现通用消息传递模式.
请求/应答
触发并忘记离线更新
发布/订阅
许多中间件产品处理消息转换(例如SWIFT到SWIFTXML).
许多中间件产品可以将单个大型请求分解为几个较小的请求.
他们几乎都支持多种平台.
顺便提一下,这个领域的两个市场领导者是IBM的Websphere MQ及相关产品,以及TIBCO的企业服务总线.
基于消息的体系结构在时间和空间上消除了消息的生成者和消费者.这有很多好处:
生产者和消费者可以在不同的机器上运行
生产者和消费者可以在不同的时间运行.
生产者和消费者可以在不同的硬件/软件平台上运行(他们只需要了解相同的消息协议)
协调多个生产者/消费者很容易(例如,对于需要多台机器的计算密集型工作,正如Dave Markle所描述的那样)
当服务暂时不可用时更高的稳定性(例如,在进行订单处理时,使用消息传递系统可以帮助避免"丢弃"订单)
当您进行RPC样式的通信时(即在等待服务响应时阻塞),您将失去大部分这些好处
一个用例是当您拥有可以处理给定项目的资源池,以及需要以可伸缩方式分发的工作列表.
我曾经有一个项目,我必须与大量的3270屏幕刮板(所有慢速)进行大型机集成.我最多可以在一个盒子上打开10个这样的进程.我有数以千计的帐户进行屏幕删除和更新,所以我将工作放在一个队列中,我的机器(我有大约3个人)只是从消息队列(MSMQ)中拾取工作项并进行屏幕抓取,就是这样.我可以很容易地启动一台新机器,或者在不中断工作流程的情况下停用旧机器,这样很好.