人形机器人（商用服务机器人）在校园、展厅、商场等场景进入批量部署阶段后，缺乏统一的接入与运营管理平台，暴露出几类核心问题：
设备接入与状态不可控：机器人通过 MQTT 上报心跳/磁盘/状态等报文，但设备批量上线后，谁在线、谁掉线、谁故障没有统一视图，运维只能靠人工排查；
多租户 / 多渠道缺乏数据隔离：学校、渠道商、运营商等不同主体共用一套系统，若不做租户与平台两级隔离，会直接造成越权访问和数据泄露；
设备形态多样、字段无法穷举：设备类型分为「大类 / 子类 / 变体」三级，不同设备的扩展字段、校验规则各不相同，硬编码表单无法灵活扩展；
内容运营链路割裂：素材（视频 / 表情包 / 脚本）的上传、审核、下发、回收各管各的，缺少全链路管控和版本追踪；
运维动作缺乏统一入口：OTA 升级、固件管理、标签分类、激活出厂等操作分散，运营效率低、易出错。
产品定位：一个 SaaS 化的机器人全生命周期运营管理平台，统一设备接入、租户/平台隔离、素材审核下发、脚本配置、OTA 升级等能力，让运营方「一套平台管住成千上万台机器人」。
1、项目有哪些具体功能模块：
平台管理：以「平台」作为数据隔离维度，管理平台 ↔ 设备类型、平台 ↔ 用户、平台 ↔ 角色的绑定关系；
租户管理：租户创建（自动初始化管理员用户、字段 Schema、按归属平台启用设备类型、同步平台菜单权限）、状态切换、到期自动禁用、免审白名单、管理员初始化；
设备管理：设备自动注册与心跳建档、设备类型三级体系、动态字段 Schema、标签打标、设备工厂（激活 / 出厂）、租户转移、注销与恢复；
脚本与素材：脚本组 / 脚本版本管理、快照、素材上传与审核（AI 审核 + 人工审核 + 白名单直通）、下载控制、回收站；
OTA 升级：固件包上传、升级任务、升级审计；
遥操与智能体：遥操模式控制、设备绑定智能体；
标签系统：全局词表 + 业务表引用，标签候选与「实际引用」查询。
2、项目的主要功能描述：
平台面向机器人运营方，提供从「设备接入 → 建档 → 打标签 → 素材内容审核下发 → 脚本配置 → OTA 升级」的完整运营闭环，并通过「平台 + 租户」两级数据隔离保证多租户安全；设备报文走 MQTT 接入，以心跳为在线状态权威来源，结合 Redis 缓存与 PostgreSQL 持久化，支撑上千台规模的设备运营。
1、「我」负责哪些具体任务：
以下按仓库内实际涉及的核心模块整理，请按你个人的真实分工增删。
负责租户、平台、设备类型、字段 Schema 等核心后端模块的设计与开发，包括租户创建全链路（初始化管理员、菜单权限同步、按平台启用设备类型）、租户状态切换与到期禁用、免审白名单；
负责设备打标、标签系统（全局词表、业务引用、onlyUsed 租户隔离）的设计与落地；
负责设备缓存一致性方案（缓存淘汰、并发写覆盖）与数据库字段迁移（timestamptz、jsonb、标签列）的处理；
负责相关模块的单元测试编写与回归。
2、项目使用了哪些技术栈、架构，实现上亮点、难点：
技术栈：Java + Spring Boot / Spring Cloud（Nacos、Gateway、OAuth 2.0）、MyBatis-Plus、PostgreSQL（jsonb / timestamptz / text）、Redis、MinIO 对象存储、MQTT 设备接入、Protobuf + JSON 报文编解码、Flyway 数据库迁移、JUnit 5 + Mockito。
架构：微服务按域拆分（网关 / 认证 / 设备 / 运维管理 / 媒体 / AI 等）；多租户 SaaS，叠加「平台」作为额外数据隔离维度；动态字段 Schema 支撑不同设备类型的灵活表单。
亮点 / 难点（均为真实落地中踩过并解决的问题）：
心跳作为在线状态唯一权威来源：多类报文合并进同一条 Redis hash，批量回写落库，非心跳上报不写在线态；
两级数据隔离与权限收口：平台 + 租户两级过滤，运维端未登记路径默认「放行」的语义与租户端相反，需逐接口收口；
缓存一致性：写库前删缓存 + 延迟双删，TTL 随机抖动防雪崩；并发整行写覆盖导致的标签回退问题定位；
跨实例定时任务互斥：用 PostgreSQL 咨询锁
评论