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

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

請求/回應

請求/響應可能是最常見的通信模式。它由一個向服務器或響應方請求服務的客戶端或調用者組成（圖1）。這是HTTP使用的模式，也是面向服務的體系結構、web服務和代表性狀態傳輸的基礎。這是一個有用的模式，特別是如果您有一個客戶端-服務器或主-從架構。支持這種模式的其他協議包括受限應用協議（CoAP）和可擴展消息和存在協議（XMPP）。

圖一 請求/響應通信模式

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

事件訂閱

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

圖二 事件訂閱通信模式

異步消息傳遞

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

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

可靠的消息傳遞

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

用兩臺調頻發射機播送一個立體聲節目

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

圖4 多播通信模式

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

發布/訂閱

發布/訂閱通信模式是多播模式的擴展，主要區別在于傳輸的消息也存儲在中間節點上。根據協議，消息或對消息的引用隨后被分發給相應的訂戶。根據選擇的協議和中介上的設置，僅存儲最新消息、存儲給定數量的消息或存儲所有消息。分發整個消息和只分發對消息的引用之間的區別很重要，它會影響解決方案在消耗帶寬方面的性能。

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

行列

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

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

圖5 隊列通信模式

消息代理

消息代理本質上是標準化的中間件組件，它為防火墻強加于網絡中對等體之間雙向通信的問題提供了一個優雅的解決方案。它們通過允許實體連接到它們來工作，然后在連接的客戶端之間代理消息。因為所有連接都是從設備到代理建立的，所以只有代理需要可以從互聯網訪問。防火墻不需要接受或轉發設備的傳入連接，如果您使用嚴格的對等協議，則需要這樣做。

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

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

聯盟

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

圖6 聯盟

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

發現

在大規模分發場景中會出現幾個問題。首先，事物在生產時既不知道網絡身份也不知道所有者的身份:它們只知道它們的概念身份。在安裝和配置后（最好使用一些零配置技術來實現），它們會學習新的網絡身份，但不會學習所有者的身份。

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

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

圖7 發現

信任委托

在互聯網上，能夠做出良好的安全決策非常重要。信任委托是一種通信模式，在這種模式下，一個事物將請求實時轉發給一個更強大、更受信任的實體，然后在根據響應的內容返回響應時執行操作（圖8）。

然后，這個受信任的實體可以使用機器學習或與物品的所有者直接通信來學習如何響應網絡上與屬于他或她的物品相關的新請求。為了使這種模式成為可能，需要實時的異步雙向消息傳遞。XMPP的擴展支持這種模式。

信任委托溝通模式