MQTT Broker 是用於連線物聯網裝置，完成訊息傳遞的重要元件。MQTT Broker 的選型，是物聯網應用構建過程中最為基礎也是最為關鍵的一步。本文將從物聯網應用普遍場景和專案需求出發，提供一些通用的選型思路和關注點，幫助讀者瞭解如何選擇一款最適合自己的 MQTT Broker。
明確您的專案需求
目前市面上可供選擇的 MQTT Broker 多達數十種，其中既有支援私有部署的 MQTT Broker，也有提供 MQTT 接入的雲服務。
數量繁多的 MQTT Broker 在給您的選擇帶來更多靈活性的同時，也增加了選擇的難度。
我們很難提供一個萬能的公式來指導您如何選擇 MQTT Broker，但是您可以從自己的專案需求出發，結合以下問題進行考慮：
- 長遠來看希望接入多少客戶端？
- 對基礎效能指標的要求？對訊息時延與可靠性敏感嗎？
- MQTT Broker 需要部署在哪裡，資料最終被如何使用？
- 使用者群/物聯網裝置的地理分佈是什麼？
- 資料特點是什麼，訊息大小與頻率是否是必須考慮的選項？
- 您的應用程式如何處理物聯網資料，比如首選的程式語言、資料儲存與分析元件是什麼？
- 所處行業是否有廣泛使用的 MQTT Broker？
- 是否有預算購買付費服務？
- …
根據以上問題，下文中我們將結合 MQTT Broker 能夠提供的特性進行進一步探討，幫助您更加明確自己所需要的 MQTT Broker 是怎樣的。
MQTT Broker 如何工作
在開始之前我們首先來瞭解一下 MQTT Broker 是如何工作的。
MQTT Broker 遵循 釋出-訂閱 訊息傳遞模型。在這個模型中，一個客戶端（訊息釋出者）將訊息釋出到一個主題中，而另一個客戶端（訊息訂閱者）則訂閱特定的主題，當釋出者釋出一條訊息時，所有訂閱了該主題的訂閱者都會收到該訊息。
檢視部落格 MQTT 釋出/訂閱模式介紹瞭解更多。
如下圖所示，透過 釋出-訂閱 模型，訊息可以在一個或多個訂閱者之間派發，訂閱者可以是裝置，也可以是應用程式。
進行訊息傳遞時客戶端和 MQTT Broker 遵循以下步驟：
- 建立連線：釋出者與訂閱者客戶端發起連線請求與 MQTT Broker 建立連線；
- 訂閱主題：訂閱者客戶端訂閱一個或多個主題；
- 訊息釋出：釋出者客戶端指定主題和 Payload 釋出訊息；
- 訊息路由：當 Broker 收到訊息時，它將檢查訂閱者列表，並向所有訂閱了該主題的客戶端路由傳送訊息；
- 斷開連線：客戶端主動傳送請求斷開連線，MQTT Broker 也可以在網路異常或心跳超期後斷開與客戶端的連線。
在基礎訊息傳遞功能上，大多數 MQTT Broker 都實現了 MQTT 協議所定義的基本功能，如 QoS 級別控制、客戶端身份認證、保留訊息、共享訂閱等，這些功能能夠幫助您快速實現特定場景下的需求。
但這不是全部。如果將 MQTT Broker 看作一個港口，訊息傳遞則僅僅是實現了貨物的運轉。實際上，為了保證貨物的運轉，需要一個完善的物流系統和倉儲設施來提供基礎保障；為了將來自各地的貨物發往不同的目的地，需要對貨物進行拆箱裝箱並使用不同的物流方式傳送；在物流的淡季與旺季，需要對港口設施與人員規模進行動態靈活調整以滿足需求的同時實現效益最大化。
以上要求對應到 MQTT Broker 分別是基礎執行時的安全防護、故障處理、指標監控，MQTT 訊息傳遞時的資料處理與資料整合，以及整個服務的彈性伸縮能力，這些特性是構建一個企業級、滿足不同需求物聯網應用的必備條件。
安全性
安全性是所有物聯網應用需要首要關注的問題，在選擇 MQTT Broker 時您應該考慮以下幾個方面。
客戶端身份認證
MQTT 客戶端身份認證是指客戶端連線 MQTT Broker 時，需要提供特定的憑證用以證明客戶端的身份。常見的身份認證手段和其對 MQTT Broker 的要求如下：
釋出訂閱授權
授權是指對在客戶端釋出和訂閱前，檢查是否具有對應主題的操作許可權。許可權列表通常儲存在內部或外部資料庫中，隨著業務變化需要在執行時動態更新。
授權功能常見的要求如下：
軟體漏洞與企業 IT 安全
根據軟體行業過往的歷史教訓，軟體的安全漏洞將會為企業業務帶來巨大影響。
如果您打算將某個 MQTT Broker 用於生產，請務必嚴格評估它是否經過了安全驗證，常用的安全驗證途徑有：
- 開源驗證：Broker 的程式碼是否開源，是否經過了開源社群充分驗證；
- 安全整合：是否具備充分的應用安全測試與安全防護，是否採用專業的安全解決方案。
企業 IT 安全的意義在於保護企業的資料安全，防止資料洩露，避免資料被破壞、竊取、濫用等，為此需要 MQTT Broker 提供包括密碼策略、安全審計、資料加密等功能。
叢集與彈性伸縮
MQTT Broker 叢集是指將多個單獨的 MQTT Broker（可以稱其為節點）連線在一起，共同處理連線和訊息的分散式的系統。
叢集對於客戶端來說是一個整體，其內部機制、節點數量的變化對客戶端是無感的，所有的連線、訊息釋出訂閱跟在單節點上沒有任何區別。
為什麼需要 MQTT Broker 叢集
提供更大的接入規模並保持可擴充套件性
試想您將一款汽車接入到了物聯網中，當它以每月數千到數萬臺的銷量湧向市場時，未來幾年內您的 MQTT Broker 需要面對數萬到數百萬連線的增長；而隨著車載系統 OTA 升級，越來越多的資料需要傳遞到雲端，MQTT Broker 的訊息吞吐也水漲船高。
在支援叢集的 MQTT Broker 中，您可以在執行時向叢集新增更多節點輕鬆地進行水平擴充套件，使其能夠處理越來越多的 MQTT 訊息和客戶端連線。
確保服務高可用
並非所有應用都需要應對業務增長壓力，當您的業務僅限於某個學校或製造工廠的環境監測時，未來數年內客戶端與訊息數量是可以預計的，甚至它不會發生任何變化。
您可能已經意識到了：單臺 MQTT Broker 可以承載數萬個客戶端，這足以滿足大多數物聯網應用需求，叢集是否是必要的？
答案是肯定的，在一個 MQTT Broker 叢集中，即使某些節點發生故障叢集也可以繼續執行，從而確保應用無單點故障、服務始終可用。
因此，當您對應用的可靠性有要求時，請務必選擇支援叢集的 MQTT Broker。
只有少部分 MQTT Broker 支援叢集
MQTT Broker 叢集最重要的工作是確保叢集節點能夠高效可靠地同步和複製 MQTT 會話狀態資訊，包括訂閱的訊息和未完成的訊息傳輸，並實現連線的負載均衡、裝置的集中管理，同時確保整個叢集具備可擴充套件性和高可用性。
要全部實現這些特性並不容易，因此絕大部分 MQTT Broker 只能以單節點的形式部署，考慮到擴容能力與高可用特性的重要性，其中一些 Broker 提供了特別的實現方案：
透過 MQTT 橋接功能連線多個 Broker
以 MQTT 訊息釋出訂閱的方式在多個 Broker 之間傳遞訊息，這種方式一定程度上可以實現接入能力擴充套件，讓更多的客戶端連線到一起通訊，但其通訊非常低效，且無法保證高可用性。
在多個節點之間全量的同步會話狀態
同時啟動多個 MQTT Broker，在節點之間全量的同步會話狀態，藉助負載均衡，在單節點故障時立即切換到另一個可用節點。這種方式以單機熱備份的方式實現了高可用性，但對於擴充套件性沒有幫助，且增加了使用成本。
以上方案確實有效，但無法同時兼顧擴容能力與高可用性，併為部署引入了額外的複雜操作。因此如果您想更加輕鬆地構建可按需擴充套件的可靠物聯網業務，最理想的選擇是那些支援叢集的 MQTT Broker。
EMQX 是如何支援單叢集億級 MQTT 併發連線的？點選檢視詳細測試過程 →
資料整合與規則引擎
在構建物聯網應用時，除了裝置與裝置的通訊，通常需要在多個系統之間進行資料交換。
例如，您可以透過 MQTT Broker 採集工廠產線感測器的資料，併傳送到與之配套的 MES、ERP 系統當中，資料庫或事件驅動的訊息佇列如 Apache Kafka 就是兩個系統之間最好的橋樑；
您也可以將遍佈某個城市的所有氣象感測器資料儲存到時序資料庫 InfluxDB 中，以便進一步的處理和分析，充分挖掘資料價值。
實現這一目的最簡單的方法是編寫一個應用程式：從 MQTT 主題訂閱訊息，寫入到對應的的資料整合當中。由於這類需求普遍存在，一些 MQTT Broker 會以外掛或擴充套件的方式直接提供類似的功能。
在最終寫入資料之前，您可能還需要將資料進行過濾、編解碼轉換等處理，以滿足實際的業務需求。
一些 MQTT Broker 提供了用於資料處理的規則引擎，允許在 Broker 上建立資料驅動型的規則並將處理結果寫入到資料整合當中。此功能通常以低程式碼的方式如 SQL、表單編輯等方式進行配置。
整個流程如下圖所示：
在需要與外部資料系統整合的物聯網應用中，內建資料整合和規則引擎是 MQTT Broker 一個重要的加分項，它不需要額外的開發工作，能夠加快業務的交付，同時它還可以隨叢集伸縮擴容，實現最終的高可用性。
效能
MQTT Broker 用於連線大量客戶端，並實現海量的訊息傳遞，在此過程中需要考慮以下效能指標：
- 最大連線數：MQTT Broker 支援的最大客戶端連線數的上限；
- 訊息傳輸延遲：訊息從傳送端到接收端的時間消耗，在網路環境相同的情況下，主要取決於 MQTT Broker 效能；
- 訊息傳送/接收速率：每秒鐘 MQTT Broker 能夠處理的訊息傳送/接收的數量；
- 訊息儲存效能：有些 MQTT Broker 支援訊息的持久化與外部資料整合，這就需要考慮訊息的儲存效能。
效能指標看起來很好衡量，資料大小決定一切，通常具有較高效能 MQTT Broker 在其他方面也不會太差，但效能指標不應該是評判 MQTT Broker 好壞的唯一標準，除非它真的非常差勁。
但要注意的是 MQTT Broker 宣稱的效能指標都是在特定的場景下測試的，訊息速率、主題層級、訊息 QoS、訊息 Payload 大小以及是否啟用規則引擎等任意條件都會對其結果造成影響。
另外，任何 Broker 都可以對外提供一個難以復現並且使用者永遠用不到的指標，如果您真的對效能有很高要求，請謹慎思考它的技術是否真的能帶來這個結果，它的測試結果是否能夠復現。實踐出真知，最好結合自己的應用場景實際做一下壓力測試。
雲原生
雲原生是一種軟體架構和交付方式，旨在支援在雲端高效、可靠地構建和執行應用程式。
藉助雲原生技術，您可以將 MQTT Broker 與基礎設施視為一個整體，藉助容器、微服務和自動化運維等技術實現 MQTT Broker 的高效、靈活、可靠部署。
同時，雲原生技術還能夠提供配置管理、叢集擴容、無縫升級、故障處理和統一監控等管理操作，更好地支援大規模物聯網應用的開發和運營。
要實現以上目標，需要要求 MQTT Broker 的伸縮能力以及管理功能與雲底層能力深度適配，而事實上每個 Broker 對雲原生的應用程度有所不同。
使用 EMQX Kubernetes Operator 在 Kubernetes 上自動化部署、配置、管理 EMQX 叢集。
支援擴充套件開發
單一的軟體無法滿足所有使用者需求，在一些應用中，您需要擴充套件開發 MQTT Broker 以新增不同的功能，例如支援更多訊息傳輸協議、實現特有的認證授權流程、支援特殊的資料加密方式、監控告警功能等。
這需要 MQTT Broker 提供對應的擴充套件機制如外掛機制，以方便必要時進行二次開發，除此之外還需要支援使用您熟悉的語言來進行擴充套件。
檢視 EMQ 提供的 MQTT 程式設計系列部落格，學習 MQTT 協議在各類客戶端中的應用實踐。
成本
成本是一個綜合的概念，需要結合您的預算進行考慮。
您可以根據情況購買企業服務或使用開源 MQTT Broker，目前可供選擇的開源 MQTT Broker 很多，在開源協議允許的情況下，通常不需要任何購買費用即可部署。但安裝、維護與擴充套件開發需要消耗更多的資源。
如果您的應用規模很大，您需要考慮 MQTT Broker 效能差異帶來的成本差異，更好的效能指標意味著更少的硬體、網路和維護開銷，這能夠降低總體成本。
如果您選擇的是託管 MQTT 雲服務，其計費模式通常與連線數和流量成正比，請務必閱讀每個計費方案的細則，選擇您的使用場景下成本最優的方案。
其他需要關注的因素
除了 MQTT Broker 本身外，您還可以從以下方面考慮：
更快、更本地化的商業服務
優先選擇那些可以提供本地化或全球化的服務 MQTT Broker 提供商，這能夠讓企業更快地獲取技術支援，可以加快交付並節省大量成本。
避免從頭開始構建系統的風險和成本
儘量選擇那些經過驗證的 MQTT Broker 或技術，選擇行業驗證過的解決方案，避免從頭開始構建系統，從而降低投資風險和成本。
支援邊緣和雲的無縫整合
如果您需要在邊緣部署，請選擇資源佔用更低、具有邊緣最佳化、或者有成熟雲端-邊緣解決方案的 MQTT Broker。
結語
本文列舉了在進行 MQTT Broker 選型時開發者需要考慮的主要因素。讀者可以根據自身專案的實際情況，逐一排查並綜合考量，選擇最適合自己的 MQTT Broker。
版權宣告： 本文為 EMQ 原創，轉載請註明出處。
原文連結：https://www.emqx.com/zh/blog/7-factors-to-consider-when-choosing-mqtt-broker-2023