Go单体仓库：为可扩展项目组织代码

Go 单体仓库：高效组织代码

在现代软件开发中，选择代码管理策略是影响团队生产力和项目可扩展性的关键因素之一。单体仓库 (monorepo) 是一种将所有服务、库和工具的代码存储在一个统一仓库中的方法。结合最初为大型项目设计的 Go 语言，单体仓库成为一个强大的工具。

在本文中，我们将探讨如何正确组织 Go 单体仓库：从基本目录结构到使用 Go Workspace 管理依赖关系。您将学习如何避免常见错误，并构建一个能够随项目一起成长的架构。

为什么单体仓库和 Go 是理想组合？

Go (Golang) 以其简单性和高效性而闻名。然而，在处理微服务或大型库时，会出现一个问题：如何组织代码以使其易于维护和重构？

Go 单体仓库的优势：

• 统一的依赖版本：所有服务使用相同版本的库，从而消除冲突。
• 简化重构：更改一个库中的 API 会立即反映在所有使用者中。
• 提交完整性：项目中不同部分的更改可以合并到一个提交中，从而简化回滚。
• 标准化：整个项目统一的 linting、测试和 CI/CD 规则。

同时，Go 提供了内置工具——模块 (go mod) 和工作区 (go work)，非常适合与单体仓库一起使用。

Go 单体仓库的基本结构

正确的目录结构是成功单体仓库的基础。让我们以包含多个微服务和共享库的项目为例，考虑推荐的组织方式。

myproject/├── apps/│   ├── api-gateway/│   │   ├── cmd/│   │   │   └── main.go│   │   ├── internal/│   │   ├── go.mod│   │   └── go.sum│   ├── user-service/│   │   ├── cmd/│   │   └── internal/│   └── order-service/│       ├── cmd/│       └── internal/├── libs/│   ├── common/│   │   ├── logger/│   │   ├── config/│   │   ├── go.mod│   │   └── go.sum│   └── db/│       ├── models/│       ├── migrations/│       ├── go.mod│       └── go.sum├── scripts/│   ├── build.sh│   └── deploy.sh├── go.work├── Makefile├── .golangci.yml└── README.md

结构说明：

• apps/ — 包含可执行应用程序（微服务、CLI 工具）。每个服务都是一个独立的 Go 模块，拥有自己的 go.mod。
• libs/ — 通用库，在服务之间重复使用。
• scripts/ — 用于构建、测试和部署的辅助脚本。
• go.work — workspace 文件，将所有模块连接到一个统一的开发空间中。

重要提示：不要将代码直接放在仓库根目录中。使用子目录按功能用途进行分组。

使用 Go Workspace 管理依赖关系

从 Go 1.18 版本开始，支持 workspace（工作区）。这是单体仓库的关键特性，允许同时开发多个模块，而无需将其发布到远程注册表。

创建 workspace：

# 在项目根目录初始化 workspacego work init ./apps/api-gateway ./apps/user-service ./libs/common

# 添加新模块go work use ./apps/order-service

# 查看当前 workspacego work edit -json

go.work 文件的内容：