物联网实战：Spring Boot + Netty 搭建 MQTT | 多协议适配与模块化设计
简述
基于Netty构建的物联网平台采用分层解耦的微服务架构，从上到下分为设备接入层、数据处理层、业务应用层和存储层
整体架构图 五层VS四层
四层
┌───────────────────────────────────────────────────────────────────┐
│ 第四层 · 业务应用层 │
│ 可视化大屏 │ 告警中心 │ 设备影子控制台 │ OTA管理 │ 开放API │
└───────────────────────────┬───────────────────────────────────────┘
│ HTTP / gRPC / Kafka
┌───────────────────────────┴───────────────────────────────────────┐
│ 第三层 · 核心服务层 │
│ ┌──────────┐ ┌──────────┐ ┌──────────────┐ ┌──────────────────┐ │
│ │设备管理 │ │认证授权 │ │规则引擎 │ │数据存储服务 │ │
│ │(物模型) │ │(ACL) │ │(DSL+动作触发) │ │(TSDB/Redis/DB) │ │
│ └──────────┘ └──────────┘ └──────────────┘ └──────────────────┘ │
│ 设备影子服务 (Shadow) │
└───────────────────────────┬───────────────────────────────────────┘
│ Kafka（核心事件总线）
┌───────────────────────────┴───────────────────────────────────────┐
│ 第二层 · 消息路由与流转层 │
│ ┌─────────────────┐ ┌──────────────────┐ ┌───────────────────┐ │
│ │ 主题匹配引擎 │ │ 订阅关系管理器 │ │ 上行/下行分发器 │ │
│ │ (Trie + 通配符) │ │ (Redis+本地缓存) │ │ (直推/离线缓存) │ │
│ └─────────────────┘ └──────────────────┘ └───────────────────┘ │
└───────────────────────────┬───────────────────────────────────────┘
│ 内部统一消息 (InternalMessage)
┌───────────────────────────┴───────────────────────────────────────┐
│ 第一层 · 统一接入层 │
│ ┌─────────────────────────── 协议适配引擎 ───────────────────────┐ │
│ │ ┌─────────┐ ┌─────────┐ ┌───────────┐ ┌─────────────────────┐│ │
│ │ │MQTT │ │CoAP │ │HTTP/WebSocket│ │自定义TCP/二进制 ││ │
│ │ │Codec │ │Codec │ │Codec │ │Codec ││ │
│ │ └─────────┘ └─────────┘ └───────────┘ └─────────────────────┘│ │
│ │ 协议自动识别 (端口/首包嗅探) │ │
│ └──────────────────────────────────────────────────────────────┘ │
│ ┌──────────────────────────────────────────────────────────────┐ │
│ │ 连接管理器 │ 心跳/会话保持 │ 安全与流控 (TLS/令牌桶/ACL前置) │ │
│ └──────────────────────────────────────────────────────────────┘ │
│ Netty 网络传输层 (TCP/UDP/Epoll) │
└───────────────────────────────────────────────────────────────────┘
五层
┌────────────────────────────────────────────────────────────────────────┐
│ 第五层 · 业务应用层 │
│ 可视化大屏 │ 告警中心 │ 设备影子 │ OTA │ 规则配置 │ 用户门户 │
└────────────────────────────┬───────────────────────────────────────────┘
│ HTTP / gRPC / WebSocket
┌────────────────────────────┴───────────────────────────────────────────┐
│ 第四层 · 核心服务层 │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌────────────────────┐│
│ │ 设备管理 │ │ 认证授权 │ │ 规则引擎 │ │ 数据存储服务 ││
│ │ (注册/拓扑) │ │ (X.509/JWT)│ │ (SQL/DSL) │ │ (TSDB+Cache+DB) ││
│ └─────────────┘ └─────────────┘ └─────────────┘ └────────────────────┘│
└────────────────────────────┬───────────────────────────────────────────┘
│ Kafka / RabbitMQ（核心事件总线）
┌────────────────────────────┴───────────────────────────────────────────┐
│ 第三层 · 消息路由与流转层 │
│ ┌──────────────────┐ ┌──────────────────┐ ┌────────────────────────┐│
│ │ 主题匹配路由 │ │ 消息队列代理 │ │ 上行/下行分发器 ││
│ │ (Trie / 通配符) │ │ (Kafka 分区) │ │ (在线直推+持久化) ││
│ └──────────────────┘ └──────────────────┘ └────────────────────────┘│
└────────────────────────────┬───────────────────────────────────────────┘
│ 内部统一消息格式
┌────────────────────────────┴───────────────────────────────────────────┐
│ 第二层 · 协议适配与连接管理层 │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │
│ │ MQTT │ │ CoAP │ │ HTTP/WS │ │ 自定义TCP │ │ 协议自动识别 │ │
│ │ Codec │ │ Codec │ │ Codec │ │ Codec │ │ (端口/首包) │ │
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────────┘ │
│ ┌──────────────────────────────────────────────────────────────────┐ │
│ │ 连接管理器（Channel 映射、心跳、会话保持）│ 流量整形 & 安全防护 │ │
│ └──────────────────────────────────────────────────────────────────┘ │
└────────────────────────────┬───────────────────────────────────────────┘
│ TCP / UDP / TLS
┌────────────────────────────┴───────────────────────────────────────────┐
│ 第一层 · 网络传输与基础设施层 │
│ Netty Server (Epoll) │ 负载均衡 (L4/L7) │ 容器网络 │ 存储、缓存、监控基础服务 │
└────────────────────────────────────────────────────────────────────────┘
直白转义
前台接待部（统一接入层）
不管你是用微信（MQTT）、短信（CoAP）、打电话（HTTP）还是写信（自定义TCP），前台都能听懂，把你的消息翻译成公司内部统一的“内部便签”
前台还负责记住你是谁、你在不在线、有没有骚扰别人
分拣中心（消息路由层）
拿到内部便签后，看上面写的“收件人/主题”，比如“客厅温度上报”
如果用户订阅了“客厅温度”，就立刻把便签复印一份送过去；如果没人订阅，就扔掉或存档
业务处理部（核心服务层）
设备档案室：记录每台设备的信息和型号
权限门禁：检查你有没有资格发这条消息
规则机器人：比如“如果温度超过50度，立刻打电话给老板报警”
愿望清单（设备影子）：帮你记着“你希望设备变成什么状态”，等设备上线了就发过去
用户窗口（业务应用层）
给你用的网页/APP，比如数据大屏、告警列表、手动控制设备的界面
名词解释
设备影子
在云端为每个物理设备创建一个持久的 JSON 文档（即影子），它始终记录设备当前期望的状态，无论设备是否在线。应用端只需读写这个影子，由平台负责将状态同步到真实设备
想象你的智能灯泡是一个不太听话的快递员，有时候它会在你面前，有时候它出去送货（离线）了
你不能一直等着它在的时候才告诉它“把灯打开”，你需要一个云端的愿望清单
愿望清单（Desired）：你写上去的指令，比如“把灯调到暖黄色，亮度80%”
现实状态（Reported）：灯泡自己汇报回来的真实情况，比如“我现在是冷白光，亮度50%”
设备影子控制台，就是你管理这个愿望清单的网页
OTA管理
远程给设备升级软件，不用你跑到设备跟前去操作
分层
第一层 · 收发大厅（统一接入层）
核心职责
把各种设备语言翻译成内部便签，管好设备连接，守住大门。
设计要点
- 多协议翻译：为 MQTT、CoAP、HTTP 等各配一个翻译器，输出统一的“内部便签”（设备ID + 主题 + 内容）。
- 自动识协议：看端口或首字节，自动匹配翻译器，无需手动配置。
- 连接登记簿：内存里记下“设备ID ↔ 通道”，心跳超时就划掉，通知上层设备离线。
- 安检三道关：①TLS 验身份证 ②查 ACL 权限表 ③令牌桶限速，超量就拦。
简要分析
- 优点：所有协议差异被封装在这一层，上层完全不用关心设备说什么语言。
- 挑战：高并发下，连接登记簿的查询要极快，必须纯内存 + 本地缓存，并同步一份到 Redis 供集群共享。
- 关键指标：单节点可支撑的并发连接数（通常目标十万级）、TLS 握手延迟。
第二层 · 自动分拣机（消息路由层）
核心职责
根据便签上的“主题”，复制给所有订阅了该主题的人或服务。
设计要点
- 主题树匹配：用 Trie 树快速匹配通配符（
+单层、#多层），找到所有订阅者。 - 订阅本管理：订阅关系存 Redis，本地内存缓存一份，设备离线时按需保留。
- 分拣策略：
- 上行：设备上报 → 匹配规则引擎、存储服务、其他设备等。
- 下行：服务端指令 → 查设备是否在线 → 在线直接投递，离线暂存等设备上线补发。
简要分析
- 优点：发布者和订阅者完全解耦，支持一对多广播，扩展新消费者只需订阅，不动任何代码。
- 挑战：当订阅者数量巨大时，一次发布可能要复制上千份，需限制单次复制量，或通过 Kafka 消费者组解耦。
- 关键指标：主题匹配延迟（微秒级）、消息分发吞吐量（万条/秒）。
第三层 · 后台处理中心（核心服务层）
核心职责
管设备档案、身份权限、自动规则、数据存储，所有业务逻辑都在这儿。
设计要点
- 设备档案库：每台设备一张卡片，记录型号、属性、功能，方便上层展示和控制。
- 身份与权限中心：签发证书，定义谁能发/订阅哪些主题，动态更新 ACL。
- 规则引擎：类 SQL 规则（如
温度 > 50 报警），触发后执行动作（发通知、调接口、存库）。 - 数据档案馆：时序数据进 TDengine，元数据进 MySQL，在线状态和影子进 Redis。
- 影子服务：每设备一张“愿望清单”（期望状态 vs 上报状态），设备上线自动同步差异。
简要分析
- 优点：业务规则集中管理，修改规则无需重启接入层，设备档案为全平台提供统一元数据。
- 挑战：规则引擎性能要够高，大量消息需实时过滤，通常用 Kafka 流式消费 + 自研轻量引擎。
- 关键指标：规则匹配吞吐量、影子同步延迟（百毫秒内）。
第四层 · 用户柜台（业务应用层）
核心职责
给最终用户看的网页/APP，把后台能力变成可操作的界面。
设计要点
- 数据大屏：通过 WebSocket 或 API 拉取实时数据、历史趋势。
- 告警中心：接收规则引擎触发的告警，推送到邮件/短信/钉钉。
- 影子控制台：简单界面显示设备当前状态，修改期望，查看历史，一键回滚。
- OTA 管理：上传固件，选择设备批量升级，监控进度，失败自动回滚。
- 开放 API：供第三方系统调用，统一网关鉴权、限流。
简要分析
- 优点：业务逻辑完全由后台处理，前端只做展示和交互，可快速迭代 UI。
- 挑战：需保证 API 的安全性（防越权），大屏实时性要求高的场景要用推送而非轮询。
- 关键指标：页面加载速度、API 响应时间、OTA 升级成功率。
总结：四层各司其职，一管进（连接翻译），二管分（消息路由），三管脑（业务处理），四管脸（用户交互）。每层可独立扩缩，加设备、加协议、加业务都能做到“只改一层，不动全身”。