This article describes the basic patterns of message exchange architecture and routing methods used in technologies such as Redis, Apache Kafka, RabbitMQ, ZeroMQ, and IBM MQ. Also describes how to use these patterns to simplify the interaction between architects and developers.
Conceptually, a message is an exchange of information between a sender and one or more receivers. Message exchange has been an essential part of computer programming and architectural design since the advent of the mainframe.
Over the years, the practice of message delivery has evolved into a variety of message delivery modes. In this article, I will share some of the more commonly used methods. I divided these patterns into two parts. The first part, titled "Message Exchange Architecture", describes the structure of moving messages between senders and receivers. The second part, "Routing", covers the logic used to pass messages between senders and receivers.
message exchange architecture
This section describes the message transmission modes related to the mechanism by which messages are transmitted between senders and receivers.
publish-subscribe
The publish-subscribe (Pub-Sub) pattern refers to the publisher sending messages to the topic (topic) on the message broker (broker). You can think of a topic as an inbox. This inbox concept has different names depending on the implementation technology. For example, RabbitMQ calls the inbox Exchange, and Kafka calls the inbox Topic. Subscribers are bound to a topic and receive messages from the topic asynchronously.
The nice thing about the publish-subscribe pattern is that it's relatively simple: message in, message out, and you're done. Also as mentioned above, the publish-subscribe model is asynchronous. Therefore, there is no blocking lock between sender and receiver. The sender sends the message to the broker, which then moves on to other tasks. The recipient receives the message at their convenience. Messages in a publish-subscribe pattern tend to be discrete and contain all the information a process needs to operate on the provided data.
Fan-out
扇出（Fanout）与发布-订阅模式类似：感兴趣的人可以绑定到一个主题，也就是收件箱。扇出模式与典型的 Pub-Sub 区别在于，许多感兴趣的参与者都将绑定（也称为订阅）到一个给定的主题。然后，当一条消息发送到该主题时，所有订阅者都将收到发送到该主题的消息的副本。该消息被“分发出去”。（请参见下面的图）
Twitter 是扇出模式的一个很好的例子。某人发送一条推文后，推文会发送给所有粉丝。
单向流
单向流（Unidirectional streaming）模式指的是发送方连续向接收方发送数据的模式。发送方可能是具有关于接收方直接知识的服务，例如连接到互联网上的网站并不断发送自身位置 GPS 信息的手机，如下图所示。
或者，发送方可能连接到某种代理技术，代理又通过某种主题/收件箱机制转发流，如下图 4 所示。绑定到代理“收件箱”上的接收方这样就能接收连续的消息流。
Apache Kafka 是实现单向流的消息代理技术的一个示例。
双向流
双向流（Bidirectional streaming）是指在发送方和接收方之间，以及接收方和发送方之间连续发送消息流的情况，如下图所示。
双向流传输的一个示例是 gRPC。gRPC 在 HTTP/2 下运行，它允许发送方建立与接收方的恒定连接。连接后，数据可以连续在发送方和接收方之间来回流动。
路由
本节列出的消息传输模式描述了在发送方和接收方之间路由消息的各种方法。发布-订阅、扇出和流模式专注于数据传输的架构，而单播、广播、多播和任播模式则专注于路由。
单播
在单播（Unicast）模式中，消息从发送方路由到指定的接收方。单播模式的一个众所周知的示例是 HTTP 请求/响应交换。
发送方（在这里是 Web 浏览器）将请求消息发送到网络上特定位置的 Web 服务器。互联网的路由机制知道如何找到这个 Web 服务器并相应地传递请求（又称消息）。然后，该 Web 服务器使用相同的路由机制将响应消息发送回调用方。
广播
广播（Broadcast）模式是一种发送方向网络上的所有接收方发送消息的模式。网络路由器负责发现网络上的设备并相应地转发消息。
广播模式的一个示例是地址解析协议（ARP）。在 ARP 下，路由器知道网络上存在的物理设备，然后将设备标识符 MAC 地址与逻辑 IP 地址相关联，进而据此转发消息。
多播
多播（Multicast）模式将消息从发送方转发到特定的接收方组（请参见下面的图 8）。比如说，可以通过设备类型或网段在网络上指定组。
互联网协议电视（IPTV）是多播模式的一个典型实现。例如，IPTV 数据会流式传输到连接到特定“频道”的设备，例如 Facebook 下的直播或特定的视频会议会话。
任播
在任播（Anycast）模式中，路由器将消息发送到满足一组确定因素中规定条件的接收方。任播模式的逻辑是“将此消息发送给满足以下条件的任何接收方”。通常来说，任播模式用于根据地理位置的接近程度将消息从发送方路由到接收方，如下图所示。
内容交付网络（CDN）是一种使用任播模式的技术。接收方可以使用 CDN 从互联网上距离它最近的服务器接收数据。
总结
如果你是在应用程序开发活动中一直在使用消息传输的架构师或开发人员，则很可能已经很熟悉上面介绍的模式了。这些模式中有的名字你可能之前没见过，但实际的实现一看就能认出来。
用通用名称封装消息传输模式的好处在于，它允许架构师和开发人员以相同的方式讨论同一件事。对消息传输模式使用常规名称可以节省时间。在设计会议中，说“使用发布-订阅模式是满足这项业务需求的好方法”要比花时间做出详尽的解释容易得多。
当然，隐含的假设是会议中的每个人都了解所引用的模式背后的细节。希望本文所提供的内容和插图可以帮助人们对当今企业架构中使用的较流行的消息传输模式达成共识。
来源：https://www.redhat.com/architect/architectural-messaging-patterns?fileGuid=hXyvxhWCtdrcTrk8
本文分享自微信公众号 - JAVA高级架构（gaojijiagou）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。