Каким был бы стандартный и лучший подход структуры репозитория git для микросервисной архитектуры?

Question

Лучший подход к структуре репозитория для приложений на основе микросервисной архитектуры?

Например, я имел в виду эталонную архитектуру Microsoft, т.е. eShopContainers в репозитории github [https://github.com/dotnet-architecture/eShopOnContainers/tree/dev/src]. Но это придумывает еще кое-чтосложность динамической рабочей среды, где командная работа над различными пользовательскими интерфейсами, микросервисами, следовательно, все в одном репозитории делает его более длительным процессом при слиянии / конфликтах и ​​т. д. Некоторые члены команды хотели бы иметь каждый микросервис в отдельном репозитории, в то время как разработка лучшеуправление, а затем экспортировать в групповое хранилище после производства, т.е. пока BAU.Благодарим за обсуждение плюсы и минусы, чтобы принять лучшее решение для нашей среды.

Answer 1

Одним из основных преимуществ использования микросервисной архитектуры является возможность внедрения новых технологий без полной перезаписи.Легко думать только о языках программирования и фреймворках - но правда в том, что программное обеспечение для контроля версий точно такое же.Я видел команды, мигрирующие из SVN в Git или TFS.Наивно полагать, что Git останется с нами навсегда.Я считаю, что это сильный аргумент в пользу использования нескольких репозиториев.

Единый репозиторий - при условии, что у него есть преимущества - всегда будет искушать разработчиков создавать какие-то межпроектные зависимости.Возможно, это будет один файл сборки в специальном инструменте сборки, используемом для компиляции всех микросервисов.Это может быть каталог общей библиотеки с конкретными версиями внешних библиотек или jar-файлов или чего-либо еще.Всегда будет тенденция создавать такую ​​вещь.Что в конечном итоге сделает эти микросервисы каким-то образом связанными и зависимыми.

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

Answer 2

Сделав оба, вот некоторые из компромиссов:

Для монорепо (все коды и сервисы в одном репо):

• Намного проще сохранить связанные изменения всинхронизация (например, изменение как производителя, так и потребителя; изменения обоих могут быть сохранены как один коммит.
• Легче настроить согласованную среду сборки. При правильной настройке все службы могут бытьпостроен с использованием точно такой же цепочки инструментов и, возможно, того же Makefile.
• Если вы решите использовать один GOPATH, все службы должны храниться в непрерывном режиме. Это может причинить много боли, если одна служба нуждается вперейти на более новую версию библиотеки с критическим изменением: каждый сервис, использующий эту библиотеку, должен обновиться сразу. Несколько GOPATHS усложняют процесс поддержки.
• При правильном управлении с помощью CI и тестирования возможнопостоянно держать HEAD в развертываемом состоянии, уменьшая вероятность того, что вы получите набор служб, которые не могут взаимодействовать, посколькупотому что они не совпадают.

Несколько репозиториев:

• Намного проще получить услугу на стабильном уровне и оставить ее в покое.Поскольку он находится в своем собственном репозитории, нет необходимости выполнять обновления, даже если другой службе требуется более новая версия библиотеки или вы решили изменить библиотеки (например, с Gin на Echo).
• Искушение пренебречь обновлениямио стабильных услугах (например, изменение от Gin к Echo), что может повлечь за собой существенное обновление для критических изменений под давлением времени;определенно увеличивая нагрузку на обслуживание (делаем ли мы долгое отложенное обновление до Echo, или мы просто оставляем его в Gin? Если нам нужно внести существенные изменения в наши API, со сколькими разными средами нам нужно будет работать, когда мы делаемчто?)
• Распространение репозиториев затрудняет поиск чего-либо, когда это необходимо (в каком сервисе мы это определили? Мне нужно повторно использовать это здесь)
• Распространение дубликатов или (хуже) почти дублированный код в нескольких репозиториях.Легко привыкнуть копировать сервис в качестве основы, а затем вносить изменения поверх старого кода, что приводит к фрактальному набору различий по кодовой базе, особенно потому, что «рабочий» код не имеет тенденцию обновляться досопоставьте изменения.

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