我的结构是这样的;单回购每。项目方法。考虑到这些服务密切相关:
github.com/user/some_project/
├── pkg/ (common own-created packages for all services)
| ├── errors/
| ├── log/
| ├── metrics/
| ├── sd/
| | ├── consul/
| | └── kubernetes/
| └── tracing/
├── services/
| ├── account/
| | ├── pb/
| | | ├── account.proto
| | | └── account.pb.go
| | ├── handler.go
| | ├── main.go
| | ├── main_test.go
| | ├── Dockerfile
| | └── README.md
| ├── auth/
| ├── frontend/
| └── user/
├── vendor/ (common vendor-packages for all services)
├── docker-compose.yml
├── go.mod
├── go.sum
├── Makefile
└── README.md
备选方案 2:
github.com/user/some_project/
├── pkg/
├── service.account/
| ├─ cmd/
| | └─ main.go
| ├─ pb/
| ├─ Dockerfile
| ├─ go.mod
| └─ go.sum
├── service.auth/
├── service.frontend/
├── service.user/
├── docker-compose.yml
├── go.mod (used primarly for packages in the /pkg dir.)
├── go.sum
├── Makefile
└── README.md
随着 go-modules 的引入,我更倾向于第二种选择。
稍后,当您开始第二个宏/微/纳米服务项目时,/pkg 文件夹中的许多这些包也将在那里需要。该怎么办?复制粘贴?不!相反,从项目中提取这些包,即日志、度量并制作您自己的工具包。
请记住,如果您使用某种 CI/CD(您确实应该),您可以选择编写一个放置在项目根目录中的脚本,该脚本只会检测您在存储库中所做的更改,因此只会检测受影响的服务将建造和交付。有几个例子可以做到这一点。