windy/my-vault

Fork 0

Files

T

windyboy 70c4508e56 vault backup: 2026-06-24 17:52:15

2026-06-24 17:52:15 +08:00

17 KiB

Raw Blame History

当前 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 当前项目能力

当前项目围绕产品、设备类型、设备分类、设备模型、设备功能等组织平台能力。

相关后端能力包括：

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

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 数据存储
设备数据查询
事件数据管理

相关页面包括：

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 项目组的优势主要在业务落地能力：

已有完整管理端页面。
已有具体行业功能，如 GIS、工单、平台级联。
已有设备接入、设备管理、告警、联动闭环。
已接入 TDengine，适合已有数据存储方案。
已有 OneNET、AEP 等第三方平台接入能力。
与内部 MINS、权限、组织、门户等体系集成较深。

13. JetLinks 优势

JetLinks Community 的优势主要在平台底座能力：

多协议接入能力更全面。
网络组件、协议组件、网关组件抽象更清晰。
物模型和设备消息体系更标准化。
规则引擎更通用，可承载告警、联动、转发等场景。
通知、日志、可视化、权限等通用平台能力更完整。
开源生态更适合参考、二开和长期演进。

14. 建议借鉴方向

如果目标是提升当前物联网管理平台功能，建议优先从以下方向借鉴 JetLinks：

14.1 强化设备接入中心

建议将接入能力统一抽象为：

网络组件
协议组件
接入网关
设备消息转换
连接状态管理
上下行日志

14.2 强化协议和编解码管理

建议补充或优化：

协议包管理
脚本化解析
设备型号与协议绑定
Topic 与物模型映射
上下行消息标准格式

14.3 强化规则引擎

建议将现有告警和联动统一抽象：

触发源：设备属性、事件、状态、定时任务
条件：表达式、阈值、时间窗口、组合条件
动作：通知、指令下发、数据转发、工单创建、HTTP/MQTT 推送
日志：执行记录、失败原因、重试记录

14.4 强化设备数据中心

建议形成统一设备数据视图：

最新属性
历史属性
事件记录
指令记录
上下线记录
告警记录
原始报文
解析后报文

14.5 强化平台运维能力

建议补充：

接入服务状态
MQTT Broker 状态
协议实例状态
设备连接数
消息吞吐量
规则执行统计
数据入库失败统计
设备离线原因分析

15. 迁移或融合建议

不建议直接用 JetLinks 替换当前项目。

更稳妥的方式是：

保留当前业务管理端、GIS、工单、平台级联等业务功能。
重点参考 JetLinks 改造接入层、协议层、规则引擎和数据中心。
如果需要引入 JetLinks，可将 JetLinks 作为设备接入和规则引擎底座，通过 API 与当前管理端集成。
当前项目继续承载行业业务和内部系统集成。

推荐融合形态：

当前 AIOT 管理端
  ├── 设备管理/业务页面/GIS/工单/平台级联
  ├── 对接内部权限、组织、门户
  └── 调用统一物联网底座 API
              |
              v
物联网底座能力
  ├── 设备接入
  ├── 协议解析
  ├── 物模型
  ├── 规则引擎
  ├── 时序数据
  └── 消息转发

16. 后续建议文档

建议继续补充以下专题文档：

当前项目设备管理功能清单
当前项目物模型与 JetLinks Thing Model 对比
当前项目设备接入流程与 JetLinks Gateway 对比
当前项目告警/联动与 JetLinks 规则引擎对比
当前项目 TDengine 数据模型说明
当前项目 GIS、工单、平台级联业务能力说明

17 KiB Raw Blame History Unescape Escape

当前 AIOT 项目组与 JetLinks Community 功能对比

1. 对比目标

2. 总体结论

3. 功能总览对比

4. 产品与物模型管理

4.1 当前项目能力

4.2 JetLinks 能力

4.3 对比结论

5. 设备管理

5.1 当前项目能力

5.2 JetLinks 能力

5.3 对比结论

6. 设备接入与协议管理

6.1 当前项目能力

6.2 JetLinks 能力

6.3 对比结论

7. 数据采集与时序数据

7.1 当前项目能力

7.2 JetLinks 能力

7.3 对比结论

8. 告警与规则联动

8.1 当前项目能力

8.2 JetLinks 能力

8.3 对比结论

9. 工单、GIS 与行业业务能力

9.1 当前项目能力

9.2 JetLinks 能力

9.3 对比结论

10. 运维监控与平台管理

10.1 当前项目能力

10.2 JetLinks 能力

10.3 对比结论

11. 功能成熟度评估

12. 当前项目优势

13. JetLinks 优势

14. 建议借鉴方向

14.1 强化设备接入中心

14.2 强化协议和编解码管理

14.3 强化规则引擎

14.4 强化设备数据中心

14.5 强化平台运维能力

15. 迁移或融合建议

16. 后续建议文档

17 KiB

Raw Blame History