对于基于消息的传递系统，您的“消息设计模式”是什么，例如
限制定向消息（即特定目的地）
避免长级联链（即用 MsgB、MsgC 等对 MsgA 作出反应）
有系统“心跳”消息
其他例子？
问问题
20843 次
5 回答
10
If you are implementing a message based system, I suggest reading the canonical resource to get insight on messaging architectures: Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions by Gregor Hohpe y Bobby Woolf.
A short summary of each pattern is available online at http://www.eaipatterns.com/toc.html At the end of the page two case studies are available.
The book is a great resource, you will find there problems and situations you don't even imagine before, with a good analysis of the strategy to solve it.
于 2009-10-26T13:11:46.993 回答
8
根据企业集成模式，作者 Gregor Hohpe 和 Bobby Woolf 记录了 60 多种消息传递模式，分为以下六类：
消息构造
Message：要在通过消息通道连接的两个应用程序之间交换一条信息，将信息打包成 Message，即消息系统可以通过消息通道传输的数据记录。
命令消息：要使用消息传递调用另一个应用程序中的过程，请使用命令消息可靠地调用该过程。
文档消息：要使用消息传递在应用程序之间传输数据，请使用文档消息来可靠地传输数据结构。
事件消息：要使用消息传递将事件从一个应用程序传输到另一个应用程序，请使用事件消息在应用程序之间进行可靠的异步事件通知。
Request-Reply：要在应用程序发送消息时从接收方获得响应，请发送一对 Request-Reply 消息，每个消息都在自己的通道上。
返回地址：为了通知回复者将回复消息发送到哪里，请求消息应包含一个返回地址。
Correlation Identifier：为了允许请求者将请求与回复匹配，每个回复消息都应包含一个 Correlation Identifier，这是一个唯一标识符，指示消息回复的目标是哪个请求。
消息序列：要通过消息传递任意大量的数据，将数据分成块并作为消息序列发送，并用序列标识字段标记每条消息。
Message Expiration：要指示何时应将消息视为陈旧并因此不应进行处理，请设置 Message Expiration 以指定时间限制消息有效的时间。
格式指示符：要设计消息的数据格式以允许将来可能发生更改，请包含格式指示符，以便消息指定它使用的格式。
消息路由
Pipes-and-Filters：要在保持独立性和灵活性的同时对消息执行复杂处理，请使用 Pipes and Filters 架构风格将较大的处理任务划分为一系列较小的、独立的处理步骤（过滤器），这些步骤由通道连接（管道）。
消息路由器：要解耦各个处理步骤，以便可以根据一组条件将消息传递到不同的过滤器，请插入一个特殊的过滤器，即消息路由器，它使用来自一个消息通道的消息并将其重新发布到不同的消息通道通道取决于一组条件。
基于内容的路由器：要处理单个逻辑功能（例如，库存检查）的实现分布在多个物理系统中的情况，请使用基于内容的路由器根据消息内容将每条消息路由到正确的接收者。
消息过滤器：为避免组件接收到不感兴趣的消息，请使用一种特殊的消息路由器，即消息过滤器，根据一组标准从通道中消除不需要的消息。
动态路由器：为了避免路由器依赖于所有可能的目的地，同时保持其效率，请使用动态路由器，该路由器可以根据来自参与目的地的特殊配置消息进行自我配置。
收件人列表：要将邮件路由到动态指定的收件人列表，请为每个收件人定义一个通道。然后使用收件人列表检查传入的邮件，确定所需收件人的列表，并将邮件转发到与列表中收件人关联的所有通道。
拆分器：要处理包含多个元素的消息，每个元素可能必须以不同的方式处理，使用拆分器将复合消息分解为一系列单独的消息，每个消息都包含与一个项目相关的数据。
聚合器：要组合单个但相关消息的结果，以便将它们作为一个整体进行处理，请使用有状态过滤器聚合器来收集和存储单个消息，直到收到完整的相关消息集。然后，聚合器发布从各个消息中提取的单个消息。
Resequencer：要将相关但无序的消息流恢复到正确的顺序，请使用有状态过滤器 Resequencer 来收集和重新排序消息，以便它们可以按指定顺序发布到输出通道.
组合消息处理器：为了在处理由多个元素组成的消息时维护整体消息流，每个元素可能需要不同的处理，使用组合消息处理器来处理组合消息。组合消息处理器将消息拆分，将子消息路由到适当的目的地，并将响应重新聚合回单个消息。
Scatter-Gather：当需要将消息发送给多个收件人（每个收件人可能会发送回复）时，为了维持整个消息流，请使用 Scatter-Gather 将消息广播给多个收件人并将响应重新聚合回单个消息。
路由单：当步骤顺序在设计时未知并且可能因每条消息而异时，要通过一系列处理步骤连续路由消息，请将路由单附加到每条消息，指定处理步骤的顺序。用一个特殊的消息路由器包装每个组件，该路由器读取路由单并将消息路由到列表中的下一个组件。
流程管理器：当在设计时可能不知道所需的步骤并且可能不是连续的时，要通过多个处理步骤路由消息，请使用中央处理单元流程管理器来维护序列的状态并确定下一个基于中间结果的处理步骤。
Message Broker：要将消息的目的地与发送者分离并保持对消息流的集中控制，请使用可以从多个目的地接收消息、确定正确目的地并将消息路由到正确通道的中央 Message Broker。
消息转换（翻译）
消息转换器：为了允许使用不同数据格式的系统使用消息传递相互通信，请在其他过滤器或应用程序之间使用特殊的过滤器消息转换器将一种数据格式转换为另一种数据格式。
Envelope Wrapper：为了允许现有系统参与对消息格式（例如消息头字段或加密）提出特定要求的消息交换，请使用 Envelope Wrapper 将应用程序数据包装在与消息传递基础结构兼容的信封中。消息到达目的地时解包。
Content Enricher：如果消息发起者没有可用的所有必需数据项，要与另一个系统通信，请使用专门的转换器 Content Enricher 来访问外部数据源，以便用缺失的信息来增加消息。
内容过滤器：为了简化处理大型消息，当一个人只对少数数据项感兴趣时，使用内容过滤器从消息中删除不重要的数据项，只留下重要的项目。
Claim Check：为了在不牺牲信息内容的情况下减少跨系统发送的消息的数据量，将消息数据存储在持久存储中，并将 Claim Check 传递给后续组件。这些组件可以使用 Claim Check 来检索存储的信息。
Normalizer：要处理语义上等效但以不同格式到达的消息，请使用 Normalizer 通过自定义消息转换器路由每种消息类型，以便生成的消息与通用格式匹配。
规范数据模型：为了在集成使用不同数据格式的应用程序时最大程度地减少依赖关系，请设计一个独立于任何特定应用程序的规范数据模型。要求每个应用程序以这种通用格式生成和使用消息。
消息传递端点
消息端点：要将应用程序连接到消息传递通道以发送和接收消息，请使用消息端点，即消息系统的客户端，然后应用程序可以使用它来发送或接收消息。
消息网关：要封装从应用程序的其余部分对消息系统的访问，请使用消息网关，该类比包装特定于消息传递的方法调用并向应用程序公开特定于域的方法。
消息映射器：要在域对象和消息基础设施之间移动数据，同时保持两者相互独立，请创建一个单独的消息映射器，其中包含消息基础设施和域对象之间的映射逻辑。对象和基础设施都不知道消息映射器的存在。
事务性客户端：为了允许客户端控制其与消息传递系统的事务，请使用事务性客户端——使客户端与消息传递系统的会话具有事务性，以便客户端可以指定事务边界。
轮询消费者：为了允许应用程序在应用程序准备好时使用消息，应用程序应该使用轮询消费者，当它想要接收消息时显式地进行调用。
事件驱动消费者：为了允许应用程序在消息可用时自动使用它们，应用程序应该使用事件驱动消费者，即当消息在通道上传递时自动传递消息。
竞争消费者：为了允许消息客户端同时处理多条消息，请在单个通道上创建多个竞争消费者，以便消费者可以同时处理多条消息。
Message Dispatcher：要在单个通道上协调多个消费者之间的消息处理，请在通道上创建一个 Message Dispatcher，它将使用来自通道的消息并将它们分发给执行者。
选择性消费者：为了允许消息消费者选择它希望接收的消息，使消费者成为选择性消费者，它过滤由其通道传递的消息，以便它只接收符合其条件的消息。
持久订阅者：为避免订阅者在未监听消息时丢失消息，请使用持久订阅者使消息传递系统在订阅者断开连接时保存发布的消息。
幂等接收器：为了允许消息接收器处理重复消息，请将接收器设计为幂等接收器，即可以安全地多次接收相同消息的接收器。
服务激活器：要创建一个应用程序服务，可以通过各种消息传递技术和非消息传递技术调用，请设计一个服务激活器，将通道上的消息连接到正在访问的服务。
消息渠道
消息通道：要允许一个应用程序使用消息传递与另一个应用程序通信，请使用消息通道连接应用程序，其中一个应用程序将信息写入通道，另一个应用程序从通道读取该信息。
点对点通道：为确保呼叫者只有一个接收者将接收文档或执行呼叫，请在点对点通道上发送消息，以确保只有一个接收者会收到特定消息。
Publish-Subscribe Channel：要允许发送者向所有感兴趣的接收者广播事件，请在 Publish-Subscribe Channel 上发送事件，该通道将特定事件的副本传递给每个接收者。
数据类型通道：为了允许应用程序发送数据项以便接收者知道如何处理它，请为每种数据类型使用单独的数据类型通道，以便特定通道上的所有数据属于同一类型。
Invalid Message Channel：为了让消息接收者能够优雅地处理接收到没有意义的消息，接收者应该将不正确的消息移动到 Invalid Message Channel，这是接收者无法处理的消息的特殊通道。
死信通道：当消息传递系统确定它不能或不应该传递消息时，它可以选择将消息移动到死信通道。
Guaranteed Delivery：为了确保发送者即使消息系统发生故障，消息也会被传递，使用 Guaranteed Delivery 使消息持久化，这样即使消息系统崩溃，它们也不会丢失。
通道适配器：要将应用程序连接到消息传递系统以便它可以发送和接收消息，请使用可以访问应用程序的 API 或数据并基于此数据在通道上发布消息的通道适配器，并且同样可以接收消息和调用应用程序内部的功能。
消息桥：要允许连接多个消息系统，以便一个消息系统上可用的消息也可以在其他系统上使用，请使用消息系统桥（消息系统之间的连接）在系统之间复制消息。
消息总线：一种使单独的应用程序能够一起工作的架构，但以一种解耦的方式，以便可以轻松地添加或删除应用程序而不影响其他应用程序，它是一种消息总线，它连接这些应用程序之间的中间件，并使它们能够使用以下方式一起工作消息传递。
系统管理（监控）
控制总线：要有效管理分布在多个平台和广泛地理区域的消息传递系统，请使用控制总线来管理企业集成系统。控制总线使用与应用程序数据相同的消息传递机制，但使用单独的通道来传输与消息流中涉及的组件管理相关的数据。
Detour：要通过中间步骤路由消息以执行验证、测试或调试功能，请使用通过控制总线控制的基于上下文的路由器构造一个 Detour。在一种状态下，路由器通过附加步骤路由传入消息，而在另一种状态下，它将消息直接路由到目标通道。
Wire Tap：要检查在点对点通道上传输的消息，请将简单的收件人列表插入到通道中，该通道将每个传入消息发布到主通道和辅助通道。
消息历史：要有效地分析和调试松散耦合系统中的消息流，请将消息历史附加到消息中。消息历史记录是消息自其产生以来通过的所有应用程序的列表。
消息存储：要在不干扰消息系统松散耦合和瞬态特性的情况下报告消息信息，请使用消息存储在中央位置捕获有关每条消息的信息。
智能代理：要跟踪向请求者指定的返回地址发布回复消息的服务上的消息，请使用智能代理存储原始请求者提供的返回地址，并将其替换为智能代理的地址。当服务发送回复消息时，会将其路由到原始返回地址。
测试消息：为了防止组件由于内部故障而导致输出消息乱码，请使用测试消息来确保消息处理组件的健康。
Channel Purger：要删除频道上的“剩余”消息，以便它们不会干扰测试或正在运行的系统，请使用 Channel Purger 从频道中删除不需要的消息。
于 2018-10-18T20:21:10.573 回答
7
All the important ones are in the book Enterprise Integration Patterns. Check it out.
于 2009-10-26T13:02:00.630 回答
5
Favour idempotent Message processing: a duplicate message is tolerated without causing "double debits".
Avoid large messages - prefer the "baggage-check" idiom
Avoid message ordering requirements - greatly simplifies burden on infrastructure
于 2009-10-26T13:03:46.167 回答
5
消息设计模式 (MDP) 和模式实现- 在第 17 届程序模式语言会议 (PLoP 2010) 上发表。
抽象的
信息交换（即消息传递）是自然和人为过程的固有部分。消息传递是我们周围世界中无处不在的一部分。传统的软件方法和组件技术忽略了消息传递，因此提供了一个不完整的模型。另一方面，消息传递范式和相关的消息传递设计模式 (MDP) 解决了这一差距，并提供了更完整和更准确的现实世界模型。因此，软件工程过程和技术得到了显着改进。在设计和制造软件时，我们不仅需要考虑软件组件，还需要考虑这些实体之间交换的消息。在降低复杂性的同时改进了封装、解耦和可重用性。本文还讨论了如何利用消息传递设计模式来实现或帮助实现其他众所周知的设计模式，如四人组设计模式 (GoF)、数据访问对象 (DAO) 和 J2EE 设计模式。请记住，大多数设计模式在某种程度上负责参与者之间的信息交换。整体设计和 UML 图被简化和流线化，使它们更容易理解和实现。由此产生的软件设计和实现也更加健壮和直接。使用 MDP 实现的设计模式可以重用，以提供对远程组件/服务的透明和安全访问，作为完整分布式组件模型的基础。负责参与者之间的信息交换。整体设计和 UML 图被简化和流线化，使它们更容易理解和实现。由此产生的软件设计和实现也更加健壮和直接。使用 MDP 实现的设计模式可以重用，以提供对远程组件/服务的透明和安全访问，作为完整分布式组件模型的基础。负责参与者之间的信息交换。整体设计和 UML 图被简化和流线化，使它们更容易理解和实现。由此产生的软件设计和实现也更加健壮和直接。使用 MDP 实现的设计模式可以重用，以提供对远程组件/服务的透明和安全访问，作为完整分布式组件模型的基础。
于 2010-12-20T02:36:32.323 回答