图解：消息传输的架构模式
本文介绍在 Redis、Apache Kafka、RabbitMQ、ZeroMQ 和 IBM MQ 等技术中使用的消息交换架构和路由方法的基本模式。另外介绍如何使用这些模式简化架构师和开发人员之间的互动。
从概念上讲，一条消息是一个发送方与一个或多个接收方之间的一次信息交换。自从大型机问世以来，消息交换一直是计算机编程和架构设计的重要组成部分。
多年来，消息传输的实践已经发展成多种消息传输模式。在本文中，我将分享一些较为常用的方法。我将这些模式分为两部分。第一部分的标题为“消息交换架构”，描述了在发送方和接收方之间移动消息的结构。第二部分是“路由”，涵盖了用于在发送方和接收方之间传递消息的逻辑。
消息交换架构
本节描述与在发送方和接收方之间传输消息的机制相关的消息传输模式。
发布-订阅
发布-订阅（Pub-Sub）模式指的是发布者将消息发送到消息代理（broker）上的主题（topic）。你可以将主题视为一个收件箱。这个收件箱的概念根据实现技术而有不同的名称。例如，RabbitMQ 将收件箱称为 Exchange，而 Kafka 将收件箱称为 Topic。订户绑定到主题，并以异步方式从主题接收消息。
发布-订阅模式的好处是它相对简单：消息输入，消息输出，完事儿。另外如上所述，发布-订阅模式是异步的。因此，在发送方和接收方之间没有阻止锁。发送方将消息发送给代理，然后移至其他任务。接收方在方便时接收消息。发布-订阅模式中的消息往往是离散的，包含进程对提供的数据进行操作所需的所有信息。
扇出
扇出（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 地址相关联，进而据此转发消息。另外，欢迎关注公众号Java笔记虾，后台回复“后端面试”，送你一份面试题宝典！
多播
多播（Multicast）模式将消息从发送方转发到特定的接收方组（请参见下面的图 8）。比如说，可以通过设备类型或网段在网络上指定组。
互联网协议电视（IPTV）是多播模式的一个典型实现。例如，IPTV 数据会流式传输到连接到特定“频道”的设备，例如 Facebook 下的直播或特定的视频会议会话。
任播
在任播（Anycast）模式中，路由器将消息发送到满足一组确定因素中规定条件的接收方。任播模式的逻辑是“将此消息发送给满足以下条件的任何接收方”。通常来说，任播模式用于根据地理位置的接近程度将消息从发送方路由到接收方，如下图所示。
内容交付网络（CDN）是一种使用任播模式的技术。接收方可以使用 CDN 从互联网上距离它最近的服务器接收数据。
总结
如果你是在应用程序开发活动中一直在使用消息传输的架构师或开发人员，则很可能已经很熟悉上面介绍的模式了。这些模式中有的名字你可能之前没见过，但实际的实现一看就能认出来。
用通用名称封装消息传输模式的好处在于，它允许架构师和开发人员以相同的方式讨论同一件事。对消息传输模式使用常规名称可以节省时间。在设计会议中，说“使用发布-订阅模式是满足这项业务需求的好方法”要比花时间做出详尽的解释容易得多。
当然，隐含的假设是会议中的每个人都了解所引用的模式背后的细节。希望本文所提供的内容和插图可以帮助人们对当今企业架构中使用的较流行的消息传输模式达成共识。
来源：https://www.redhat.com/architect/architectural-messaging-patterns?fileGuid=hXyvxhWCtdrcTrk8
推荐阅读：