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