[導(dǎo)讀]從概念上講，一條消息是一個發(fā)送方與一個或多個接收方之間的一次信息交換。自從大型機(jī)問世以來，消息交換一直是計算機(jī)編程和架構(gòu)設(shè)計的重要組成部分。多年來，消息傳輸?shù)膶嵺`已經(jīng)發(fā)展成多種消息傳輸模式。在本文中，我將分享一些較為常用的方法。我將這些模式分為兩部分。第一部分的標(biāo)題為“消息交換架...
從概念上講，一條消息是一個發(fā)送方與一個或多個接收方之間的一次信息交換。自從大型機(jī)問世以來，消息交換一直是計算機(jī)編程和架構(gòu)設(shè)計的重要組成部分。
多年來，消息傳輸?shù)膶嵺`已經(jīng)發(fā)展成多種消息傳輸模式。在本文中，我將分享一些較為常用的方法。我將這些模式分為兩部分。第一部分的標(biāo)題為“消息交換架構(gòu)”，描述了在發(fā)送方和接收方之間移動消息的結(jié)構(gòu)。第二部分是“路由”，涵蓋了用于在發(fā)送方和接收方之間傳遞消息的邏輯。
發(fā)布-訂閱模式非常適合向感興趣的各方提供事件信息
發(fā)布-訂閱模式的好處是它相對簡單：消息輸入，消息輸出，完事兒。另外如上所述，發(fā)布-訂閱模式是異步的。因此，在發(fā)送方和接收方之間沒有阻止鎖。發(fā)送方將消息發(fā)送給代理，然后移至其他任務(wù)。接收方在方便時接收消息。發(fā)布-訂閱模式中的消息往往是離散的，包含進(jìn)程對提供的數(shù)據(jù)進(jìn)行操作所需的所有信息。
扇出模式將向所有感興趣的訂閱者發(fā)送消息的副本
Twitter 是扇出模式的一個很好的例子。某人發(fā)送一條推文后，推文會發(fā)送給所有粉絲。
在單向流模式中，發(fā)送方連續(xù)向接收方發(fā)送數(shù)據(jù)
或者，發(fā)送方可能連接到某種代理技術(shù)，代理又通過某種主題/收件箱機(jī)制轉(zhuǎn)發(fā)流，如下圖 4 所示。綁定到代理“收件箱”上的接收方這樣就能接收連續(xù)的消息流。
使用消息代理管理單向流
Apache Kafka 是實現(xiàn)單向流的消息代理技術(shù)的一個示例。
雙向流模式在服務(wù)器和接收方之間在兩個方向上連續(xù)不斷地流轉(zhuǎn)數(shù)據(jù)
雙向流傳輸?shù)囊粋€示例是 gRPC。gRPC 在 HTTP/2 下運行，它允許發(fā)送方建立與接收方的恒定連接。連接后，數(shù)據(jù)可以連續(xù)在發(fā)送方和接收方之間來回流動。
在單播模式中，發(fā)送方向單個接收方發(fā)送一條消息
發(fā)送方（在這里是 Web 瀏覽器）將請求消息發(fā)送到網(wǎng)絡(luò)上特定位置的 Web 服務(wù)器?；ヂ?lián)網(wǎng)的路由機(jī)制知道如何找到這個 Web 服務(wù)器并相應(yīng)地傳遞請求（又稱消息）。然后，該 Web 服務(wù)器使用相同的路由機(jī)制將響應(yīng)消息發(fā)送回調(diào)用方。
在廣播模式中，發(fā)送方向網(wǎng)絡(luò)上的所有接收方發(fā)送一條消息
廣播模式的一個示例是地址解析協(xié)議（ARP）。在 ARP 下，路由器知道網(wǎng)絡(luò)上存在的物理設(shè)備，然后將設(shè)備標(biāo)識符 MAC 地址與邏輯 IP 地址相關(guān)聯(lián)，進(jìn)而據(jù)此轉(zhuǎn)發(fā)消息。
多播模式將消息從發(fā)送方轉(zhuǎn)發(fā)到網(wǎng)絡(luò)上的一組接收方
互聯(lián)網(wǎng)協(xié)議電視（IPTV）是多播模式的一個典型實現(xiàn)。例如，IPTV 數(shù)據(jù)會流式傳輸?shù)竭B接到特定“頻道”的設(shè)備，例如 Facebook 下的直播或特定的視頻會議會話。
內(nèi)容交付網(wǎng)絡(luò)通常使用任播模式
內(nèi)容交付網(wǎng)絡(luò)（CDN）是一種使用任播模式的技術(shù)。接收方可以使用 CDN 從互聯(lián)網(wǎng)上距離它最近的服務(wù)器接收數(shù)據(jù)。
用通用名稱封裝消息傳輸模式的好處在于，它允許架構(gòu)師和開發(fā)人員以相同的方式討論同一件事。對消息傳輸模式使用常規(guī)名稱可以節(jié)省時間。在設(shè)計會議中，說“使用發(fā)布-訂閱模式是滿足這項業(yè)務(wù)需求的好方法”要比花時間做出詳盡的解釋容易得多。當(dāng)然，隱含的假設(shè)是會議中的每個人都了解所引用的模式背后的細(xì)節(jié)。希望本文所提供的內(nèi)容和插圖可以幫助人們對當(dāng)今企業(yè)架構(gòu)中使用的較流行的消息傳輸模式達(dá)成共識。
多年來，消息傳輸?shù)膶嵺`已經(jīng)發(fā)展成多種消息傳輸模式。在本文中，我將分享一些較為常用的方法。我將這些模式分為兩部分。第一部分的標(biāo)題為“消息交換架構(gòu)”，描述了在發(fā)送方和接收方之間移動消息的結(jié)構(gòu)。第二部分是“路由”，涵蓋了用于在發(fā)送方和接收方之間傳遞消息的邏輯。
消息交換架構(gòu)
本節(jié)描述與在發(fā)送方和接收方之間傳輸消息的機(jī)制相關(guān)的消息傳輸模式。發(fā)布-訂閱
發(fā)布-訂閱（Pub-Sub）模式指的是發(fā)布者將消息發(fā)送到消息代理（broker）上的主題（topic）。你可以將主題視為一個收件箱。這個收件箱的概念根據(jù)實現(xiàn)技術(shù)而有不同的名稱。例如，RabbitMQ 將收件箱稱為 Exchange，而 Kafka 將收件箱稱為 Topic。訂戶綁定到主題，并以異步方式從主題接收消息。發(fā)布-訂閱模式非常適合向感興趣的各方提供事件信息
發(fā)布-訂閱模式的好處是它相對簡單：消息輸入，消息輸出，完事兒。另外如上所述，發(fā)布-訂閱模式是異步的。因此，在發(fā)送方和接收方之間沒有阻止鎖。發(fā)送方將消息發(fā)送給代理，然后移至其他任務(wù)。接收方在方便時接收消息。發(fā)布-訂閱模式中的消息往往是離散的，包含進(jìn)程對提供的數(shù)據(jù)進(jìn)行操作所需的所有信息。
扇出
扇出（Fanout）與發(fā)布-訂閱模式類似：感興趣的人可以綁定到一個主題，也就是收件箱。扇出模式與典型的 Pub-Sub 區(qū)別在于，許多感興趣的參與者都將綁定（也稱為訂閱）到一個給定的主題。然后，當(dāng)一條消息發(fā)送到該主題時，所有訂閱者都將收到發(fā)送到該主題的消息的副本。該消息被“分發(fā)出去”。（請參見下面的圖 2）扇出模式將向所有感興趣的訂閱者發(fā)送消息的副本
Twitter 是扇出模式的一個很好的例子。某人發(fā)送一條推文后，推文會發(fā)送給所有粉絲。
單向流
單向流（Unidirectional streaming）模式指的是發(fā)送方連續(xù)向接收方發(fā)送數(shù)據(jù)的模式。發(fā)送方可能是具有關(guān)于接收方直接知識的服務(wù)，例如連接到互聯(lián)網(wǎng)上的網(wǎng)站并不斷發(fā)送自身位置 GPS 信息的手機(jī)，如下圖 3 所示。在單向流模式中，發(fā)送方連續(xù)向接收方發(fā)送數(shù)據(jù)
或者，發(fā)送方可能連接到某種代理技術(shù)，代理又通過某種主題/收件箱機(jī)制轉(zhuǎn)發(fā)流，如下圖 4 所示。綁定到代理“收件箱”上的接收方這樣就能接收連續(xù)的消息流。
使用消息代理管理單向流
Apache Kafka 是實現(xiàn)單向流的消息代理技術(shù)的一個示例。
雙向流
雙向流（Bidirectional streaming）是指在發(fā)送方和接收方之間，以及接收方和發(fā)送方之間連續(xù)發(fā)送消息流的情況，如下圖 5 所示。雙向流模式在服務(wù)器和接收方之間在兩個方向上連續(xù)不斷地流轉(zhuǎn)數(shù)據(jù)
雙向流傳輸?shù)囊粋€示例是 gRPC。gRPC 在 HTTP/2 下運行，它允許發(fā)送方建立與接收方的恒定連接。連接后，數(shù)據(jù)可以連續(xù)在發(fā)送方和接收方之間來回流動。
路由
本節(jié)列出的消息傳輸模式描述了在發(fā)送方和接收方之間路由消息的各種方法。發(fā)布-訂閱、扇出和流模式專注于數(shù)據(jù)傳輸?shù)募軜?gòu)，而單播、廣播、多播和任播模式則專注于路由。單播
在單播（Unicast）模式中，消息從發(fā)送方路由到指定的接收方。單播模式的一個眾所周知的示例是 HTTP 請求/響應(yīng)交換。在單播模式中，發(fā)送方向單個接收方發(fā)送一條消息
發(fā)送方（在這里是 Web 瀏覽器）將請求消息發(fā)送到網(wǎng)絡(luò)上特定位置的 Web 服務(wù)器?；ヂ?lián)網(wǎng)的路由機(jī)制知道如何找到這個 Web 服務(wù)器并相應(yīng)地傳遞請求（又稱消息）。然后，該 Web 服務(wù)器使用相同的路由機(jī)制將響應(yīng)消息發(fā)送回調(diào)用方。
廣播
廣播（Broadcast）模式是一種發(fā)送方向網(wǎng)絡(luò)上的所有接收方發(fā)送消息的模式。網(wǎng)絡(luò)路由器負(fù)責(zé)發(fā)現(xiàn)網(wǎng)絡(luò)上的設(shè)備并相應(yīng)地轉(zhuǎn)發(fā)消息。在廣播模式中，發(fā)送方向網(wǎng)絡(luò)上的所有接收方發(fā)送一條消息
廣播模式的一個示例是地址解析協(xié)議（ARP）。在 ARP 下，路由器知道網(wǎng)絡(luò)上存在的物理設(shè)備，然后將設(shè)備標(biāo)識符 MAC 地址與邏輯 IP 地址相關(guān)聯(lián)，進(jìn)而據(jù)此轉(zhuǎn)發(fā)消息。
多播
多播（Multicast）模式將消息從發(fā)送方轉(zhuǎn)發(fā)到特定的接收方組（請參見下面的圖 8）。比如說，可以通過設(shè)備類型或網(wǎng)段在網(wǎng)絡(luò)上指定組。多播模式將消息從發(fā)送方轉(zhuǎn)發(fā)到網(wǎng)絡(luò)上的一組接收方
互聯(lián)網(wǎng)協(xié)議電視（IPTV）是多播模式的一個典型實現(xiàn)。例如，IPTV 數(shù)據(jù)會流式傳輸?shù)竭B接到特定“頻道”的設(shè)備，例如 Facebook 下的直播或特定的視頻會議會話。
任播
在任播（Anycast）模式中，路由器將消息發(fā)送到滿足一組確定因素中規(guī)定條件的接收方。任播模式的邏輯是“將此消息發(fā)送給滿足以下條件的任何接收方”。通常來說，任播模式用于根據(jù)地理位置的接近程度將消息從發(fā)送方路由到接收方，如下圖 9 所示。內(nèi)容交付網(wǎng)絡(luò)通常使用任播模式
內(nèi)容交付網(wǎng)絡(luò)（CDN）是一種使用任播模式的技術(shù)。接收方可以使用 CDN 從互聯(lián)網(wǎng)上距離它最近的服務(wù)器接收數(shù)據(jù)。
總結(jié)
如果你是在應(yīng)用程序開發(fā)活動中一直在使用消息傳輸?shù)募軜?gòu)師或開發(fā)人員，則很可能已經(jīng)很熟悉上面介紹的模式了。這些模式中有的名字你可能之前沒見過，但實際的實現(xiàn)一看就能認(rèn)出來。用通用名稱封裝消息傳輸模式的好處在于，它允許架構(gòu)師和開發(fā)人員以相同的方式討論同一件事。對消息傳輸模式使用常規(guī)名稱可以節(jié)省時間。在設(shè)計會議中，說“使用發(fā)布-訂閱模式是滿足這項業(yè)務(wù)需求的好方法”要比花時間做出詳盡的解釋容易得多。當(dāng)然，隱含的假設(shè)是會議中的每個人都了解所引用的模式背后的細(xì)節(jié)。希望本文所提供的內(nèi)容和插圖可以幫助人們對當(dāng)今企業(yè)架構(gòu)中使用的較流行的消息傳輸模式達(dá)成共識。
下載文檔
