Comments 11
Вроде миллионная по счёту история о переходе с монолита на микросервисы, но читать приятно.
Скажите, а у вас под каждый модуль свой реплзиторий, или весь проект в одном репозитории ютится?
Спасибо!
У нас все модули в одном репозитории, с NX в качестве «управлятора» ими.
Боюсь у вас не микросервисная архитектура а монолит модули которого общаются по сетевому протоколу и должны запускаться по не понятным правилам. Идея микросервисов в том что их можно релизить/обновлять по отдельности и писать на том стеке технологий, который больше подходит (хотя надо благоразумием соблюдать).
А у вас монорепозитарий с жесткими зависимостями.
Кстати, нет. Мы стремимся к тому, что бы сервисы были максимально независимы и могли использоваться по отдельности.
Безусловно, у модулей есть зависимости. Но эти зависимости разделены интерфейсами и могут быть заменены на любую другую реализацию на любом стеке.
То, что нам удобнее разрабатывать на едином стеке внутри одного репозитория, не делает систему монолитом.
Для «коробочного» решения довольно странной идеей является обновление компонентов по одному, но даже если это потребуется, нет никаких препятствий это сделать (пока совместимы интерфейсы).
А в чем, по Вашему мнению заключается «жесткость» наших зависимостей?
"С версионированием сервисов мы решили пойти прямым путем — поскольку все они генерятся из одного репозитория, то и версия у них должна быть одна на всех. Да, из версии сервиса не всегда понятно, есть ли в нем новая функциональность или же она не менялась.Но мы точно можем сказать, что состояние, когда у всех сервисов одинаковая версия, является поддерживаемым."
Идея микросервисов - у вас есть одинаковые сервисы с разным фунционалом (разными версиями)
У вас 1 Млн пользователей, пользующиеся микросервисом v1. Вы выпустили новую фичу v2. Поскольку в ней могут быть баги вы не хотите чтобы весь ваш 1 Млн. пользователей их увидел. Следовательно вы релизите вторую версию для 100 тыс. пользователей. После этого у вас сразу работают 2 версии микросервиса.
Кстати, если речь идет о микросервисах,то предполагается что их от 1 до N, в зависимость от нагрузки.
В противном случае у вас максимум распределенная архитектура а не микросервисная.
Простите, а как принцип присвоения версий влияет на то, о чем вы написали?
Про масштабирование - пожалуйста, перечитайте статью. Там этот момент освящен.
То, что вы описали, это стратегии деплоя. Микросервисы тут не при чём, монолит точно так же можно раскатывать на часть пользователей, если правильно подобрать и настроить инструменты
Модульный монолит?)
Для образовательных организаций Squadus бесплатный?
Как мы создаем Squadus: путешествие от монолита к микросервисам