文章标签 ‘iot’
2024七月23

BudIot 开源物联网设备平台v1.0发布

BUDIOT 是一个开源的、企业级的物联网平台,它集成了设备管理、协议解析、消息订阅、场景联动等一系列物联网核心能力,支持以平台适配设备的方式连接海量设备,支持在线下发指令实现远程控制,支持扩展水电气等各类计费业务场景。

本平台是在千万级设备实时计费物联网平台经验基础上,在不损失性能的前提下进行功能删减、结构优化而来,小而美,同时又具备灵活的扩展性。

源码: https://github.com/budwk/budiot

在线演示地址: https://demo.budiot.com 用户名: superadmin 密码: 1

官网: https://budiot.com

开发框架

基于自研 Java 微服务框架 https://budwk.com

简单说明

Jar 运行模块

  • budiot-access/budiot-access-gateway 设备网关,用于设备协议和 network 组件
  • budiot-access/budiot-access-processor 设备数据上报业务处理模块
  • budiot-server WEB 服务 API ,定时任务等

其他模块说明

  • budiot-access/budiot-access-network 网络组件,支持 TCP/MQTT/UDP/HTTP 等
  • budiot-access/budiot-access-protocol 设备协议开发包,内含 demo 示例
  • budiot-access/budiot-access-storage 设备数据存储,可扩展时序数据库等

前端模块

  • budiot-vue-admin Vue3 + Element-Plus

开发环境

  • OpenJDK 11
  • Redis 6.x
  • MariaDB 10.x
  • MongoDB 7.0.x
  • RocketMQ 5.2.x

设备上报有效数据存储

默认采用 MongoDB 7 的时序集合,可根据项目规模需要,扩展为 TDEngine 等时序数据库

2024七月8

600万设备连接平台遇到的坑

MongoDB 的坑

listCollections

  • 问题:代码中存在 listCollections 操作,大量数据上报时,造成MongoDB CPU高升,使处理性能受到影响。经过检查,发现通信报文日表是自动创建的,每次都会判断集合是否存在;而mongo驱动包里判断集合是否存在的操作,就是先执行 listCollections;
  • 优化:提前创建好需要的集合,不要在数据上报的时候进行判断、创建;ps:其实其他数据库,比如mysql、tdengine等,都是同样的道理;

连接数过大

  • 问题:MongoDB 连接数配置较大,导致很多handler服务,过多的线程会导致上下文切换开销变大,同时内存开销也会上涨;
  • 优化:调低连接数配置,进行压力测试;

规则引擎的坑

  • 问题:为了提升性能,往往采用队列+规则引擎来处理业务,设备协议解析+计费业务是在一个handler里,而规则引擎则在下一个队列处理;规则引擎负责为欠费的表具创建短信提醒、关阀指令(产品欠费规则配置),往往在第一个队列里需等待N秒,将规则引擎创建的指令一起下方给表具,每天几百万表具实时上报数据+实时计费,数据并发量较大,如果都等待N秒,会严重影响处理性能;
  • 优化:对计费后余额大于等于0的的表具,不等待N秒,直接回复结束指令,绝大部分表具其实已经是关阀状态,无需本次下发关阀指令,哪怕有需要关阀的,延后到下次通信再执行也没影响;对于小于0的表具,则使用原有逻辑;优化后,降低了90%的等待时间,大大提升高峰高并发处理性能;

HTTP订阅的坑

  • 问题:前期主要通过AEP平台的http订阅实现NB表的通信,但是http服务在高并发时有时候会挂掉(具体表象就是两个http服务,只有一个存活,另一个服务存在,但不处理数据);
  • 优化:将http服务单独服务部署,不要和其他handler、服务抢占服务器资源,jvm也就不会崩了;后期采用MQ订阅方式;

站内信的坑

  • 问题:原有产品设计当设备产生告警时(原生告警、规则告警等)有站内信提醒,经过项目实际运行,站内信数据非常庞大,时刻都有设备告警,导致web页面卡顿、后台web服务资源占用高;
  • 优化:去掉设备站内信告警功能,一是站内信管理人员完全看不过来,二是设备告警在功能菜单里可以查询到;