574 lines
17 KiB
Markdown
574 lines
17 KiB
Markdown
# 当前 AIOT 项目组与 JetLinks Community 功能对比
|
||
|
||
## 1. 对比目标
|
||
|
||
本文重点从“物联网管理平台功能”角度，对比当前 AIOT 项目组与 JetLinks Community。
|
||
|
||
对比对象：
|
||
|
||
- 当前项目组：`aiot-admin`、`aiot-access`、`aiot-core`、`aiot-dao`、`aiot-datac`、`aiot-task`
|
||
- JetLinks Community：<https://github.com/jetlinks/jetlinks-community>
|
||
|
||
本文不重点讨论底层技术架构，只关注平台能力、业务功能和产品完整度。
|
||
|
||
## 2. 总体结论
|
||
|
||
当前 AIOT 项目组已经覆盖物联网管理平台的主要功能，包括：
|
||
|
||
- 产品管理
|
||
- 设备管理
|
||
- 物模型管理
|
||
- 设备接入
|
||
- MQTT/HTTP 接入
|
||
- 设备数据采集
|
||
- TDengine 时序数据
|
||
- 告警规则
|
||
- 设备联动
|
||
- 编解码管理
|
||
- GIS 管理
|
||
- 工单管理
|
||
- 平台级联
|
||
- 数据共享
|
||
|
||
JetLinks Community 的功能覆盖面更偏“通用物联网平台底座”，在以下方面更完整：
|
||
|
||
- 多协议统一接入
|
||
- 协议插件化
|
||
- 网络组件管理
|
||
- 规则引擎平台化
|
||
- 通知组件
|
||
- 数据可视化
|
||
- 权限体系
|
||
- 日志体系
|
||
- 设备模拟器
|
||
- 通用平台扩展能力
|
||
|
||
因此：
|
||
|
||
- 当前项目更像面向具体业务场景落地的 AIOT 管理平台。
|
||
- JetLinks 更像可二次开发的通用物联网基础平台。
|
||
|
||
## 3. 功能总览对比
|
||
|
||
| 功能域 | 当前 AIOT 项目组 | JetLinks Community | 对比结论 |
|
||
|---|---|---|---|
|
||
| 产品管理 | 支持产品、产品功能、产品主题、产品分类等 | 支持产品、物模型、协议绑定等 | 两者均具备，JetLinks 抽象更通用 |
|
||
| 设备管理 | 支持设备、分组、类型、分类、图片、认证等 | 支持设备生命周期、状态、配置、实例管理 | 两者均具备，当前项目业务页面更直接 |
|
||
| 物模型 | 支持 schema、功能、事件、属性等能力 | 支持 Thing Model，模型体系更标准化 | JetLinks 物模型体系更平台化 |
|
||
| 设备接入 | 支持 MQTT、HTTP、OneNET、AEP 等 | 支持 MQTT、TCP、UDP、HTTP、CoAP 等 | JetLinks 协议接入覆盖更广 |
|
||
| 网络组件 | 有网络配置和 MQTT/HTTP 客户端能力 | 有独立 network-component | JetLinks 网络层抽象更完整 |
|
||
| 协议/编解码 | 有编解码管理、解析相关能力 | 有 protocol-component、脚本、协议包机制 | JetLinks 更适合多协议扩展 |
|
||
| 数据采集 | 有 `aiot-datac`、采集任务、MQTT 数据处理 | 有网关、消息流、时序组件 | 两者均具备，JetLinks 更偏平台化数据管道 |
|
||
| 时序数据 | 支持 TDengine/TSDB | 支持 TimescaleDB、TDengine、ES 等 | JetLinks 存储适配更丰富 |
|
||
| 告警管理 | 有告警规则、告警记录、告警通知 | 通过规则引擎、通知组件实现 | 当前项目告警业务更直接，JetLinks 扩展更强 |
|
||
| 设备联动 | 有设备联动、条件、动作、日志 | 通过规则引擎和场景规则实现 | JetLinks 规则编排能力更完整 |
|
||
| 工单管理 | 有工单、工单流程、推送配置 | 社区版核心不以工单为主 | 当前项目工单能力更贴近业务应用 |
|
||
| GIS 管理 | 有 GIS 应用、图层、图例、轮廓 | JetLinks 核心不突出 GIS | 当前项目 GIS 业务能力更明显 |
|
||
| 平台级联 | 有平台级联、订阅、审计等页面 | 可通过集成/网关扩展实现 | 当前项目已有明确业务页面 |
|
||
| 数据共享 | 有 MQTT/HTTP 数据共享处理 | 可通过规则、网关、消息订阅扩展 | 当前项目数据共享更业务化 |
|
||
| 数据可视化 | 有 dashboard、设备概览、图表组件 | 有 dashboard/visualization-manager | JetLinks 可视化平台化更强 |
|
||
| 用户权限 | 依赖内部 MINS/IBLS/Token 体系 | 有 authentication-manager | JetLinks 权限模块开源完整度更高 |
|
||
| 日志审计 | 当前项目中不作为突出模块 | 有 logging-component/manager | JetLinks 日志体系更完整 |
|
||
| 通知能力 | 有告警通知、通知相关核心能力 | 有 notify-component，短信、邮件等通知抽象 | JetLinks 通知组件更通用 |
|
||
| 设备模拟 | 有设备模拟相关页面 | 有 simulator 模块 | JetLinks 设备模拟能力更独立 |
|
||
| 运维监控 | 有 MQTT 监控、平台监控相关页面 | 有日志、网关、设备状态等监控能力 | 两者均具备，侧重点不同 |
|
||
|
||
## 4. 产品与物模型管理
|
||
|
||
### 4.1 当前项目能力
|
||
|
||
当前项目围绕产品、设备类型、设备分类、设备模型、设备功能等组织平台能力。
|
||
|
||
相关功能页面包括：
|
||
|
||
- `deviceTypeManage`：设备类型管理
|
||
- `deviceCateManage`：设备分类管理
|
||
- `deviceModelManage`：设备模型管理
|
||
- `deviceFunManage`：设备功能管理
|
||
- `deviceAccess`：设备接入配置
|
||
- `coderDecoderManage`：编解码管理
|
||
|
||
相关后端能力包括：
|
||
|
||
- `IotProductController`
|
||
- `IotProductFeatureController`
|
||
- `IotFeatureController`
|
||
- `IotCategoryController`
|
||
- `IotCodecController`
|
||
- `IotCodecFieldController`
|
||
- `aiot-core/schema`
|
||
- `aiot-core/codec`
|
||
|
||
### 4.2 JetLinks 能力
|
||
|
||
JetLinks 以产品、设备、物模型、协议为核心组织管理能力。
|
||
|
||
典型能力包括：
|
||
|
||
- 产品定义
|
||
- 物模型定义
|
||
- 属性、事件、功能定义
|
||
- 产品与协议绑定
|
||
- 产品与设备实例关联
|
||
- 物模型数据处理
|
||
|
||
### 4.3 对比结论
|
||
|
||
| 方面 | 当前项目 | JetLinks |
|
||
|---|---|---|
|
||
| 产品管理 | 已具备业务化管理页面 | 更标准化、平台化 |
|
||
| 物模型 | 已有 schema 和功能模型 | Thing Model 体系更成熟 |
|
||
| 编解码 | 有专门编解码管理 | 协议包/脚本化能力更强 |
|
||
| 适合场景 | 固定业务场景快速落地 | 多行业、多协议平台化扩展 |
|
||
|
||
## 5. 设备管理
|
||
|
||
### 5.1 当前项目能力
|
||
|
||
当前项目设备管理相关功能比较完整，覆盖设备基础信息、分组、认证、图片、订阅、模拟等。
|
||
|
||
相关页面包括：
|
||
|
||
- `deviceManage`：设备管理
|
||
- `deviceGroupManage`：设备分组
|
||
- `deviceAuthManage`：设备认证
|
||
- `deviceSub`：设备订阅
|
||
- `deviceSubscribe`：设备订阅管理
|
||
- `deviceImitate`：设备模拟
|
||
- `deviceView`：设备视图
|
||
- `deviceOverview` / `deviceOverviewNew`：设备概览
|
||
|
||
相关后端能力包括：
|
||
|
||
- `IotDerviceController`
|
||
- `IotDeviceGroupController`
|
||
- `IotDerviceDataController`
|
||
- `IotDerviceEventController`
|
||
- `IotDerviceCmdController`
|
||
- `IotDervicePicController`
|
||
- `IotDeviceStatisticsController`
|
||
|
||
### 5.2 JetLinks 能力
|
||
|
||
JetLinks 设备管理能力更偏平台标准化，通常包括：
|
||
|
||
- 设备实例管理
|
||
- 设备状态管理
|
||
- 设备属性、事件、功能调用
|
||
- 设备分组/标签/关系
|
||
- 设备消息上下行
|
||
- 设备影子/配置
|
||
- 设备生命周期管理
|
||
|
||
### 5.3 对比结论
|
||
|
||
当前项目设备管理页面更贴合现有业务；JetLinks 设备模型更通用，适合大规模、多协议、多产品线设备统一管理。
|
||
|
||
## 6. 设备接入与协议管理
|
||
|
||
### 6.1 当前项目能力
|
||
|
||
当前项目设备接入主要由 `aiot-access` 和 `aiot-core` 承担。
|
||
|
||
已观察到的能力包括：
|
||
|
||
- MQTT 接入
|
||
- HTTP 接入
|
||
- OneNET 接入
|
||
- AEP 接入
|
||
- 网络配置
|
||
- 数据共享
|
||
- MQTT 消息服务
|
||
- 设备缓存
|
||
- 自定义 Topic
|
||
|
||
相关目录：
|
||
|
||
```text
|
||
aiot-access/aiot-access-server/src/main/java/com/aifa/mins/aiot/access/core/network
|
||
aiot-access/aiot-access-server/src/main/java/com/aifa/mins/aiot/access/mqtt
|
||
aiot-access/aiot-access-server/src/main/java/com/aifa/mins/aiot/access/datashare
|
||
aiot-core/src/main/java/com/aifa/mins/aiot/core/mqtt
|
||
aiot-core/src/main/java/com/aifa/mins/aiot/core/emq
|
||
```
|
||
|
||
### 6.2 JetLinks 能力
|
||
|
||
JetLinks 在设备接入方面是核心优势之一，支持：
|
||
|
||
- MQTT
|
||
- TCP
|
||
- UDP
|
||
- HTTP
|
||
- CoAP
|
||
- TLS/DTLS
|
||
- 网关接入
|
||
- 协议插件
|
||
- 网络组件管理
|
||
- 设备消息统一转换
|
||
|
||
### 6.3 对比结论
|
||
|
||
| 方面 | 当前项目 | JetLinks |
|
||
|---|---|---|
|
||
| MQTT | 支持 | 支持 |
|
||
| HTTP | 支持 | 支持 |
|
||
| TCP/UDP | 未作为明显功能暴露 | 支持 |
|
||
| CoAP | 未作为明显功能暴露 | 支持 |
|
||
| 第三方平台接入 | OneNET、AEP 更明确 | 可通过协议/网关扩展 |
|
||
| 协议插件化 | 有编解码能力，但插件化程度有限 | 更成熟 |
|
||
| 网络组件管理 | 有网络配置 | 独立 network-component |
|
||
|
||
如果当前平台后续需要接入更多厂家、更多私有协议，JetLinks 的协议与网络组件设计值得重点参考。
|
||
|
||
## 7. 数据采集与时序数据
|
||
|
||
### 7.1 当前项目能力
|
||
|
||
当前项目的数据相关能力主要包括：
|
||
|
||
- MQTT 数据接收
|
||
- 数据采集任务
|
||
- 数据转换处理
|
||
- TDengine/TAOS 数据存储
|
||
- 设备数据查询
|
||
- 事件数据管理
|
||
|
||
相关模块：
|
||
|
||
- `aiot-datac`
|
||
- `aiot-core/tsdb`
|
||
- `aiot-admin` 中的设备数据、事件数据、TDengine 查询页面
|
||
|
||
相关页面包括：
|
||
|
||
- `eventData`
|
||
- `deviceOverview`
|
||
- `deviceOverviewNew`
|
||
- `plfmMonitor`
|
||
|
||
### 7.2 JetLinks 能力
|
||
|
||
JetLinks 在数据处理上提供更平台化的能力：
|
||
|
||
- 设备消息统一处理
|
||
- 属性、事件、功能调用数据处理
|
||
- 时序数据组件
|
||
- TDengine 集成
|
||
- TimescaleDB 支持
|
||
- Elasticsearch 可选支持
|
||
- 数据可视化组件
|
||
|
||
### 7.3 对比结论
|
||
|
||
当前项目已经能支撑业务场景下的数据采集和 TDengine 存储；JetLinks 的优势在于数据模型更统一，时序数据存储适配更开放。
|
||
|
||
## 8. 告警与规则联动
|
||
|
||
### 8.1 当前项目能力
|
||
|
||
当前项目告警和联动相关功能比较明确。
|
||
|
||
相关页面包括：
|
||
|
||
- `warnRuleManage`：告警规则管理
|
||
- `deviceWarn`：设备告警
|
||
- `deviceLinkage`：设备联动
|
||
|
||
相关后端能力包括：
|
||
|
||
- `IotWarmRuleController`
|
||
- `IotWarmRecordController`
|
||
- `IotWarmNoticeController`
|
||
- `IotWarmSettingController`
|
||
- `IotDeviceLinkageController`
|
||
- `IotDeviceLinkageConditionController`
|
||
- `IotDeviceLinkageActionController`
|
||
- `IotDeviceLinkageActionLogController`
|
||
- `aiot-core/rule`
|
||
- `aiot-core/warn`
|
||
|
||
### 8.2 JetLinks 能力
|
||
|
||
JetLinks 将规则引擎作为核心能力，通常可覆盖：
|
||
|
||
- 设备数据触发
|
||
- 条件判断
|
||
- 场景联动
|
||
- 告警触发
|
||
- 通知发送
|
||
- 数据转发
|
||
- 脚本处理
|
||
- 规则执行日志
|
||
|
||
### 8.3 对比结论
|
||
|
||
当前项目已经有完整的告警和设备联动业务闭环，适合直接支撑具体业务。
|
||
|
||
JetLinks 的规则引擎更通用，适合把告警、联动、数据转发、消息处理统一成规则编排平台。
|
||
|
||
建议当前项目重点借鉴 JetLinks 的：
|
||
|
||
- 规则模型抽象
|
||
- 触发器设计
|
||
- 条件表达式设计
|
||
- 动作执行器设计
|
||
- 规则执行日志
|
||
- 通知组件解耦
|
||
|
||
## 9. 工单、GIS 与行业业务能力
|
||
|
||
### 9.1 当前项目能力
|
||
|
||
当前项目明显包含一些行业业务功能：
|
||
|
||
- 工单管理
|
||
- GIS 应用管理
|
||
- GIS 图层管理
|
||
- GIS 图例管理
|
||
- GIS 轮廓管理
|
||
- 平台级联
|
||
- 审核订阅
|
||
|
||
相关页面包括：
|
||
|
||
- `workOrder`
|
||
- `GISApplication`
|
||
- `GisAppManage`
|
||
- `GisLayerManage`
|
||
- `GisLegendManage`
|
||
- `GisOutlineManage`
|
||
- `platformCascade`
|
||
- `subAuditManage`
|
||
|
||
相关后端能力包括：
|
||
|
||
- `IotWorkOrderController`
|
||
- `IotWorkOrderProcessController`
|
||
- `GisAppController`
|
||
- `GisLayerController`
|
||
- `GisLegendController`
|
||
- `GisOutlineController`
|
||
- `IotPlatformCascadeController`
|
||
- `IotPlatformRssController`
|
||
|
||
### 9.2 JetLinks 能力
|
||
|
||
JetLinks Community 更偏通用物联网平台底座，核心关注：
|
||
|
||
- 设备接入
|
||
- 设备管理
|
||
- 规则引擎
|
||
- 数据处理
|
||
- 通知
|
||
- 可视化
|
||
- 权限
|
||
- 日志
|
||
|
||
工单、GIS、行业流程并不是 JetLinks 社区版最核心的功能重点，通常需要在业务层二次开发。
|
||
|
||
### 9.3 对比结论
|
||
|
||
在行业业务管理方面，当前项目比 JetLinks Community 更贴近具体业务落地。
|
||
|
||
如果当前项目已经服务于某个行业场景，如园区、城市、能源、设备运维等，保留当前业务层更合理。
|
||
|
||
## 10. 运维监控与平台管理
|
||
|
||
### 10.1 当前项目能力
|
||
|
||
当前项目已有一些平台运维和监控功能：
|
||
|
||
- MQTT 监控
|
||
- 平台监控
|
||
- 设备统计
|
||
- 设备概览
|
||
- 数据采集任务
|
||
- 任务调度
|
||
- 系统管理页面
|
||
|
||
相关页面包括：
|
||
|
||
- `plfmMonitor`
|
||
- `deviceOverview`
|
||
- `deviceOverviewNew`
|
||
- `dashboard`
|
||
- `system`
|
||
|
||
相关后端能力包括：
|
||
|
||
- `IotMonitorController`
|
||
- `IotMqttMonitorApi`
|
||
- `IotTdMqMonitorController`
|
||
- `IotDeviceStatisticsController`
|
||
|
||
### 10.2 JetLinks 能力
|
||
|
||
JetLinks 平台管理能力包括：
|
||
|
||
- 网关状态
|
||
- 设备状态
|
||
- 日志管理
|
||
- 通知配置
|
||
- 规则执行监控
|
||
- 数据看板
|
||
- 用户权限
|
||
- 系统配置
|
||
|
||
### 10.3 对比结论
|
||
|
||
当前项目偏业务运维视角，JetLinks 偏平台运维视角。
|
||
|
||
如果要增强当前项目，可以考虑补充：
|
||
|
||
- 接入网关运行状态
|
||
- 协议实例状态
|
||
- 规则执行链路
|
||
- 设备消息链路追踪
|
||
- 设备上下线日志
|
||
- 指令下发日志
|
||
- 数据转发日志
|
||
|
||
## 11. 功能成熟度评估
|
||
|
||
| 功能 | 当前项目成熟度 | JetLinks 成熟度 | 说明 |
|
||
|---|---:|---:|---|
|
||
| 设备管理 | 高 | 高 | 两者均完整 |
|
||
| 产品/物模型 | 中高 | 高 | JetLinks 标准化更强 |
|
||
| MQTT 接入 | 高 | 高 | 两者均支持 |
|
||
| HTTP 接入 | 中高 | 高 | JetLinks 接入抽象更统一 |
|
||
| TCP/UDP/CoAP | 低/未明显体现 | 高 | JetLinks 覆盖更广 |
|
||
| 编解码 | 中高 | 高 | JetLinks 协议包机制更强 |
|
||
| 告警规则 | 高 | 高 | 当前业务闭环更直接 |
|
||
| 规则引擎 | 中 | 高 | JetLinks 更平台化 |
|
||
| TDengine | 高 | 中高 | 当前项目绑定更明显 |
|
||
| 多时序存储 | 中 | 高 | JetLinks 适配更多 |
|
||
| GIS | 高 | 低/需二开 | 当前项目优势 |
|
||
| 工单 | 高 | 低/需二开 | 当前项目优势 |
|
||
| 平台级联 | 中高 | 中/需扩展 | 当前项目已有业务页面 |
|
||
| 数据可视化 | 中 | 中高 | JetLinks visualization-manager 更平台化 |
|
||
| 权限管理 | 中/依赖内部体系 | 高 | JetLinks 开源体系更完整 |
|
||
| 日志审计 | 中 | 高 | JetLinks 日志模块更突出 |
|
||
|
||
## 12. 当前项目优势
|
||
|
||
当前 AIOT 项目组的优势主要在业务落地能力：
|
||
|
||
1. 已有完整管理端页面。
|
||
2. 已有具体行业功能，如 GIS、工单、平台级联。
|
||
3. 已有设备接入、设备管理、告警、联动闭环。
|
||
4. 已接入 TDengine，适合已有数据存储方案。
|
||
5. 已有 OneNET、AEP 等第三方平台接入能力。
|
||
6. 与内部 MINS、权限、组织、门户等体系集成较深。
|
||
|
||
## 13. JetLinks 优势
|
||
|
||
JetLinks Community 的优势主要在平台底座能力：
|
||
|
||
1. 多协议接入能力更全面。
|
||
2. 网络组件、协议组件、网关组件抽象更清晰。
|
||
3. 物模型和设备消息体系更标准化。
|
||
4. 规则引擎更通用，可承载告警、联动、转发等场景。
|
||
5. 通知、日志、可视化、权限等通用平台能力更完整。
|
||
6. 开源生态更适合参考、二开和长期演进。
|
||
|
||
## 14. 建议借鉴方向
|
||
|
||
如果目标是提升当前物联网管理平台功能，建议优先从以下方向借鉴 JetLinks：
|
||
|
||
### 14.1 强化设备接入中心
|
||
|
||
建议将接入能力统一抽象为：
|
||
|
||
- 网络组件
|
||
- 协议组件
|
||
- 接入网关
|
||
- 设备消息转换
|
||
- 连接状态管理
|
||
- 上下行日志
|
||
|
||
### 14.2 强化协议和编解码管理
|
||
|
||
建议补充或优化：
|
||
|
||
- 协议包管理
|
||
- 脚本化解析
|
||
- 设备型号与协议绑定
|
||
- Topic 与物模型映射
|
||
- 上下行消息标准格式
|
||
|
||
### 14.3 强化规则引擎
|
||
|
||
建议将现有告警和联动统一抽象：
|
||
|
||
- 触发源：设备属性、事件、状态、定时任务
|
||
- 条件：表达式、阈值、时间窗口、组合条件
|
||
- 动作：通知、指令下发、数据转发、工单创建、HTTP/MQTT 推送
|
||
- 日志：执行记录、失败原因、重试记录
|
||
|
||
### 14.4 强化设备数据中心
|
||
|
||
建议形成统一设备数据视图：
|
||
|
||
- 最新属性
|
||
- 历史属性
|
||
- 事件记录
|
||
- 指令记录
|
||
- 上下线记录
|
||
- 告警记录
|
||
- 原始报文
|
||
- 解析后报文
|
||
|
||
### 14.5 强化平台运维能力
|
||
|
||
建议补充：
|
||
|
||
- 接入服务状态
|
||
- MQTT Broker 状态
|
||
- 协议实例状态
|
||
- 设备连接数
|
||
- 消息吞吐量
|
||
- 规则执行统计
|
||
- 数据入库失败统计
|
||
- 设备离线原因分析
|
||
|
||
## 15. 迁移或融合建议
|
||
|
||
不建议直接用 JetLinks 替换当前项目。
|
||
|
||
更稳妥的方式是：
|
||
|
||
1. 保留当前业务管理端、GIS、工单、平台级联等业务功能。
|
||
2. 重点参考 JetLinks 改造接入层、协议层、规则引擎和数据中心。
|
||
3. 如果需要引入 JetLinks，可将 JetLinks 作为设备接入和规则引擎底座，通过 API 与当前管理端集成。
|
||
4. 当前项目继续承载行业业务和内部系统集成。
|
||
|
||
推荐融合形态：
|
||
|
||
```text
|
||
当前 AIOT 管理端
|
||
├── 设备管理/业务页面/GIS/工单/平台级联
|
||
├── 对接内部权限、组织、门户
|
||
└── 调用统一物联网底座 API
|
||
|
|
||
v
|
||
物联网底座能力
|
||
├── 设备接入
|
||
├── 协议解析
|
||
├── 物模型
|
||
├── 规则引擎
|
||
├── 时序数据
|
||
└── 消息转发
|
||
```
|
||
|
||
## 16. 后续建议文档
|
||
|
||
建议继续补充以下专题文档：
|
||
|
||
1. 当前项目设备管理功能清单
|
||
2. 当前项目物模型与 JetLinks Thing Model 对比
|
||
3. 当前项目设备接入流程与 JetLinks Gateway 对比
|
||
4. 当前项目告警/联动与 JetLinks 规则引擎对比
|
||
5. 当前项目 TDengine 数据模型说明
|
||
6. 当前项目 GIS、工单、平台级联业务能力说明
|