Микросервисы Каждый сервис живёт своей жизнью

Определяем, как монолит и новый сервис будут взаимодействовать друг с другом: выбираем REST, gRPC или асинхронную очередь, описываем эндпоинты и методы, форматы запросов и ответов, а также правила обработки ошибок и таймаутов. Фиксируем этот контракт в OpenAPI, gRPC или AsyncAPI, после чего изменяем его только по предварительному согласованию.

Пишем новый сервис с нуля, выбирая технологию под конкретную задачу: для нотификаций — Python + FastAPI, чтобы быстро реализовать лёгкий HTTP-сервис, для авторизации — Java + Spring Security, чтобы обеспечить надёжность, для каталога — NestJS, чтобы использовать единый стек с фронтендом. Сервис сразу упаковываем в Docker, покрываем unit- и интеграционными тестами и обеспечиваем необходимыми логами, метриками и healthcheck.

Новый сервис разворачивается в Kubernetes рядом с монолитом, при этом монолит продолжает работать как обычно. Настраиваем Service Discovery, чтобы монолит мог находить новый сервис, API Gateway — если требуется внешний доступ, а также мониторинг и логирование, чтобы сразу видеть, что происходит с сервисом.

Постепенно перенаправляем запросы с монолита на новый сервис: в первый день — 1% трафика, во второй — 5% при отсутствии ошибок, в третий — 20%, в четвёртый — 50%, а на пятый — 100%. На каждом этапе контролируем ошибки в логах, время ответа, нагрузку на CPU и память, а также проверяем отсутствие рассинхронизации данных. Если что-то идёт не так, в течение минуты возвращаем трафик на 0% с помощью feature flag, reverse proxy или canary deployment.

Удаляем из монолита код вынесенной функции и оптимизируем базу данных, убирая таблицы, которые теперь принадлежат новому сервису. Затем выбираем следующего кандидата и повторяем шаги 1–5. Процесс продолжается до тех пор, пока монолит не станет достаточно маленьким либо не останутся только те части, вынос которых экономически нецелесообразен.