物联网平台不是“企业级中间件展览馆”
作者：He Daye
标签：物联网平台、轻量级架构、Netty、DDD、道家哲学、技术软文
摘要
本文针对当前物联网平台架构的“过度工程”现象，结合作者自主开发百万级接入能力的单体物联网平台经验，提出：物联网平台不是企业级中间件展览馆。平台应以“能真实表达业务”为最高准则，减少无谓的异步和解耦链，回归“设备在线即业务在线”的本质逻辑，实现小而美、强内聚、易运维的产品形态。
背景：一地鸡毛的物联网“中间件化”趋势
你可能也见过这样的平台：
- 一个设备上报数据，要绕十几个处理节点；
- TCP 会话感知不到在线状态，数据一律打成 Kafka 消息异步处理；
- 设备量不多，但整个平台用了 MQ、微服务、网关、DDD、CQRS、消息总线、配置中心……中间件堪比展览馆；
- 想联控几个异构设备？对不起，要“设计流程引擎”；
- 想让平台主动发起 RPC？没有这种逻辑，“只能尝试下发指令”然后看设备啥时候响应……
这样复杂的体系，在真实业务面前，反而笨重而脆弱。
我们的理念：平台不重，逻辑要“道”
物联网的“道”是什么？
设备在线即业务在线，数据流动即业务驱动。
道家说：“无为而治”，并不是不作为，而是不妄为。平台架构也是如此，不为解耦而解耦，不为扩展而扩展，一切架构服务于业务清晰和高效表达。
实战案例：百万级设备接入平台的极简架构
我们自研的物联网平台遵循以下核心原则：
1. 单体 JAR 部署，Spring Boot 起步即运行
- 无需中间件依赖（无MQ、无Redis、无服务注册中心）
- 一台服务器起步，低成本验证业务闭环
2. 单库 PostgreSQL 持久化，逻辑清晰
- 设备、产品、协议、规则、告警统一建模
- 配合表达式引擎，实现灵活的数据驱动业务
3. Netty 接入，TCP/UDP/MQTT全支持
- 每个连接都对应上下文会话对象
- 设备在线即为业务实体在线，随时可发起 RPC
4. 协议可视化配置，自定义解析规则
- 支持 TLV、定长、JSON、自定义字段提取
- 多端口、多协议并存，无需编码
5. 真正异构联控能力
- 一端触发，多个设备可立即响应
- RPC调用毫秒级可控，不依赖异步轮询
为什么我们不需要 Kafka、Redis、MQ？
因为：
- 数据的核心是实时业务，而不是异步日志。
- 设备连接本身就是强会话关系，不需要“消息中转站”。
- 你的项目规模根本没到非拆不可的程度。
反思主流做法：他们的道在哪？
当你看到：
- Spring Cloud 全家桶只为了接几个电表；
- Kafka 冗余多个副本只为了收传感器电压；
- Redis 做“在线状态感知”却感知不到 TCP 掉线；
- 多租户权限系统做得跟 ERP 一样复杂……
这不是“技术先进”，而是道已迷失。平台本应贴近设备、贴近业务，却变成了“中间件大观园”，缺乏实战效率与灵活性。
我们走的是“务实而通”的道路
不“鄙视”中间件，但更珍惜业务表达效率； 不追求高大上术语，而追求设备联控的即时性； 不拒绝扩展性，但先做好一件事：为业务服务。
总结：大道至简，能打的架构从不复杂
物联网平台，应该是一套“道法术器”高度统一的体系：
- 道：业务逻辑的本质，设备联动、数据驱动、状态可控
- 法：规则驱动、配置化协议、上下文会话
- 术：Netty、JPA、PostgreSQL、表达式引擎
- 器：你写出来的平台，不是“技术堆砌物”，而是业务利器
大道自然。脱去冗余，中庸中道，才是高效平台的最强形态。
SEO关键词
物联网平台、轻量级架构、Netty 接入、设备上下文、单体应用、Spring Boot、PostgreSQL、协议解析、设备联控、道家哲学、DDD 落地、中间件滥用、物联网设计误区、TCP 会话、RPC 控制、物联网规则引擎
如果你也在构建物联网平台，欢迎交流
📧 公众号 / 博客 / 邮箱
留言交流，我们可以探讨你设备的协议、你想联控的场景，或你是否也曾因“中间件堆积”而困惑。
有道者，事半功倍；无道者，事倍功半。
