代码仓库架构概览 (Repository Architecture Overview)
选择代码仓库策略是多服务平台的基础决策。选择 Monorepo（单体仓库）还是 Polyrepo（多仓库）取决于团队规模、发布频率以及组织需求。
比较：Monorepo vs Polyrepo
| 维度 | Monorepo | Polyrepo |
|---|---|---|
| 代码共享 | 跨应用原生引用。 | 需要发布到注册表或使用 Git 子模块。 |
| 原子性变更 | 在单个 PR 中进行跨应用变更。 | 需要多个 PR 并进行协调。 |
| 入职流程 | 单个 git clone 指令。 | 需要克隆多个代码仓库。 |
| CI/CD 复杂性 | 高（需要路径过滤）。 | 低（标准的单仓库流水线）。 |
| 权限控制 | 整个仓库级别。 | 每个服务细粒度控制。 |
Monorepo 策略
Monorepo 将所有服务存储在 单个 Git 仓库 中。
优点
- 原子性变更：在一次提交中更新 API、后端和前端。
- 简化依赖管理：通过本地引用共享代码。
- 集成工具链：IDE 可以立即显示所有使用者的错误。
权衡
- 规模问题：随着时间推移，仓库可能会变得非常庞大。
- 工具开销：需要 Nx、Turborepo 或 Bazel 等专门工具。
Polyrepo 策略
在 Polyrepo 策略中，每个服务都位于其 独立的代码仓库 中。
优点
- 独立 lifecycle：自主的 CI/CD、版本控制和发布。
- 清晰边界：自然防止意外耦合。
- 细粒度访问：团队仅访问其拥有的代码。
权衡
- 协调开销：跨服务变更需要多个 PR。
- 封装复杂性：共享代码必须作为包发布。
决策指南
| 因素 | Monorepo | Polyrepo |
|---|---|---|
| 团队规模 | 中小型 (< 30 名开发者) | 中大型 |
| 发布频率 | 协同发布 | 每个服务独立发布 |
| 共享代码 | 重度跨服务共享 | 极少；首选 API 契约 |
| 所有权 | 共享/流动 | 每个仓库明确归属 |
推荐选择 Monorepo 的情况：
- 团队在全栈范围内协作。
- 内部包版本管理引起摩擦（“版本地狱”）。
- 需要在整个平台实现端到端的类型安全。
推荐选择 Polyrepo 的情况：
- 团队高度专业化且自主。
- 某个仓库包含海量二进制文件或模型。
- 需要对每个服务进行严格的访问控制。