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 等时序数据库

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服务资源占用高；
• 优化：去掉设备站内信告警功能，一是站内信管理人员完全看不过来，二是设备告警在功能菜单里可以查询到；