Привет! У меня есть свой pet-проект — онлайн-магазин. Я решил разделить REST API на микросервисы, написал proto-файлы и сгенерировал код, и, кажется, все работает нормально. У меня клиент использует HTTP, а взаимодействие между микросервисами происходит через gRPC. У меня остался вопрос: следует ли размещать все микросервисы в одном репозитории и запускать их таким образом, или лучше распределить их по разным веткам проекта и затем импортировать в главный?
Привет! Разделение на микросервисы — это важный шаг, и правильно организовать их структуру и развертывание — ключ к успеху.
### Репозиторий микросервисов
1. **Monorepo (один репозиторий для всех микросервисов)**:
- **Преимущества**:
- Упрощенное управление зависимостями.
- Легко обеспечивать согласованность версий между сервисами.
- Упрощает координацию изменений и рефакторинг общего кода.
- **Недостатки**:
- При развитии большого проекта может сильно увеличиться размер репозитория.
- Чтобы обновить один сервис, возможно, придется работать с другими, даже если они не изменились.
2. **Multirepo (раздельные репозитории для каждого микросервиса)**:
- **Преимущества**:
- Большая гибкость при развертывании и масштабировании, так как каждая команда может работать независимо.
- Удобно регулировать доступ и разрешения к различным сервисам.
- Легче управлять версиями одним сервиcом без учета остальных.
- **Недостатки**:
- Сложность в координации изменений между сервисами.
- Необходимость в инструментах для управления зависимостями между репозиториями.
### Рекомендации
1. **Размер и сложность проекта**: Если ваш проект еще небольшой и не очень сложный, вам может быть проще начать с monorepo. Это упростит разработку и тестирование.
2. **Команда и управление**: Если у вас есть большая команда, разделение на разные репозитории (multirepo) может помочь избежать конфликтов и упростить процесс разработки.
3. **Автоматизация и CI/CD**: Независимо от выбора, важно настроить автоматизацию для сборки и развертывания ваших сервисов, чтобы упростить производственный процесс.
4. **Контейнеризация**: Если не делали этого ранее, посмотрите в сторону Docker и orchestration-систем (например, Kubernetes) для управления деплоем микросервисов.
5. **Документация**: Обязательно поддерживайте актуальную документацию API и схемы взаимодействия. Это поможет избежать путаницы при взаимодействии между командами.
### Вывод
В конечном счете, решение зависит от ваших конкретных потребностей и структуры команды. Если вы планируете постепенно масштабировать проект и команду, возможно, стоит сразу рассмотреть подход с многими репозиториями. Але если вы только начинаете и хотите минимизировать трудности на первоначальном этапе, monorepo может быть лучшим выбором.
микросервисы - сущность характерная для более-менее активных нагрузок, ибо сама идея была на уровне горизонтального масштабирования.
То есть грубо если на 100500 запросов масштабировать монолит - то надо xN экземпляров монолита с такой же кратностью ресурсов, а если прикладная система рубится на те самые функциональные части (микросервисы), то оказывается что надо разное количество экземпляров для разных "кусков" (микросервисов), что на больших цифрах и даст профит.
Естественно у этого профита есть и обратная сторона - передача данных между микросервисами это совсем не то же самое что передача параметров в вызов метода (даже по значению) и т.п.
Так что для pet проектов - это всё будет баловством и натягиванием микросервисом за уши.
Но если уж очень захочется - можно и пострадать микросервисами головного мозга и сделать вычурное:
- взять и разделить всё например по api - грубо на каждую crud четвёрку - свой микросервис
- не дать взаимодействовать микросервисам между собой - пусть этим занимается отдельный микросервис-передаст
- аналогично базой - вот пусть с ней работает отдельный микросервис, а остальные ходят к нему (хотя это слегка нарушит концепт "каждому микросервису по своей БД")
Ну и дальше - каждый микросервис сможет пилить отдельная команда разработки -> каждому по своему репозиторию... ну а знание друг о друге микросервисов замкнутся на одном/нескольких репозиториях контрактов
Монстр - готов)
Микросервисы — не только для нагрузки, а также инструмент менеджмента разработки.
Что это значит?
Это значит, что есть большая команда и наличие одной кодовой базы — есть точка препятствия, когда одна команда зависит от другой, а нужно делать быстро и независимо. Иными словами пример: есть в Яндекс.Такси 10 команд, в одной кодовой базе ни будут толкаться и зависеть друг от друга, зависимости общие, разрезание на микросервисы помогают разделить эту работу, выделить скоуп и каждая команда теперь может работать со своей скоростью, своими логами, своим релизным циклом и не зависеть от других...