关于java对接物联网设备自定义协议的安全性，以及长链接场景下需要注意的事项

1. 目前从事于物联网行业。 共享充电宝。 负责通讯相关。 当前设备在线量约50W 台。记录一下走得弯路。 方便大家借鉴。

   文笔不太好，希望大家轻喷。

   本文主要是从以下几个方面探讨：

   1. 物联网方案选型

   2. 通讯协议设计

   3. 后台架构设计

   4. 统计和监控

    

   1.物联网方案选型

   方案选型这一块其实蛮多的。 需要大家根据自己得业务类型来做出选择。 是直接走TCP长连接？ 还是使用MQTT， HTTP这些已经封装好得协议。

   mqtt 协议开箱即用，方便快捷。 而且相关的开源项目也不少。方便借鉴和资料查找。 目前各大云平台也有IOT相关服务。 直接链入快速开发即可。 但却不在本文讨论之中。本文只讨论TCP协议。

   如果使用TCP协议， 对于业务的话则需要重传， 确认机制。 对于业务性强的领域。 可以考虑增加 短信，和UDP 进行通讯。

   我方目前采用 TCP + 短信进行通讯， 目前95% 的流量再TCP就进行处理了。（只有部分剩余机器所处网络状况不佳） 剩余 约 5 % 使用的短信进行通讯。

    

   2. 通讯协议设计

   这里推荐大家自定义私有协议。 安全性高。 报文体积小。 在这里有几点需要注意：

   1. 如果机器没有时间芯片，不推荐使用时间作为报文的序号
   2. 报文一定要增加序号， 最好自动递增
   3. 重要的报文增加 sessionId 会话编号。 即后台下发 机柜返回。方便做业务上的对应
   4. 报文建议增加简单的加密， 简单的异或都可以
   5. 报文需要设计重传机制。

   对于报文设计来说， 最好的是尽可能的将所有设备信息上报。 方便业务进行处理。 而不要在硬件上进行消息屏蔽。 应在后台业务中做出处理。

    

   3. 后台架构设计

   当前的云服务器 ECS  4C/8G/10MB , 这种配置一台可以扛住1W 以上链接。 但是在做链入设计时。 最好使用2台以上服务器来进行轮询分配。 避免单点故障。 这一点在任何系统中都应该做备灾设计。 至于开发语言。 其实用什么都可以的。 目前无论时 java/ php/ nodejs 。性能基本都足够使用。  反正我现在觉得 性能什么的都是扯淡。 业务才是最重要的。       只要业务能赚钱， 完全可以重构做2.0, 3.0； 性能时迭代上去的。

    

   4. 统计和监控

   在这里也需要注意一点， 对于物联网来说， 统计监控必须要做好。

   推荐使用列式存储， 可压缩。而且方便分析处理。 我们使用的是 clickhouse. 

   主要需要统计以下指标：

   • 链入次数
   • 接口请求走势
   • 数据上报走势
   • 异常发生走势
   • 当前在线设备

   对于设备来说， 日志可以多存一点方便跟踪和排查问题。 以上指标最好做聚合分析。 使用钉钉什么做一个推送。一有异常， 马上排查。 对于物联网设备来说， 量小一般不会有什么问题。 设备量大问题马上就暴露了。 而且由于重试等机制， 容易出现洪水攻击导致后台雪崩。 所以监控最好早点做。 防微杜渐。

最后，在物联网开发对接中， 序列化是一个必须要解决的问题。很多时间都会花在协议对接和字节操作的细节之中。所以这里我封装了一套序列化的框架，欢迎大家使用！

magic-byte: 一种简单的方式将java对象转为字节数据，用于快速高效的自定义序列化/反序列化场景，类似C的Strcut结构体，多用于私有通讯协议实现。 (gitee.com)