# 星尘（Stardust）产品分析文档 > 版本：v1.0 | 日期：2026-07-17 | 作者：产品通（产品管理专家） > 配套文档：[星尘交互设计文档](/NewLife/Stardust/Blob/master/Doc/产品文档/星尘交互设计文档.md) ｜ 原型见 `原型/` 目录 > 数据来源：仓库 `Stardust/Doc/功能清单.md`、`需求文档.md`、`架构设计.md` 及 `Stardust.Web` 代码探查 --- ## 0. 文档目的 本分析文档是星尘交互重设计的**事实基础**。它回答三个问题： 1. 星尘到底包含哪些功能？（功能清单） 2. 这些功能之间如何相互依赖？（依赖分析）→ 这是"渐进式展开"的**唯一科学依据** 3. 当前交互有什么问题，重设计要解决什么？（现状与痛点） 完整的逐条功能清单（117 项，含实现状态）见 [功能清单.md](/NewLife/Stardust/Blob/master/Doc/产品文档/../../Stardust/Doc/功能清单.md)，本文做收敛与结构化，不重复罗列。 --- ## 1. 产品定位 星尘是**轻量级分布式服务框架**，为应用服务提供"集群管理 + 配置中心 + APM 监控 + 远程发布 + 服务治理"一站式能力。 > 隐喻：应用是"尘埃"，计算机节点是"星星"，星星与尘埃构成浩瀚星空，即为星尘。 | 工程 | 定位 | 部署 | |------|------|------| | **StarServer** | 服务平台后端（API/配置/注册/发布/指标聚合） | 中心 1~N 节点 | | **StarWeb** | 管理与可视化（基于 NewLife.Cube） | 中心 1 节点 | | **StarAgent** | 节点代理（进程守护/远程发布/监控采集/Web 面板） | 每台服务器 1 实例 | | **StarGateway** | 流量网关（反向代理/动态路由/负载均衡） | 按需 | | **Stardust（核心库）** | 客户端 SDK（配置/注册/追踪/日志上报） | 与业务同进程 | | **DeployAgent** | 部署代理（构建与分发） | 按需（编译节点） | **核心卖点（来自愿景）**：一键接入分布式、超轻量无侵入、全平台覆盖、自带运维体系、一体化管理。 --- ## 2. 功能清单（结构化收敛） 功能共 **12 大模块 / 117 项能力**，完成率 99%（116/117）。按"用户价值层次"重新归组如下（编码沿用 [功能清单.md](/NewLife/Stardust/Blob/master/Doc/产品文档/../../Stardust/Doc/功能清单.md)）： ### 2.1 底座层（让系统能跑起来） | 模块 | 能力要点 | 说明 | |------|----------|------| | **M1 核心 SDK** | StarClient/AppClient、配置拉取、注册发现、StarTracer 调用追踪、性能监控、日志上报、ASP.NET 中间件、DDNS、事件总线 | 客户端库，被几乎所有模块消费 | | **M2 服务端基础** | 健康检测、接口列表、数据保留清理、.NET 运行时同步、分表、上行链路、Apollo 集成、远程命令安全 | 服务端基础设施，用户几乎无感 | | **M3 平台管理** | 星系项目（多租户隔离）、项目用户、StarServer 设置、OAuth 授权 | 其他模块的"项目"上下文来源 | ### 2.2 接入层（数据产生的源头） | 模块 | 能力要点 | 说明 | |------|----------|------| | **M5 节点管理** | 节点注册登录/心跳/在线、历史/数据/版本/统计/规则、命令下发、升级、会话、定位、框架管理、**防火墙、远程部署、DDNS、进程管理**、StarAgent Web 面板 | "机器"的托管，18 项能力最多 | | **M4 应用管理** | 应用注册登录/心跳/在线、历史、命令下发、消费关系、客户端日志、令牌、会话、**性能查看** | "服务"的托管，10 项 | ### 2.3 观测层（看见系统状态） | 模块 | 能力要点 | 说明 | |------|----------|------| | **M6 配置中心** | 配置拉取/设置、历史、数据管理、Scope 规则、在线状态、HTTP 提供者、自动注册 | 热更新配置 | | **M7 注册中心** | 服务注册/发现、服务信息、消费方、健康检查、Web 管理 | 服务治理 | | **M8 监控/APM** | 埋点上报（含压缩）、追踪统计、应用/埋点/分钟级统计、采样/追踪数据、追踪规则、**告警组/历史/记录/服务**、应用跟踪器、调用链可视化、接入 API | 17 项，系统资源占用大户 | | **M9 日志中心** | 日志接收、查询、客户端日志管理 | 集中查日志 | ### 2.4 运维层（对系统做操作） | 模块 | 能力要点 | 说明 | |------|----------|------| | **M10 远程发布** | 部署集/节点/版本/历史、流水线（管理/步骤/运行）、编译节点、部署资源、SSL、附件、Webhook、产品版本/发布包、dotNet 包、部署服务/客户端、多部署模式、**应用包规范、DeployAgent、分布式文件存储** | 21 项，最复杂的操作域 | ### 2.5 扩展层（规模变大才需要） | 模块 | 能力要点 | 说明 | |------|----------|------| | **M11 网关管理** | 配置下发、路由/集群/节点/证书管理、StarGateway 集成 | 按需 | | **M12 数据中间件** | Redis 节点/数据/消息队列、MySQL 节点/数据、代理服务 | 相对独立，可选 | > **关键观察**：能力数量呈"金字塔"分布——接入层（M4/M5，28 项）与运维层（M10，21 项）是主体，扩展层（M11/M12，12 项）是长尾。**多数用户只会用到顶部两层**，这正是渐进式披露的机会。 --- ## 3. 功能依赖关系分析 > 这是本分析的**核心**。依赖关系决定了"什么必须先有，什么可以后说"，直接驱动渐进式交互的展开顺序。 ### 3.1 工程依赖（已有，来自架构设计） ``` Stardust(核心库) ← Stardust.Extensions ↑ Stardust.Data ← Stardust.Server(服务端API) ← Stardust.Web(管理界面) StarAgent / StarGateway / DeployAgent → 各自引用 SDK，经 API 与 StarServer 交互 ``` ### 3.2 功能依赖分层（本文推导） 按"数据/流程前置依赖"将 12 模块划分为 **5 层**，下层是上层的必需前提： ``` Layer 0 底座层 M1 SDK · M2 基础 · M3 平台(项目隔离) │ （所有模块的消费方 / 上下文来源） ▼ Layer 1 接入层 M5 节点管理 · M4 应用管理 │ （数据产生源头：机器 + 服务） ▼ Layer 2 观测层 M6 配置 · M7 注册 · M8 监控 · M9 日志 │ （依赖 M4/M5 的数据才能产生价值） ▼ Layer 3 运维层 M10 远程发布 ＋ M5 高级子能力(防火墙/DDNS/远程部署/进程/面板) │ （依赖接入层做"动作"，依赖观测层做"判断"） ▼ Layer 4 扩展层 M11 网关 · M12 数据中间件 （按需启用，依赖前序服务/节点） ``` ### 3.3 关键依赖边（强依赖，必须前置） | 依赖方 | 依赖前驱 | 依赖性质 | 渐进式含义 | |--------|----------|----------|------------| | M4 应用管理 | M1 SDK（应用需引用 SDK 才能登录）、M3 项目 | 数据/身份 | 应用必须在"项目"内、且接入 SDK 后才出现 | | M5 节点管理 | M1 SDK（StarAgent 内置）、M2 上行链路 | 数据/通信 | 节点来自 StarAgent 心跳 | | M6 配置中心 | M4 应用（配置按应用作用域） | 数据主体 | 没应用就没配置可管 | | M7 注册中心 | M4 应用（服务由应用注册） | 数据主体 | 同上 | | M8 监控/APM | M4 应用 + M5 节点（指标源）+ M1 StarTracer | 数据主体 | 应用/节点接入后自动产生监控数据 | | M9 日志中心 | M4 应用 + M1 日志上报 | 数据主体 | 同上 | | M10 远程发布 | M5 节点（部署目标）+ M4 应用 + M6 配置 | 动作目标 | 部署动作必须落到"已接入的节点/应用" | | M10-20 DeployAgent | M10 流水线 | 支撑组件 | 编译节点是流水线的执行体 | | M10-21 文件存储 | M10 附件分发 | 支撑组件 | 多节点分发依赖它 | | M11 网关 | M4/M7 服务（路由后端） | 动作目标 | 网关路由指向已注册服务 | | M12 数据中间件 | M2 基础（连接代理） | 弱依赖 | 较独立，可最后启用 | ### 3.4 接入顺序依赖（Onboarding Chain） 这是"渐进式展开"的**主干脚本**——用户第一次用星尘，应按此顺序被引导： ``` ① 建项目 (M3) → 地基：先有"星系" ↓ ② 接入节点 (M5-1/M5-15) → 先有"机器"：装 StarAgent（可远程部署） ↓ ③ 接入应用 (M4-1/M1) → 再有"服务"：应用引用 SDK 注册 ↓ ④ 看见价值 (M8/M9) → 自动有监控+日志，立刻看到好处（零额外操作） ↓ ⑤ 配置治理 (M6/M7) → 按需调配置、做服务发现 ↓ ⑥ 发布运维 (M10) → 要上线/迭代才用远程发布 ↓ ⑦ 扩展 (M11/M12) → 规模变大才上网关/数据中间件 ``` > **核心洞察**：第④步"看见价值"是**零操作自动获得**的——只要接入了节点和应用，监控与日志自然产生。这意味着渐进式设计可以在"接入"完成后立刻给用户正向反馈，极大降低早期弃用率。 ### 3.5 StarAgent 端内聚（另一套小型渐进链） StarAgent 自带 Web 面板（M5-18，7 tab 平铺：状态/子服务/控制/配置/星尘设置/日志/看门狗）。其内部也存在依赖：状态(总览) → 子服务(进程) → 控制(启停) → 配置 → 看门狗(守护)。可独立做"状态优先、其余折叠"的渐进式。 --- ## 4. 用户与角色 | 角色 | 关注层 | 最高频功能 | 渐进式首屏应呈现 | |------|--------|-----------|------------------| | **平台管理员** | L0~L4 | M3 项目、M2 设置、M11/M12 | 全局健康 + 项目切换 | | **运维（SRE）** | L1~L3 | M5 节点、M10 发布、M8 告警 | 节点状态 + 待处理告警 + 一键部署 | | **开发** | L1~L2 | M4 应用、M6 配置、M8 追踪、M9 日志 | 我的应用 + 调用链 + 日志 | | **技术负责人/老板** | 跨层 | 概览、成本、健康 | 一屏看板（节点数/应用数/告警数/部署次数） | --- ## 5. 当前交互现状与痛点 基于 `Stardust.Web` 代码实际探查（非文档推测）： **现状** - 导航由 NewLife.Cube 的 Area 自动注册：`[DisplayName]`+`[Menu(排序,可见)]` 决定菜单项。 - 共 **9 个 Area**：Platform(999)、Nodes(888)、Redis(887)、Registry(777)、Configs(666)、Deployment(555)、Monitors(444)、Gateway、MySql。 - **全部平铺、左侧导航两层结构且完全展开**；网关/MySql 因 Area 缺 `[Menu]` 被平铺成顶层入口。 - **无首页/概览 Dashboard**（无 Home/Dashboard Controller），进入即 Cube 默认欢迎页 + 功能菜单。 - **无新手引导、无折叠、无按需展开、无角色区分**。 - StarAgent StarPanel：7 个 tab 全部平铺切换。 **痛点（重设计要解决的）** 1. **首屏过载**：新手一进来面对 9~12 个平级模块，不知道先点哪个，认知负荷高。 2. **价值延迟**：监控/日志这种"接入即获得"的高价值能力，被埋在 12 模块中间，没被优先呈现。 3. **进阶与核心同权**：防火墙、DDNS、网关、Redis 浏览等低频长尾功能，与节点/应用/监控等核心功能同等曝光。 4. **无上下文**：缺少"我刚接入了什么"的连续性，每次进入都从零开始看菜单。 5. **角色无差异**：管理员、开发、运维看到完全一样的界面。 --- ## 6. 渐进式交互设计原则（Progressive Disclosure） > 核心约束（用户明确要求）：**每次只呈现用户最需要的功能**。 据此确立 5 条原则，三套方案均须遵守： 1. **分层展开**：按 §3.2 的 5 层模型，未满足前置依赖的功能**不主动暴露**（或折叠为"待解锁"）。 2. **首屏即价值**：进入后第一屏只给"当前最该看的东西"——接入进度 / 异常告警 / 关键指标，而非功能菜单。 3. **完成即解锁**：用户完成"接入节点""接入应用"后，相关观测/治理功能才从折叠态展开。 4. **异常优先**：有离线节点、触发告警、部署失败时，这些"需要动作"的项**上浮到最前**，其余下沉。 5. **可深度展开**：进阶/长尾能力（防火墙/DDNS/网关/数据中间件）默认收起，提供"更多/高级"入口按需展开。 --- ## 7. 设计目标与北极星指标 | 类型 | 指标 | 基线（假设） | 目标 | |------|------|--------------|------| | **北极星** | 新项目 7 日内完成"节点+应用+监控"接入率 | 低（当前无引导） | ≥ 70% | | 驱动 | 首次进入后 5 分钟内触达监控页的比例 | 未知 | ≥ 60% | | 驱动 | 首屏到首个"有价值动作"（查看监控/处理告警）的步数 | 多（翻菜单） | ≤ 2 步 | | 健康 | 高级功能误触率（点开即退出） | 高 | 下降 50% | | 健康 | 新用户 30 日留存 | 低 | 提升 30% | > 指标设计遵循"可观测、可归因、有基线目标"。当前无埋点基线，上线后需以 StarWeb 自身接入 M8/M9 来采集真实数据。 --- ## 8. 交付物清单 | 文件 | 内容 | |------|------| | `星尘产品分析文档.md`（本文） | 功能清单 + 依赖分析 + 现状痛点 | | `星尘交互设计文档.md` | 3 套渐进式方案 + 对比 + 落地建议 | | `原型/方案A-向导式渐进.html` | 方案 A 可交互原型 | | `原型/方案B-场景式渐进.html` | 方案 B 可交互原型 | | `原型/方案C-角色式渐进.html` | 方案 C 可交互原型 | --- *下一步：见 [星尘交互设计文档](/NewLife/Stardust/Blob/master/Doc/产品文档/星尘交互设计文档.md)，进入三套方案设计与原型。*