在您著手一個新的物聯(lián)網(wǎng)項目之前，您應(yīng)該考慮哪些通信模式最適合它。事實上，在決定使用協(xié)議、通信框架和中間件之前，您應(yīng)該考慮這些模式。原因很簡單:這個決定防止您將自己拖入一個在不破壞解決方案的代碼、架構(gòu)、安全性或互操作性的情況下很難擺脫的困境。

通過遵守標(biāo)準(zhǔn)和開放規(guī)范，您可以提高互操作性。同樣，通過使用現(xiàn)有的開放、標(biāo)準(zhǔn)化、可互換的組件，您還可以避免構(gòu)建昂貴的中間件。一些模式可能會在項目早期引入額外的復(fù)雜性，但與項目生命周期后期不可預(yù)見但可避免的問題（包括與集成相關(guān)的問題）的成本相比，這種成本可能微不足道。

請求/回應(yīng)

請求/響應(yīng)可能是最常見的通信模式。它由一個向服務(wù)器或響應(yīng)方請求服務(wù)的客戶端或調(diào)用者組成（圖1）。這是HTTP使用的模式，也是面向服務(wù)的體系結(jié)構(gòu)、web服務(wù)和代表性狀態(tài)傳輸?shù)幕A(chǔ)。這是一個有用的模式，特別是如果您有一個客戶端-服務(wù)器或主-從架構(gòu)。支持這種模式的其他協(xié)議包括受限應(yīng)用協(xié)議（CoAP）和可擴(kuò)展消息和存在協(xié)議（XMPP）。

圖一 請求/響應(yīng)通信模式

然而，這種模式的一個缺點是參與者的不平等，這在互聯(lián)網(wǎng)拓?fù)渲幸埠苊黠@。雙方互相請求信息的雙向通信可能很困難，尤其是在有防火墻的情況下。你必須決定誰是客戶，誰是服務(wù)器。如果您將傳感器設(shè)置為客戶端，將中間件設(shè)置為服務(wù)器，則傳感器可以在需要時報告數(shù)據(jù)，但中間件在需要時將很難獲取信息。如果傳感器是服務(wù)器，中間件是客戶端，中間件可以在需要時收集數(shù)據(jù)，但傳感器可能不受防火墻保護(hù)，任何人都可以連接到傳感器。因此，如果在網(wǎng)絡(luò)中使用防火墻，事件和事件訂閱或安全性很難管理，有時需要額外的服務(wù)或大量資源。

事件訂閱

事件訂閱模式允許客戶端從服務(wù)器訂閱給定類型的事件。然后，服務(wù)器在每次觸發(fā)事件時通知客戶端，而不必不斷輪詢服務(wù)器（圖2）。高級事件訂閱機(jī)制可以包括何時以及在什么條件下需要事件的客戶特定要求。使用這種模式的好處是，隨著時間的推移，有一半的消息是不需要的，并且更新的延遲保持在最低限度。支持這種模式的協(xié)議包括CoAP；XMPP以及通用事件通知體系結(jié)構(gòu)，它是通用即插即用體系結(jié)構(gòu)的一部分，是HTTP的擴(kuò)展版本。

圖二 事件訂閱通信模式

異步消息傳遞

異步消息傳遞是在網(wǎng)絡(luò)中的對等點之間發(fā)送消息的能力。該模式假設(shè)消息可以雙向傳輸，參與者之間沒有隱含的層級差異（圖3）。如果一個協(xié)議支持異步消息傳遞通信模式，那么所有其他通信模式都可以建立在它的基礎(chǔ)上。支持這種模式的協(xié)議包括XMPP高級消息隊列協(xié)議（AMQP）；在IP層上，是用戶數(shù)據(jù)報協(xié)議（UDP），盡管后者可能與防火墻有問題。

圖3 異步消息傳遞通信模式

可靠的消息傳遞

對于關(guān)鍵應(yīng)用程序來說，知道消息已經(jīng)被準(zhǔn)確地傳遞到目的地一次是很重要的，異步消息傳遞通信模式正是這樣做的。消息可能在途中丟失，但是使用請求/響應(yīng)模式，您可以重試發(fā)送消息，直到從目的地返回確認(rèn)（或響應(yīng)）為止。因為消息及其響應(yīng)都可能丟失，所以該方法確保消息至少被傳遞到其目的地一次，但是對于某些應(yīng)用程序（如需要事務(wù)或進(jìn)行計數(shù)的應(yīng)用程序）來說，最多傳遞一次（或至少傳遞一次）是不夠的?？煽康南鬟f是一種確保消息只被傳遞到目的地一次的方法。支持可靠消息傳遞的協(xié)議包括消息隊列遙測傳輸（MQTT）、AMQP以及通過已發(fā)布的開放擴(kuò)展的HTTP和XMPP。

用兩臺調(diào)頻發(fā)射機(jī)播送一個立體聲節(jié)目

前面的模式關(guān)注的是兩個實體之間的通信。然而，有時如果相同的信息要同時發(fā)送給多個實體，則需要更有效的模式。最簡單的這種模式是多播通信模式。在這里，發(fā)送方通過中介（代理或路由器）發(fā)送一條消息，然后中介將消息分發(fā)給多個請求參與通信的接收方（圖4）。這種模式節(jié)省了帶寬，因為發(fā)送方不必單獨向各方發(fā)送單獨的消息。事實上，發(fā)送者甚至不需要知道接收者是誰。這種模式在很多方面都很有用——例如，在同步多個實體或向多個接收者分發(fā)信息時。支持多播的協(xié)議包括XMPP、AMQP和UDP。

圖4 多播通信模式

然而，有一點需要注意:盡管您可以使用這種模式來節(jié)省帶寬，但它也經(jīng)常被用作克服所選協(xié)議及其對事件訂閱模式支持的限制的一種方法。此外，多播本來就很難保證安全，只有當(dāng)接收方實際使用大部分傳輸?shù)闹禃r，多播在帶寬方面才更有效。如果在需要事件訂閱但無法訂閱的網(wǎng)絡(luò)中使用頻繁的多播來減少延遲，多播模式可能會大大增加而不是減少所需的帶寬。

發(fā)布/訂閱

發(fā)布/訂閱通信模式是多播模式的擴(kuò)展，主要區(qū)別在于傳輸?shù)南⒁泊鎯υ谥虚g節(jié)點上。根據(jù)協(xié)議，消息或?qū)ο⒌囊秒S后被分發(fā)給相應(yīng)的訂戶。根據(jù)選擇的協(xié)議和中介上的設(shè)置，僅存儲最新消息、存儲給定數(shù)量的消息或存儲所有消息。分發(fā)整個消息和只分發(fā)對消息的引用之間的區(qū)別很重要，它會影響解決方案在消耗帶寬方面的性能。

如果訂閱者使用了大部分消息，那么轉(zhuǎn)發(fā)消息本身會更有效，就像多播的情況一樣。但是，如果消費僅在需要時發(fā)生，則發(fā)送較短的引用會更有效，因為這些消息較小，訂閱者將僅使用其中的一小部分來獲取實際消息。要在后一種情況下獲取消息，需要執(zhí)行單獨的請求/響應(yīng)操作。支持發(fā)布/訂閱模式的協(xié)議包括MQTT、AMQP和XMPP。

行列

隊列（或先入先出隊列）是一種通信模式，它允許一個或多個實體向隊列發(fā)送消息或工作項目，然后讓一個或多個接收者以有序的方式接收這些消息（圖5）。隊列通常位于所有參與者都連接到的中間節(jié)點或網(wǎng)絡(luò)上。

隊列是一個很好的負(fù)載平衡工具，從多個來源收集的工作項需要在現(xiàn)有的工作人員之間進(jìn)行分配，這些工作人員可能具有不同的性能。通過使用隊列，您可以避免數(shù)據(jù)提供者和工作者之間的任何硬鏈接，從而可以根據(jù)實際工作負(fù)載輕松擴(kuò)展或收縮數(shù)據(jù)提供者集和工作者集。在本文討論的協(xié)議中，只有AMQP本身支持隊列。

圖5 隊列通信模式

消息代理

消息代理本質(zhì)上是標(biāo)準(zhǔn)化的中間件組件，它為防火墻強(qiáng)加于網(wǎng)絡(luò)中對等體之間雙向通信的問題提供了一個優(yōu)雅的解決方案。它們通過允許實體連接到它們來工作，然后在連接的客戶端之間代理消息。因為所有連接都是從設(shè)備到代理建立的，所以只有代理需要可以從互聯(lián)網(wǎng)訪問。防火墻不需要接受或轉(zhuǎn)發(fā)設(shè)備的傳入連接，如果您使用嚴(yán)格的對等協(xié)議，則需要這樣做。

除了代理消息之外，代理還可以為連接的實體提供重要的服務(wù)，例如在多播、發(fā)布/訂閱和隊列模式中充當(dāng)中介。消息代理通常還提供客戶端認(rèn)證服務(wù)，這對于分布式網(wǎng)絡(luò)中的連接設(shè)備來說是一件棘手的事情。

因此，如果代理轉(zhuǎn)發(fā)通信中已通過身份驗證的各方的身份，實體可以使用此信息做出安全決策，而無需在每個設(shè)備中實施定制的身份驗證。盡管對等通信可能是許多人的選擇，但這種解決方案必須自己處理客戶端身份驗證以避免變得不安全。如果您使用包含消息代理的協(xié)議，您可能不需要開發(fā)自己的中間件來使您的解決方案工作。以某種形式使用代理的協(xié)議包括XMPP、AMQP和MQTT。

聯(lián)盟

聯(lián)盟是一種重要的模式，在這種模式中，全球網(wǎng)絡(luò)被劃分為多個邏輯部分，以實現(xiàn)全球可擴(kuò)展性和有機(jī)增長（圖6）。這里的關(guān)鍵是使用分而治之的方法在不限制現(xiàn)有網(wǎng)絡(luò)性能的情況下實現(xiàn)增長。在無代理通信中，例如使用HTTP或CoAP進(jìn)行的通信，聯(lián)盟發(fā)生在域級別。每個域都指向自己的一組托管自己的web服務(wù)器的IP地址。您可以在新域上添加新的web服務(wù)器，而不限制對現(xiàn)有web服務(wù)器的訪問。這是萬維網(wǎng)成功和可擴(kuò)展性的一個關(guān)鍵特征。

圖6 聯(lián)盟

當(dāng)使用支持聯(lián)合的代理協(xié)議時，代理之間相互連接以路由或中繼消息。每個代理在其自己的域上處理身份驗證，并識別如何連接到其他域以向它們轉(zhuǎn)發(fā)消息。最著名的支持聯(lián)合的代理協(xié)議是簡單郵件傳輸協(xié)議。在本文討論的代理協(xié)議中，只有XMPP支持聯(lián)邦。聯(lián)合代理網(wǎng)絡(luò)提供了一種優(yōu)雅的方式來為每個實體分配一個全局身份。

發(fā)現(xiàn)

在大規(guī)模分發(fā)場景中會出現(xiàn)幾個問題。首先，事物在生產(chǎn)時既不知道網(wǎng)絡(luò)身份也不知道所有者的身份:它們只知道它們的概念身份。在安裝和配置后（最好使用一些零配置技術(shù)來實現(xiàn)），它們會學(xué)習(xí)新的網(wǎng)絡(luò)身份，但不會學(xué)習(xí)所有者的身份。

在合同中，所有者可能通過掃描盒子上的貼紙來了解自己的網(wǎng)絡(luò)身份和物品的概念身份。發(fā)現(xiàn)通信模式創(chuàng)建了一種機(jī)制，通過這種機(jī)制，使用事物概念身份的公共知識將事物的網(wǎng)絡(luò)身份與所有者的網(wǎng)絡(luò)身份相匹配（圖7）。

這通過使用網(wǎng)絡(luò)上對物品和所有者都可用的物品注冊表來實現(xiàn)。事物向注冊中心注冊它們的概念身份，所有者僅使用它們的概念身份來聲明這些事物。如果成功，每個人的網(wǎng)絡(luò)身份將被發(fā)送給另一個人，然后雙方都知道如何相互通信。XMPP的擴(kuò)展支持這種模式。

圖7 發(fā)現(xiàn)

信任委托

在互聯(lián)網(wǎng)上，能夠做出良好的安全決策非常重要。信任委托是一種通信模式，在這種模式下，一個事物將請求實時轉(zhuǎn)發(fā)給一個更強(qiáng)大、更受信任的實體，然后在根據(jù)響應(yīng)的內(nèi)容返回響應(yīng)時執(zhí)行操作（圖8）。

然后，這個受信任的實體可以使用機(jī)器學(xué)習(xí)或與物品的所有者直接通信來學(xué)習(xí)如何響應(yīng)網(wǎng)絡(luò)上與屬于他或她的物品相關(guān)的新請求。為了使這種模式成為可能，需要實時的異步雙向消息傳遞。XMPP的擴(kuò)展支持這種模式。

信任委托溝通模式