Хранение микросервисов Go в разных репозиториях на Github

Question

Я работаю над проектом микро-услуг. Для этого я хотел бы иметь один пакет Go для каждой услуги, все они включены в родительский пакет для проекта. Это выглядит так:

.
└── github.com
    └── username
        └── project
            ├── service1
            └── service2

Я думаю, что эта структура позволяет соблюдать соглашения Go по именам и путям пакетов. Следствием этого является то, что все мои микросервисы заканчиваются в одном и том же хранилище на Github, так как хранилище будет на глубине 3 в URL. Я думаю, что это может стать проблемой в будущем, если кодовая база станет большой. Это также может добавить сложность для конвейера CI / CD, например, изменение одного сервиса вызовет сборку для всех других сервисов, и код для клонирования будет излишне большим.

Есть ли способ избежать этогоконфликт между соглашениями Go и тем, как работает Github? Или это проблема, которую нужно решить во время работы CI / CD?

Answer 1

То, о чем вы говорите, в наши дни принято называть «монорепо». Хотя мне лично нравится, что все мои проекты находятся в собственных независимых репозиториях (включая микросервисы и все остальное), есть ряд сторонников того, чтобы иметь весь код для компании в одном репозитории. Интересно, что и Google , и Facebook используют монорепозицию, хотя нужно сказать, что они создали много необычных инструментов, чтобы заставить их работать на них.

Важно отметить, что ваш репозиторийотдельная вещь от вашей архитектуры. Между ними не обязательно существует какая-либо корреляция. Вы можете иметь микросервисы в одном репо и монолит, разделенный на несколько репо;репозиторий - это всего лишь инструмент для хранения и документирования вашей кодовой базы, не более того.

При изучении этой темы, вот некоторые преимущества и недостатки, взятые из ряда статей в Интернете:

Преимущества Monorepo

• Простота совместного использования модулей между проектами (даже в микросервисах часто возникают сквозные проблемы)
• Одно единственное место, которое можно увидеть изнать, какой код существует - особенно полезно в больших компаниях с большим количеством кода
• Упрощает процессы автоматического и ручного анализа кода
• Упрощает документирование, а не извлечение из нескольких отключенных репозиториев

Недостатки Monorepo

• Массивная кодовая база может быть сложной / медленной, чтобы регистрироваться / выходить на местный
• Без очень четких, строгих указаний это может быть легковызывает тесную связь между продуктами
• Требуется (немного) более сложная оснастка CI / CD для частичного выпуска
• В зависимости от платформы репозитория очень большие кодовые базы могут влиять на производительность

и . Здесь хорошо обсуждается о плюсах и минусах monorepos, а вот одна , конкретно связаннаяперейти на монорепо с архитектурой микросервисов. Вот еще один с множеством ссылок как за, так и против монорепо.

Как и многие другие вещи в программировании и особенно в SOA, правильное решение для вас зависит от ряда факторовэто только вы можете определить. Основной вывод заключается в том, что крупные и малые компании добились успеха с обоими вариантами и многими промежуточными, поэтому выбирайте осторожно, но не слишком переживайте по этому поводу.

Answer 2

Подпакеты управления версиями, от которых зависит проект Go, можно отслеживать с помощью git tagging . Поэтому, используя Go-модули, рекомендуется перемещать подпакеты в свои собственные git-репозитории.

Если большая часть вашего решения будет написана на go, я бы предложил использовать go modules .

В этом блоге объясняется, как управлять go.mod модулями Go с учетом зависимостей пакетов и связанных с ними версия тегов git:

• https://blog.golang.org/migrating-to-go-modules