Как выделить сервис из монолита и ничего не сломать

Сервис из монолита выделяют так: находят шов в коде и данных, фиксируют текущее поведение тестами, превращают часть в модуль с интерфейсом внутри того же приложения, разделяют данные по стадиям, запускают новый сервис рядом со старым кодом в теневом режиме, переводят нагрузку порциями и только потом удаляют старое. Каждый шаг можно откатить, и ни один не требует остановки бизнеса.

Выделение нужно не всегда: сначала решите, нужен ли вам сервис, по статье «Микросервисы или монолит». Здесь предполагается, что решение принято, и разбирается техника. Общие правила работы с системой, которую нельзя остановить, описаны в статье «Как рефакторить legacy, не останавливая бизнес». Услуги описаны на страницах «Рефакторинг legacy-систем» и «Event-driven системы».

Что должно быть готово до первого шага

Выделение сервиса меняет много частей сразу, поэтому у системы должна быть страховка. Без неё первый же перенос превратится в угадывание.

Если условий нет, начинайте с них, а не с сервиса. Обычно это уже половина полезного эффекта, и выделять после этого приходится меньше.

Шаг 1. Найдите шов: где проходит граница

Хорошая граница пересекает как можно меньше данных и вызовов. Искать её нужно по трём источникам.

• Данные. Постройте матрицу «модуль — таблицы»: кто читает и кто пишет. Если часть читает и пишет собственные таблицы и лишь изредка заглядывает в чужие, это кандидат. Если ей нужны десять чужих таблиц, это не граница.
• Вызовы. Соберите, кто кого вызывает. Много вызовов внутрь и мало наружу — хороший признак: часть можно закрыть интерфейсом.
• История изменений. Файлы, которые меняются вместе, принадлежат одной части. Если правки разных модулей всегда идут в одном изменении, граница между ними проведена неверно.

Первой берут самую независимую часть: приём вебхуков, формирование файлов, уведомления. Ядро с заказами и деньгами выделяют последним, если выделяют вообще.

Шаг 2. Зафиксируйте текущее поведение

Задача сервиса — вести себя точно так же, как вела себя часть монолита, включая странности, на которые уже опираются другие. Правильность здесь определяется старым поведением, а не документацией.

Практические приёмы:

• Записанные запросы и ответы. Снимите реальный поток на границе части, обезличьте и сохраните вместе с ответами старой реализации. Это готовый набор для сравнения.
• Контрактные тесты. Описание того, что принимает и отдаёт часть: поля, коды ошибок, форматы дат и сумм. Тест запускается и на старой реализации, и на новой.
• Тесты на странные случаи. Пустые значения, длинные строки, повторные запросы, запросы не по порядку. Чаще всего ломается именно здесь.

Тест, написанный по старой реализации, называют характеризационным: он не говорит, что «правильно», он говорит, что «так есть сейчас». Менять это поведение надо отдельным решением, а не в ходе переноса.

Шаг 3. Отделите часть внутри монолита

Сервис лучше начинать как обычный модуль в том же приложении, и только потом выносить в отдельный процесс. Так проверяется граница без сети и без развёртывания.

1. Соберите код части в одном месте и закройте его интерфейсом: остальной код обращается только к нему.
2. Запретите обходные обращения: проверка в сборке, которая падает, если чужой код читает таблицы или вызывает внутренние функции модуля.
3. Замените чужие обращения к его таблицам вызовами интерфейса. Пока всё работает в одном процессе, ошибки видны сразу.
4. Включите контрактные тесты и убедитесь, что они проходят.

Часто на этом шаге выясняется, что выделять сервис уже не нужно: модуль с чёткими границами решил проблему порядка в коде и выпусков. Это нормальный результат.

Шаг 4. Разделите данные по стадиям

Данные разделяют не за один раз. Каждая стадия обратима, а переход к следующей делается после проверки.

Между стадиями 3 и 4 нужна сверка: сравнение числа записей, сумм и выборки по полям на живых данных. Расхождение должно разбираться, а не списываться на задержку. Как делать так, чтобы событие не терялось и не дублировалось при обмене между базами, описано в статье «Outbox и гарантированная доставка простыми словами».

Шаг 5. Вынесите и переключите нагрузку порциями

Когда граница и данные готовы, часть выносят в отдельный процесс и ставят перед ней прослойку, которая решает, кого обслуживает старый код, а кого новый сервис. Переключение идёт по лестнице:

1. Теневой режим. Запрос выполняет старый код, а копия уходит в новый сервис. Ответ нового никто не видит, но его сравнивают со старым. Расхождения разбираются до того, как кто-то пострадал.
2. Малая доля. Новый сервис отвечает настоящим пользователям, но только небольшой доле: внутренним сотрудникам, одной организации, одному региону. Выбирайте долю по признаку, который проще откатить, а не по случайному проценту запросов.
3. Расширение. Доля растёт ступенями; на каждой ступени выдерживается срок, достаточный, чтобы увидеть редкие случаи, например конец месяца.
4. Полное переключение. Старый код остаётся доступным, и прослойку можно вернуть на него одним действием.

Откат должен быть проверен заранее: на тестовом стенде переключите трафик туда и обратно и убедитесь, что данные после возврата в порядке. Откат, который ни разу не пробовали, не является откатом. Переключатель лучше держать в конфигурации, а не в коде, чтобы возврат не требовал выпуска.

Что ломается чаще всего

Ломаются обычно одни и те же места. Они не зависят от языка и платформы.

Обмен событиями между монолитом и сервисом удобен, но добавляет свои задачи: порядок сообщений, повторы, задержки. Когда событийный обмен уместен и когда избыточен, объясняет статья «Событийная архитектура: что это и когда нужна».

Шаг 6. Удалите старое, иначе получится две системы

Последний шаг чаще всего пропускают. Старый код «пока оставили на всякий случай», и через год две реализации отличаются, а команда не знает, какая настоящая. Поэтому в плане выделения заранее записывают:

• дату удаления старой реализации и условия, при которых она переносится;
• что именно удаляют: код, таблицы, настройки, тесты, документацию;
• кто подтверждает, что вызовов старого кода не осталось: по журналу, а не по ощущению;
• что делать с копией данных старой стороны: сколько хранить и когда удалить.

После удаления сервису нужен владелец, мониторинг и план обновлений. Выделение, которое не передали в сопровождение, откладывает проблему на другое место.

Что делаем мы и с чего начать

Начинаем с обследования: 200 000 ₽ и 2–3 недели на один контур, 350 000 ₽ и 3–4 недели, если система окружена несколькими другими. На выходе карта границ с матрицей «модуль — таблицы», рекомендация, какую часть выделять первой и нужно ли это вообще, план стадий и вилка бюджета. Сумма вычитается из первого этапа, если продолжаете с нами. Затем пилот на одной части: от 150 000 до 400 000 ₽ за 2–8 недель, с нагрузочными испытаниями до и после.

Мы выделяем одну часть или один контур, а не переписываем систему целиком, и не обещаем сервисов ради сервисов: если хватает модульного монолита, скажем об этом. Исходники лежат в вашем репозитории с первого коммита, остановиться можно после любой ступени. Цены и сроки — на странице «Тарифы», описание подхода — на странице «Микросервисы и высоконагруженные системы».