关于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)

posted @   枫潇雨  阅读(167)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· 在鹅厂做java开发是什么体验
· 百万级群聊的设计实践
· WPF到Web的无缝过渡:英雄联盟客户端的OpenSilver迁移实战
· 永远不要相信用户的输入:从 SQL 注入攻防看输入验证的重要性
· 全网最简单!3分钟用满血DeepSeek R1开发一款AI智能客服,零代码轻松接入微信、公众号、小程
点击右上角即可分享
微信分享提示