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

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

請(qǐng)求/回應(yīng)

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

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

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

事件訂閱

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

圖二 事件訂閱通信模式

異步消息傳遞

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

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

可靠的消息傳遞

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

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

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

圖4 多播通信模式

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

發(fā)布/訂閱

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

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

行列

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

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

圖5 隊(duì)列通信模式

消息代理

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

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

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

聯(lián)盟

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

圖6 聯(lián)盟

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

發(fā)現(xiàn)

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

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

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

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

信任委托

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

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

信任委托溝通模式