圖解：消息傳輸的架構模式
作者 | Bob Reselman
譯者 | 王強
策劃 | 萬佳
本文介紹在 Redis、Apache Kafka、RabbitMQ、ZeroMQ 和 IBM MQ 等技術中使用的消息交換架構和路由方法的基本模式。另外介紹如何使用這些模式簡化架構師和開發人員之間的互動。
從概念上講，一條消息是一個發送方與一個或多個接收方之間的一次信息交換。自從大型機問世以來，消息交換一直是計算機編程和架構設計的重要組成部分。
多年來，消息傳輸的實踐已經發展成多種消息傳輸模式。在本文中，我將分享一些較爲常用的方法。我將這些模式分爲兩部分。第一部分的標題爲 “消息交換架構”，描述了在發送方和接收方之間移動消息的結構。第二部分是 “路由”，涵蓋了用於在發送方和接收方之間傳遞消息的邏輯。
1 消息交換架構
本節描述與在發送方和接收方之間傳輸消息的機制相關的消息傳輸模式。
發佈 - 訂閱
發佈 - 訂閱（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 下運行，它允許發送方建立與接收方的恆定連接。連接後，數據可以連續在發送方和接收方之間來回流動。
2 路由
本節列出的消息傳輸模式描述了在發送方和接收方之間路由消息的各種方法。發佈 - 訂閱、扇出和流模式專注於數據傳輸的架構，而單播、廣播、多播和任播模式則專注於路由。
在公衆號後端架構師後臺回覆 “架構整潔”，獲取一份驚喜禮包。
單播
在單播（Unicast）模式中，消息從發送方路由到指定的接收方。單播模式的一個衆所周知的示例是 HTTP 請求 / 響應交換。
在單播模式中，發送方向單個接收方發送一條消息
發送方（在這裏是 Web 瀏覽器）將請求消息發送到網絡上特定位置的 Web 服務器。互聯網的路由機制知道如何找到這個 Web 服務器並相應地傳遞請求（又稱消息）。然後，該 Web 服務器使用相同的路由機制將響應消息發送回調用方。
廣播
廣播（Broadcast）模式是一種發送方向網絡上的所有接收方發送消息的模式。網絡路由器負責發現網絡上的設備並相應地轉發消息。
在廣播模式中，發送方向網絡上的所有接收方發送一條消息
廣播模式的一個示例是地址解析協議（ARP）。在 ARP 下，路由器知道網絡上存在的物理設備，然後將設備標識符 MAC 地址與邏輯 IP 地址相關聯，進而據此轉發消息。
多播
多播（Multicast）模式將消息從發送方轉發到特定的接收方組（請參見下面的圖 8）。比如說，可以通過設備類型或網段在網絡上指定組。
多播模式將消息從發送方轉發到網絡上的一組接收方
互聯網協議電視（IPTV）是多播模式的一個典型實現。例如，IPTV 數據會流式傳輸到連接到特定 “頻道” 的設備，例如 Facebook 下的直播或特定的視頻會議會話。
任播
在任播（Anycast）模式中，路由器將消息發送到滿足一組確定因素中規定條件的接收方。任播模式的邏輯是 “將此消息發送給滿足以下條件的任何接收方”。通常來說，任播模式用於根據地理位置的接近程度將消息從發送方路由到接收方，如下圖 9 所示。
內容交付網絡通常使用任播模式
內容交付網絡（CDN）是一種使用任播模式的技術。接收方可以使用 CDN 從互聯網上距離它最近的服務器接收數據。
3 總結
如果你是在應用程序開發活動中一直在使用消息傳輸的架構師或開發人員，則很可能已經很熟悉上面介紹的模式了。這些模式中有的名字你可能之前沒見過，但實際的實現一看就能認出來。
用通用名稱封裝消息傳輸模式的好處在於，它允許架構師和開發人員以相同的方式討論同一件事。對消息傳輸模式使用常規名稱可以節省時間。在設計會議中，說 “使用發佈 - 訂閱模式是滿足這項業務需求的好方法” 要比花時間做出詳盡的解釋容易得多。當然，隱含的假設是會議中的每個人都瞭解所引用的模式背後的細節。希望本文所提供的內容和插圖可以幫助人們對當今企業架構中使用的較流行的消息傳輸模式達成共識。
原文鏈接：
redhat.com/architect/architectural-messaging-patterns?fileGuid=hXyvxhWCtdrcTrk8
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/psmOOqKz1OoC17qTwI-rAg