消息总线 Message bus

场景：

　　在一个集成环境中存在不一样应用，这些应用的提供者不一样且这些应用运行在各类各样的平台上。其中的一些

应用程序生产消息，其余不少应用程序消费这些消息。

　　例如，某金融方面应用程序集成了贸易工具、投资管理应用、模型和风险分析工具、贸易指示以及自动收报机。

市场活动致使系统的交换。例如，一个贸易系统经过发送消息到其余贸易应用程序来实现卖出事务的操做。贸易

系统各自链接每个贸易应用程序。在应用程序较少的时候这些操做可以执行，可是随着应用程序数量的增长，

系统负担将愈来愈重。而实际上，增长或删除贸易程序不该该影响贸易的处理过程。

 

问题：

　　随着集成环境愈来愈复杂，如何才能下降添加或删除应用所带来的开销？

 

约束：

　　添加一个应用程序到集成环境或删除集成环境中的一个应用须要平衡下列约束：

　　1. 应用程序间的通讯一般需建立程序间的依赖，发送端必须能与接收端通讯，接收端必须能识别从全部发送

端发来的消息。这些依赖转化成不一样应用间的耦合。

　　2. 当采用点对点的方式来链接时，耦合数随着应用程序的增长呈平方增加。例如，三个已链接的应用程序

须要三个链接，可是10个应用程序须要45个链接。而链接数愈来愈多，维护管理、修改和集成的难度愈来愈大。

　　3. 一般，应用程序集成解决方案有不一样接口。修改应用程序的接口难度是很大的，即便能改变一个应用程序

的接口，改变全部应用的接口几乎是不可能的。

　　4. 一些集成解决方案由一组固定的程序组成。一个集成解决方案很难扩展或修改需求，当他不须要适应新

应用时。

 

解决方案：

　　经过一个逻辑组件，即消息总线来完成全部应用程序的链接，一个消息总线明确消息传递的发送方和接

收方。一个消息总线包含三个关键的元素：

　　1. 一组达成一致的消息计划。

　　2. 一组公共命令消息。

　　3. 共享通讯基础框架来发送总线消息到接收端。

 使用消息总线时，应用程序发送消息再也不单独链接其余应用程序，只须要将消息发布到消息总线上，消息总线将

消息发送到全部其余监听总线上消息的应用上。一样，应用程序再也不直接接收来自其余发送者的消息，而是从

消息总线上获取消息。实际上，消息总线减小了每一个应用输出端的数量，由多个减小到一个。

　　一般，总线不保证消息秩序。内部的优化、路由选择、缓冲等甚至优先传输机制可能影响消息具体传递到

接收端的方式。所以，消息到达的顺序是不肯定的。例如，发送端可以插入有序的数据到消息中，而后接收端

可使用这些数据并进行重排，逻辑顺序能够由总线提供，且逻辑顺序对于应用程序能够是透明的。然而，

这种附加的逻辑不是必须的。

　　下图一描述了一个集成环境下使用消息总线的形式。经过总线发送消息的应用程序必须准备好消息，以便消息符合总线指望的消息类型。相似的，应用程序接收消息时必须可以理解消息类型。若是集成环境中全部的应用程序都实现

了总线接口，增长或移除应用程序对总线没有影响。

　　消息总线与应用程序间共享的基础通讯框架可使用消息路由来实现，而消息路由可使用订阅发布机制来实现。

以下图，展现了消息总线与订阅发布模式的关系。

　　期待将某一特殊的消息总线运用在订阅发布的实现中，对消息总线架构产生了深远的影响。实现订阅发布模式

包含三类方式：http://www.cnblogs.com/svenzhang9527/p/7351769.html

 

消息总线与基于链表的订阅发布模式

Message Bus with List-Based Publish/Subscribe

　　基于链表的订阅发布模式本质包含两点，一是维护包含发布主题和订阅者信息的链表，二是当事件发生时，通知

该链表中的元素处理事件信息。

　　为了使用包含基于链表的订阅发布机制的消息总线，当系统发送命令消息到消息总线时，消息总线检查全部感

兴趣的消息总线订阅方，并给每一个消息总线发送一个原始消息的拷贝。任何同消息有关的数据都使用通用格式，以便

全部系统都能理解命令和数据，并给出合理回复。

 

消息总线与基于广播的订阅发布模式

Message Bus with Broadcast-Based Publish/Subscribe