Разбивать монолит: почему порядок важнее скорости
Как планировать миграцию от монолитной архитектуры без остановки операций - о последовательности, рисках и точках отката.
Разговор о разбивке монолита начинается примерно одинаково. Система выросла, стала тяжело изменяемой, каждое обновление - событие с рисками. Команды мешают друг другу. Деплой превратился в ритуал с молитвой. Решение кажется очевидным: разобрать монолит на сервисы.
Я видел несколько таких проектов. Самые болезненные - те, где всё делалось быстро и параллельно. Самые успешные - те, где заранее продумывали порядок.
Почему порядок имеет значение
Монолит - это живая система. Пока вы его перестраиваете, он продолжает обслуживать бизнес. Это не рефакторинг в спокойной обстановке - это замена двигателя на ходу.
Если начать с нескольких модулей одновременно, вы получаете несколько незавершённых изменений одновременно. Каждое из них - источник нестабильности. Сложить их вместе - значит сложить риски.
Хорошая миграция движется как хирург: один разрез, убедиться что пациент стабилен, следующий шаг.
Как выбрать, с чего начать
Не нужно начинать с самого большого модуля или с того, который больше всего раздражает команду. Нужно начать с того, который имеет наименьшие зависимости и наибольшую ценность для бизнеса в случае успеха.
Хорошие кандидаты для первого шага - модули, у которых:
- чётко определённые входы и выходы;
- мало внутренних вызовов к другим частям системы;
- понятный владелец со стороны бизнеса;
- возможность работы в параллельном режиме - новый сервис и старый монолит работают одновременно, трафик переключается постепенно.
Последнее особенно важно. Паттерн "strangler fig" - когда новый сервис обёртывает старый функционал и принимает трафик постепенно - это способ снизить риск до минимума. Вы никогда не оказываетесь в ситуации "либо всё, либо ничего".
Что нужно решить до начала
До того как первая строчка кода написана для нового сервиса, должны быть ответы на несколько вопросов.
Как будет выглядеть граница между новым сервисом и остатком монолита? Какой API? Кто владелец данных, которые затрагивает модуль? Как будет происходить переключение трафика - мгновенно или постепенно? Что происходит, если новый сервис падает - откат на монолит или нет?
Эти вопросы не технические. Это вопросы о том, как вы управляете рисками и как принимаете решения в процессе.
Типичные ловушки
Первая: переоценить самостоятельность модуля. Кажется, что он изолирован, но в реальности тихо читает из общей базы данных или вызывает десяток внутренних функций. Это обнаруживается в процессе и останавливает миграцию.
Вторая: переехать код, но не переехать данные. Новый сервис работает, но данные продолжают жить в монолите. Теперь у вас есть сервис с зависимостью от монолита - архитектура не улучшилась, только усложнилась.
Третья: нет точки отката. Если нельзя быстро вернуться назад, каждый шаг становится необратимым. Давление на команду растёт, ошибки труднее исправлять.
Несколько вопросов перед стартом
Если вы стоите перед решением о начале такой миграции:
- Есть ли карта зависимостей между модулями в монолите - не в теории, а реальная, актуальная?
- Выбран ли первый кандидат на выделение и понятно ли, почему именно он?
- Есть ли план параллельной работы нового сервиса и монолита?
- Есть ли точка отката для первого шага?
- Кто принимает решение о переключении трафика - и по каким критериям?
Если ответы есть - можно двигаться. Если нет - сначала ответы.