Сообщить об ошибкеКороткий ответ
Strangler fig постепенно «обрастает» монолит новыми сервисами, перехватывая часть функциональности через прокси/роутер, пока вся нужная функциональность не будет перенесена и старый код не выведен из эксплуатации, без единого «большого взрыва»; критерии успеха и темп миграции определяются конкретным проектом, а не фиксированным планом.
Как это работает подробнее
Перед монолитом ставится роутер, который постепенно перенаправляет отдельные эндпоинты на новые сервисы, оставляя остальной трафик идти в монолит; данные и трафик мигрируют по частям, и на каждом этапе монолит и новые сервисы работают параллельно.
Быстрая агрессивная миграция сокращает срок и стоимость поддержки двух архитектур одновременно, но повышает риск крупных инцидентов и усложняет откат; медленная поэтапная миграция снижает риск каждого шага и даёт дешёвый откат, но растягивает период параллельной поддержки, что само по себе стоит ресурсов и может никогда не «довестись до конца» без управленческой воли. Критерий выбора темпа — терпимость бизнеса к риску, доступность инженерных ресурсов и готовность выделить время на завершение миграции.
Пример кода
Gateway routing rule (поэтапный перенос эндпоинта /orders):
/orders/* -> 10% трафика в Order Service, 90% в монолит (canary)
-> при отсутствии роста ошибок за 2 недели: 100% в Order Service
-> мониторинг: error_rate, latency p99, бизнес-метрики сравниваются
между путём через монолит и через новый сервис на этапе 10%/90%Что использовать на практике
- Практика. Успешная миграция определяется контролируемостью риска — на каждом этапе должна быть возможность безопасного откат(а), наблюдаемость, и чёткий критерий «этот кусок полностью перенесён и старый код можно удалить» (отсутствие трафика на старый путь в течение достаточного периода).
Подводные камни
- Риск. Переносить сразу большие куски функциональности без промежуточных контрольных точек; не выделять время на удаление старого кода монолита после переноса, из-за чего обе архитектуры годами поддерживаются параллельно.