大多数中小型物联网项目，根本不需要复杂架构

说个可能不太受欢迎的观点：

大多数中小型物联网项目，根本不需要复杂架构。

如果你经常浏览知乎上的物联网话题，可能会觉得：

• 物联网 = 云原生
• 物联网 = 微服务
• 物联网 = 高并发 + 分布式 + 时序数据库

但在真实项目里接过设备、处理过协议、经历过现场交付之后，我越来越确定：

大量中小型物联网项目，真正需要的不是"更复杂的架构"，而是"更贴近设备的系统"。

这也是为什么，我倾向于采用：

Java + Netty + PostgreSQL

以单体架构构建物联网底座。对于连接规模、消息频率和业务复杂度适当的项目，这种组合可以在保持系统简洁的同时，支撑相当规模的设备连接。具体承载能力仍需要结合设备行为、消息模型和目标硬件进行压测验证。

一、一个容易被忽略的事实：物联网的重心，不只在云，更在协议

很多物联网讨论一开始就关注：

• 平台功能
• 多租户
• 规则引擎
• 数据大屏

但如果真正参与过项目交付，就会发现：设备能否稳定接入，往往是项目首先要解决的问题。

真实世界里的设备协议通常具有这些特点：

• 私有协议较多
• 标准不统一
• 定长、TLV 或混合数据结构
• 上下行报文不对称
• 通信过程存在状态依赖

这意味着什么？

如果系统不能从 Byte 级别理解和处理数据，后续的平台能力就很难真正落地。

设备接入不是简单地接收一段 JSON。很多时候，需要从原始字节流开始，逐层完成协议处理。

二、为什么我坚持使用 Netty？因为协议不是 JSON，而是字节流

很多"物联网快速方案"默认了一个前提：

设备或网关已经完成协议处理，平台只需要接收 JSON 数据。

但在真实项目中，情况往往恰恰相反。

常见的数据处理链路是：

TCP 字节流
    ↓
拆包 / 粘包处理
    ↓
协议帧解析
    ↓
字段提取
    ↓
业务语义转换

Netty 的价值在这里体现得非常直接：

• ByteBuf：能够精细控制字节数据的读取、写入和边界处理。
• Pipeline：适合将解码、业务处理和编码拆分为清晰的处理阶段。
• 非阻塞 I/O：适合大量长连接场景，减少为每条连接分配独立阻塞线程的需要。
• 线程模型清晰：可以将网络 I/O 与耗时业务处理合理分离。

这不是单纯的"性能偏好"，而是由问题模型决定的技术选型。

当核心工作是处理 TCP 连接、二进制协议和设备通信状态时，Netty 提供了足够直接的控制能力。

三、一个更容易引发争议的观点：中小型物联网项目，单体架构反而可能更稳定

在很多技术讨论中，单体架构常常被贴上"过时"的标签。

但在物联网设备接入场景下，单体架构有一些天然优势：

• 设备连接具有状态性
• 协议解析可能依赖连接上下文
• 设备反控通常关注响应延迟
• 设备状态变化频繁

如果过早拆分系统，可能带来额外成本：

• 状态需要外置或同步
• 服务间调用链变长
• 故障定位和排查更加复杂
• 性能问题更难直接观察

而在 Netty 的事件驱动模型下，可以通过较少的 I/O 线程管理大量连接，并结合清晰的业务线程边界，减少不必要的线程切换和服务间通信。

对于连接规模和业务复杂度尚未达到拆分必要性的项目，单体架构往往更容易部署、调试和维护。

当然，单体并不意味着所有逻辑都堆在一起。模块边界、线程隔离、异常处理、资源管理和可观测性仍然重要。架构是否合适，最终应由真实负载和团队维护能力决定。

四、为什么我没有一开始就使用时序数据库？

这是另一个经常被默认的问题。

但在大量中小型项目中，真实的数据需求通常包括：

• 设备状态
• 事件记录
• 告警数据
• 简单统计
• 报表查询与导出

PostgreSQL 在这些场景中的能力，远比很多人想象得更强：

• JSONB：适合存储结构存在差异的半结构化数据。
• 事务能力：能够为关键业务数据提供成熟的数据一致性保障。
• 索引与聚合：可以支持常见的条件查询、统计和报表需求。
• 运维生态成熟：降低部署、维护和人员学习成本。

配合批量写入、异步持久化、合理的索引设计和数据归档策略，PostgreSQL 可以覆盖不少中小型物联网项目的业务需求。

并不是所有设备数据都必须从第一天起写入专用时序数据库。是否引入专用存储，应当根据数据规模、写入频率、查询模式、保留周期和运维能力来判断。

五、协议驱动，而不是"代码驱动"

在设备接入项目中，昂贵的往往不是服务器资源，而是反复为"相似但略有不同的协议"修改代码、测试和部署。

因此，在架构设计中，一个重要方向是：

把可描述的协议差异抽象为配置模型，而不是把所有差异都写死在业务代码里。

这样做可以带来一些实际收益：

• 将协议参数、字段映射和数据结构进行统一描述
• 减少相似设备重复开发的工作
• 让部分协议调整通过配置完成
• 让一套接入底座能够复用于多个项目

需要强调的是，并非所有私有协议都能完全配置化。遇到复杂状态机、特殊校验、加密算法或厂商私有交互逻辑时，仍然需要编写专用适配代码。

合理的目标不是消灭代码，而是把稳定、重复、可描述的部分沉淀为模型，把真正特殊的部分留给扩展机制。

协议成为系统的一部分，而不是让每一次新协议适配都变成一次重复造轮子。

六、现实结论：不是 Java / Netty 不行，而是技术选型必须回到真实问题

关于"Java 是否适合物联网"，很多争论容易停留在语言和框架的标签上。

但真实项目更关心的是：

• 能不能接入现场设备？
• 私有协议能不能处理？
• 长连接能不能稳定维护？
• 资源受限的边缘环境能不能运行？
• 出现问题后能不能快速定位？
• 后续新增设备和调整协议的成本高不高？

技术选型不应该从流行架构出发，而应该从设备协议、通信模型、数据规模、部署环境和交付成本出发。

对于中小型、项目制物联网系统，Java + Netty + PostgreSQL 是一套值得认真考虑的技术组合。

它并不意味着适合所有场景，也不意味着不需要演进。当连接规模、团队协作、业务边界或可用性要求发生变化时，系统仍然需要根据实际情况调整。

结语：物联网不是比谁的架构复杂，而是比谁更贴近设备

Java + Netty + PostgreSQL
单体架构
协议驱动业务

这套组合并不追求技术时髦，而是强调从设备通信和真实交付出发，选择足够简单、可控、可维护的技术方案。

架构不是越复杂越先进。能解决现场问题、能长期稳定运行、能让后续维护和扩展成本可控，才是有价值的架构。