我的结构是这样的;单回购每。项目方法。考虑到这些服务密切相关:

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(您确实应该),您可以选择编写一个放置在项目根目录中的脚本,该脚本只会检测您在存储库中所做的更改,因此只会检测受影响的服务将建造和交付。有几个例子可以做到这一点。