说个可能不太讨喜的观点：
大多数中小型物联网项目，根本不需要复杂架构
如果你经常刷知乎的物联网话题，可能会形成一种错觉：
物联网 = 云原生
物联网 = 微服务
物联网 = 高并发 + 分布式 + 时序数据库
但在真实项目里跑过设备之后，我越来越确定一件事：
大量中小型物联网项目，真正需要的不是“更复杂的架构”，而是“更贴近设备的系统”。
这也是为什么，我最终选择用：
Java + Netty + PostgreSQL
做一个单体，却能长期稳定跑万级 TCP 连接的物联网底座
一、一个容易被忽略的事实：
物联网的重心，不在云，而在“协议”
很多物联网讨论，一上来就聊：
- 平台功能
- 多租户
- 规则引擎
- 数据大屏
但如果你真正参与过项目交付，就会发现：
90% 的项目风险，发生在“设备接不接得进来”。
真实世界里的设备协议通常是：
- 私有的
- 非标准的
- 定长、TLV、混合结构
- 上下行不对称
- 强状态依赖
这意味着什么？
如果你的系统不能从 Byte 级别开始思考问题，后面的“平台能力”基本都是空谈。
二、为什么我坚持用 Netty？
因为协议不是 JSON，是字节流
很多“物联网快速方案”，默认前提是：
设备已经帮你把协议处理好了，你只需要收 JSON。
但现实项目里，往往恰恰相反。
我面对的更多是：
TCP 字节流 → 拆包 / 粘包 → 协议帧解析 → 字段提取 → 业务语义
Netty 的价值在这里体现得非常直接：
- ByteBuf 让你真正控制数据边界
- Pipeline 非常适合分层协议处理
- 非阻塞模型对大量长连接极其友好
- IO 和业务线程清晰分离
👉 这不是“性能偏好”，而是“问题模型决定技术选型”。
三、一个更容易引发争议的观点：
中小型物联网，单体架构反而更稳定
在很多技术讨论中，单体常常被贴上“过时”的标签。
但在物联网设备接入场景下，单体往往具备天然优势：
- 设备连接是有状态的
- 协议解析依赖上下文
- 反控要求低延迟
- 状态变化非常频繁
如果过早拆分系统，会带来什么？
- 状态被迫外置
- 调用链变长
- 排障复杂度急剧上升
- 性能问题更隐蔽
而在 Netty 的事件驱动模型下：
- 少量线程
- 大量连接
- 内存内状态
- 极低的线程切换成本
👉 在 2C4G 的服务器上，稳定承载上万 TCP 长连接，并不是什么极端情况。
四、为什么我没有一开始就用时序数据库？
这是另一个经常被默认的问题。
但在大量中小型项目中，真实的数据需求通常是：
- 设备状态
- 事件记录
- 告警数据
- 简单统计
- 报表导出
PostgreSQL 在这些方面的能力，远比很多人想象中强：
- JSONB 适合半结构化数据
- 强事务保证
- 成熟的索引与聚合能力
- 运维成本低、生态成熟
通过 批量写入 + 异步持久化：
👉 数据库并没有成为性能瓶颈，反而简化了整体系统结构。
五、协议驱动，而不是“代码驱动”
在项目中，真正昂贵的从来不是服务器，而是：
反复为“相似但略有不同的协议”改代码。
因此，我在架构层做了一个关键决定：
把协议本身，抽象成可配置模型，而不是硬编码逻辑。
结果是：
- 新设备接入不再依赖重新开发
- 协议调整不需要重新部署
- 一套底座可以支撑多个项目
👉 协议成为系统的一部分，而不是工程负担。
六、现实结论：
不是 Java / Netty 不行，而是很多项目根本没走到这一层
很多“Java 不适合物联网”的结论，本质上来自：
- 没跑过真实设备
- 没接过私有协议
- 没长期维护过长连接
- 没在资源受限环境下运行系统
而在真实项目中：
客户关心的从来不是你用什么语言，而是：
- 能不能接我的设备？
- 稳不稳定？
- 成本高不高？
- 改起来快不快？
结语：
物联网不是比谁架构复杂，而是比谁更贴近设备
Java + Netty + PostgreSQL
单体架构
协议驱动业务
这套组合并不追求“技术时髦”，
但它在中小型、项目制物联网中，反复证明了自己的价值。
项目说明
本文中的架构，已在实际项目中长期运行。
项目名称：星焰物联（Null-IoT）
官网地址：www.null-iot.com
定位于：
面向中小型项目的协议驱动物联网底座，专注私有协议、极致性能与快速交付。
