Scope Definition: TiDB Cloud DBaaS Mono-Repo

项目范围定义

Date: 2026-03-01
Version: 1.0
Status: Scope Finalized

Executive Summary

本项目交付物： TiDB Cloud DBaaS 平台的完整 mono-repo

范围边界：

• ✅ 包含： TiDB Cloud 从云、部署、管控、监控、O11y、交付的全链路
• ✅ 包含： TiDB/TiKV/PD/TiFlash 核心数据库（云相关）
• ❌ 排除： PingCAP 组织与 TiDB Cloud 无关的项目

核心原则： 以 TiDB Cloud 产品为中心，不是以 PingCAP 组织为中心。

In Scope (纳入范围)

1. 核心数据库 (Core Database)

✅ TiDB
   - 计算层 (SQL Layer)
   - 优化器 (Optimizer)
   - 执行器 (Executor)
   - 存储引擎接口 (KV Interface)

✅ TiKV
   - 分布式 KV 存储
   - Raft 共识
   - 事务处理

✅ PD (Placement Driver)
   - 集群管理
   - 调度
   - 元数据管理

✅ TiFlash
   - 列式存储
   - 实时分析

✅ 生态组件
   - TiCDC (变更数据捕获)
   - TiDB-Binlog
   - DM (数据迁移)

理由： 这些是 TiDB Cloud 的核心交付物，必须纳入 mono-repo 以实现端到端优化。

2. 云平台基础设施 (Cloud Platform)

✅ 云资源管理
   - 多云抽象层 (AWS/GCP/Azure/阿里云)
   - 计算资源管理 (EC2/GCE/VM)
   - 存储资源管理 (EBS/GCS/S3)
   - 网络资源管理 (VPC/Security Group)

✅ 集群部署
   - TiDB Operator (Kubernetes)
   - 自动化部署工具
   - 配置管理
   - 版本管理

✅ 管控服务 (Control Plane)
   - 集群生命周期管理
   - 实例管理
   - 备份恢复
   - 扩缩容
   - 升级管理

✅ 监控与可观测性 (Monitoring & O11y)
   - 指标收集 (Metrics)
   - 日志聚合 (Logging)
   - 链路追踪 (Tracing)
   - 告警系统
   - Dashboard (Grafana/自研)

✅ 交付与运维 (Delivery & Operations)
   - CI/CD 流水线
   - 自动化测试
   - 发布管理
   - 运维工具
   - 事故响应工具

理由： 这些是 TiDB Cloud DBaaS 的核心竞争力，必须纳入 mono-repo 以实现端到端自动化。

3. 云原生特性 (Cloud-Native Features)

✅ 弹性伸缩
   - 自动扩缩容
   - 资源调度优化
   - 成本优化

✅ 高可用
   - 多可用区部署
   - 跨区域复制
   - 故障转移

✅ 安全合规
   - 身份认证 (IAM 集成)
   - 访问控制 (RBAC)
   - 数据加密
   - 审计日志
   - 合规认证 (SOC2/GDPR 等)

✅ 多租户
   - 资源隔离
   - 配额管理
   - 计费计量

理由： 这些是 DBaaS 产品的差异化特性，需要跨组件协同优化。

4. 开发者工具 (Developer Tools)

✅ SDK 与客户端
   - TiDB Vector SDK (Python/Go/Java)
   - 驱动 (MySQL Protocol)
   - ORM 集成

✅ 管理工具
   - CLI 工具
   - Web Console
   - API Gateway

✅ 迁移工具
   - 数据迁移 (DM)
   -  schema 迁移
   - 增量同步

理由： 这些是用户体验的关键部分，需要与后端协同优化。

Out of Scope (排除范围)

1. PingCAP 组织内与 TiDB Cloud 无关的项目

❌ OSS Insight
   - 原因：独立 OSS 分析平台，不是 TiDB Cloud 核心功能
   - 处理：保持独立 repo

❌ AutoFlow / Graph RAG
   - 原因：实验性 AI 项目，不是 TiDB Cloud 核心功能
   - 处理：保持独立 repo

❌ 纯内部工具（与 TiDB Cloud 无关）
   - 原因：不服务 TiDB Cloud 客户
   - 处理：评估后决定（可能归档）

❌ 市场/网站/文档（非技术文档）
   - 原因：不是研发代码
   - 处理：保持独立系统

2. 第三方 Fork（评估后决定）

⚠️ Tantivy (搜索)
   - 评估：如果 TiDB Cloud 强依赖，保留；否则用上
   - 决策：待评估

⚠️ Sarama (Kafka Client)
   - 评估：如果 TiCDC 强依赖，保留；否则用上游
   - 决策：待评估

⚠️ 其他 Fork
   - 评估：是否有 TiDB Cloud 特定修改
   - 决策：有修改→保留；无修改→用上

原则： 只保留 TiDB Cloud 有定制修改的 fork，纯 fork 回归上游。

3. 已废弃/低维护项目

❌ 超过 1 年无活跃维护
❌ 无生产使用
❌ 功能被其他项目替代

处理：归档或删除，不纳入 mono-repo

Repo 分类与优先级

P0: 核心产品 (Core Products)

必须第一批迁移

小计： ~1.75 GB

P1: 云平台 (Cloud Platform)

必须第二批迁移

小计： ~800 MB

P2: 工具与 SDK (Tools & SDKs)

必须第三批迁移

小计： ~521 MB

P3: 评估后决定 (Evaluate)

需要评估是否纳入

预计规模

纳入 Repo 统计

对比： 之前估算 400 repos / 39 GB → 现在 21 repos / 3.1 GB

结论： 范围聚焦后，规模减少 90%，可在 2 个月内完成迁移。

边界案例处理

案例 1: TiDB 社区版 vs 云版本

场景：
- TiDB 有社区版（开源）和云版本（TiDB Cloud 特性）
- 云版本有额外特性（Serverless、弹性伸缩等）

处理：
✅ 统一代码库（mono-repo）
✅ 用 Feature Flag 区分社区版和云版本
✅ 云版本特性在 mono-repo 内开发
✅ 社区版从 mono-repo 构建（去除云特性）

好处：
- 代码复用最大化
- 云版本特性可以快速迭代
- 社区版仍然可以独立发布

案例 2: 内部工具 vs 客户工具

场景：
- 有些工具只供内部运维使用
- 有些工具客户直接使用

处理：
✅ 都纳入 mono-repo
✅ 用权限控制访问（内部工具限制访问）
✅ 内部工具也遵循相同质量标准

好处：
- 内部工具也能受益于 AI 优化
- 统一工具链
- 内部/客户工具可以互相借鉴

案例 3: 第三方依赖

场景：
- TiDB Cloud 依赖大量第三方库
- 有些是 fork 后修改的

处理：
✅ 有 TiDB Cloud 特定修改的 fork → 纳入 mono-repo (libs/)
✅ 无修改的依赖 → 使用上游（通过包管理）
✅ 定期评估 fork，能回归上游的回归

好处：
- 减少维护负担
- 聚焦核心差异
- 保持与社区同步

迁移策略

Phase 1: P0 核心产品 (Week 1-3)

目标：TiDB/TiKV/PD/TiFlash/TiCDC/tidb-operator

行动：
1. 创建 mono-repo 骨架
2. 迁移 6 个核心 repo
3. 建立统一构建系统
4. 验证端到端构建

成功标准：
- 6 个 repo 在 mono-repo 中可构建
- 测试通过率 100%
- 构建时间 <1 小时

Phase 2: P1 云平台 (Week 4-6)

目标：Control Plane, Deploy, Monitoring, O11y, Delivery, Security

行动：
1. 迁移 6 个云平台 repo
2. 建立统一 API Gateway
3. 建立统一监控体系
4. 验证端到端部署

成功标准：
- 云平台可部署 TiDB Cloud
- 监控告警正常
- 部署自动化率 >90%

Phase 3: P2 工具与 SDK (Week 7-8)

目标：Dashboard, tiup, docs, SDKs

行动：
1. 迁移 5 个工具 repo
2. 统一文档体系
3. 统一 SDK 发布流程

成功标准：
- 工具可正常使用
- 文档完整
- SDK 可正常发布

Phase 4: AI 赋能 (Week 9+)

目标：部署 AI 基础设施，开始 AI 闭环

行动：
1. 部署 OpenClaw + Agents
2. AI 主导开发/测试/部署
3. AI 主导监控/运维

成功标准：
- AI 完成功能 >20%
- AI 部署变更 >10%
- 人类 routine 工作 <30%

治理模式

代码所有权

mono-repo/
├── products/
│   ├── tidb/           @tidb-core-team
│   ├── tikv/           @tikv-core-team
│   ├── pd/             @pd-team
│   └── tiflash/        @tiflash-team
├── platform/
│   ├── control-plane/  @cloud-platform-team
│   ├── deploy/         @cloud-deploy-team
│   └── monitoring/     @cloud-monitoring-team
├── tools/
│   ├── dashboard/      @dashboard-team
│   └── tiup/           @tooling-team
└── libs/
    └── ...             @platform-architects

审批权限

决策记录

2026-03-01: 范围聚焦决策

决策： 聚焦 TiDB Cloud DBaaS，排除无关项目

理由：

1. 400 repos / 39 GB 规模太大，迁移周期过长（3-4 个月）
2. 聚焦 TiDB Cloud 可快速交付价值（2 个月）
3. 无关项目（OSS Insight、AutoFlow）会分散注意力
4. 聚焦后可验证 AI 驱动 mono-repo 的可行性

影响：

• 迁移规模：400 repos → ~21 repos
• 迁移时间：3-4 个月 → 5-8 周
• 成本：~$500 → ~$50
• 风险：大幅降低

后续：

• 如果 TiDB Cloud mono-repo 成功，可扩展到其他产品线
• 排除的项目保持独立，未来可评估是否并入

结论

范围聚焦后：

✅ 更清晰的目标 — TiDB Cloud DBaaS 全链路
✅ 更小的规模 — 21 repos / 3.1 GB（vs 400 / 39GB）
✅ 更快的交付 — 5-8 周（vs 3-4 个月）
✅ 更低的成本 — ~$50（vs ~$500）
✅ 更低的风险 — 聚焦核心，减少复杂度

建议： 立即按此范围启动迁移，快速验证 AI 驱动 mono-repo 的可行性。

Scope Definition: TiDB Cloud DBaaS Mono-Repo
2026-03-01 | Large-scale Agentic Engineering Team