Siéntete libre de divulgar nuestra web y códigos en tus redes sociales, danos de tu ayuda para ampliar nuestra comunidad.
Solución:
La otra respuesta aquí aboga por poner cada microservicio en su propio repositorio. Puede haber razones válidas para dividir las cosas de esa manera, pero puede haber razones igualmente válidas para querer mantener todo en un repositorio también (realmente depende de su proyecto / circunstancias)
Si desea todo el código en un repositorio, puede, solo necesita seguir las reglas del paquete de Go. (esta es una buena lectura: https://golang.org/doc/code.html#Workspaces)
Si tiene una combinación de comandos y bibliotecas, la estructura de directorio que propuso en su pregunta se acerca, pero probablemente no necesite la src directorios allí. A continuación, se muestra un ejemplo de cómo se vería una estructura de directorio dentro de un repositorio con bibliotecas y comandos:
lib1/
-- some.go
-- source.go
lib2/
-- more.go
-- source.go
cmd/
-- microservice1/
-- main.go
-- microservice2/
-- anothermain.go
Para usar este repositorio, debe clonarlo dentro de un espacio de trabajo de Go en su sistema (vea el enlace que compartí arriba). Suponiendo que su repositorio vive en github.com/mybiz/project, y su GOPATH era ~/go, el espacio de trabajo se vería de la siguiente manera:
~/go/src/github.com/mybiz/
-- project/
El archivo cmd/microservice1/main.go incluiría la biblioteca lib1 a través de una ruta en la que lo espera en relación con $GOPATH/src como sigue:
import "github.com/mybiz/project/lib1"
Ahora, su código tiene acceso a los símbolos exportados en ese paquete usando el nombre del paquete declarado en los archivos bajo lib1… generalmente solo:
package lib1
En cmd/microservice1/main.go, con la importación anterior, puede usar lib1 símbolos de la siguiente manera:
lib1.CallMe()
Espero que ayude a aclarar cómo funciona la estructura de directorios de Go.
Lo estoy estructurando así; mono-repo per. enfoque del proyecto. Teniendo en cuenta que estos servicios están estrechamente relacionados:
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
Alternativa 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
Con la introducción de los módulos go, me inclino más hacia la segunda alternativa.
En algún momento posterior, cuando empiece con su segundo macro/ micro / nano-services, muchos de estos paquetes en la carpeta / pkg también serían necesarios allí. ¿Qué hacer? ¿Copiar pegar? ¡No! En su lugar, extraiga estos paquetes del proyecto, es decir, log, métrica y cree su propio kit.
Recuerda que si usas algún tipo de CI / CD (realmente deberías), tienes la opción de escribir un script colocado en la raíz del proyecto que solo detectará los cambios que realices en el repositorio, por lo que solo se construirán los servicios afectados y entregado. Hay varios ejemplos de cómo hacer esto.
Gracias a @ karl-andresen. Estaba investigando sobre el mismo tema y se me ocurrió la siguiente estructura, espero que esto ayude a alguien
github.com/username/container/
├── pkg/ ('username' created packages - common for all services & reusable in other projects)
| ├── errors/
| ├── log/
| ├── metrics/
| ├── infra/ (sub category in packages)
| | ├── consul/
| | └── kubernetes/
| └── tracing/
├── services/ (where all microservices will be imported as submodules - may or may not be reused)
| ├── account/
| | ├── handler.go
| | ├── handler_test.go (unit testing, note filename with '_test')
| | ├── main.go
| | ├── main_test.go (another unit testing)
| | ├── account.cfg (configuration file for account microservice)
| | ├── submodule/ (sub directory)
| | | ├── submodule.go
| | | └── submodule_test.go (submodule unit test)
| | ├── Dockerfile
| | └── README.md
| ├── auth/
| ├── booking/
| └── user/
├── api/ (OpenAPI/Swagger specs, JSON schema files, protocol definition files.)
| ├── proto/ (protocol buffer files)
| | ├── v1/
| | | ├── account.proto
| | | ├── account.pb.go
| | | ├── booking.proto
| | | └── booking.pb.go
| | └── v2/
| └── rest/ (json files)
| ├── v1/
| | ├── booking.json
| | └── account.json
| └── v2/
├── configs/ (project config settings, default configs, file templates)
├── scripts/ (Scripts to perform various build, install, analysis, etc operations.)
├── build/ (Packaging and Continuous Integration.)
├── test / (system and module level tests)
├── docs/ (project documents folder)
├── examples/ (project examples for service interactions)
├── third_party/ (all open source, third party codes, where applicable fork and add as submodule)
├── githooks/ (project git hooks)
├── assets/ (common assests for all services)
├── Makefile
├── README.md
└── docker-compose.yml
Recuerda comunicar esta noticia si te valió la pena.