Java物联网平台后端架构构思设计

Posted 2023-04-04 「已注销」

文章目录

• 前言
• 一、概述
• • 1.1 功能需求
  • 1.2 业务流程
  • • 数据提供者
    • 业务操作人
    • 业务安全
  • 1.3 中间件分析
  • • 数据存储
    • 缓存
    • 消息队列
    • 负载均衡
    • 分布式应用协调
  • 1.4 整体架构设计
• 二、实践落地
• • 2.1 系统模块组设计
  • 2.3 部署说明
• 代码仓库

前言

对于物联网的后端架构设计也是在不断地摸索中，业务划分的可能还不是很清晰，大家可根据实际情况进行取舍。

目录
《DDD领域驱动设计》

一、概述

提示：这里可以添加本文要记录的大概内容

1.1 功能需求

1. 实体设备接入及控制
2. 服务治理及监控
3. 业务权限控制
4. 高阶治理-机器学习数据预测、告警业务流处理等

1.2 业务流程

我们从大致的三个方面去进行分析

• 对于数据的提供者
• 对于数据的获取者及实际的业务操作用户
• 从业务安全角度出发

数据提供者

从南向业务出发，不谈接口技术，只谈业务情况，大致分为两个类别

1. 检测型设备
2. 控制型设备

对于检测型设备来说，是只提供数据传输功能而没有控制效果（或者说它的控制效果对于实际业务情况的帮助不大，例如单纯的开关控制），例如光照传感器设备、客流统计设备、温湿度检测设备。

而对于控制型设备，它传输的数据主要是来源于设备的实时状态，例如灯光、窗帘等，并且从数据传输来说，它是双向的，控制方传输控制指令，设备方返回状态值。

对于上述的两种情况，其实从业务处理中，可以浅划分成两种处理方式：

1. 实时性处理
2. 异步处理

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-GVibN0Lh-1662290566147)(https://csdn-pic-1301850093.cos.ap-guangzhou.myqcloud.com/csdn-pic/iot平台架构设计-业务流程-数据提供者数据处理方式.jpg)]

这一举措的目的主要是两块

• 依赖解耦 - 大量的feign调用是需要提前引入各方的API-JAR，数量及业务过多且复杂的情况下稍不留神将导致依赖循环等恶行问题；
• 功能分离

业务操作人

对于实际业务操作人，也就是用户，需要考虑几个问题

1. 权限分离

   对于权限分离，例如管理人员、普通用户，是否可操作某个区域的设备？是否可查看某个区域的数据？此时我们就需要做到几个方面：

   • 用户操作记录保存
   • 操作业务的区分，控制 or 查询 ？
   • 权限划分数据表

2. 请求内容合法性

3. 请求来源端

   从Unity客户端，抑或是小程序等方向进行请求，在操作同一设备的相反功能情况下，势必会“打架”，是否需要做短延时/同步锁处理（某功能操作后延时2秒后才可以继续操作）？

业务安全

也还是从两个方面去说明

• 对外安全

  代码漏洞、0day攻击等；

• 对内安全

  业务所能承受的最大负载、人员误操作等方面；

1.3 中间件分析

针对各中间件对应实际的业务效果

数据存储

mysql

MongoDB - 时序性数据存储的选型

缓存

Redis

消息队列

MQTT

RabbitMQ

RocketMQ

负载均衡

LVS

nginx

分布式应用协调

Zookeeper

1.4 整体架构设计

根据上述的内容总结后，大致的架构图如下

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Aem5vzXU-1662290566147)(https://csdn-pic-1301850093.cos.ap-guangzhou.myqcloud.com/csdn-pic/iot平台架构设计-架构设计-1.jpg)]

针对架构区域进行分区剖析

• 北向对接数据请求客户端（如Unity模型、小程序等），单向反馈数据与控制状态；
• 南向对接底层数据源，如部分中控厂家、单设备厂家（如施耐德、西门子）、MQTT、Modbus设备及云平台等，实时获取到设备数据与控制接口；
• 在服务治理上，根据实际需要补充如定时任务框架、线程池监控等第三方服务运维治理组件，保障系统运行稳定性及线上排障有效化；
• 同时东向对接数据存储源，本地MySQL、Redis缓存，或者云端虚拟化产品；
• 业务模块中，根据业务情况进行划分，考虑到划分的越细也同时会导致微服务架构的复杂化，要根据实际情况进行取舍；

二、实践落地

提示：这里可以添加本文要记录的大概内容

2.1 系统模块组设计

源码在最后一个章节，XMind确实是挺好用的，我种草了。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-EgAyAgTF-1662290566148)(https://csdn-pic-1301850093.cos.ap-guangzhou.myqcloud.com/csdn-pic/miot-架构设计-1.png)]

最后大家可根据实际业务及功能需要进行扩展，目前设计的只针对与物联网行业，但实际上不管怎么变化，架构内核是不变的。

2.3 部署说明

相关的中间件及一些配置都在my-config目录中，例如nacos及MySQL的基础配置，导入即可。

代码仓库

地址
物联网通用后台模型-基于BladeX: 基于开源版BladeX所搭建的通用物联网平台服务端 (gitee.com)

结束。

IoT -- 物联网平台架构设计分析

现在网上讨论的有关物联网的帖子非常之多，但大部分都是介绍理论或者有关硬件，通讯相关的问题，比如物联网模块，物联网通讯协议MQTT、XMPP、NB_IOT等，个人认为这些只是物联网中一部分，而涉及到物联网的设备如何管理，用户如何管理，数据包如何解析，大数据如何展示等也是物联网模块中非常重要的部分，所以作者就根据自身工作中总结出来的建构在云端的物联网平台基本架构分享给大家，并基于此架构如何一步一步来开发一套物联网平台。

物联网平台，应该是基于现在的互联网，通讯技术来建构，而不依赖与特定的硬件模块，用户可以基于自身的设备技术架构，简单轻松接入物联网。下图是物联网的核心架构：

1. 四大核心模块

在物联网中存在4大核心模块，那就是设备管理，用户管理，数据传输管理，数据管理，只有具备了这四大核心模块，才能认为是一个完整的物联网平台，而所有其他的功能模块都是基于此四大功能模块的延展。

1.1 设备管理

设备类型管理：定义设备的类型，此功能一般由设备的制造商来定义，一种设备类型最重要的是关联到一套独有的数据解析方法，数据的存储方法，已经设备规格等数据，也只有设备的制造商才可以编辑有关设备类型的数据，而设备的使用者只能浏览设备类型的相关信息

设备管理：设备管理定义设备相关信息，每个设备必须定义其设备类型，设备类型有使用者属性，设备在完成销售，并被使用者激活后设备就属于设备使用者了，这时候设备使用者对设备有完全的控制权，可以控制设备的哪些数据可以被制造商查看，可以被哪些用户查看等权限

1.2 用户管理

组织管理：在物联网平台中一个很重要的观念就是组织，所有的设备，用户，数据都是基于组织的管理的，设备制造商是一个组织，设备的使用者是一个组织，家庭都可以是一个组织。

用户管理：用户是基于一个组织下的人员构成，每个组织下面都有管理员角色，管理员可以为其服务的组织添加不通的用户，并分配每个用户不同的权限。一个用户也可以属于多个不同的组织，并且扮演不同的组织

用户组：一组用户，也是基于组织的用户组管理，同一用户组的用户拥有相同的权限

权限管理：同样是基于组织的权限管理，主要是针对对象级别的权限细分，如设备的浏览权限，可以控制每个用户是否看到这个设备；设备数据浏览权限定义是否可以查看设备的运行数据

1.3 数据传输管理

1.31 基本格式

数据传输管理，定义针对一类型设备的数据传输协议，基本格式是:

每一个设备有厂商唯一的序列号，因为每个制造商有自己的编码格式，固此序列号没有固定格式。

命令码，为此条数据的作用，比如是上传数据，或者服务器下发给设备的命令等，一般采用2位数字编码00~99

数据，此部分是此条报文，所包含的数据部分，每个协议可以定义不同的解析方式，比如服务器在收到数据包后，会根据预先定义好的解析方式解析数据字段，并按照规则存储

1.32 数据解析定义

每种设备类型可以定义多条命令，每个命令都有自己不同的解析方式，组织的管理员可以为自己的设备类型定义解析方式

服务器接收到数据后，会自动根据预先定义的解析方式解析数据字段

设备开发者要根据在IOT平台定义的数据格式，自行开发自己设备的解析代码

数据字段都按照HEX方式收发

1.33 数据的存储

存储要支持分布式架构，可以为每个设备定义不同的存储位置，在diego iot中数据存储使用mysql数据库，实现不同的设备存储在不同的mysql数据库中?

每条数据定义生命周期，在生命结束后，系统将自动删除

1.4 数据管理

权限管理，数据的权限在物联网平台中是至关重要，数据属于谁是一个非常重要的概念，只有设备的拥有者才能定义数据可以给谁看

大数据，物联网数据本身就是海量的数据，我们可以借助一些开源的大数据平台来实现数据的可视化分析，只有经过分析的数据才是有价值的数据

数据的导出，用户可以导出数据到本地做分析

2.网络通讯

现在所有的云端的物联网平台和设备之间的通讯，本质上都是建构在TCP/IP协议之上的，只是对数据包的再封装而已，基于此我们可以是用wifi，4g来实现设备和云平台的通讯，不过设备与设备之间的通讯，可以有wifi，Bluetooth，zigbee等，下面介绍几种常用的通讯架构

2.1 基于移动3/4G通讯

此架构是最简单的架构，设备就如同我们的手机，基于移动通讯来上网，其主要需要考虑如下几点

每个设备都需要一个SIM卡，可以到移动服务器商办理专门针对物联网的SIM卡

数据流量问题，这种架构完全是走数据流量，如果有视频数据，将会产生比较大的流量费用，这都是要考虑的

通讯质量问题，这完全依赖于移动服务商的网络覆盖状况，就如同我们手机一样，在有些环境下是没有信号的，也就没办法收发数据

2.2 基于wifi局域网

此中架构，适合于所有的物联网设备都是运行在一个局部环境中，设备通过wifi或者有线连接到路由器，而由路由器统一连接的物联网服务器，就如同我们家中装一个wifi路由器上网一样的架构，需要注意的事项：

局域网内的智能设备，是没有公网独立的ip的，只有一个局域网内的ip，带来的问题就是，设备可以直接给物联网服务器发送数据包，而物联网服务器是不能直接给设备发送数据包，就因为设备没有公网独立ip 功耗问题，对于使用wifi接入的设备，最好不是电池供电，因为wifi的功耗比较大 干扰问题，如果在大型的厂房部署这种架构，一定要考虑，厂房内是否有强干扰源，如电磁干扰，可以考虑采用工业级的无线路由器，一般抗干扰能力比较强

2.3 基于蓝牙通讯

一般的基于蓝牙的物联网，会考虑通过蓝牙网关来部署

蓝牙由于其点对点的通讯方式，所以要考虑如下问题：

蓝牙网关的容量问题，也就是一个蓝牙网关能接入几个蓝牙设备，这取决于蓝牙网关中使用了多少个蓝牙设备 蓝牙的配对问题，蓝牙设备直接的通讯都首先配对才能通讯，如果实现自动配对，如果不能自动配对，大规模部署，将是一个很麻烦的事情

还有一种场景是针对不需要一直在线的物联网设备，而只是在某种特殊需求的情况下，需要连上服务器，这中场景下，我们可以通过手机的蓝牙功能来让设备接入物联网

蓝牙手环是这种架构的一种典型应用模式

2.4 基于zigbee

ZigBee也是一种流行的组网模式，zigbee本身设计是针对传感器之间的联网，具有非常强的低功耗能力

zigbee接入网络也依赖于zigbee网关，网关本身也是一个zigbee设备，zigbee设备是自组网的，在使用过程中注意的问题有 数据量的问题，设备能力和功耗本身是自相矛盾的，由于ZigBee是超低功耗方案，固在通信能力上也是打折扣的， 很适合一些传感器数据的采集，如温度湿度，但如果对大数据量的视频类的就不适用了

这里主要介绍了，几种常用的物联网部署架构，至于物联网协议，这里就不多介绍，网上文章非常多。

3.智能设备

diego iot设计的初衷是让智能设备开发者摆脱对特殊模块的依赖，对于智能设备的开发，只要具备联网功能即可，没有特别多的要求。

互联互通社区

互联互通社区专注于IT互联网交流与学习，旨在打造最具价值的IT互联网智库中心，关注公众号：互联互通社区，每日获取最新报告并附带专题内容辅助学习。

方案咨询、数字化转型、中台建设、前沿技术培训与交流，合作请+微信：hulianhutongshequ