Hive 自有节点平台管理系统规划
本文基于当前 management/registry 与 management/registry-ui 的实现现状整理，目标不是再做一个通用第三方平台，而是把 Hive 演进成一套“自有设备节点接入、集中编排、按用户分发订阅”的管理系统。
一、先给结论
当前系统已经具备了一个可用的 节点注册中心 + 管理后台 + 基础订阅导出 雏形，但还不能算完整的“平台系统”。
它现在更偏向：
- 设备自动注册与节点资产台账
- 管理员查看和维护节点
- 导出全量订阅或公开分组订阅
- 基础运维与权限管理
它还缺少平台核心能力：
- 面向终端用户的账户、套餐、到期、流量、设备数控制
- 基于用户权限动态生成订阅
- 线路/入口/节点策略编排
- 节点真实在线状态与质量数据
- 用户侧门户、自助订阅、公告与工单
所以建议把后续工作拆成两条主线并行设计：
- 节点控制面：设备如何接入、上报、分组、上下线、打标签、健康检查
- 业务交付面：用户买到什么、能看见哪些线路、如何生成订阅、如何限制使用
二、当前已经有的能力
1. 节点侧与注册中心
- 节点可以通过
POST /nodes/register幂等注册自身信息 - 已保存节点基础字段：
mac、hostname、cf_url、tunnel_id、tailscale_ip、easytier_ip、frp_port、xray_uuid、location、note - 支持节点列表、节点详情、节点编辑、节点删除
- 节点注册时会自动写
registered_at、last_seen - 删除节点时会尝试同步移除 UFW 放行的 FRP 端口
2. 订阅能力
- 已支持全量 VLESS 订阅导出
- 已支持全量 Clash/Mihomo YAML 导出
- 已支持“订阅分组”模型：一个分组绑定多台节点
- 已支持公开订阅链接
GET /s/{token} - 节点名展示已经能使用
location+note+hostname
3. 管理后台
- 已有登录、登出、当前用户信息接口
- 已有用户管理、角色管理、权限管理、审计日志
- 已有 Dashboard、节点列表、节点详情、订阅页、用户页、角色页、审计页
- 前后端 OpenAPI 已打通，UI 已不是纯静态页面
4. 运维辅助
- 已支持 Prometheus targets 导出
- 已支持标签打印页
- 已有比较完整的部署文档、provision 文档、节点运维文档
三、当前系统的边界
当前系统本质上只有两层模型：
- 节点
- 管理员
订阅虽然已经存在，但它还是“管理员视角的节点清单导出”，不是“用户视角的线路交付”。
这意味着现在的订阅能力更像：
- 我把哪些节点塞进一个分组
- 然后生成一个公开链接给别人用
而不是：
- 某个用户买了什么套餐
- 这个套餐可以访问哪些线路
- 这个用户的订阅何时过期
- 是否限制设备数 / 流量 / 速率
- 他的订阅是否需要单独禁用或重置
四、离“平台系统”还缺哪些核心能力
1. 用户与套餐域模型缺失
当前没有下面这些关键对象：
- 终端用户
- 套餐 / 产品
- 订单 / 开通记录
- 到期时间
- 流量额度与重置周期
- 最大设备数
- 用户级订阅令牌
- 用户级禁用 / 封禁状态
这是最核心的缺口。没有这层，系统只能给管理员发全量或分组订阅，不能运营真实用户。
2. 节点控制面还太薄
当前节点模型更像静态资产表，还不是动态控制面。
缺少的能力包括：
- 心跳上报接口
- 节点真实在线状态判定
- 节点出口 IP / 国家 / ASN / 带宽信息
- 节点版本信息（镜像版本、xray 版本、配置版本）
- 节点负载、延迟、丢包、拨测结果
- 节点启用 / 禁用 / 排水（drain）状态
- 节点标签、权重、容量、优先级
- 节点所属入口、线路、区域的归属关系
尤其要注意：现在的 last_seen 主要依赖注册和管理更新，并不是可靠心跳。
3. 线路编排模型缺失
平台不是直接把“节点列表”发给用户，而是把“线路”发给用户。
建议补齐以下对象：
- 区域
region - 线路
line - 入口
inbound - 节点-线路映射
line_nodes - 线路策略：权重、优先级、测速策略、回退策略
这样才能表达：
- 日本家宽
- 香港优化
- 新加坡低倍率
- 美国流媒体
- 仅高级套餐可见
当前的 subscription_groups 可以保留，但更适合逐步演进为“线路分组”的过渡实现，而不是最终业务模型。
4. 用户级订阅分发缺失
当前订阅导出是：
- 全量订阅
- 公开分组订阅
缺少的是：
- 用户专属订阅链接
- 用户专属 token 重置
- 到期后自动失效
- 按套餐筛选节点
- 按客户端生成不同格式
- 按平台差异输出不同配置项
如果不补这一层，后面用户数量一上来，分组 token 会非常难管。
5. 客户端兼容能力不足
当前只覆盖：
- VLESS 链接
- Clash/Mihomo YAML
后面至少要规划：
- sing-box
- v2rayN / v2rayNG
- Shadowrocket
- Surge
- Hiddify
不是所有客户端都吃同一份配置，最终要做“订阅模板”。
6. 风控、审计、运营侧还不够
当前已有基础 RBAC 和审计，但还不够支撑正式平台运营。
还需要：
- 用户操作审计
- 订阅访问日志
- token 使用日志
- 登录失败限制、频率限制
- 节点变更审计
- 分组 / 线路变更审计
- 管理操作回滚能力
7. 用户侧产品界面不存在
当前 registry-ui 是管理员后台，不是用户门户。
还缺：
- 用户注册 / 登录
- 用户首页
- 套餐与到期信息
- 一键复制订阅
- 使用说明
- 公告页
- 工单 / 联系支持
五、建议的新域模型
建议后续按下面的核心对象扩展，而不是继续把所有逻辑堆在 nodes 和 subscription_groups 上。
节点控制面
nodes：设备节点主表，保留现有基础字段node_heartbeats：节点心跳与运行快照node_tags：节点标签node_metrics：延迟、丢包、出口信息、健康状态inbounds：入口定义，描述域名、协议、传输层参数lines：面向用户展示的线路line_nodes：线路与节点的绑定关系
业务交付面
customers：终端用户plans：套餐customer_subscriptions：用户已开通的套餐实例subscription_tokens：用户订阅令牌plan_lines：套餐可访问线路device_bindings：设备数限制与设备记录usage_rollups：流量统计与周期汇总
运营与支撑
announcements：公告tickets：工单operation_logs：比现有 audit 更细的领域日志
六、推荐路线图
Phase 0：把现在的 Registry 先做稳
目标：让当前系统从“资产表”升级成“可依赖的节点控制台”。
建议实现：
- 新增节点心跳接口，例如
POST /nodes/{mac}/heartbeat - 心跳上报运行状态、版本、出口 IP、延迟、负载摘要
- 节点增加字段：
status、enabled、drain、weight、tags - 节点列表支持按状态、地区、标签筛选
- 订阅分组的增删改操作补审计日志
- 管理员认证与设备认证分离，不再共享同一套简化口令思路
- 统一修正文档与实现中的遗留描述
完成标志：
- 不用猜测节点是否在线
- 节点故障、失联、停用、排水可视化
- 现有订阅分组可以被稳定维护
Phase 1：建立“线路”模型
目标：从“节点导出”切到“线路交付”。
建议实现：
- 新增
lines、line_nodes、inbounds - 节点可属于多个线路
- 线路可设置名称、区域、展示顺序、权重、可见性
- 支持线路启用 / 禁用
- 订阅从“遍历所有节点”改为“遍历用户可见线路”
- 前端新增线路管理页
完成标志：
- 运营上可以说“给用户开日本、香港、美国线路”
- 不再直接暴露底层节点分组给业务层
Phase 2：补齐用户、套餐、订阅授权
目标：让系统第一次真正具备“平台”业务能力。
建议实现：
- 新增终端用户体系
- 新增套餐、套餐周期、到期时间
- 新增套餐可访问线路映射
- 新增用户专属订阅 token
- 用户订阅链接支持重置、禁用、过期
- 支持设备数限制
- 支持倍率、流量额度、重置周期
完成标志：
- 每个用户看到的订阅内容都不同
- 线路权限和套餐绑定
- 过期用户自动失效
Phase 3：做用户门户与客户端适配
目标：完成基本可运营闭环。
建议实现：
- 用户登录 / 控制台页面
- 订阅复制、导入说明、客户端教程
- 公告与通知
- 多格式订阅模板
- 按客户端类型生成差异化配置
完成标志：
- 用户不需要管理员手工发链接
- 前台可以独立服务用户
Phase 4：再决定是否做商业化闭环
如果你只是做内部或小范围定向分发，这一阶段可以后置。
如果要做完整平台运营，再补：
- 订单
- 支付回调
- 优惠码
- 邀请返利
- 工单
- 风控与封禁
七、建议的最小可行版本（MVP）
如果你希望最快做出“能用的平台版”，我建议第一批只做下面 6 件事：
- 节点心跳与真实在线状态
- 线路模型
lines + line_nodes - 终端用户与套餐
- 套餐可访问线路映射
- 用户专属订阅 token
- 用户门户里的“我的订阅”
做到这一步，系统就已经从“节点管理后台”升级为“可交付的自有节点平台”。
八、对当前代码库的直接建议
后端 management/registry
- 保留现有
nodes、users、roles、subscription_groups - 不建议继续把“平台业务”直接叠加在
subscription_groups - 先补心跳、状态、线路、用户授权 4 条主链路
- 订阅生成逻辑要从“查全部节点”改成“查用户授权的线路及节点”
前端 management/registry-ui
- 现有页面适合作为管理员后台继续扩展
- 后续新增页面优先级建议是：
lines、customers、plans、subscriptions、node-health - 用户门户建议单独做，不要和管理员后台强耦合到同一导航模型里
九、推荐的执行顺序
如果按工程效率排序，我建议这样做：
- 先整理数据模型和接口，不急着先堆 UI
- 先把节点心跳与线路模型补上
- 再做用户、套餐、订阅授权
- 最后补用户门户和商业化能力
原因很简单：
- 没有心跳，节点状态不可靠
- 没有线路模型，套餐授权没法表达
- 没有用户授权，订阅系统只是分组导出
十、下一步建议
如果继续往下做，最合理的下一步不是直接改页面，而是先产出一版更细的设计稿，至少包括：
- 数据库 ER 图
- 新增表结构草案
- API 列表
- 管理端页面结构
- 用户端页面结构
- 订阅生成规则
这部分我可以继续直接帮你做，并且下一轮可以进入“可实现级别”的设计，把每个表、每个接口、每个页面拆到开发任务单。