评估一个开源平台功能列表与 star 数都容易修饰从 clone 到看到数据的耗时是最诚实指标它把文档质量、依赖管理、启动编排一次性摊在桌面上。工业物联网平台的部署门槛又格外高——数据库要带扩展、消息队列要预配置、服务之间存在启动顺序任何一环缺失首次体验就停在报错页。本文基于 DC3 当前主干完整走一遍流程四步每一步给出实际执行的命令与应当看到的结果。前置条件以仓库 贡献指南 为准JDK 21、Maven 3.9、Podman 或 Docker以及可联网环境浏览器验证环节另需 Node.js 与 pnpm。容器编排不绑定具体运行时——Makefile 会先探测 Docker Compose不可用则回落到 Podman Compose两条路径命令一致。第一步启动基础设施gitclone https://github.com/pnoker/iot-dc3.gitcdiot-dc3makeup-dbmake up-db背后是dc3/docker-compose-db.yml这份编排启动两个容器dc3-postgres与dc3-rabbitmq。前者不是官方 PostgreSQL 镜像而是分层构建的定制镜像——在基础镜像之上叠加 TimescaleDB、pgvector、AGE 扩展与全部初始化脚本容器内 5432 映射到宿主机 35432。首次以空数据卷启动时入口脚本按文件名顺序执行 initdb 目录下的建库脚本从扩展安装、公共表、认证数据一直到观测性表菜单、默认租户与账号都在这一步写入——这也是后文seed 仅在空数据卷执行的由来。两个容器均配置健康检查PostgreSQL 用pg_isreadyRabbitMQ 用rabbitmq-diagnostics pingmake ps看到 healthy 即告完成。国内网络环境可使用make up-db-cn阿里云镜像源。第二步源码编译sourcedc3/env/dev.env.sh mvn-s.mvn/settings.xml clean packagedev.env.sh把本地源码运行所需的变量灌入当前 shell——数据库指向localhost:35432、消息队列指向localhost:35672与第一步映射出来的端口一一对应。随后 Maven 按仓库自带的 settings.xml 拉取依赖并全量打包首次编译需拉取依赖视网络情况约 5–15 分钟。仅需验证编译时可改用mvn -s .mvn/settings.xml -q -DskipTests compile输出安静、结论不变。这一步与容器路径的关系值得说明根目录的统一 Dockerfile 在构建镜像时会在 builder 阶段内部自行执行 Maven 打包纯容器部署并不依赖宿主机编译宿主机这一步服务于源码级开发——IDE 中逐服务运行make run SERVICEgateway与断点调试都以它的产物为基础。两条路径并存编译结论可互为印证。第三步启动全栈服务makeup-devmake up-dev对应dc3/docker-compose-dev.yml网关8000、认证中心8300、管理中心8400、数据中心8500、智能体中心8600与全部驱动容器逐一启动。服务不是并排拉起——编排中每个服务都声明了带健康条件的依赖网关要等四个中心全部健康才启动数据中心要等管理中心就绪。就绪探针统一指向各服务的/actuator/health/readiness端点比进程活着更接近能接流量的真实状态。首次执行会构建全部镜像多阶段 Dockerfile 使多个服务镜像共享同一次 Maven 构建不会每个镜像都重跑编译make logs可跟踪启动过程。可选观测组件EMQX、ELK、Prometheus、Grafana通过make up-optional启动与核心链路无关不影响后续验证。第四步浏览器验证后端就绪后在dc3-web目录执行pnpm dev启动前端开发服务器浏览器打开http://localhost:8080页面请求由开发服务器代理到网关 8000。登录使用种子数据内置的默认账号dc3/dc3dc3dc3——由 initdb 脚本以 BCRYPT 哈希写入首次启动即存在。登录之后验证不是页面能打开而是按数据链路逐段确认验证项链路上的含义首页仪表盘正常渲染网关 → 认证中心 → 各中心服务的调用链畅通设备列表与实时数据持续变化虚拟驱动 → 消息总线 → 数据中心的采集链路在工作点位历史曲线有数据数据中心 → 时序存储的写入与查询链路在工作配置模型后用 AI Chat 自然语言查询设备与点位智能体中心的工具调用链路在工作虚拟驱动无设备环境的链路验证第一次部署就能看到数据在动靠的是 Virtual 虚拟驱动但它验证的东西并不虚。从源码看虚拟驱动的读方法按点位类型生成数据字符串点位返回固定样例值abcd1234布尔点位返回随机真假数值点位返回 0 到 100 之间的随机值。真正的关键在框架侧驱动框架用 Quartz 定时任务周期性对启用设备的点位发起读取读到的值经消息总线送入数据中心、写入时序存储前端的实时数据与历史曲线读的都是这条链路的产出驱动自身的调度还会周期性上报设备事件。换句话说页面上的每一个数字都完整走过了采集 → 传输 → 入库 → 查询的路径与接入真实设备的差别只在最前端的读这一环——换成 Modbus 或 OPC UA 驱动链路其余部分原样复用。这正是虚拟驱动的价值把部署验证与设备接入解耦让从 clone 到看到数据不必等待硬件到位。若想获得更完整的业务画面可导入演示数据集podman exec -i dc3-postgres psql -U dc3 -d dc3 dc3/dependencies/postgres/demo/iot-dc3-demo.sql。这份脚本可重复执行——每次先清理固定 ID 段再插入内容是一个园区冷站的完整场景冷冻水泵、空调机组等设备分属 Modbus TCP、OPC UA、MQTT、S7 与 Virtual 五个驱动首页仪表盘、事件看板、列表与详情页随之都有数据可看。常见问题8080 端口被其他服务占用时前端页面空白更换端口即可首次建库失败多与数据卷状态有关——seed 初始化仅在空数据卷时执行失败后需make down确认卷已清理再重试涉及删卷的make reset设有确认开关防止误删国内镜像拉取慢统一使用-cn后缀的 make 目标其余问题建议直接查 docs.dc3.site 的 Troubleshooting 章节支持按报错关键字检索。适用范围与限制本流程覆盖部署与数据链路验证接入真实设备的时间取决于协议适配与点位建模属于部署之后的另一件事与本文四步无关。生产署请看 dc3/doc/DEPLOYMENT.mdK8s / Helm / Swarm 配置、TLS、容量规划都在那里本文的 compose 流程适合开发与体验。结语从 clone 到登录页看到第一条实时数据实质命令不超过五条。部署体验是开源平台的门面也是工程质量的直接投影——initdb 脚本是否可重复执行、健康检查是否真实、启动顺序是否由编排保证这些细节比任何宣传页都更能说明一个项目处于什么水位。仓库GitHub pnoker/iot-dc3 · Gitee pnoker/iot-dc3GVP文档docs.dc3.siteQuickstart / Troubleshooting· book.dc3.site · demo.dc3.site 从零部署 IoT DC3：四步快速启动实录
评估一个开源平台功能列表与 star 数都容易修饰从 clone 到看到数据的耗时是最诚实指标它把文档质量、依赖管理、启动编排一次性摊在桌面上。工业物联网平台的部署门槛又格外高——数据库要带扩展、消息队列要预配置、服务之间存在启动顺序任何一环缺失首次体验就停在报错页。本文基于 DC3 当前主干完整走一遍流程四步每一步给出实际执行的命令与应当看到的结果。前置条件以仓库 贡献指南 为准JDK 21、Maven 3.9、Podman 或 Docker以及可联网环境浏览器验证环节另需 Node.js 与 pnpm。容器编排不绑定具体运行时——Makefile 会先探测 Docker Compose不可用则回落到 Podman Compose两条路径命令一致。第一步启动基础设施gitclone https://github.com/pnoker/iot-dc3.gitcdiot-dc3makeup-dbmake up-db背后是dc3/docker-compose-db.yml这份编排启动两个容器dc3-postgres与dc3-rabbitmq。前者不是官方 PostgreSQL 镜像而是分层构建的定制镜像——在基础镜像之上叠加 TimescaleDB、pgvector、AGE 扩展与全部初始化脚本容器内 5432 映射到宿主机 35432。首次以空数据卷启动时入口脚本按文件名顺序执行 initdb 目录下的建库脚本从扩展安装、公共表、认证数据一直到观测性表菜单、默认租户与账号都在这一步写入——这也是后文seed 仅在空数据卷执行的由来。两个容器均配置健康检查PostgreSQL 用pg_isreadyRabbitMQ 用rabbitmq-diagnostics pingmake ps看到 healthy 即告完成。国内网络环境可使用make up-db-cn阿里云镜像源。第二步源码编译sourcedc3/env/dev.env.sh mvn-s.mvn/settings.xml clean packagedev.env.sh把本地源码运行所需的变量灌入当前 shell——数据库指向localhost:35432、消息队列指向localhost:35672与第一步映射出来的端口一一对应。随后 Maven 按仓库自带的 settings.xml 拉取依赖并全量打包首次编译需拉取依赖视网络情况约 5–15 分钟。仅需验证编译时可改用mvn -s .mvn/settings.xml -q -DskipTests compile输出安静、结论不变。这一步与容器路径的关系值得说明根目录的统一 Dockerfile 在构建镜像时会在 builder 阶段内部自行执行 Maven 打包纯容器部署并不依赖宿主机编译宿主机这一步服务于源码级开发——IDE 中逐服务运行make run SERVICEgateway与断点调试都以它的产物为基础。两条路径并存编译结论可互为印证。第三步启动全栈服务makeup-devmake up-dev对应dc3/docker-compose-dev.yml网关8000、认证中心8300、管理中心8400、数据中心8500、智能体中心8600与全部驱动容器逐一启动。服务不是并排拉起——编排中每个服务都声明了带健康条件的依赖网关要等四个中心全部健康才启动数据中心要等管理中心就绪。就绪探针统一指向各服务的/actuator/health/readiness端点比进程活着更接近能接流量的真实状态。首次执行会构建全部镜像多阶段 Dockerfile 使多个服务镜像共享同一次 Maven 构建不会每个镜像都重跑编译make logs可跟踪启动过程。可选观测组件EMQX、ELK、Prometheus、Grafana通过make up-optional启动与核心链路无关不影响后续验证。第四步浏览器验证后端就绪后在dc3-web目录执行pnpm dev启动前端开发服务器浏览器打开http://localhost:8080页面请求由开发服务器代理到网关 8000。登录使用种子数据内置的默认账号dc3/dc3dc3dc3——由 initdb 脚本以 BCRYPT 哈希写入首次启动即存在。登录之后验证不是页面能打开而是按数据链路逐段确认验证项链路上的含义首页仪表盘正常渲染网关 → 认证中心 → 各中心服务的调用链畅通设备列表与实时数据持续变化虚拟驱动 → 消息总线 → 数据中心的采集链路在工作点位历史曲线有数据数据中心 → 时序存储的写入与查询链路在工作配置模型后用 AI Chat 自然语言查询设备与点位智能体中心的工具调用链路在工作虚拟驱动无设备环境的链路验证第一次部署就能看到数据在动靠的是 Virtual 虚拟驱动但它验证的东西并不虚。从源码看虚拟驱动的读方法按点位类型生成数据字符串点位返回固定样例值abcd1234布尔点位返回随机真假数值点位返回 0 到 100 之间的随机值。真正的关键在框架侧驱动框架用 Quartz 定时任务周期性对启用设备的点位发起读取读到的值经消息总线送入数据中心、写入时序存储前端的实时数据与历史曲线读的都是这条链路的产出驱动自身的调度还会周期性上报设备事件。换句话说页面上的每一个数字都完整走过了采集 → 传输 → 入库 → 查询的路径与接入真实设备的差别只在最前端的读这一环——换成 Modbus 或 OPC UA 驱动链路其余部分原样复用。这正是虚拟驱动的价值把部署验证与设备接入解耦让从 clone 到看到数据不必等待硬件到位。若想获得更完整的业务画面可导入演示数据集podman exec -i dc3-postgres psql -U dc3 -d dc3 dc3/dependencies/postgres/demo/iot-dc3-demo.sql。这份脚本可重复执行——每次先清理固定 ID 段再插入内容是一个园区冷站的完整场景冷冻水泵、空调机组等设备分属 Modbus TCP、OPC UA、MQTT、S7 与 Virtual 五个驱动首页仪表盘、事件看板、列表与详情页随之都有数据可看。常见问题8080 端口被其他服务占用时前端页面空白更换端口即可首次建库失败多与数据卷状态有关——seed 初始化仅在空数据卷时执行失败后需make down确认卷已清理再重试涉及删卷的make reset设有确认开关防止误删国内镜像拉取慢统一使用-cn后缀的 make 目标其余问题建议直接查 docs.dc3.site 的 Troubleshooting 章节支持按报错关键字检索。适用范围与限制本流程覆盖部署与数据链路验证接入真实设备的时间取决于协议适配与点位建模属于部署之后的另一件事与本文四步无关。生产署请看 dc3/doc/DEPLOYMENT.mdK8s / Helm / Swarm 配置、TLS、容量规划都在那里本文的 compose 流程适合开发与体验。结语从 clone 到登录页看到第一条实时数据实质命令不超过五条。部署体验是开源平台的门面也是工程质量的直接投影——initdb 脚本是否可重复执行、健康检查是否真实、启动顺序是否由编排保证这些细节比任何宣传页都更能说明一个项目处于什么水位。仓库GitHub pnoker/iot-dc3 · Gitee pnoker/iot-dc3GVP文档docs.dc3.siteQuickstart / Troubleshooting· book.dc3.site · demo.dc3.site