让能力可见、可消费、可追踪
Phase 1 搭好了集群骨架，Phase 2 让集群"活"起来——定义能力注册表、建立跨层依赖关系、用三类新图可视化复杂的服务网络。上层项目消费下层能力，依赖可追溯、可分析。
核心目标
💡 Phase 2 的核心交付
能力注册表（按类型 + 两级）、跨层依赖编辑器、三类新图（服务依赖/部署拓扑/数据流）、Sankey 矩阵视图、项目内跨层上下文面板、能力版本管理。
📋 能力注册表
按类型分类（基础设施 + API 服务），两级粒度（系统 + 模块），支持版本管理。
🔗 依赖编辑器
上层项目消费下层能力（1 对 N），可视化编辑 + 人工确认。
📊 三类新图
服务依赖图、部署拓扑图、数据流图——一起设计、一起实现。
明确边界：本阶段不做
⚠️ 范围控制
| 不做的事 | 原因 | 推迟到 |
|---|---|---|
| 共享实体定义 | 需要先有能力依赖基础 | Phase 3 |
| 自动依赖检测 | 数据基础不具备（ref: 仅 3 处） | Phase 4+ |
| 集群模板 | 需要在有真实使用数据后设计 | Phase 4 |
| 影响分析 | 需要先有共享实体 | Phase 3 |
| 一键部署 | 超出原型阶段 | 远期 |
能力模型
能力类型
能力按提供方类型分为两大类：
🏗️ 基础设施能力
云基础设施层提供，通常无 UI，作为底层服务被全集群消费。
存储
CDN
数据库
缓存
消息队列
容器编排
🔌 API 服务能力
微应用层提供，以 API 接口形式对外暴露，可被上层业务系统调用。
用户认证
支付能力
消息通知
权限校验
两级能力粒度
能力分为系统级（分组容器）和模块级（可被单独消费的最小单元）：
// 两级能力结构
用户中心（系统级）
├── 用户认证（模块级） ← 可被上层单独消费
├── 用户画像（模块级） ← 可被上层单独消费
└── 权限校验（模块级） ← 可被上层单独消费
支付中心（系统级）
├── 支付能力（模块级）
├── 退款能力（模块级）
└── 对账能力（模块级）
能力数据结构
{
id: 'cap-user-auth',
name: '用户认证',
type: 'api_service', // infrastructure | api_service
level: 'module', // system | module
systemId: 'sys-user-center', // 所属系统（level=module 时）
provider: {
projectId: 'p-user', // 提供方项目
moduleId: 'm-auth' // 提供方模块
},
layerId: 'L3',
currentVersion: '2.0',
versions: [{ version, status, schema, changelog }],
schema: { // 能力契约（可选）
input: { 'loginType': 'enum', 'credential': 'string' },
output: { 'accessToken': 'string' }
}
}
依赖模型
上层项目直接消费下层能力（1 对 N 关系）：
{
id: 'dep-1',
consumer: { // 上层消费者
projectId: 'p-order',
moduleId: 'm-order-create'
},
capabilityId: 'cap-user-auth', // 被消费的模块级能力
type: 'invoke', // invoke | data | event
description: '下单前校验用户登录态',
detectedBy: 'manual'
}
依赖类型
| 类型 | 说明 | 视觉 |
|---|---|---|
invoke | 同步调用（HTTP/gRPC） | 实线 → |
data | 数据引用（读取共享实体） | 虚线 → |
event | 异步事件（消息队列） | 点线 → |
线框图（9 张）
1️⃣ 能力注册面板
集群工作台的新 Tab，展示所有已注册的能力，按类型分组。
集群工作台 · 能力 Tab
总览
分层架构
能力依赖
共享实体
文档
能力分类
🏗️ 基础设施能力 (5)
🔌 API 服务能力 (12)
+ 注册能力
🏗️ 基础设施能力
MySQL 数据库服务
云基础设施层 · 端口 3306 · 被 4 个项目消费
Redis 缓存服务
云基础设施层 · 端口 6379 · 被 3 个项目消费
Kafka 消息队列
云基础设施层 · 被 2 个项目消费
K8s 容器编排
云基础设施层 · 管理所有服务部署
2️⃣ 依赖编辑器
上层项目选择消费下层能力的交互界面。
编辑跨层依赖
编辑跨层依赖
用户认证
用户中心 · L3
支付能力
支付中心 · L3
消息通知
消息中心 · L3
权限校验
用户中心 · L3
3️⃣ 能力依赖矩阵
矩阵视图展示上层系统 × 下层能力的消费关系。
能力依赖矩阵
矩阵图
Sankey 图
| 上层系统 \ 下层能力 | 用户认证 | 支付能力 | 消息通知 | MySQL |
|---|---|---|---|---|
| 订单系统 | ✓ invoke | ✓ invoke | ✓ event | - |
| 客服系统 | ✓ data | - | ✓ event | ✓ data |
| 营销系统 | ✓ data | - | - | ✓ data |
4️⃣ 服务依赖图
ECharts Graph 拓扑图，展示服务间调用关系。
服务依赖图 · ECharts Graph
🖥️ 订单系统 ─────invoke────→ ⚙️ 用户中心 ────data────→ ⚙️ MySQL
│ │
├─────invoke────→ ⚙️ 支付中心 │
│ │
└─────event─────→ ⚙️ 消息中心 │
│
🖥️ 客服系统 ─────data──────→ ⚙️ 用户中心
│
🖥️ 营销系统 ─────data──────→ ⚙️ 用户中心
5️⃣ 部署拓扑图
K8s 风格的部署视图，展示 Namespace → Service → Pod 结构。
部署拓扑图 · K8s 风格
┌─ Namespace: order-system ─────────────────────────┐
│ [Service: order-api] │
│ ├── [Pod: order-api-7d9f4] 🟢 Running │
│ ├── [Pod: order-api-3a2b1] 🟢 Running │
│ └── [Pod: order-api-9c8e7] 🟢 Running │
└────────────────────────────────────────────────────┘
┌─ Namespace: user-service ─────────────────────────┐
│ [Service: user-api] │
│ ├── [Pod: user-api-4d5e6] 🟢 Running │
│ └── [Pod: user-api-1a2b3] 🟢 Running │
└────────────────────────────────────────────────────┘
┌─ Database ────────────────────────────────────────┐
│ [MySQL Primary]──→ [MySQL Replica] │
└────────────────────────────────────────────────────┘
6️⃣ 数据流图
ECharts Sankey 图，展示共享实体在项目间的流向。
数据流图 · ECharts Sankey
⚙️ MySQL ────write────→ ⚙️ 用户中心 ────read────→ ⚘ 订单系统
│ ⚘ 客服系统
│ ⚘ 营销系统
│
⚙️ Kafka ────event────→ ⚙️ 消息中心 ────notify─→ ⚘ 订单系统
⚘ 客服系统
7️⃣ Sankey 矩阵视图
左侧上层系统，右侧下层能力，中间流量 = 依赖数量。
Sankey 矩阵
上层系统 流量 下层能力
┌────────┐ ═══════ ┌────────┐
│订单系统 │═══╦═══════╡→ │用户认证 │
│ │ ║ │ │支付能力 │
│ │ ║ │ │消息通知 │
├────────┤ ║ │ └────────┘
│客服系统 │═══╬═══════╢→ │MySQL │
├────────┤ ║ │ └────────┘
│营销系统 │═══╩═══════╢→ │用户认证 │
└────────┘ │ └────────┘
8️⃣ 项目内跨层上下文
进入某个项目后，看到"我消费谁"+"谁消费我"。
项目详情 · 跨层上下文面板
总览
能力
API 契约
运行时
跨层上下文
文档
⬇️ 我消费的下层能力
用户认证 · 用户中心 · L3
被模块：订单创建 使用 · invoke
支付能力 · 支付中心 · L3
被模块：订单创建 使用 · invoke
消息通知 · 消息中心 · L3
被模块：订单状态变更 使用 · event
⬆️ 我的能力被谁消费
订单查询
被 客服系统 · 工单处理 消费
订单查询
被 营销系统 · 数据分析 消费
9️⃣ 能力版本管理
能力支持多版本共存，消费者绑定到特定版本。
能力版本管理
能力版本 · 用户认证
v2.0 stable · 2026-06-01 · 消费者：订单系统、客服系统
新增短信登录、微信登录；token 拆分为 access/refresh
v1.0 deprecated · 2025-01-15 · 无活跃消费者
三类新图详解
服务依赖图
| 维度 | 说明 |
|---|---|
| 数据源 | capabilities + dependencies + runtime |
| 图表类型 | ECharts Graph（力导向图） |
| 节点 | 项目/服务（大小 = 被依赖数） |
| 边 | 依赖关系（实线=invoke / 虚线=data / 点线=event） |
| 交互 | 点击节点 → 查看服务详情；点击边 → 查看依赖详情 |
部署拓扑图
| 维度 | 说明 |
|---|---|
| 数据源 | capabilities.runtime（镜像/端口/副本） |
| 图表类型 | 自定义 SVG（K8s 风格） |
| 层次 | Namespace → Service → Pod |
| 视觉 | 颜色 = 层（L1-4），状态 = 🟢健康 / 🔴异常 |
数据流图
| 维度 | 说明 |
|---|---|
| 数据源 | sharedEntities + dependencies（type=data） |
| 图表类型 | ECharts Sankey（桑基图） |
| 流向 | 左 → 右（写入方 → 读取方） |
| 宽度 | 流量 = 依赖该实体的项目数 |
任务清单（28 项）
📅 Week 1 · 能力注册（Day 1-5）
| # | 任务 | Day | 工作 | 依赖 |
|---|---|---|---|---|
| 1.1 | 能力类型定义（infrastructure / api_service） | D1 | 0.5 天 | - |
| 1.2 | 两级能力数据结构（system / module） | D1 | 0.5 天 | 1.1 |
| 1.3 | capability CRUD RPC（6 个） | D2-3 | 2 天 | 1.2 |
| 1.4 | 能力注册面板 UI | D4-5 | 2 天 | 1.3 |
📅 Week 2 · 依赖建模（Day 6-10）
| # | 任务 | Day | 工作 | 依赖 |
|---|---|---|---|---|
| 2.1 | dependency CRUD RPC | D6 | 1 天 | 1.3 |
| 2.2 | 依赖编辑器 UI | D7-8 | 2 天 | 2.1 |
| 2.3 | 依赖类型可视化（实线/虚线/点线） | D9 | 1 天 | 2.1 |
| 2.4 | 分层架构图（含依赖线） | D10 | 1 天 | 2.2 |
📅 Week 3 · 能力依赖矩阵（Day 11-15）
| # | 任务 | Day | 工作 | 依赖 |
|---|---|---|---|---|
| 3.1 | 能力依赖矩阵 UI | D11-12 | 2 天 | 2.4 |
| 3.2 | Sankey 矩阵图 UI | D13 | 1 天 | 3.1 |
| 3.3 | 矩阵 ↔ Sankey 切换 | D14 | 0.5 天 | 3.2 |
| 3.4 | 矩阵筛选/排序 | D15 | 0.5 天 | 3.3 |
📅 Week 4 · 三类新图（Day 16-20）
| # | 任务 | Day | 工作 | 依赖 |
|---|---|---|---|---|
| 4.1 | 服务依赖图（ECharts Graph） | D16-18 | 3 天 | 2.4 |
| 4.2 | 部署拓扑图（K8s SVG） | D19 | 1 天 | 4.1 |
| 4.3 | 数据流图（Sankey） | D20 | 1 天 | 4.1 |
📅 Week 5 · 上下文面板 + 版本管理（Day 21-25）
| # | 任务 | Day | 工作 | 依赖 |
|---|---|---|---|---|
| 5.1 | 项目内跨层上下文面板 | D21-23 | 3 天 | 4.1 |
| 5.2 | 能力版本管理 UI | D24-2 | 2 天 | 1.3 |
📅 Week 6 · 联调 & 打磨（Day 26-30）
| # | 任务 | Day | 工作 | 依赖 |
|---|---|---|---|---|
| 6.1 | 端到端测试 | D26-27 | 2 天 | 5.2 |
| 6.2 | UI 打磨 | D28 | 1 天 | 6.1 |
| 6.3 | 性能优化（大数据量） | D29 | 1 天 | 6.1 |
| 6.4 | 文档 & 演示 | D30 | 1 天 | 6.3 |
完成标准（Definition of Done）
✅ Phase 2 完成时，以下必须全部满足
| # | 验收项 | 验证方式 |
|---|---|---|
| 1 | 能力注册表可注册基础设施 + API 服务两类能力 | UI 检查 |
| 2 | 两级能力（系统 + 模块），模块级可独立消费 | 创建测试能力 |
| 3 | 依赖编辑器可创建/删除跨层依赖（1 对 N） | 创建测试依赖 |
| 4 | 依赖类型可视化正确（实线 invoke / 虚线 data / 点线 event） | UI 检查 |
| 5 | 分层架构图含动态跨层依赖线 | UI 检查 |
| 6 | 能力依赖矩阵正确展示上层 × 下层关系 | UI 检查 |
| 7 | Sankey 矩阵图正确展示能力依赖流量 | UI 检查 |
| 8 | 服务依赖图（ECharts Graph）渲染正确 | UI 检查 |
| 9 | 部署拓扑图（K8s SVG）展示运行时信息 | UI 检查 |
| 10 | 数据流图（Sankey）展示实体流向 | UI 检查 |
| 11 | 项目内跨层上下文面板显示"消费谁"+"被谁消费" | UI 检查 |
| 12 | 能力版本管理支持多版本共存 | 创建测试版本 |
| 13 | 至少 1 个测试集群含完整能力+依赖数据 | 测试数据 |
| 14 | 文档完成 | docs/ |
| 15 | 无 P0/P1 Bug 残留 | 端到端测试 |
风险与缓解
| 风险 | 概率 | 影响 | 缓解措施 |
|---|---|---|---|
| 能力粒度难以统一标准 | 中 | 中 | 提供推荐粒度模板，允许自定义调整 |
| 依赖数据初始为空 | 高 | 中 | 提供批量导入 + 引导创建 |
| ECharts Graph 性能（节点多时） | 低 | 中 | 虚拟滚动 + 分页加载 |
| 三类新图数据不足 | 中 | 低 | 用 mock 数据先展示，逐步接入真实数据 |