Привет! Меня зовут Игорь Шаталкин, я разработчик-эксперт в CUSTIS. В этой статье продолжим обсуждение монолитов и микросервисов. Опираясь на практический опыт компании CUSTIS, я рассмотрю ключевые особенности перехода от монолита к микросервисам: когда это необходимо и как это осуществить.
Когда возникает необходимость перехода
Перед тем как углубляться в детали перехода к микросервисам, важно понять, при каких обстоятельствах вообще возникает такая необходимость.
Новые технологии и модернизация:
Перевод монолита на новые технологии может быть дорогим, поэтому логично переводить его частями, выделяя микросервисы.Масштабирование критичных компонентов:
Когда отдельные части монолита не справляются с возрастающей нагрузкой, возникает потребность в масштабировании. Вместо разворачивания всего приложения на нескольких серверах выгоднее дублировать только наиболее нагруженные компоненты.
Основные аспекты перехода
Выделение микросервисов при доработках
Микросервисы можно выделять при масштабных доработках монолита.
Преимущества для заказчика:
При проведении значительных изменений заказчик увидит явную выгоду и будет готов увеличить бюджет в связи с пониманием долгосрочной пользы и оптимизацией процессов.Планирование этапов:
Разбейте приложение на независимые функциональные модули, которые можно постепенно выделять в микросервисы.
Взаимодействие между монолитом и микросервисами
При переходе важно продумать схему взаимодействия новых микросервисов с оставшейся частью монолита.
Не всегда легко внедрить современные паттерны взаимодействия в устаревший код. Возможны ситуации, когда стандартные решения приводят к критическим ошибкам. Например, в одном из проектов монолит намертво зависал при вызове микросервиса. Проблема усугублялась тем, что зависание происходило не всегда, а лишь при определённых и редко встречающихся обстоятельствах. А решить проблему оказалось крайне просто — надо было всего лишь поправить одну строчку кода)
Помните, что взаимодействие устаревшей части приложения и новых микросервисов может проходить со сбоями, и тщательно тестируйте интеграционные сценарии.
Обучение команды
Одним из ключевых моментов успешного перехода к микросервисам является повышение квалификации специалистов.
Расширение знаний архитекторов и разработчиков:
Если сотрудники не знакомы с концепциями вроде шины, Outbox и другими паттернами, переход будет затруднён. Важно не просто обучить работе с инструментами, а объяснить суть заложенных концепций. Команда должна понимать не только техническую реализацию паттерна, но и случаи, когда его следует применять.Преимущества грамотного обучения:
Если команда понимает принципы работы, то многие вопросы отпадают сами собой.
Мотивация команды через участие в декомпозиции
Переход от монолита к микросервисам — это серьёзный технологический и организационный вызов.
-
Уникальный опыт для специалистов:
Участие в таком проекте можно выгодно отметить в резюме.
Талантливые разработчики и инженеры будут стремиться работать над таким значимым проектом.
-
Психологический эффект:
Процесс декомпозиции стимулирует инновационный дух в команде.
Участие в крупном и амбициозном проекте повышает вовлечённость сотрудников.
В нашей практике случались переходы от монолита к микросервисам, но с обратным процессом мы ни разу не сталкивались. Возможно, кто-то из читателей работал в проекте, где был осуществлён обратный переход. Было бы интересно узнать о причинах, побудивших это сделать, и об оценке эффективности принятого решения.
Заключение
Как в жизни, так и в мире разработки выбор между микросервисами и монолитом может быть сложным.
Представьте себе, что монолит — это бургер, который вы съедаете за один раз. Это быстро, просто и удобно, особенно когда вы голодны. Но микросервисы? Это как тарелка с разными ингредиентами этого бургера: котлета, помидоры, салат и соус. Каждый ингредиент может быть улучшен и заменён, в идеале без вреда для остальных. Вы можете наслаждаться каждым вкусом по отдельности или комбинировать их, создавая новые сочетания.
Так что какой выбор сделать, зависит от вашего аппетита. Но помните, что важно не только то, что вы выбираете, но и как вы это используете. Будь то микросервисы или монолит, главное — это создавать что-то вкусное и полезное для пользователей. Приятного аппетита и успешной разработки!
Dhwtj
IgorShatalkin Автор
Не совсем понимаю, какие именно конкретные кейсы хочется услышать) Что касается статей - то это наш практический опыт использования микросервисов. Мы столкнулись с рядом проблем и задач, когда стали использовать микросервисы в наших проектах. Цикл статей систематизирует наш опыт и показывает, в каких случаях стоит использовать микросервисы, какие у них есть подводные камни и как перейти на микросервисы, если было принято такое решение
Dhwtj
Тогда вопросы:
Метрики команды до и после этого изменения. Какие вам больше нравятся метрики те и пишите. Трудоемкость и время внедрения сравнимых таск, например
И стек. Например, про увлечение микросервисами на Go/PHP поверю, на Java/C#/Rust скорее нет. Потому что там монолит даёт больше гарантий и хороших плюшек, от которых трудно отказаться на трезвую голову.
IgorShatalkin Автор
Метрики "до" и "после" не собирали. В большинстве случаев в этом, на самом деле, нет смысла, поскольку мы решали задачи, которые можно решить только с использованием микросервисов (например, обновление техстека в монолите).
Стек: C#, Java
allishappy
Какие гарантии и плюшки даёт монолит на C#? И почему условный PHP их не даёт?
Dhwtj
В целом
На Шарп компилятор даёт гарантии контрактов. Пхп нет. И поэтому контракты на пхп разумно реализовать через апи, но это сложнее и иногда выглядит как костыль