精讲企业集成的消息传递模式

在优锐课的学习分享中，让咱们看一下消息传递模式，例如数据类型通道，无效消息和无效消息，崩溃验证和有保证的传递以及非消息客户端。

前言

当两个或多个应用程序要交换数据时，它们经过经过链接到其余应用程序的通道发送数据来进行交换。发送数据的应用程序可能不知道哪一个应用程序将接收数据，可是经过选择一个特定的通道来发送数据，发送方知道接收方将是经过在其上查找数据来查找此类数据的接收方渠道。

在设计应用程序时，开发人员必须知道在何处放置什么类型的数据以与其余应用程序共享该数据，一样也要在哪里寻找来自其余应用程序的哪些类型的数据。这些通讯路径没法在运行时动态建立和发现。它们须要在设计时达成共识，以便应用程序知道其数据来自何处以及数据将到达何处。一个例外是请求-答复中的答复渠道。请求者能够建立或得到应答者不知道的新通道，将其指定为请求消息的返回地址，而后应答者可使用它。另外一个例外是支持分层通道的邮件系统实现。接收者能够订阅层次结构中的父对象，而后发送者能够将接收者不知道的内容发布到新的子频道，订阅者仍将接收消息。

首先，应用程序肯定消息传递系统将须要提供的渠道。后续的应用程序将尝试在可用的通道周围设计其通讯，可是，若是这不切实际，则将须要添加其余通道。当一组应用程序已经使用了一组特定的通道，而新的应用程序但愿加入时，它们也将使用现有的一组通道。现有应用程序添加新功能时，它们可能须要新渠道。

另外一个常见的混乱缘由是消息通道是单向仍是双向。从技术上讲，二者都不是；通道更像是一些应用程序向其中添加数据而其余应用程序从中获取数据的存储桶。可是因为数据是在从一个应用程序传播到另外一个应用程序的消息中，因此给出了通道方向，使其成为单向的。若是某个通道是双向的，则意味着一个应用程序既会向同一通道发送消息，又会从同一通道接收消息，由于该应用程序倾向于继续消耗本身的消息，而该消息本来应该发送给其余应用程序。所以，出于全部实际目的，通道是单向的。结果，对于两个应用程序进行双向对话，它们将须要两个通道，每一个方向一个。

所以，在消息传递系统中使用了不一样类型的通道。消息通道是消息传递系统的基本体系结构模式，从根本上用于在应用程序之间交换数据。

一、一对一或一对多

当应用程序仅与一个其余应用程序或对该数据感兴趣的任何其余应用程序共享数据时。 而后你可使用点对点通道。 这不能保证在该通道上发送的每条数据都一定会到达同一接收器，由于该通道可能有多个接收器。 但它确实确保仅其中一个应用程序能够接收任何一条数据。

若是全部接收者都须要接收数据，请使用发布-订阅通道。 而后，数据被通道有效地复制，并将其传递到每一个接收器。 发送者简单地将事件广播给全部感兴趣的接收者。

二、数据类型（数据类型通道）

邮件内容必须符合某种类型，以便接收者理解数据的结构。 数据类型通道是一个原则，通道上的全部数据必须具备相同的类型。 这是消息传递系统须要大量渠道的主要缘由。 若是数据能够是任何类型，则消息传递系统在任何两个应用程序之间仅须要一个通道（在每一个方向上）。

三、无效和无效的消息

消息系统能够确保正确传递消息，可是不能保证接收方知道如何处理。 接收者对数据的类型和含义有指望。 可是，它能够作的是将奇怪的消息放在专门指定的“无效消息通道”上，但愿监视该通道的某些实用程序能够提取该消息并弄清楚该如何处理。

许多消息传递系统具备相似的内置功能，即死信通道，用于成功发送但最终没法成功传递的消息。 再次，但愿一些监视该通道的实用程序将知道如何处理没法传递的消息。

四、防撞证实

若是消息传递系统崩溃或为了维护而关闭。 备份并运行时，这些消息仍将保留在其通道中。 默认状况下，否； 通道将其消息存储在内存中。 可是，``保证传递''使通道保持持久状态，以便其消息存储在磁盘上。 这会影响性能，但会使消息传递更加可靠。

五、非邮件客户端

若是应用程序没法链接到消息传递系统，但仍想参与消息传递。 可是，若是消息传递系统能够经过其用户界面，其业务服务API，数据库或经过网络链接（例如TCP / IP或HTTP）以某种方式链接到应用程序，则可使用消息传递系统上的``通道适配器''来 将一个通道（或一组通道）链接到应用程序，而无需修改应用程序，也没必要在应用程序所在的同一台计算机上运行消息传递客户端。

有时，“非消息客户端”其实是一个消息客户端，仅用于其余消息系统。 在这种状况下，做为两个消息传递系统上的客户端的应用程序能够在二者之间创建一个消息传递桥，从而将它们有效地链接到一个复合消息传递系统中。

总结

文章写到这里，相信你们如今能有一个简单的描述了。若有不足之处，欢迎补充评论。