3、ThingsBoard网关概览：网关功能、网关架构、支持的协议

好，咱们进入第三章。这一章我打算跟你聊聊ThingsBoard网关的全貌。说实话，网关这东西，在IoT系统里就是个「二传手」——但它这个二传手，干的可不只是传个球那么简单。

我记得刚入行那会儿，有个项目要把一堆老旧Modbus设备接入云端。设备本身连网口都没有，更别提MQTT了。怎么办？加网关。从那以后，我对网关的定位就特别清晰：它是连接「哑设备」和「智能平台」的桥梁。

3.1 网关的核心功能

ThingsBoard网关能做什么？我总结了三件事：

• 协议转换：把Modbus、OPC UA、BACnet这些「方言」翻译成MQTT、HTTP、CoAP这些「普通话」
• 数据汇聚：把多个设备的数据收上来，打包发给平台
• 边缘处理：在本地做过滤、聚合、甚至简单的规则判断

你想想看，如果每个传感器都要直接连平台，那平台得扛多少连接？网关就是那个「以一当百」的角色。

3.2 网关的架构设计

ThingsBoard网关的架构，说白了就是「插件化」的。我画个简图给你看：

┌─────────────────────────────────────────┐
│           ThingsBoard Gateway            │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐  │
│  │ Connector│  │ Connector│  │ Connector│  │
│  │ (Modbus) │  │  (OPCUA) │  │ (MQTT)  │  │
│  └────┬────┘  └────┬────┘  └────┬────┘  │
│       │            │            │         │
│  ┌────┴────────────┴────────────┴────┐   │
│  │         Core Engine               │   │
│  │  (数据路由、缓存、重连、日志)      │   │
│  └────────────────┬──────────────────┘   │
│                   │                      │
│  ┌────────────────┴──────────────────┐   │
│  │         Remote Client              │   │
│  │  (MQTT/HTTP/CoAP → ThingsBoard)   │   │
│  └───────────────────────────────────┘   │
└─────────────────────────────────────────┘

这个架构的好处是什么？松耦合。每个Connector只管自己的协议解析，Core Engine负责统一调度。我曾经在一个项目里，同时跑了Modbus、OPC UA和BLE三个Connector，互不干扰，稳得很。

3.3 支持的协议：MQTT / HTTP / CoAP

网关跟ThingsBoard平台通信，主要就这三种协议。我一个个说。

3.3.1 MQTT

MQTT是默认选项，也是我最推荐的。为什么？

• 轻量：报文头只有2字节，适合低带宽场景
• 双向：支持发布/订阅，平台可以主动下发指令
• 可靠：QoS 0/1/2 三级，按需选

配置示例：

{
  "broker": {
    "host": "demo.thingsboard.io",
    "port": 1883,
    "ssl": false,
    "credentials": {
      "accessToken": "YOUR_ACCESS_TOKEN"
    }
  },
  "mapping": {
    "topicFilter": "/sensor/+/data",
    "converter": "JsonConverter"
  }
}

嗯，这里要注意：Access Token是身份凭证，千万别硬编码在代码里。我建议用环境变量或者加密配置文件。

3.3.2 HTTP

HTTP适合什么场景？低频上报。比如一个温湿度传感器，每5分钟上报一次数据。用MQTT有点大材小用，HTTP就够了。

ThingsBoard网关的HTTP Connector支持RESTful API，数据格式通常是JSON：

POST /api/v1/YOUR_ACCESS_TOKEN/telemetry
Content-Type: application/json

{
  "temperature": 25.3,
  "humidity": 68.2
}

但HTTP有个缺点：单向。平台想下发指令？得靠设备主动轮询。所以实时性要求高的场景，别用HTTP。

3.3.3 CoAP

CoAP是专门为资源受限设备设计的。它基于UDP，比TCP更轻量。我一般在NB-IoT或者LoRaWAN的场景下用CoAP。

配置示例：

{
  "coap": {
    "host": "0.0.0.0",
    "port": 5683,
    "timeout": 5000
  }
}

CoAP的报文格式跟HTTP很像，但更紧凑。它支持GET/POST/PUT/DELETE，也支持观察模式（类似MQTT的订阅）。

3.4 网关的部署模式

ThingsBoard网关可以跑在多种硬件上：

硬件平台	推荐场景	我的经验
树莓派	原型验证、小规模部署	够用，但别跑太多Connector
工业网关（如Advantech）	工厂、车间	稳定，支持宽温
Docker容器	云网关、集中管理	我最喜欢的方式，升级方便
嵌入式Linux	资源受限设备	需要裁剪系统，门槛高一些

我个人习惯用Docker部署。为什么？环境隔离、版本可控、一键升级。你想想看，如果网关分布在几十个站点，每个都要手动升级，那得多痛苦？

3.5 本章小结

这一章我们聊了：

• 网关的三大功能：协议转换、数据汇聚、边缘处理
• 插件化架构：Connector + Core Engine + Remote Client
• 三种通信协议：MQTT（推荐）、HTTP（低频）、CoAP（超低功耗）
• 部署方式：树莓派、工业网关、Docker、嵌入式Linux

下一章，我会带你亲手搭建一个网关环境，从安装到跑通第一个数据流。到时候你会看到，这些理论是怎么落地的。

---

公众号:蓝海资料掘金营，微信deep3321