四、消息传递通道

4.1 引言

1）消息通道主题

确定应用使用什么通道，以及使用通道做什么

• 固定的通道集：在设计应用时，开发人员必须知道把哪种类型的数据放在哪里，这样才能与其他应用共享这些数据;另外还要知道在哪里查找来自其他应用的特定类型的数据。
• 确定通道集：与之相关产生了一个问题，谁来决定哪些消息通道是可用的，是消息传递系统还是应用?换句话说，消息传递系统能指定某种通道并要求应用使用这些通道通信吗?还是要由应用决定需要什么通道，并要求消息传递系统提供这些通道?这个问题不容易回答。要设计所需的通道集，这个过程是不断反复的。首先，应用确定消息传递系统应该提供哪些通道。接着应用要尽可能围绕可用的通道来设计它们的通信，但是当实现不了时，就会请求增加额外的通道。当一组应用已经使用了某个通道集，同时又有新的应用想要加入时，这些新加入的应用也会使用已有的通道集。已有的应用增加了新的功能时，它们可以请求新的通道。
• 单向通道：另一个让我们普遍感到混淆的问题是，消息通道是单向的还是双向的?从技术上讲，它既不是单向的，也不是双向的。通道更像是一个桶，有的应用往里面添加数据，其他应用从里面取出数据(不过，这种桶是以一种协作的方式分布在多个计算机上)但是，由于数据是封装在消息中从一个应用传播到另一个应用的，这就决定了通道的方向性，从而建立了单向的通道。如果通道是双向的，也就是说应用能在同样的通道中发送和接收消息，尽管这在技术上是可行的，但实现双向通道并没有太大的意义，因为应用一般只消费自己的消息一一也就是准备发送给其他应用的消息。因此，从各种实用的角度看，通道总是单向的。对于完成双向会话的两个应用，它们需要两个通道，每个通道分别完成个方向的通信(见下一章中的“请求/应答”)

2）消息通道的决策

• 一对一或一对多
• 确定数据类型
• 非法和无用消息：消息系统可以确保消息得到正确的传递，但不能保证接收者一定知道该如何处理消息。接收者对数据的类型和含义有自己的期望。当它收到的消息不能满足这些期望时，没有多少工作能做。不过，它可以在一个专门指定的非法消息通道(InvalidMessage Channel)上放上奇怪的消息，以便监控这个通道的某个工具能提取这些消息，并确定如何处理。许多消息传递系统都提供了类似于此的一种内置特性，称为死文字通道Dead Letter Channel)，这种通道针对的是那些已经成功发出但最终未能成功传送的消息而且，应当有一个系统管理工具监控死信队列，并对无法传送的消息做出处理。
• 崩溃恢复
• 通信中枢：随着越来越多的企业应用连接到消息传递系统，并通过消息传递共享它们的功能，消息传递系统已经成为企业中提供一站式功能共享的中心点。一个新的应用要想加入，只需要知道使用哪个通道请求功能以及使用哪些通道监听返回的结果。消息传递系统本身从本质上构成了一个消息总线 (Message Bus)，它是一个通信中枢，能够访问企业中各种不断变化的应用和功能。只要从一开始就对此做专门的设计，就能更快、更方便地实现这种集成。

4.2 点对点通道

当点对点通道只有一个消费者时，消息只会消费一次，这一点不足为奇。当通道有多个消费者时，它们会成为竞争消费者(Competing Consumer)，通道将保证每条消息只能被其中一个消费者消费。

4.3 发布-订购通道

发布-订购通道可以作为一个有用的调试工具。尽管消息只面向一个接收者，但是通过采用发布-订购通道，你就能监听消息通道，而不会干扰已有的消息流。监控通道上的全部流量对于调试消息传递应用很有帮助。这样一来，你不必在参与消息传递解决方案的每个应用中都插入大量的打印语句。创建一个程序来监听所有活动通道上的消息，并把消息记录到个日志文件中，这样就像消息存储库 (Message Store)一样，可以提供许多相同的好处。

4.4 数据类型通道

接收者必须知道消息内容的数据结构和数据格式。数据结构有可能是字符数组、字节数组、串行化对象、XML 文档等等。数据格式可能是字节或字符的记录结构、串行化对象的类XML 文档的模式定义。这些知识通常都泛指为消息类型，它表示消息内容的结构和格式。

4.5 非法消息通道

从理论上讲，消息通道中的任何东西都是消息，消息接收者只是处理消息。但是，为了处理一条消息，接收者必须能解释其数据，并理解数据的含义。并不是每个消息都可以理解:消息体可能会导致解析错误、词法错误或验证错误。消息首部可能缺少必要的属性，或者某些属性值没有意义。发送者可能会把一条完好的消息发送到错误的通道上，并传送到错误的接收者。一个恶意的发送者会故意发送不正确的消息，目的只是要干扰接收者。接收者可能无法处理接收到的所有消息，因此它必须采取另外的某种方式来处理它认为不合法的消息。

系统需要一种方法把不正确的消息从通道中清除出去，同时能把它们安置在另一个地方，一方面要不碍事，另一方面还能被检测到，从而让消息传递系统诊断出问题所在。

设计应用使用的消息传递系统时，管理员必须为应用定义一个或多个非法消息通道，以供使用。

要记住，消息并不是一直合法或非法的，它与接收者的上下文和期望有关。对某个接收者合法的消息对另一个接收者可能是非法的。

如果消息的结构正确，但是它的内容存在语义错误，此时也会出现类似的问题，但并不完全相同。例如，如果有一个命令消息要求接收者删除一条并不存在的数据库记录。它不属于消息传递错误，而是一个应用错误。同样，系统会尝试把它发送给非法消息通道，但是消息本身并没有错误，因此把它当作是非法的消息很容易产生误解。类似这样的错误应该作为非法的应用请求进行处理，而不是非法的消息。

许多消息传递系统都实现了一个类似的概念:死信队列。非法消息通道中是能够发送和接收但是不能处理的消息，而死信队列中是消息传递系统无法正确传送的消息。

4.6 死信队列

有很多原因会造成消息传递系统无法传送消息。比如，消息传递系统没有正确地配置好消息通道:消息已经发送但还没有接收到时，或者正在等待接收的过程中，消息通道被删除:消息在传输前就已经到期(见消息到期);如果消息没有一个明确的到期时间，倘若很长时间都无法传送，它将永远也不会超时;尽管消息提供了一个选择值，但是所有选择性消费者都无法识别和处理这个值，那么这个消息永远也不会读取，并最终成为死消息:消息的首部存在某种错误，以至于无法正确传送。

一旦消息传递系统确定无法传送某个消息，就必须对消息做出处理。可以仅把消息留在原处，但这样会扰乱系统。也可以尝试把消息返回给发送者，但是发送者并不是接收者，因此并不能识别返回的消息。

死信队列还会记录原先打算传送消息的原始通道
死消息与非法消息的区别在于，如果消息传递系统认为一个消息是死消息，则无法成功地传送这个消息，而非法消息能得到正确传送，只是不能被接收者处理。确定某条消息是否应该转移到死信队列，是由消息传递系统对消息的首部进行评估分析后决定的。与此不同，如果接收者感兴趣的消息体或消息首部中的特定字段有问题，接收者则会将这个消息转移到非法消息通道。对接收者来说，死消息的确定和处理是自动进行的，而非法消息必须由接收者自己处理。使用消息传递系统的开发人员始终坚持:任何类型的死消息都应该由消息传递系统处理，他只负责设计自己的非法消息处理程序，有些消息看似为死消息，而且消息传递系统没有处理，这些消息也要由非法消息处理程序来处理

示例：股票交易系统，交易请求在合理时间内收到（可能少于5分钟），如果消息传递系统无法在规定时间期限内传送请求，或者交易应用无法及时接收消息，那么消息传递系统将把消息从交易请求通道中取出，并放入死信队列。交易系统要监控系统的死文字通道，以确定是否漏掉了交易。

4.7 可靠传输

如果网络不可用，消息传递系统将存储消息，直到网络重新可用。同样地，如果接收者不可用，消息传递系统将存储消息并反复发送消息，直到接收者重新可用。这就是消息传递所基于的存储转发 (store-and-forward) 过程。因此，转发消息之前,应该把消息存储在哪里呢?

默认情况下，消息传递系统把消息存储在内存中，直到能把消息成功转发给下一个存默认情况下，储点。只要消息传递系统能可靠运行，这种操作方式就有效。但是，如果消息传递系统崩溃(例如，由于其中一台计算机掉电，或者是消息传递过程异常中止)，存储在内存中的消息就会丢失。

超时重传

4.8 通道适配器

应该如何把应用连接到消息传递系统，使之能发送和接收消息?

大多数应用在设计时没有考虑与消息传递基础设施配合工作。但是遗留系统的集成是目前企业集成解决方案中最常见的集成目标。

如果应用需要与其他应用交换数据，它们在设计时一般采用更通用的接口机制，如文件交换或数据库表。

使用通道适配器可访问应用的 API或数据，并基于此数据把消息发布到通道中;反之，也可接收消息并调用应用内部的功能。

1. 用户接口适配器
2. 业务逻辑适配器
3. 数据库适配器
4. 元数据适配器
5. 消息传递桥（消息传递系统与其他消息传递系统连接起来）

4.9 消息传递桥

4.10 消息总线

消息总线是由规范数据模型、公共命令集和消息传递基础设施组成的，能让不同系统通过共享的接口集通信。

消息总线由许多部件组合而成。

1. 公共通信基础设施
2. 适配器
3. 公共命令结构

消息总线为企业形成一个简单有用的面向服务的体系结构。每个服务至少有一个能接收请求的请求通道，这些请求采用了共同协商的格式;另外还可能要有一个能支持指定应答格式的应答通道。任何参与集成的应用通过发送请求并等待应答使用这些服务。实际上，请求通道相当于可用服务的目录。