Миграция по паттерну «душитель фикуса» не терпит неудачу в первый день. Она проваливается ближе к концу, когда оставшиеся фрагменты оказываются неохваченными рамками проекта, а бизнес уже зафиксировал победу.
Канонические описания от Фаулера, Microsoft и AWS хорошо объясняют форму этого паттерна; при этом в них гораздо меньше говорится о том, кому принадлежат данные во время периода совместной работы, во сколько на самом деле обходится поддержка фасада или почему команды останавливаются на полпути.
Это руководство продолжает то место, где эти справочные материалы заканчиваются. Оно исходит из того, что вы уже приняли решение модернизировать систему, а не пересоздавать ее заново, и что вариант полного переписывания приложения был рассмотрен и отклонен.
Паттерн «душитель фикуса» в двух предложениях
Паттерн «душитель фикуса» заменяет устаревшую систему по одному функциональному элементу за раз, направляя трафик через фасад до тех пор, пока на старый код ничего не будет указывать и устаревшую систему наконец не отключат. Мартин Фаулер назвал и описал этот паттерн в 2004 году, и с тех пор это определение не нуждалось в пересмотре.
Чего не затрагивают канонические статьи, так это реалии процесса поставки: одновременный запуск двух систем, оплату обеих и поддержание согласованности данных между ними на протяжении всей миграции. В ходе проектов по реплатформингу мы неоднократно наблюдали, как фасады, изначально запланированные как временные, переживали устаревшие системы, для вывода из эксплуатации которых они создавались.
Это руководство продолжает материал блога Фаулера bliki, где дается определение паттерна, Центра архитектуры Azure от Microsoft Learn, описывающего эталонную реализацию, руководства AWS Prescriptive Guidance, разбирающего механику поставки, и Википедии, резюмирующей общепринятое определение: стоимость маршрутизации, двойная запись в сочетании с механизмом отслеживания изменений данных (CDC) и точка, на которой большинство миграций фактически буксуют.
Как фасад маршрутизирует запросы во время миграции
Слой фасада — это единственная точка перехвата при миграции по паттерну «душитель фикуса»: каждый запрос от клиента попадает сначала на него, и именно он решает, какая система — старая или новая — обработает этот запрос. Ничто другое в архитектуре не должно знать о происходящей миграции.
На практике команды строят этот фасад в виде обратного прокси-сервера (reverse proxy) или API-шлюза, расположенного перед обеими системами и выполняющего сопоставление по URL-пути, заголовку или флагу функции, не затрагивая клиентский код.
Оригинальная статья Мартина Фаулера 2004 года в bliki о приложении-душителе описывает именно этот механизм: перехватить вызов, маршрутизировать его и постепенно перенаправлять все большую часть трафика на новую систему по мере миграции функциональных возможностей.
Эталонная реализация в Центре архитектуры Azure от Microsoft развертывает фасад как экземпляр управления API (API Management) или шлюз приложений (Application Gateway), выполняя маршрутизацию по путям, так что мигрировавшие конечные точки разрешаются в новую систему, а все немигрировавшее перенаправляется на устаревшую систему. Паттерн «душитель фикуса» в AWS Prescriptive Guidance имеет ту же форму с Amazon API Gateway или Application Load Balancer в качестве точки перехвата.
Ничто из этого не работает бесплатно. Фасад — это еще один сервис, который нужно развертывать, мониторить и патчить, и он задействован в обработке каждого запроса до тех пор, пока обе системы работают бок о бок, то есть в течение всей миграции, а не какого-то окна развертывания.
Здесь важно отметить одно различие: этот фасад не является противокоррупционным слоем. Противокоррупционный слой оборачивает систему, которую вы намерены сохранить; фасад-душитель создается с расчетом на то, что он исчезнет, как только устаревшая система за ним будет выведена из эксплуатации.
Кому принадлежат данные во время периода совместной работы?
Тот, кто делает последнюю запись в период совместного использования, владеет истиной, и определение этого фактора на старте — то, что отличает успешную миграцию по паттерну «душитель фикуса» от той, которая тихо разрушает собственные данные. Именно эту проблему эталонные архитектуры обходят стороной.
За синхронизацию отвечают два механизма. Двойная запись передает каждое обновление как в устаревшую, так и в новую систему на уровне приложения; этот подход прост в реализации, но несостоятелен под нагрузкой: частичный сбой между двумя записями оставляет одну систему впереди другой без каких-либо записей о том, какая из них права.
Захват изменений данных (CDC) считывает журнал упреждающей записи (write-ahead log) устаревшей базы данных и асинхронно воспроизводит изменения в новой системе, полностью разделяя путь записи. Согласно документации Confluent по CDC, конвейеры CDC на основе журналов обычно обеспечивают задержку репликации менее чем в секунду при правильной настройке, что намного ниже задержки в несколько минут, характерной для подходов на основе опроса (polling).
Наш опыт участия в проектах по реплатформингу показывает, что команды по умолчанию выбирают двойную запись, поскольку она укладывается в рамки одного спринта, а затем месяцами отлаживают рассинхронизацию, которую CDC сделал бы структурно невозможной. Выберите одну систему в качестве источника истинных данных для каждого домена до того, как будет отправлен первый фрагмент, а не после. Даже при наличии CDC сверка данных не является опциональной.
Создавайте задачу сверки данных как первоклассный артефакт, а не как задачу по очистке, и запускайте ее до переключения (cutover), а не после того, как бизнес уже решил, что миграция завершена.
Описанный ранее слой фасада эту проблему не решает. Он маршрутизирует запросы; у него нет собственного мнения о том, какая база данных права, когда они расходятся во мнениях.
Какой функционал следует «душить» первым?
Правильная функциональность для первоочередного «удушения» — это та, у которой меньше всего восходящих (upstream) зависимостей и самый чистый интерфейс взаимодействия (seam), а не та, которая доставляет больше всего проблем. Именно здесь последовательность действий при миграции по паттерну «душитель фикуса» обычно нарушается.
Команды выбирают самый крупный и неприглядный модуль в первую очередь, потому что его проще всего продать внутри компании. Этот модуль почти всегда связан с общим изменяемым состоянием: таблицами, в которые пишут еще пять сервисов, пакетными заданиями, которыми никто полностью не владеет, полями, которые никто не может переименовать, не нарушив работу нисходящего (downstream) отчета.
«Удушить» его в первую очередь означает создание логики захвата измененных данных (CDC) и сверки для самой сложной проблемы с данными во всем портфеле до того, как команда применила этот паттерн хотя бы единожды.
Если вы сопоставляете паттерн «душитель фикуса» с другими вариантами, данный каталог архитектурных паттернов помогает определить, когда какой подход подходит лучше всего. Мы выстраиваем последовательность иначе. Начните с функционала, который интенсивно выполняет чтение, имеет узкую зону записи и находится за интерфейсом, который слой фасада может перехватить, не затрагивая общее состояние.
Каталог паттернов Криса Ричардсона описывает приложение-душитель точно так же: оно подходит для слабо связанных функциональных возможностей с четкими границами, а не для наиболее запутанных. Сначала докажите работоспособность маршрутизации, пути двойной записи и задачи сверки на малорискованной почве.
Оставьте модуль, затрагивающий общее изменяемое состояние, напоследок — когда у команды появится работающий шаблон владения и отката — или исключите его вовсе, если эту связь невозможно разорвать.
Эта же логика на практике определяет последовательность декомпозиции монолитов.
Почему миграции методом «душения» буксуют на отметке 80%
Миграции методом «душения» редко терпят неудачу на старте. Они останавливаются на отметке 80% готовности, когда оставшиеся фрагменты оказываются теми самыми неохваченными элементами, флагманский функционал уже запущен, а бизнес уже зафиксировал победу.
Паттерн разрушения предсказуем. Ранние компоненты выделяются легко, так как для них были выбраны аккуратные точки разделения. То, что остается — это домены, которых все избегали при секвенировании: пакетные задания с недокументированными побочными эффектами, модуль устаревшей системы, в который три команды до сих пор пишут напрямую, и отчетные конвейеры, считывающие старую схему, потому что никто не взял на себя ответственность за их миграцию.
Ничего из этого никогда не было отдельной строкой расходов, поэтому нет ни запроса на бюджет, ни ответственного лица, которое могло бы его подать.
Мы наблюдали, как фасад принимает на себя всю вину в этой ситуации. Он планировался как временный уровень маршрутизации, но поскольку устаревшая система все еще обслуживает 15% немигрированного трафика, его вывод из эксплуатации перестает быть чьей-либо обязанностью.
Решение носит структурный, а не мотивационный характер: финансируйте миграцию через контрольные точки (decision gates), привязанные к выводу из эксплуатации устаревшей системы, а не к паритету функциональности в новой системе. Каждая такая точка должна требовать четкого ответа на вопросы «что все еще пишет в старый источник?» и «кто отвечает за перенос?» до того, как будет выделен бюджет на следующий этап.
Оригинальный труд Мартина Фаулера о паттерне «душитель» (strangler fig) рассматривает фасад как средство достижения цели. Относитесь к последним 20% работы как к финансируемому этапу с собственным гейтом, а не как к задаче по очистке, и тогда это перестанет быть проектом, который никогда не запускается.
Реальная стоимость параллельной работы двух систем
Параллельная работа двух систем обходится дороже, чем временное увеличение затрат во время перехода: вам приходится запускать, патчить и мониторить оба стека в течение всего проекта. Это означает удвоение затрат на инфраструктуру, удвоение нагрузки на дежурных инженеров и появление зоны мониторинга, объем которой никто не закладывал в первоначальное бизнес-обоснование.
Уровень фасада поглощает большую часть этой скрытой нагрузки. Его планируют как прослойку маршрутизации, которая исчезнет, как только будет переключен последний компонент. На практике мы видели, как фасады превращаются в постоянную инфраструктуру, потому что фасад — это единственный компонент, который перехватывает каждый запрос, затрагивающий как старую, так и новую систему.
В нем появляются собственные логи, собственные правила оповещения, собственный регламент для дежурных. Компонент, обслуживать который никто не планировал, все равно нуждается в поддержке, и эти затраты на обслуживание редко исключаются из бюджета после того, как миграция официально объявлена завершенной.
Работа с данными усугубляет ситуацию. Каждый путь двойной записи, каждый конвейер захвата измененных данных (CDC), каждая задача сверки — это вторая рабочая нагрузка, которой теперь владеет команда, и кто-то должен решить, какая система хранит достоверный источник данных (source of truth), пока обе они активны. Это решение не становится проще со временем, чем дольше длится миграция, оно лишь дороже в отмене.
Общее изменяемое состояние — это то место, где затраты перестают быть линейными. Когда две системы пишут в одну и ту же базу данных без четких границ ответственности, гонки данных (race conditions) проявляются только под рабочей нагрузкой в продакшене, а сверка перестает быть запланированным пакетным заданием и превращается в постоянную категорию инцидентов. 94% успешных миграций удерживали старую и новую системы в параллельном режиме в течение 3–6 месяцев.
Такое размывание инженерного времени — веская причина, почему отслеживание технического долга должно включать собственные накладные расходы миграции, а не только заменяемый устаревший код.
Когда не стоит использовать паттерн «душитель»
Паттерн «душитель» терпит неудачу, когда нет точки перехвата, когда общее изменяемое состояние связывает старый и новый код с одними и теми же данными, или когда устаревшая система настолько мала, что полное переписывание с нуля (big-bang rewrite) действительно обойдется дешевле.
Мартин Фаулер ввел этот термин в 2004 году для описания пошаговой замены функциональности, и его определение предполагает возможность вставить фасад перед вызовами, которые вы «душите». Нет точки перехвата — нет паттерна. Пакетные задания, которые читают базу данных напрямую, тесно связанный десктопный клиент и системы без промежуточного уровня API или шины сообщений — все они попадают в эту ловушку.
Общее изменяемое состояние — более серьезное препятствие. Если два сервиса пишут в одни и те же таблицы без четких границ ответственности, фасад не может решить, какая сторона владеет конкретной строкой, и каждая двойная запись превращается в состояние гонки, а не в шаг миграции. Разделение этой базы данных обычно и является настоящим проектом, а не работа с фасадом поверх нее.
Небольшие проекты полностью меняют математику. Ниже определенного масштаба накладные расходы на одновременную работу двух систем в течение всей миграции стоят дороже, чем целенаправленное переписывание, и инкрементальный подход лишь добавляет риски к этим затратам.
Мы видели, как команды тратили реальное инженерное время на создание фасада для приложения, которое небольшая команда могла бы переписать целиком с нуля, потому что никто не проверил на прочность альтернативу с полным переписыванием до того, как подписаться на этот паттерн.
Паттерн «душитель» против полного переписывания (Big-bang rewrite): что дешевле?
Полное переписывание с нуля стоит дешевле на старте и дороже в момент неудачи; паттерн «душитель» стоит дороже на старте и дешевле в тот момент, когда переписанная система должна была бы заработать. В этом и заключается все сравнение, и это вопрос времени, а не общей стоимости.
У полного переписывания есть одна статья финансирования и одна дата перехода. Заложите бюджет один раз, выпустите релиз один раз, защитите бизнес-обоснование один раз. У паттерна «душитель» нет единой даты перехода.
Он запускает старую и новую системы параллельно, иногда годами, и каждый месяц совпадения означает оплату обоих решений: инфраструктуры, лицензий и работы по сверке данных, которая не дает расходиться двойной записи и механизмам захвата изменений.
Кто-то должен отвечать за эту задачу сверки, и на нее редко выделяются ресурсы после первого квартала.
Профили рисков расходятся сильнее, чем бюджеты. Крупные проекты по переписыванию чаще всего выходят за рамки исходного бюджета и графика. В среднем крупные ИТ-проекты превышают бюджет на 45% и сроки на 7% (McKinsey Digital, 2012). Полное переписывание с нуля, которое терпит неудачу, делает это поздно и сразу целиком, когда устаревшая система уже частично выведена из эксплуатации.
Застопорившаяся миграция методом «душителя» обычно останавливается на отметке 80% выполнения, а не на нуле, потому что ранние этапы уже принесли ценность, которую бизнес зафиксировал в отчетах, после чего финансирование остальной части прекратилось.
Мы подробно описываем структуру финансирования и контрольных точек, предотвращающих такую остановку, в нашем руководстве по принятию решений о модернизации.
Для инфраструктуры, достаточно компактной для полного описания, переписывание с нуля часто является честным и более дешевым ответом. Для всего остального, что вы не можете полностью оценить заранее, паттерн «душитель» жертвует гарантированно меньшими затратами ради меньшего риска проиграть всю ставку.
Как узнать, что миграция завершена?
Миграция завершена, когда устаревшая система обрабатывает ноль производственного трафика, а у каждого принадлежащего ей домена есть проверенный владелец в новой системе, а не тогда, когда выпускается последняя функция. Доля трафика — единственный имеющий значение показатель, поскольку уровень фасада может незаметно продолжать направлять часть чтений в старую систему задолго до того, как команда решит, что переход завершен.
Проверьте три вещи, прежде чем объявлять работу законченной: уровень фасада направляет 100% как чтений, так и записей в новую систему; задача сверки отработала безупречно (нулевое расхождение) в течение полного бизнес-цикла, а не одного спокойного дня; и каждый нижестоящий потребитель данных или API устаревшей системы был перенаправлен или официально объявлен устаревшим.
Пропустите хотя бы одно из этого, и вы выведете из эксплуатации инфраструктуру, от которой кто-то другой все еще тихо зависит.
Вывод фасадного слоя из эксплуатации — это отдельное решение от вывода из эксплуатации устаревшей системы, и их смешение приводит к тому, что временная инфраструктура становится постоянной.
Как только устаревшая система отключена, фасад выполняет свою работу: либо удалите его, либо осознанно превратите в постоянный интеграционный слой с новым названием, владельцем и соглашением SLA, чтобы он перестал числиться как «временный» на доске миграций, на которую больше никто не смотрит.
Мы видели фасады, запланированные на один квартал, которые продолжали маршрутизировать трафик два года спустя просто потому, что никто не взял на себя ответственность принять решение об их удалении.
У переписывания нет эквивалентного момента, есть только дата переключения и все, что всплывает после нее.
Паттерн «Душитель» при декомпозиции монолита и в микросервисах
Применение паттерна «Душитель» к декомпозиции монолита означает маршрутизацию одного фрагмента ограниченного контекста за раз через фасад, а не перенос всей доменной модели за один проход. Сам паттерн ограничен рамками миграции; определение того, где на самом деле проходят границы сервисов, — это отдельный вопрос, который рассматривается в нашем сравнении монолитов и микросервисов.
Как только границы заданы, фасад перехватывает операции чтения и записи для мигрирующего фрагмента, оставляя все остальные домены направленными напрямую в устаревшую систему. В каталоге паттернов декомпозиции Криса Ричардсона (Chris Richardson) перечислены две основные стратегии проведения этих границ: по бизнес-возможностям или по поддоменам, и любая из них подходит в качестве единицы миграции для паттерна «Душитель».
Флаги функций (feature flags) делают такое переключение для каждого отдельного фрагмента обратимым. Переключите трафик для одного домена на новую систему, понаблюдайте за ней и откатитесь на старый путь, не затрагивая маршрутизацию для еще не мигрировавших доменов. Без флагов каждый фрагмент превращается в дверь в один конец, из-за чего фасады, запланированные как временные, остаются в продакшене еще долго после того, как устаревшая система должна была отправиться на покой.
Когда не стоит использовать паттерн «Душитель»?
Пропустите паттерн «Душитель», если у устаревшей системы есть общее изменяемое состояние, которое вы не можете разделить, или если между вызывающими абонентами и базой данных нет точки перехвата. Монолит с одной общей таблицей и без слоя API часто попадает в эту ловушку. В таких случаях честным ответом будет ограниченное радикальное переписывание (big-bang) или предварительная переработка слоя данных.
Сколько времени занимает миграция по паттерну «Душитель»?
У нее нет фиксированной продолжительности; это зависит от того, сколько возможностей нужно выделить и насколько запутана модель данных устаревшей системы. Миграции, которые выглядят завершенными на последнем этапе, часто буксуют, потому что оставшиеся фрагменты никто не оценил по объему. Закладывайте бюджет и персонал на этот последний отрезок, а не только на заметные ранние победы.
Паттерн «Душитель» против радикального переписывания: что дешевле?
Радикальное переписывание (big-bang) дешевле на бумаге, так как позволяет избежать одновременной работы двух систем, но оно несет в себе более высокие риски поставки, поскольку ничто не выпускается в продакшн, пока не будет готова вся система. Паттерн «Душитель» обходится дороже в течение всего периода реализации, так как команды платят за старую и новую инфраструктуру одновременно. Там, где риск неудачного переключения перевешивает дополнительные затраты на параллельную работу, побеждает паттерн «Душитель».
Как определить, подходит ли паттерн «Душитель» для вашей миграции
Паттерн «Душитель» оправдывает свою сложность, когда устаревшая система слишком велика или опасна для замены за один релиз. Проверка этого предположения ничего не стоит до того, как вы выделите инженерные ресурсы.
Если ваша команда выбирает между новой разработкой и инкрементальной заменой, не уверена, кому принадлежат достоверные данные во время периода перекрытия, или задается вопросом, как сверка данных влияет на обязательства по конфиденциальности для регулируемых полей и условий privacy compliance, короткий разговор по оценке объема, доступный круглосуточно в разных часовых поясах, прояснит последовательность шагов и затраты на фасад быстрее, чем поиск в Google.
Пообщайтесь с нашей командой по поводу вашей устаревшей системы, пока она не превратилась в миграцию, объем которой никто не оценил.
Если вы предпочитаете узнать, как структурированный подход работает на практике, наши услуги по модернизации устаревших систем электронной коммерции описывают, как команды выстраивают последовательность этих миграций, не подрывая работу бизнеса.
