## 引言：統一管理的閘道器框架

作為一款大規模分散式物聯網 MQTT 訊息伺服器，EMQX 除了完整支援 MQTT 3.x 和 5.0，還支援 STOMP、[MQTT-SN](https://www.emqx.com/zh/blog/connecting-mqtt-sn-devices-using-emqx)、LwM2M/[CoAP](https://www.emqx.com/zh/blog/connecting-coap-devices-to-emqx)，JT/T 808 等多種主流協議接入。不僅提供了廣泛的連線能力，以處理適用於各類場景的物聯網裝置；還為後端的物聯網管理服務提供了統一接入平臺和管理介面，以降低異構協議間的適配成本。

在[最新發布的 EMQX 5.0 ](https://www.emqx.com/zh/blog/emqx-v-5-0-released)中，我們重構了多協議接入的底層架構，統一了配置格式和管理介面，提供了一個全新的擴充套件閘道器框架。同時規範了各類閘道器的實現，使得各個閘道器功能定義更為清晰。

本文將對 EMQX 5.0 全新的閘道器框架及功能使用進行詳細解讀，幫助讀者更好地利用 EMQX 強大的多協議接入支援能力連線各類協議裝置，滿足更多物聯網場景的資料接入需求。

## EMQX 閘道器框架概述

由於裝置的接入協議種類繁多，各個協議對連線登入、訊息傳輸等擁有不同定義，這通常要求服務端部署各種協議的接入服務，導致軟體和維護的成本急劇上升。EMQX 自發布以來就提供了多協議接入的支援，來遮蔽接入層協議的異構，以降低使用者的開發和運營成本。

在 5.0 版本之前，EMQX 的多協議支援透過釋出各類協議的接入外掛來實現，這些獨立的外掛之間缺乏統一的定義和標準，相對來說有一定的使用難度。

為了給使用者帶來更加便捷易用的多協議支援，EMQX 5.0 對整個多協議接入架構進行了重構。所有非 MQTT 協議的接入都被統稱為閘道器（Gateway）。所有閘道器由一個統一的框架提供通用操作的支援，包括：

- **統一的使用者層介面：**該框架提供了風格統一的配置檔案、HTTP API 和命令列介面。以監聽器引數配置為例，4.x 版本中不同協議外掛對於監聽器暴露的引數各不相同，而在 5.0 版本中這些引數的風格都將是統一的。
- **統一的統計和監控指標：**提供了閘道器和客戶端級別的統計指標，例如收發位元組數、訊息等。
- **獨立的連線和會話管理：**每個閘道器都有在自己的客戶端管理頁面，且不同的閘道器允許使用相同的 Client ID ，而不是像 4.x 版本一樣都混合在 MQTT 客戶端列表中進行管理。
- **獨立的客戶端認證：**支援為每個閘道器配置獨立的認證，不再像 4.x 像一樣與 MQTT 客戶端認證混合在一起。
- **易擴充套件和規格清晰化：**框架抽象了一套標準的概念和介面使自定義閘道器變得更加容易。

[![](http://img.blog.itpub.net/blog/2022/09/13/b784ff8e516777ec.png?x-oss-process=style/bb)](https://www.emqx.com/zh/blog/emqx-connects-multiple-iot-protocols)

每個閘道器內的實現，和之前類似：

- **監聽器：**每個閘道器可以啟動多個監聽器來接受客戶端的網路請求，監聽器型別支援 TCP、SSL、UDP、DTLS。每類閘道器支援的監聽器型別各有不同。
- **報文解析：**每個閘道器都有屬於自己的報文解析模組，負責處理該協議的報文。
- **連線/會話：**負責建立連線、會話，並處理協議中定義的各種行為，例如登入認證、訊息收發等。
- **訊息模型轉換：** 負責處理本閘道器與 MQTT PUB/SUB 訊息模型的相容。例如，將 LwM2M 中的訊息轉換為 EMQX 中帶主題和 QoS 的訊息。

[![](http://img.blog.itpub.net/blog/2022/09/13/0b103aef17434479.png?x-oss-process=style/bb)](https://www.emqx.com/zh/blog/emqx-connects-multiple-iot-protocols)

## 閘道器通用行為規範

除了上述架構上的重構，EMQX 5.0 的閘道器還對**接入認證**和**訊息收發**這類通用行為進行了統一。

### 接入認證：客戶端資訊

閘道器統一使用**客戶端資訊**進行認證，客戶端資訊由閘道器在處理該客戶端接入時建立的，其中：

- 無論哪種閘道器，其客戶端資訊都包含通用欄位，例如 Client ID、Username、Password 等（即使該協議無該欄位的定義，閘道器會為其設定合適的預設值）同樣也包括 Peername、ProtoName、Peercert 等
- 每種閘道器也有其特定的客戶端資訊，例如 LwM2M 有 Endpoint Name 和 Life Time 等。

因此，在執行客戶端認證時，此類通用的客戶端欄位和特有的欄位都可以作為引數傳遞給認證器執行驗證。

### 訊息收發：PUB/SUB 訊息模型轉換

為了適配 MQTT 的 PUB/SUB 訊息模型，每類閘道器都必須完成對這種訊息模型的相容，以達到相互通訊的目的。對於 PUB/SUB 型別的協議閘道器，例如 MQTT-SN、STOMP 通常定義了主題和訊息負載的概念，則：

- 直接使用客戶端指定的主題和訊息內容
- 選擇一個合適的值作為訊息的 QoS。

但對於非 PUB/SUB 型別的協議，它缺少對主題、釋出、訂閱等概念的定義，則：

- 需要為其指定訊息主題。例如 LwM2M 閘道器，使用者可以配置各個型別訊息的主題。
- 需要為其設計訊息內容的格式。每種型別的閘道器都可能會使用不同的訊息格式。

## EMQX 5.0 閘道器框架詳解

### 客戶端認證

EMQX 4.x 中每種型別裝置都和 MQTT 使用相同的認證鏈，這種耦合導致在配置認證器時，需要考慮每種閘道器的異構情況：

[![](http://img.blog.itpub.net/blog/2022/09/13/5dbc67f7c45a2aa2.png?x-oss-process=style/bb)](https://www.emqx.com/zh/blog/emqx-connects-multiple-iot-protocols)

在 EMQX 5.0，閘道器框架允許為每種型別的閘道器都配置專屬於自己的認證器：

> 這個圖改一下：只需要 MQTT 與 LwM2M 對比一下就行了，去掉 MQTT-SN 跟其他，將之前的認證器上下排布改為左右排布。

[![](http://img.blog.itpub.net/blog/2022/09/13/22fefcebe96f4790.png?x-oss-process=style/bb)](https://www.emqx.com/zh/blog/emqx-connects-multiple-iot-protocols)

### 訊息模型轉換

**訊息模型轉換不適用於已定義 PUB/SUB 等概念的閘道器。**例如 MQTT-SN 協議已經定了釋出/訂閱的行為，則 MQTT-SN 閘道器會：

- 將協議中的 PUBLISH 報文，作為訊息釋出，其主題和 QoS 都由該報文指定。
- 將協議中的 SUBSCRIBE 報文，作為訂閱操作，其主題和 QoS 都由該報文指定。
- 將協議的 UNSUBSCRIBE 報文，作為取消訂閱操作，其主題由該報文指定。

**訊息模型轉換也不適用於具有與 PUB/SUB 模型概念相近的閘道器。**例如 STOMP 協議完全相容此訊息模型，則 STOMP 閘道器會：

- 將協議中的 SEND 報文作為訊息釋出。其主題為 SEND 報文中的 `destination` 欄位，訊息內容為 SEND 報文的訊息體內容，QoS 固定為 0。
- 將協議中的 SUBSCRIBE 報文作為訂閱請求。其主題為 SUBSCRIBE 報文中的 `destination` 欄位，QoS 固定為 0。且支援 MQTT 協議中定義的萬用字元。
- 將協議中 UNSUBSCRIBE 報文作為取消訂閱請求。其主題為 UNSUBSCRIBE 報文中的 `destination` 欄位。

**訊息模型轉換僅適用於未定義 PUB/SUB 等概念的閘道器。**例如 LwM2M 協議，則需要為其新增一些配置，來指定使用的主題格式，以及閘道器會內建一些規則來組織訊息內容的格式：

```fsharp
gateway.lwm2m {

mountpoint = "lwm2m/${endpoint_name}/"

translators {  
    // 下行命令主題。
    // 對於每個成功上線的新 LwM2M 客戶端，閘道器會建立一個訂閱關係來接收下行訊息並將其傳送給客戶端
    command {
      topic = "dn/#"
      qos = 0
    }

// 用於釋出來自 LwM2M 客戶端的註冊事件的主題                   
    register {
      topic = "up/register"
      qos = 0
    }
    ...                                   
  } 
}
```

則，如果一個 `endpoint_name` 為 `epn1` 的客戶端上線後：

- 閘道器會為其代理訂閱 `lwm2m/epn1/dn/#` 主題，以期望接收下行的控制訊息
- 閘道器會將該客戶端的 REGISTER 訊息，釋出到 `lwm2m/epn1/up/register` 主題上。其訊息格式由 LwM2M 閘道器的定義的資料轉換規則決定，例如 REGISTER 訊息的格式為：

```prolog
{ "msgType": "register",                                                
  "data": {                                                             
    "ep": "epn1",                                            
    "lt": 6400,                                                
    "sms": "sms_no_example",                                                 
    "lwm2m": "1.2",          
    "objectList": ["1/0", "3/0", "19/0"]                                       
  }                                                                     
}
```

### 釋出訂閱授權

閘道器中無獨立的主題授權管理，他們都集中於在 AuthZ 中。參考：[授權](https://www.emqx.io/docs/zh/v5.0/security/authz/authz.html#授權資料來源)

> 注：使用 PUB/SUB 模型轉換 的閘道器無需對其設定的主題配置許可權，因為這類客戶端的主題規則是強制性的。

### 鉤子支援性

EMQX 依賴鉤子實現各種功能的擴充套件，例如上下線訊息、規則引擎的觸發。因此，閘道器必須將關鍵性的事件釋出到鉤子上，以獲取與 EMQX 其他功能的相容。

在 v4.x，每種鉤子的支援並沒有規範，v5.0 中我們對其進行了總結，以下為必須支援的鉤子：

[![](http://img.blog.itpub.net/blog/2022/09/13/bcf8e07cf4c7b39d.png?x-oss-process=style/bb)](https://www.emqx.com/zh/blog/emqx-connects-multiple-iot-protocols)

例如：

- LwM2M 閘道器支援了 `client.connected` 鉤子，因此規則引擎可以透過 `$event/client_connected` 拿到每個 LwM2M 裝置的上線事件。
- LwM2M 閘道器支援了 `client.authenticate` 鉤子，因此 ExHook 可以透過掛載該鉤子處理 LwM2M 的客戶端的認證。

### 自定義認證

閘道器與 [MQTT 客戶端](https://www.emqx.com/zh/mqtt-client-sdk)一樣，也基於認證鏈分發認證請求，直到鏈上的某個認證器、外掛或 ExHook 返回允許/拒絕：

[![](http://img.blog.itpub.net/blog/2022/09/13/e3e3fcbb27ea277c.png?x-oss-process=style/bb)](https://www.emqx.com/zh/blog/emqx-connects-multiple-iot-protocols)

因此，同樣可以透過**自定義認證外掛或使用 ExHook** 來擴充套件對認證的支援。每個認證器的語義可簡寫為：

```kotlin
fun authenticate(ClientInfo, LastAuthResult)  // 入參為：客戶端資訊、和上次認證器的執行結果
    -> {stop, NewAuthResult}                  // 返回情況1：終止鏈執行，並返回新的認證結果
     | ignore                                 // 返回情況2：忽略，並繼續執行鏈上的下一個認證器
```

> 注：所有協議都會將認證請求釋出到該認證鏈上，所以需要透過 protocol 、listener_id 等欄位區分客戶端是來自於哪類閘道器和監聽器

## 使用者層介面

閘道器框架為所有的閘道器提供了統一的使用者層介面，例如，可以使用閘道器的 HTTP API 達到：

- 對某閘道器的啟用、停止和配置更新等
- 啟用、關閉、更新某閘道器的認證器等
- 新增、刪除、更新某閘道器的監聽器等
- 查詢、踢出某閘道器的客戶端，或為某客戶端新增、取消訂閱等

[![](http://img.blog.itpub.net/blog/2022/09/13/125a3fce30da5ed0.png?x-oss-process=style/bb)](https://www.emqx.com/zh/blog/emqx-connects-multiple-iot-protocols)

本文中僅提供一些簡單示例，詳情可參考官網文件： [閘道器配置](https://www.emqx.io/docs/zh/v5.0/admin/cfg.html#gateway)、[閘道器 HTTP API](https://www.emqx.io/docs/zh/v5.0/admin/api.html#/gateway)

例1，透過配置檔案啟用一個 STOMP 閘道器：

```abnf
gateway.stomp {

mountpoint = "stomp/"

listeners.tcp.default {
    bind = 61613
    acceptors = 16
    max_connections = 1024000
    max_conn_rate = 1000
  }
}
```

例2，透過 HTTP API 啟用一個 MQTT-SN 閘道器：

```ada
curl -X 'POST' 'http://127.0.0.1:18083/api/v5/gateway' \
  -u admin:public \
  -H 'Content-Type: application/json' \
  -d '{
  "name": "mqttsn",
  "enable": true,
  "gateway_id": 1,
  "mountpoint": "mqttsn/",
  "listeners": [
    {
      "type": "udp",
      "bind": "1884",
      "name": "default",
      "max_conn_rate": 1000,
      "max_connections": 1024000
    }
  ]
}'
```

## 未來展望

閘道器框架的全新升級為使用者使用 EMQX 5.0 進行多協議裝置接入帶來了諸多便利，未來我們還將在以下方面持續最佳化這一功能：

- 監控資訊支援輸出到 Prometheus 和 StatsD，以增加可觀測性。
- 各個協議實現的標準化測試。
- 完善個性化管理介面、客戶端資訊。例如針對 LwM2M 裝置的資源模型進行操作。
- LwM2M 等 UDP 型別的協議接入，需要支援 NAT 網路下的會話識別。一旦裝置休眠後，由於 NAT 轉換會導致 LwM2M 的裝置喚醒後，到服務端的地址和埠發生了變化，因此應該設計某類機制來識別這種變化。
- 為 ExProto 實現更輕量的設計，以降低 gRPC 的使用難度，提高執行效率。

## 結語

透過全新閘道器框架實現多種協議的接入和統一管理，進一步提升了 EMQX 的易用性。結合強大的資料整合、安全可靠的認證授權，以及億級的水平擴充套件能力等諸多優勢功能特性，各行業的物聯網使用者可以在多種業務場景中使用 EMQX 實現物聯網實時資料的高效連線、移動與處理。

>版權宣告： 本文為 EMQ 原創，轉載請註明出處。
>
>原文連結：[https://www.emqx.com/zh/blog/emqx-connects-multiple-iot-protocols](https://www.emqx.com/zh/blog/emqx-connects-multiple-iot-protocols)

EMQX 5.0 全新閘道器框架：輕鬆實現多物聯網協議接入

相關文章