代碼倉庫架構概覽 (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 策略中，每個服務都位於其 獨立的代碼倉庫 中。
優點
- 獨立生命週期：自主的 CI/CD、版本控制和發布。
- 清晰邊界：自然防止意外耦合。
- 細粒度訪問：團隊僅訪問其擁有的代碼。
權衡
- 協調開銷：跨服務變更需要多個 PR。
- 封裝複雜性：共享代碼必須作為包發布。
決策指南
| 因素 | Monorepo | Polyrepo |
|---|---|---|
| 團隊規模 | 中小型 (< 30 名開發者) | 中大型 |
| 發布頻率 | 協同發布 | 每個服務獨立發布 |
| 共享代碼 | 重度跨服務共享 | 極少；首選 API 契約 |
| 所有權 | 共享/流動 | 每個倉庫明確歸屬 |
推薦選擇 Monorepo 的情況：
- 團隊在全棧範圍內協作。
- 內部包版本管理引起摩擦（“版本地獄”）。
- 需要在整個平台實現端到端的類型安全。
推薦選擇 Polyrepo 的情況：
- 團隊高度專業化且自主。
- 某個倉庫包含海量二進制文件或模型。
- 需要對每個服務進行嚴格的訪問控制。