Миграция по методу «Strangler Fig» не терпит неудачу в первый же день. Она проваливается ближе к концу, когда оставшиеся фрагменты оказываются не охваченными планом, а бизнес уже посчитал задачу выполненной.
Канонические описания от Fowler, Microsoft и AWS хорошо объясняют суть этого паттерна; однако они гораздо меньше говорят о том, кто владеет данными во время переходного периода, во сколько на самом деле обходится работа фасада и почему команды останавливаются на полпути.
Это руководство продолжает тему там, где заканчиваются упомянутые источники. Оно предполагает, что вы уже приняли решение модернизировать систему, а не переписывать её с нуля, и что вариант полной переработки приложения был рассмотрен и отброшен.
Паттерн «Strangler Fig» в двух предложениях
Паттерн «Strangler Fig» (фикус-душитель) заменяет устаревшую систему по одной функциональной возможности за раз, направляя трафик через фасад до тех пор, пока ничто не будет указывать на старый код и устаревшую систему можно будет окончательно отключить. Мартин Фаулер дал название и определение этому паттерну в 2004 году, и с тех пор это определение не требовало пересмотра.
Чего не охватывают канонические описания, так это реальности процесса: одновременная работа двух систем, оплата обеих и поддержание согласованности данных между ними на протяжении всей миграции. В ходе проектов по реплатформингу мы наблюдали, как фасады, задуманные как временные, переживали устаревшие системы, которые они должны были заменить.
Это руководство продолжает там, где bliki Фаулера определяет паттерн, Azure Architecture Center от Microsoft Learn документирует эталонную реализацию, AWS Prescriptive Guidance описывает механику доставки, а Wikipedia суммирует консенсусное определение: стоимость маршрутизации, двойная запись с использованием CDC (Change Data Capture) и момент, на котором большинство миграций фактически буксуют.
Как фасад маршрутизирует запросы во время миграции
Уровень фасада — это единая точка перехвата при миграции по методу «Strangler Fig»: каждый запрос от клиента сначала попадает в него, и он решает, какая система — устаревшая или новая — будет обслуживать этот запрос. Ничто другое в архитектуре не должно знать о том, что происходит миграция.
На практике команды создают этот фасад как обратный прокси или API-шлюз, расположенный перед обеими системами, выполняя сопоставление по пути URL, заголовку или функциональному флагу, не затрагивая при этом клиентский код.
Оригинальная запись в bliki Мартина Фаулера от 2004 года о приложении «Strangler Fig» описывает именно этот механизм: перехватить вызов, маршрутизировать его и постепенно переключать всё больше трафика на новую систему по мере миграции функциональных возможностей.
Эталонная реализация Azure Architecture Center от Microsoft развертывает фасад как экземпляр API Management или Application Gateway, выполняя маршрутизацию по пути, чтобы мигрированные конечные точки направлялись в новую систему, а всё немигрированное попадало в устаревшую систему. Паттерн «Strangler Fig» в AWS Prescriptive Guidance имеет ту же форму с использованием Amazon API Gateway или Application Load Balancer в качестве точки перехвата.
Всё это не бесплатно. Фасад — это еще один сервис, который нужно развертывать, отслеживать и обновлять, и он обрабатывает каждый запрос до тех пор, пока обе системы работают параллельно, что составляет весь срок миграции, а не только период внедрения.
Здесь важно одно различие: этот фасад не является уровнем защиты от коррупции (anti-corruption layer). Уровень защиты от коррупции оборачивает систему, которую вы намерены сохранить; фасад «Strangler» предназначен для того, чтобы исчезнуть, как только устаревшая система за ним будет выведена из эксплуатации.
Кто владеет данными во время переходного периода?
Тот, кто записывает последним во время переходного периода, владеет истиной, и решение этого вопроса заранее — это то, что отличает успешную миграцию по методу «Strangler Fig» от той, которая незаметно повреждает собственные данные. Это проблема, которую эталонные архитектуры обходят стороной.
Два механизма обеспечивают синхронизацию. Двойная запись (dual writes) отправляет каждое обновление как в устаревшую, так и в новую систему на уровне приложения, что просто реализовать, но неправильно при высокой нагрузке: частичный сбой между двумя записями оставляет одну систему впереди другой без записи о том, какая из них верна.
Change Data Capture (CDC) считывает журнал транзакций (write-ahead log) устаревшей базы данных и асинхронно воспроизводит изменения в новой системе, полностью разделяя путь записи. Согласно документации Confluent по CDC, конвейеры на основе журналов обычно вносят задержку репликации менее секунды при правильной настройке, что намного меньше задержек в несколько минут, характерных для подходов на основе опроса (polling).
Наш опыт в проектах по реплатформингу показывает, что команды по умолчанию выбирают двойную запись, потому что это укладывается в один спринт, а затем месяцами отлаживают рассинхронизацию, которую CDC сделал бы структурно невозможной. Выберите одну систему в качестве источника истины для каждого домена до того, как будет перенесен первый фрагмент, а не после. Даже при наличии CDC сверка данных обязательна.
Создавайте задачу сверки как полноценный результат, а не как задачу по очистке, и запускайте её до переключения, а не после того, как бизнес уже решил, что миграция завершена.
Уровень фасада, который мы описали ранее, не решает эту проблему. Он маршрутизирует запросы; у него нет мнения о том, какая база данных верна, когда они противоречат друг другу.
Какую функциональность следует «задушить» первой?
Правильная функциональность для первой «задушки» — это та, у которой меньше всего восходящих зависимостей и самый чистый стык, а не та, которая доставляет больше всего проблем. Именно здесь обычно ошибаются с последовательностью при миграции по методу «Strangler Fig».
Команды выбирают самый большой и сложный модуль первым, потому что это самая легкая победа для внутренней продажи идеи. Этот модуль почти всегда связан с общим изменяемым состоянием: таблицами, в которые пишут пять других сервисов, пакетными заданиями, которыми никто полностью не владеет, полями, которые нельзя переименовать, не сломав отчеты ниже по потоку.
«Задушить» его первым означает создание логики CDC и сверки для самой сложной проблемы с данными в системе до того, как команда хотя бы раз применила этот паттерн.
Если вы взвешиваете «Strangler Fig» против других вариантов, этот каталог архитектурных паттернов поможет понять, когда каждый подход подходит лучше всего. Мы выстраиваем последовательность иначе. Начните с функциональности, которая ориентирована на чтение, имеет узкую поверхность записи и находится за интерфейсом, который фасад может перехватить, не затрагивая общее состояние.
Каталог паттернов Криса Ричардсона описывает приложение «Strangler» так же: оно подходит для слабосвязанных компонентов с четкими границами, а не для самых запутанных. Сначала докажите работоспособность маршрутизации, пути двойной записи и задачи сверки на менее рискованной почве.
Оставьте модуль, затрагивающий общее изменяемое состояние, на потом, когда у команды появится работающая модель владения и отката, или исключите его вовсе, если связь нельзя разорвать.
Та же логика определяет последовательность декомпозиции монолита на практике.
Почему миграции «Strangler» останавливаются на 80%?
Миграции «Strangler» редко умирают на этапе запуска. Они умирают на 80% готовности, когда оставшиеся фрагменты — это те, которые никто не оценил, флагманская функциональность уже работает, а бизнес уже посчитал задачу выполненной.
Схема коллапса последовательна. Ранние части (срезы) легко отделяются, потому что они были выбраны по четким границам. Остаются области, которых все избегали при секвенировании: пакетные задания с недокументированными побочными эффектами, модуль устаревшей системы, в который три команды по-прежнему записывают данные напрямую, конвейеры отчетов, которые считывают старую схему, потому что никто не отвечает за их миграцию.
Ничто из этого никогда не было отдельной статьей расходов, поэтому нет запроса на бюджет и нет ответственного, кто бы его поднял.
Мы наблюдали, как фасад брал на себя вину в этой ситуации. Он был задуман как временный маршрутизирующий слой, но поскольку устаревшая система по-прежнему обслуживает 15% немигрированного трафика, вывод его из эксплуатации перестает быть чьей-либо задачей.
Решение структурное, а не мотивационное: финансируйте миграцию на этапах принятия решений, привязанных к выводу устаревшей системы из эксплуатации, а не к паритету функций в новой системе. Каждый этап должен требовать четкого ответа на вопрос "что по-прежнему записывает данные в старый источник, и кто отвечает за его перенос", прежде чем будет выделен бюджет на следующий срез.
В оригинальных работах Мартина Фаулера о паттерне "удушающей фиги" фасад рассматривается как средство достижения цели. Рассматривайте последние 20% как финансируемую фазу с собственным этапом, а не как задачу по очистке, и тогда это перестанет быть фазой, которая никогда не будет завершена.
Реальная стоимость параллельной работы двух систем
Параллельная работа двух систем стоит дороже, чем временный всплеск во время перехода: вы запускаете, исправляете и мониторите оба стека на протяжении всего проекта. Это означает удвоенные расходы на инфраструктуру, удвоенное дежурство и поверхность мониторинга, которую никто не учитывал в первоначальном бизнес-обосновании.
Слой фасада поглощает большую часть этой скрытой нагрузки. Он задумывается как маршрутизирующий слой, который исчезает после перехода последнего среза. На практике мы видели, как фасады превращались в постоянную инфраструктуру, потому что фасад — это единственный компонент, который перехватывает каждый запрос, затрагивающий как устаревшую, так и новую систему.
Он накапливает собственные логи, собственные правила оповещения, собственный регламент дежурства. Компонент, который никто не планировал поддерживать, все равно нуждается в поддержке, и эти затраты на обслуживание редко удаляются из бюджета после объявления миграции завершенной.
Сторона данных усугубляет это. Каждый путь двойной записи, каждый конвейер захвата измененных данных, каждая задача сверки — это вторая рабочая нагрузка, которой теперь владеет команда, и кто-то должен решить, какая система является источником истины, пока обе системы активны. Это решение не становится проще с увеличением продолжительности миграции, а лишь дороже для отмены.
Общее изменяемое состояние — это то, где стоимость перестает быть линейной. Когда две системы записывают данные в одну и ту же базу данных без четкой границы владения, состояния гонки проявляются только при производственной нагрузке, а сверка перестает быть запланированным пакетным заданием и превращается в постоянную категорию инцидентов. 94% успешных миграций поддерживали параллельную работу устаревших и новых систем в течение 3-6 месяцев.
Это сокращение инженерного времени является большой частью того, почему отслеживание технического долга должно включать собственные накладные расходы на миграцию, а не только устаревший код, который она заменяет.
Когда не следует использовать паттерн "удушающей фиги"
Паттерн "удушающей фиги" не работает, когда нет точки перехвата, когда общее изменяемое состояние связывает старый и новый код с одними и теми же данными, или когда устаревшая система достаточно мала, чтобы полная переработка (big-bang rewrite) была действительно дешевле.
Мартин Фаулер ввел этот термин в 2004 году для описания поэтапной замены функциональности, и его собственное определение предполагает, что вы можете вставить фасад перед вызовами, которые вы "удушаете". Нет точки перехвата — нет паттерна. Пакетные задания, которые напрямую читают базу данных, тесно связанные настольные клиенты и системы без слоя API или шины сообщений — все это попадает в эту ловушку.
Общее изменяемое состояние — это более сложный блокиратор. Если два сервиса записывают данные в одни и те же таблицы без четкой границы владения, фасад не может решить, какая сторона владеет данной строкой, и каждая двойная запись становится состоянием гонки вместо шага миграции. Разделение этой базы данных обычно является настоящим проектом, а не работой по "удушению", которая находится поверх нее.
Небольшие системы полностью меняют расчеты. Ниже определенного размера накладные расходы на параллельную работу двух систем в течение миграции стоят дороже, чем целенаправленная переработка, а инкрементальный подход лишь добавляет риск к этой стоимости.
Мы видели, как команды тратили реальное инженерное время на фасад для приложения, которое небольшая команда могла бы полностью переписать, потому что никто не проверил альтернативу полной переработки (big-bang rewrite) перед тем, как принять решение о применении паттерна.
Паттерн "удушающей фиги" против полной переработки (Big-bang rewrite): что дешевле?
Полная переработка (big-bang rewrite) стоит меньше на начальном этапе и больше в момент сбоя; паттерн "удушающей фиги" стоит больше на начальном этапе и меньше в тот момент, когда переработка могла бы произойти. Это все сравнение, и это вопрос времени, а не общей стоимости.
Полная переработка (big-bang rewrite) имеет одну статью финансирования и одну дату перехода. Бюджетируйте один раз, выпускайте один раз, утверждайте бизнес-кейс один раз. Паттерн "удушающей фиги" не имеет единого перехода.
Он запускает устаревшую и новую системы параллельно, иногда годами, и каждый месяц совпадения означает оплату обеих: инфраструктуры, лицензий и работы по сверке, которая предотвращает расхождение двойных записей и захвата измененных данных.
Кто-то должен отвечать за эту работу по сверке, и она редко получает ресурсы после первого квартала.
Профили рисков расходятся сильнее, чем бюджеты. Крупные проекты по переработке чаще всего превышают свой первоначальный бюджет и сроки. В среднем, крупные ИТ-проекты превышают бюджет на 45% и сроки на 7% (McKinsey Digital, 2012). Полная переработка (big-bang rewrite), которая терпит неудачу, делает это поздно и сразу, при этом устаревшая система уже частично выведена из эксплуатации.
Миграция по паттерну "удушающей фиги", которая останавливается, обычно останавливается на 80% выполнения, а не на нуле, потому что ранние срезы уже принесли ценность, которую бизнес зафиксировал, и прекратил финансирование остального.
Мы подробно рассматриваем структуру финансирования и этапов принятия решений, которая предотвращает такой застой, в нашем руководстве по принятию решений о модернизации.
Для системы, достаточно небольшой, чтобы полностью ее специфицировать, полная переработка (big-bang rewrite) часто является честным и более дешевым решением. Для всего, что вы не можете полностью оценить заранее, паттерн "удушающей фиги" предлагает более низкую гарантированную стоимость в обмен на меньший шанс проиграть всю ставку.
Как узнать, что миграция завершена?
Миграция завершена, когда устаревшая система не обрабатывает производственный трафик, и каждый домен, которым она владела, имеет подтвержденного владельца в новой системе, а не когда выпущена последняя функция. Доля трафика — единственная важная метрика, потому что слой фасада может незаметно продолжать маршрутизировать часть запросов на чтение в старую систему долго после того, как команда считает переход завершенным.
Проверьте три вещи, прежде чем объявить о завершении: слой фасада маршрутизирует 100% запросов на чтение и запись в новую систему, задача сверки выполнена чисто (без расхождений) в течение полного бизнес-цикла, а не одного спокойного дня, и каждый нижестоящий потребитель данных или API устаревшей системы был перенаправлен или официально объявлен устаревшим.
Пропустите любой из этих пунктов, и вы выведете из эксплуатации инфраструктуру, на которую кто-то другой по-прежнему незаметно полагается.
Вывод из эксплуатации фасадного слоя — это решение, отдельное от вывода из эксплуатации устаревшей системы, и их смешение приводит к тому, что временная инфраструктура становится постоянной.
Как только устаревшая система отключена, фасад выполнил свою задачу: либо удалите его, либо осознанно преобразуйте в постоянный интеграционный слой с новым названием, владельцем и SLA, чтобы он перестал числиться «временным» в плане миграции, на который уже никто не смотрит.
Мы видели фасады, рассчитанные на один квартал, которые продолжали маршрутизировать трафик спустя два года просто потому, что никто не взял на себя ответственность за решение об их удалении.
У полной переработки (rewrite) нет эквивалентного момента, есть только дата переключения и все то, что всплывает после нее.
Паттерн Strangler Fig при декомпозиции монолита и микросервисах
Применение паттерна Strangler Fig к декомпозиции монолита означает маршрутизацию одного ограниченного контекста (bounded-context) за раз через фасад, а не перенос всей доменной модели за один проход. Сам паттерн ограничен рамками миграции; определение того, где на самом деле проходят границы сервисов, — это отдельный вопрос, который мы рассматриваем в нашем сравнении монолитов и микросервисов.
Как только границы установлены, фасад перехватывает операции чтения и записи для мигрируемого фрагмента, а все остальные домены направляет напрямую в устаревшую систему. Каталог паттернов декомпозиции Криса Ричардсона перечисляет две основные стратегии проведения этих границ: по бизнес-возможностям или по поддоменам, и любая из них подходит в качестве единицы миграции для Strangler Fig.
Функциональные флаги (feature flags) делают такое переключение для каждого фрагмента обратимым. Переключите трафик одного домена на новую систему, понаблюдайте за ним и откатитесь к старому пути, не затрагивая маршрутизацию для еще не мигрировавших доменов. Без флагов каждый фрагмент становится дверью в одну сторону, из-за чего фасады, задуманные как временные, остаются в продакшене задолго после того, как устаревшая система должна была быть выведена из эксплуатации.
Когда не стоит использовать паттерн Strangler Fig?
Откажитесь от паттерна Strangler Fig, если в устаревшей системе есть общее изменяемое состояние, которое невозможно разделить, или если между вызывающими сторонами и базой данных нет точки перехвата. Монолит с одной общей таблицей и без API-слоя часто попадает в эту ловушку. В таких случаях честным ответом будет либо ограниченная полная переработка (big-bang rewrite), либо предварительный редизайн уровня данных.
Сколько времени занимает миграция по методу Strangler Fig?
Фиксированной длительности нет; все зависит от того, сколько возможностей нужно выделить и насколько запутанной является модель данных устаревшей системы. Миграции, которые кажутся завершенными на финальном этапе, часто буксуют, потому что оставшиеся фрагменты — это те, которые никто не оценил. Заложите бюджет и ресурсы на этот последний рывок, а не только на заметные ранние успехи.
Strangler Fig против полной переработки: что дешевле?
Полная переработка на бумаге дешевле, так как позволяет избежать одновременной работы двух систем, но она несет более высокие риски при поставке, поскольку ничего не работает, пока не будет готова вся система. Паттерн Strangler Fig обходится дороже на протяжении всего процесса, так как команды оплачивают инфраструктуру и старой, и новой систем одновременно. В случаях, когда риск неудачного переключения перевешивает дополнительные расходы на параллельную работу, побеждает паттерн Strangler Fig.
Определение того, подходит ли Strangler Fig для вашей миграции
Паттерн Strangler Fig оправдывает свою сложность, когда устаревшая система слишком велика или рискованна для замены за один релиз. Проверка этого предположения ничего не стоит до того, как вы начнете тратить инженерные ресурсы.
Если ваша команда взвешивает целесообразность новой разработки против поэтапной замены, не уверена, кто владеет данными в период наложения систем, или задается вопросом, как сверка данных влияет на обязательства по конфиденциальности в отношении регулируемых полей и условий соблюдения конфиденциальности, короткая консультация по оценке объема работ, доступная круглосуточно в разных часовых поясах, прояснит последовательность действий и затраты на фасад быстрее, чем поиск в Google.
Поговорите с нашей командой о вашей устаревшей системе, прежде чем она превратится в миграцию, которую никто не спланировал.
Если вы хотите узнать, как структурированный подход работает на практике, наши услуги по модернизации устаревших коммерческих систем описывают, как команды выстраивают последовательность таких миграций, не нарушая работу бизнеса.
