部署架构与组件选型
部署架构把逻辑能力落实为进程、容器、网络和数据依赖。选择时应先确定需要交付的产品、设备与 AI 流程，再选择宿主、基础组件和专项服务。
本页以当前部署生成器和服务装配方式说明默认组合、预设差异及替代条件。具体环境仍以生成配置、固定版本镜像和实际运行结果为准。
放大查看 SVG ↗ · 下载 SVG · 下载高清 PNG
1. 先确定需要运行的业务链路
一个只需要设备接入与查询的组合，与包含音视频、脚本执行、行业模块及云边管理的产品，具有不同依赖。选型可以按以下顺序展开：
- 确定产品入口：AllInOne、Cloud、具体 Edge 或相应独立服务。
- 确定设备协议、客户端和实际业务模块。
- 确定关系数据、时序数据、对象资源和消息依赖。
- 按 AI 工具类型、媒体和第三方协议增加专项能力。
- 核对已有客户端、数据迁移与发布回滚要求。
这样得到的是一个具体交付组合，而不是将所有支持的组件同时部署。
2. 默认数据与接入组合
当前生成器默认选择 PostgreSQL 作为关系库与时序路径，RustFS 作为对象存储，MQTT 使用内置 Broker。缓存、事件和其他依赖由所用服务及实际配置装配。
| 维度 | 默认或常用支撑 | 承担什么 |
|---|---|---|
| 关系数据 | PostgreSQL | 企业、应用、设备资料及相应业务记录 |
| 设备历史 | PostgreSQL 时序路径 | 设备历史数据与对应查询语义 |
| 对象资源 | RustFS | 图片、文件、固件、工具或其他对象资源 |
| 设备连接 | 内置 MQTT | 对应宿主中的设备连接与消息接入 |
| 缓存与运行状态 | Redis 等实际配置 | 对应服务的缓存及运行支撑 |
| 业务事件 | EventBus / NATS 等实际配置 | 相应异步业务投递与消费 |
默认生成配置中的业务库和 PG 时序连接可以指向同一 PostgreSQL 服务，但二者仍具有不同表、数据生命周期与查询职责。是否分离实例、怎样设置扩展与资源，应结合实际仓储实现和部署需求确定。
使用内置 MQTT 的组合中，某些兼容网络入口用于满足既有客户端连接约定。判断是否存在独立 Broker，应查看真实消息处理宿主与生成服务，不能只凭一个服务别名推断已经部署了 EMQX。
3. slim、full 与 dev 的差异
| 预设 | 设计用途 | 当前组合差异 |
|---|---|---|
slim | 默认交付组合 | PG、PG 时序、RustFS、内置 MQTT，并包含所配置的 AI Sandbox；不包含音视频组件 |
full | 包含相应专项能力的组合 | 在对应基础组合中增加音视频，并包含所配置的 AI Sandbox |
dev | 开发所需基础设施准备 | 采用对应 PG、PG 时序、RustFS 与内置 MQTT 的基础设施口径 |
预设为生成配置提供起点，追加和移除选项再调整实际组合。生成后仍需核对启动入口、服务清单和每个依赖地址，不能只根据预设名称判断所有模块已经可用。
这里的“包含 Sandbox”表示生成器选择了相应执行依赖。HTTP 和 Agent MCP 工具仍使用各自执行路径，不会因此全部改为经过 Sandbox。
4. 可选替代与专项服务
| 组件或能力 | 什么时候考虑 | 同时需要核对 |
|---|---|---|
| MySQL | 选择对应关系库组合 | 具体模块、表结构、查询及迁移兼容范围 |
| TDengine | 选择对应时序后端 | 仓储配置、写入、历史查询和聚合语义 |
| 外接 EMQX | 需要外部 MQTT Broker 组合 | 连接、认证、主题访问及消息转发路径 |
| 外部对象存储 | 使用其他兼容存储或云服务 | 认证、对象地址、上传下载及访问范围 |
| ZLMediaKit | 交付相应音视频能力 | 控制与媒体协议、网络及终端可用性 |
| Sandbox / Runtime | 工具需要脚本或包执行 | 运行器、连接、工作空间、输出和限制 |
| etcd | 所用服务需要相应注册发现 | 注册方式、客户端配置和实际服务地址 |
| 独立协议服务 | 原生通信与平台协议存在需适配差异 | 设备认证、连接、载荷、指令与反馈 |
技术栈支持某种组件，意味着存在对应实现或配置路径；某个具体业务模块是否完整兼容该组合，需要单独核对。替换数据库或 Broker 也不只是换一个连接地址，还会影响迁移、鉴权和实际消息语义。
5. 融合式宿主与独立服务怎样选择
AllInOne 和场景入口将多个模块组合到相应宿主，适合明确的融合交付。独立服务使用对应 API / RPC 合同与自己的运行配置，提供不同进程和故障边界。
| 观察维度 | 融合式宿主 | 独立服务 |
|---|---|---|
| 装配 | 一个入口注册多个能力 | 各服务分别启动与连接 |
| 资源 | 共享所在进程的 CPU、内存和影响 | 按实际进程分别安排 |
| 调用 | direct 与按配置保留的 RPC 依赖并存 | 使用对应远程合同和连接 |
| 运维 | 关注整体宿主及其外部依赖 | 增加服务发现、连接和多进程维护 |
| 变更 | 核对入口内受影响模块 | 核对调用合同和各服务版本组合 |
选择方式取决于交付组合、负载和隔离需要。逻辑上存在多个模块，并不要求一次性将它们全部拆成独立服务；选择融合交付后，也仍需正确配置实际保留的 RPC 依赖。
6. 一次业务请求会经过哪些部署依赖
不同请求只使用所需依赖。设备历史查询可能访问业务与时序仓储；文件下载还需要对象地址与访问条件；包技能需要对应 Runtime；音视频则具有另外的媒体网络条件。
服务进程健康，只能说明某一层运行检查通过。登录、设备查询、文件访问、控制反馈和 AI 工具执行，应通过各自实际业务请求确认。
7. 数据、文件与工作空间的生命周期
| 类别 | 需要保留和核验的内容 |
|---|---|
| 业务数据库 | 结构、业务记录、初始化状态与对应版本迁移 |
| 设备历史 | 历史表与时间范围、查询结果及相应存储策略 |
| 对象存储 | 文件、固件、图片等对象及其可访问性 |
| AI 工作空间 | 实际执行所需文件、挂载、产物和生命周期 |
| 配置与授权 | 业务配置、依赖连接、身份和适用产品授权 |
重建容器与重建数据是不同操作。部署方案需要明确哪些路径持久化、备份覆盖什么、恢复后如何核验，以及新版本回滚时是否仍能读取已有数据。仅保留一个镜像标签，无法替代数据和配置恢复方案。
环境地址、凭据、证书和实际机器清单由对应环境资料维护，本页不列具体环境值。这里的架构关系也不构成某台服务器的运行清单。
8. 旧客户端与兼容入口
apilegacy 继续承担旧客户端协议兼容。后端主线更新时，需要核对网关所消费的字段、ID 表达、时间、错误、认证，以及上传、回调和 WebSocket 行为。
部署顺序应根据合同兼容性决定：新服务与兼容适配是否能同时工作、旧版本是否还可读取更新后的数据，以及回滚时需要保留哪些组件，都应在实际发布前明确。新版客户端正常不能代替旧端验证。
9. 官网、文档与业务界面分别交付
官网、文档站与平台管理应用具有独立构建产物。架构文图在各站使用本地发布资源，正式文章和下载链接需要同步有效。
更新两站架构资料时，先确保文档目标及图片已准备，再更新官网入口。业务管理应用的发布还需核对自己的 API 与配置，不能将静态官网可访问视为业务系统已完成部署。
10. 从选型走到可用
部署核验可以沿“版本与配置 → 服务和依赖 → 认证与权限 → 真实业务结果 → 备份与恢复”展开。使用真实设备的组合还需要控制回执和实际状态，使用 AI 的组合还需要工具结果及产物。
安装操作从快速开始进入，后续更新、备份与恢复见urops 使用指南。独立应用的初始化、应用注册和成员授权继续阅读应用部署。
架构专题导航
平台总体架构 · 后端运行架构 · SaaS 与权限架构 · IoT 接入与数据架构 · AI 与工具执行架构 · 前端与客户端架构 · 云边协同架构
更新日志
2026/10/27 13:22
查看所有更新日志
c4a4b-于93dfc-于