消息总线 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