图解：消息传输的架构模式.docxVIP

图解：消息传输的架构模式 本节描述与在发送方和接收方之间传输消息的机制相关的消息传输模式。 发布-订阅 发布-订阅（Pub-Sub）模式指的是发布者将消息发送到消息代理（broker）上的主题（topic）。你可以将主题视为一个收件箱。这个收件箱的概念依据实现技术而有不同的名称。例如，RabbitMQ 将收件箱称为 Exchange，而 Kafka 将收件箱称为 Topic。订户绑定到主题，并以异步方式从主题接收消息。 发布-订阅模式格外适合向感爱好的各方供应大事信息 发布-订阅模式的好处是它相对简约：消息输入，消息输出，完事儿。另外如上所述，发布-订阅模式是异步的。因而，在发送方和接收方之间没有阻挠锁。发送方将消息发送给代理，然后移至其他任务。接收方在便利时接收消息。发布-订阅模式中的消息往往是离散的，包含进程对供应的数据进行操作所需的全部信息。 扇出 扇出（Fanout）与发布-订阅模式类似：感爱好的人可以绑定到一个主题，也就是收件箱。扇出模式与典型的 Pub-Sub 区分在于，很多感爱好的参与者都将绑定（也称为订阅）到一个给定的主题。然后，当一条消息发送到该主题时，全部订阅者都将收到发送到该主题的消息的副本。该消息被“分发出去”。（请参见下面的图 2） 扇出模式将向全部感爱好的订阅者发送消息的副本 Twitter 是扇出模式的一个很好的例子。某人发送一条推文后，推文会发送给全部粉丝。 单向流 单向流（Unidirectional streaming）模式指的是发送方连续向接收方发送数据的模式。发送方可能是具有关于接收方直接学问的服务，例如连接到互联网上的网站并不断发送本身位置 GPS 信息的手机，如下图 3 所示。 在单向流模式中，发送方连续向接收方发送数据 或者，发送方可能连接到某种代理技术，代理又通过某种主题/收件箱机制转发流，如下图 4 所示。绑定到代理“收件箱”上的接收方这样就能接收连续的消息流。 使用消息代理管理单向流 Apache Kafka 是实现单向流的消息代理技术的一个示例。 双向流 双向流（Bidirectional streaming）是指在发送方和接收方之间，以及接收方和发送方之间连续发送消息流的情况，如下图 5 所示。 双向流模式在服务器和接收方之间在两个方向上连续不断地流转数据 双向流传输的一个示例是 gRPC。gRPC 在 HTTP/2 下运转，它允许发送方建立与接收方的恒定连接。连接后，数据可以连续在发送方和接收方之间来回流淌。 路由 本节列出的消息传输模式描述了在发送方和接收方之间路由消息的各种方法。发布-订阅、扇出和流模式专注于数据传输的架构，而单播、广播、多播和任播模式则专注于路由。 单播 在单播（Unicast）模式中，消息从发送方路由到指定的接收方。单播模式的一个众所周知的示例是 HTTP 恳求/响应交换。 在单播模式中，发送方向单个接收方发送一条消息 发送方（在这里是 Web 扫瞄器）将恳求消息发送到网络上特定位置的 Web 服务器。互联网的路由机制晓得如何找到这个 Web 服务器并相应地传递恳求（又称消息）。然后，该 Web 服务器使用相同的路由机制将响应消息发送回调用方。 广播 广播（Broadcast）模式是一种发送方向网络上的全部接收方发送消息的模式。网络路由器担任发觉网络上的设备并相应地转发消息。 在广播模式中，发送方向网络上的全部接收方发送一条消息 广播模式的一个示例是地址解析协议（ARP）。在 ARP 下，路由器晓得网络上存在的物理设备，然后将设备标识符 MAC 地址与规律 IP 地址相关联，进而据此转发消息。 多播 多播（Multicast）模式将消息从发送方转发到特定的接收方组（请参见下面的图 8）。比如说，可以通过设备类型或网段在网络上指定组。 多播模式将消息从发送方转发到网络上的一组接收方 互联网协议电视（IPTV）是多播模式的一个典型实现。例如，IPTV 数据会流式传输到连接到特定“频道”的设备，例如 Facebook 下的直播或特定的视频会议会话。 任播 在任播（Anycast）模式中，路由器将消息发送到满足一组确定因素中规定条件的接收方。任播模式的规律是“将此消息发送给满足以下条件的任何接收方”。通常来说，任播模式用于依据地理位置的接近程度将消息从发送方路由到接收方，如下图 9 所示。 内容交付网络通常使用任播模式 内容交付网络（CDN）是一种使用任播模式的技术。接收方可以使用 CDN 从互联网上距离它最近的服务器接收数据。 总结 假如你是在应用程序开发活动中一直在使用消息传输的架构师或开发人员，则很可能已经很生疏上面引见的模式了。这些模式中有的名字你可能之前没见过，但实际的实现一看就能认出来。 用通用名称封装消息传输模式的好处在于，它允许架构师和开