В общем, вы можете иметь все свои микросервисы в одном репозитории, но я думаю, что в то время как код растет для каждого из них, с этим может быть трудно справиться.
Вот некоторые вещи, которые вы, возможно, захотитеПрежде чем принять решение поместить все ваши микро-сервисы в один репозиторий, подумайте:
Дисциплина разработчиков : будьте осторожны с соединением кода. Поскольку код для всех ваших микро-сервисов находится в одном репозитории, у вас нет реальной физической границы между ними, поэтому разработчики могут просто использовать некоторый код из других микро-сервисов, например, добавить ссылку или подобное. Наличие всех микросервисов в одном репозитории потребует от разработчиков определенной дисциплины и правил, чтобы они не пересекали границы и не злоупотребляли ими.
Возникло искушение создавать и злоупотреблять общим кодом. Это не плохо, если вы делаете это правильно и структурировано. Опять же, это оставляет много места для того, чтобы сделать это неправильно. Если люди просто начнут использовать одну и ту же банку или подобную, это может привести к большому количеству проблем. Для того, чтобы что-то было доступно, оно должно быть изолированным и упакованным, и в идеале должно иметь некоторые версии с поддержкой обратной совместимости. Таким образом, каждый микросервис при обновлении этой библиотеки все еще будет иметь рабочий код с предыдущей версией. Тем не менее, его можно выполнить в том же репозитории, но, как и в пункте 1. выше, он требует планирования и управления.
Замечания по Git : Управление большим количеством запросов на извлечение иветки в одном хранилище могут быть сложными и могут привести к ситуации: «Я заблокирован кем-то другим». Также, поскольку, возможно, больше людей будут работать над проектом и будут подчиняться вашей ветке с исходным кодом, вам придется делать перебазирование и / или слияние ветки с исходным кодом в вашу ветку разработки или функции гораздо чаще (даже если вам не нужны изменения издругие услуги). Уведомления по электронной почте, настроенные для репозитория, могут быть очень раздражающими, поскольку вы будете получать электронные письма о вещах, которых нет в вашем коде микросервиса. В этом случае вам нужно создать несколько фильтров / правил в своих почтовых клиентах, чтобы избежать нежелательных писем.
Количество микросервисов будет расти еще дальшеваши начальные 10-15. число может расти? Если не все в порядке, но если это произойдет в какой-то момент, возможно, вы захотите разделить каждый микро-сервис в отдельном хранилище. Выполнение этого в тот момент, когда вы находитесь на более поздней стадии проекта, может быть сложным и может потребовать некоторой работы, а в худшем случае вы обнаружите, что есть какие-то соединения, которые люди делали с течением времени, и вам придется решать на этом этапе.
Рекомендации по конвейеру CI : Если вы используете что-то вроде Jenkins для сборки, тестирования и / или развертывания своего кода, вы можете столкнуться с некоторыми небольшими трудностями конфигурации, такими как интеграция между Jenkins иGithub. Вам необходимо настроить конвейер, который будет создавать / тестировать только определенную часть кода (или один микросервис), если кто-то создаст запрос на объединение / извлечение этого микросервиса. Я никогда не пытался сделать такую вещь, но я думаю, вам придется выяснить, как это сделать (сценарий и автоматизировать это). Думаю, это выполнимо, но для этого потребуется определенная работа.
Заключение
Тем не менее все или большинство из этих пунктов можно решить с помощьюнекоторое дополнительное управление и настройка, но все же стоит знать, с какими дополнительными усилиями вы можете столкнуться. Я предполагаю, что есть и другие моменты, которые следует принять во внимание, но мой общий совет - использовать отдельные репозитории для каждого микросервиса, если это возможно (ценообразование в частном репозитории и аналогичные причины). Это решение, которое принимается проект за проектом. Надеюсь, что эти заметки помогут вам:)