IoT 中樞和可靠性
Azure IoT 中樞 是雲端中裝載的受控服務,可作為IoT應用程式與其連結裝置之間通訊的中央訊息中樞。 您可以可靠地安全地連線數百萬部裝置及其後端解決方案。 幾乎任何裝置都可以連線到IoT中樞。
IoT 中樞支援監視,以協助您追蹤裝置建立、裝置連線和裝置失敗。
IoT 中樞也支援下列傳訊模式:
- 裝置到雲端遙測
- 從裝置上傳檔案
- 請求-回應方法來從雲端控制您的裝置
如需有關 IoT 概念和 Azure IoT Hub 的詳細資訊,請參閱 和。
若要瞭解IoT中樞如何支援可靠的工作負載,請參考下列主題:
- IoT 中樞高可用性和災害復原
- 如何使用IoT中樞 實現跨區域高可用性
- 如何將 Azure IoT 中樞複製到另一個區域
下列各節專屬於 Azure IoT 中樞和可靠性:
- 設計考慮
- 設定檢查清單
- 建議的組態選項
設計考慮
如需 Azure IoT 中樞服務等級協定的詳細資訊,請參閱 Azure IoT 中樞的 SLA。
核對清單
您是否已將 Azure IoT 中樞設定為可靠性?
- 在另一個區域中布建第二個IoT中樞,並在裝置上有路由邏輯。
- 經常傳送事件時,請使用
AMQP
或MQTT
通訊協定。 - 如果您在使用裝置連接的 X.509 憑證,請僅在生產環境中使用由根 CA 驗證的憑證。
- 如需最大輸送量,請在建立IoT中樞時,使用分割區數目上限 (
32
),如果您打算使用內建端點。 - 若要調整規模,請增加階層並配置IoT中樞單位,而不是為每個區域新增多個IoT中樞。
- 在高輸送量情境中,使用批次事件。
- 如果您需要最小可能的延遲,請勿使用路由,並從內建端點讀取事件。
- 作為整個解決方案可用性和災害復原策略的一部分,請考慮使用ioT中樞 跨區域災害復原選項。
- 使用 SDK 將事件傳送至 IoT 中樞時,請確保正確捕獲由重試機制拋出的例外狀況(
EventHubsException
或OperationCancelledException
)。 - 若要避免因節流和超過配額限制而導致遙測中斷,請考慮新增 自定義自動擴展方案。
設定建議
請考慮下列建議,以在設定 Azure IoT 中樞時將可靠性優化:
建議 | 描述 |
---|---|
在另一個區域中布建第二個IoT中樞,並在裝置上有路由邏輯。 | 這些組態可以使用 禮賓服務進一步增強。 |
經常傳送事件時,請使用 AMQP 或 MQTT 通訊協定。 |
初始化會話時,AMQP 和 MQTT 具有較高的網路成本,不過 HTTPS 每個要求都需要額外的 TLS 額外負荷。
AMQP 和 MQTT 對於經常發行者來說效能較高。 |
如果您使用裝置連線 X.509 憑證,則只在生產環境中使用根 CA 所驗證的憑證。 | 請確定您有流程在憑證到期前更新憑證。 |
如需最大輸送量,請在建立IoT中樞時,使用分割區數目上限 (32 ),如果您打算使用內建端點。 |
事件中樞相容端點的裝置到雲端分割區數量反映了您可實現的下游平行處理程度。 這可讓您擴充至 32 並行處理實體,並提供最高的傳送和接收可用性。 建立之後,就無法變更此數位。 |
若要調整規模,請增加階層並配置IoT中樞單位,而不是為每個區域新增多個IoT中樞。 | 每個區域新增多個IoT中樞並不提供額外的復原功能,因為所有中樞都可以在相同的基礎叢集上執行。 |
在高吞吐量的情況下,使用批次事件。 | 服務會將包含多個事件的陣列提供給消費者,而不是只有一個事件的陣列。 取用的應用程式必須處理這些陣列。 |
如果您需要最小可能的延遲,請勿使用路由,並從內建端點讀取事件。 | 在IoT中樞中使用訊息路由時,訊息傳遞的延遲會增加。 平均而言,延遲不應超過 500 ms ,但無法保證傳遞延遲。 |
作為整個解決方案可用性和災害復原策略的一部分,請考慮使用ioT中樞 跨區域災害復原選項。 | 此選項會將IoT中樞端點移至配對的 Azure 區域。 只有裝置註冊表會被複製。 事件不會複製到次要區域。 客戶起始故障轉移的 RTO 介於 10 分鐘到數小時之間。 Microsoft起始的故障轉移,RTO 為 2-26 小時。 確認此 RTO 符合客戶的需求,並符合更廣泛的可用性策略。 如果需要較高的 RTO,請考慮實作用戶端故障轉移模式。 |
使用 SDK 將事件傳送至 IoT 中樞時,請確定已正確攔截重試原則擲回的例外狀況(EventHubsException 或 OperationCancelledException )。 |
使用 HTTPS 時,請實作適當的重試模式。 |