Тема 3/5: Разбивка монолитной системы на микросервисы → Урок 1/4

Паттерн Strangler Fig

В прошлой теме мы разобрали технологии и паттерны, которые используют для проектирования микрофронтендов.
Обычно микрофронтенды внедряют в приложение, когда там уже есть микросервисы. Сначала разбирают на части внутреннюю логику, а потом — фронтенд.
Сделаем шаг назад. В этой теме посмотрим на проблемы монолита со стороны бэкенда и расскажем, как спроектировать микросервисы и провести миграцию.
⚙ Важное уточнение
На практике, когда речь заходит о миграции монолита, приложение уже на том уровне сложности, когда команды задействуют продвинутые DevOps-практики. Готовых инфраструктурных решений не хватает — нужно копаться под капотом и настраивать всё под себя.
Естественно, что среди лучших практик разработки микросервисов важное место занимают комплексные инструменты развёртывания и CI/CD. В этом спринте мы не будем на них останавливаться, а рассмотрим техники работы с микросервисами в общем. Позже мы ещё вернёмся к инструментам развёртывания и микросервисам.
Сергей
Поехали!

Проблемы монолитного бэкенда

Возьмём уже знакомый пример. Компания «Шайба» продаёт спортивные товары. У неё есть онлайн-магазин — это большое и сложное монолитное приложение. Оно целиком написано на Django.
В приложении пять бизнес-функций: каталог товаров, профиль пользователя, корзина, управление заказами и обработка платежей.
Архитектура выглядит так:
Поначалу разработка шла быстро, а приложение работало надёжно. Но бизнес рос — росло и приложение. Сейчас монолитный бэкенд создаёт проблемы:
  • в производительности приложения есть узкие места,
  • развёртывание занимает много времени,
  • обслуживание обходится дорого,
  • монолитная архитектура недостаточно гибкая — компании сложно адаптироваться к изменениям на рынке и внедрять инновации.
Остановимся на последней проблеме и посмотрим, как проявляется тяжеловесность монолита.
Допустим, конкуренты «Шайбы» внедрили новую систему доставки — теперь клиент может примерить одежду перед оплатой. Функция пользуется популярностью у пользователей. Чтобы не отставать, команда «Шайбы» решила внедрить такую же функциональность. Однако на этапе планирования стало понятно, что реализовать её не получится. Новая система доставки затронет все системы приложения: от хранения товара на складе до оплаты. Риск сломать систему превышает возможную прибыль.
В итоге «Шайба» отстаёт от конкурентов. С монолитной архитектурой приложение не успевает за потребностями бизнеса.
Одно из решений проблемы — переход с монолитной архитектуры на микросервисы.
Сергей
Подробнее
В микросервисной архитектуре приложение разбивают на несколько сервисов, которые можно разрабатывать, развёртывать и масштабировать независимо друг от друга. Каждый сервис выполняет одну функцию.
Например, микросервисная архитектура в «Шайбе» может выглядеть так:
С такой архитектурой будет проще внедрить новую функциональность. Изменения затронут не всё приложение, а три сервиса из шести: сервис управления заказами, профиль пользователя и обработку платежей.
Сергей
Есть подводные камни?
Переход на микросервисы — это сложный и ответственный процесс. Если провести миграцию неправильно, новая архитектура только увеличит количество проблем.
Есть разные стратегии миграции. Подходы, которые помогают снизить риски, называют паттернами. А подходы, которые риски увеличивают, — антипаттернами.

Антипаттерн «Большой взрыв»

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

Паттерн Strangler Fig

Паттерн Strangler Fig придумал Мартин Фаулер в начале 2000-х. Название паттерна отсылает к поведению фикусов-душителей (strangler figs).
Эти деревья растут в тропиках и субтропиках. Леса там густые, поэтому растениям приходится конкурировать за свет и воду. Фикусы-душители адаптировались к постоянной борьбе и разработали свою стратегию выживания.
Сначала семечко фикуса попадает на ветку или крону другого дерева. Окрепнув, растение спускает свои корни по стволу и укореняется в почве. Постепенно фикус-душитель обвивает побегами всё дерево и поднимает свои ветви над его кроной. Забирая свет и воду, новое дерево медленно убивает старое. В итоге дерево-хозяин погибает, а фикус-душитель занимает его место.
Сергей
При чём здесь архитектура?
Паттерн Strangler Fig предлагает итеративный подход к миграции. Монолитный бэкенд онлайн-магазина — это дерево-хозяин, а микросервисы — фикус-душитель. Новую систему постепенно создают по краям старой: компоненты по очереди извлекают из монолита и заменяют на микросервисы.
Над микросервисами работают без спешки. Новую архитектуру развивают в течение нескольких лет, пока она не «задушит» монолит. При релизе каждого микросервиса разработчики перенаправляют запросы от монолита к новой системе. В итоге бэкенд отмирает по кусочкам, а команда может дорабатывать готовые микросервисы по отзывам пользователей.
Такой подход позволяет постоянно совершенствовать систему и минимизировать риски, которые связаны с большими изменениями.
🏛️ Минутка истории. Можете прочитать пост, который Мартин Фаулер написал в 2004 году. Именно после этой публикации паттерн Strangler Fig начал завоёвывать популярность.

Пример реализации паттерна

Итак, компания «Шайба» решила перейти от монолита к более гибкой архитектуре микросервисов. В ходе обсуждения сформулировали два требования к миграции:
  • Нужно максимально снизить риски, связанные с полной перестройкой системы. Если изменения приведут к простою приложения, компания потеряет прибыль.
  • Нужно обеспечить непрерывную реализацию новых функций, чтобы догнать конкурентов.
Алекс — ведущий разработчик «Шайбы» — предложил использовать паттерн Strangler Fig. Он решает обе эти задачи.
Последовательность разработки микросервисов зависит от потребностей бизнеса. Например, можно начать миграцию с написания сервиса, которого в приложении ещё не было. Или выбрать ту часть приложения, где больше всего legacy-кода.
Команда Алекса первым делом выделила в отдельный микросервис систему авторизации и аутентификации. Это позволило сохранить предыдущий функционал и сделать систему регистраций новых пользователей более гибкой. Теперь клиентов можно делить на разные группы и сообщества — например, в зависимости от вида спорта, которым они занимаются. Это поможет настроить рекламу.
Так будет выглядеть архитектура приложения на разных этапах миграции:

Монолитная архитектура до начала миграции.

Задание 1

Ваша компания решила перейти на микросервисную архитектуру. Вам поручили разработать план миграции с использованием паттерна Strangler Fig. Как вы будете проводить переход?
Выберете один ответ.

Преимущества паттерна Strangler Fig

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

1. Постепенная замена монолита

Итеративный подход помогает:
  • Уменьшить количество сбоев. Заменяя компоненты приложения по очереди, компания может продолжить свою деятельность без серьёзных перерывов.
  • Повысить адаптивность новой системы. Постепенный переход позволяет разработчикам освоиться с новыми требованиями и технологиями. Это гарантирует, что новая система будет развиваться в соответствии с целями бизнеса.
  • Обучить и адаптировать команду. Чтобы реализовать «Большой взрыв», нужна суперопытная команда, которая справится с быстрым переходом. С паттерном Strangler Fig всё проще: у разработчиков есть время, чтобы учиться и корректировать свои стратегии в процессе миграции. Больше шанс, что специалисты будут принимать качественные решения и эффективно проведут внедрение.

2. Снижение рисков и управление ими

Паттерн Strangler Fig снижает риски, которые сопровождают миграцию. Этому способствуют:
  • Инкрементные изменения. Небольшие изменения легче тестировать, отслеживать и откатывать. Это снижает вероятность катастрофических сбоев.
  • Параллельные операции. Микросервисы запускают параллельно с существующими монолитными компонентами. Если появятся проблемы, их можно будет устранить, не затрагивая всю систему. Например, новый микросервис работает на продакшене с ошибками. Чтобы его доработать, вы сможете перенаправить запросы обратно на компонент монолита с помощью маршрутизации.
  • Контролируемое развёртывание. Новые функции внедряют только после тщательного тестирования и проверок на каждом этапе. А значит, они не нарушат работу пользователей.

3. Инкрементная доставка новых функций в процессе миграции

Паттерн даёт возможность релизить новые функции на протяжении всей миграции. Это хорошо для бизнеса, потому что:
  • Приложение продолжает развиваться. Новые функции и улучшения можно релизить по готовности. Для этого не нужно ждать окончания миграции. Так система останется динамичной и сможет чутко реагировать на потребности пользователей.
  • Пользовательский опыт улучшается. По мере модернизации и оптимизации компонентов пользователи увидят, что приложение работает лучше: повышается производительность и надёжность знакомых функций. Параллельно разработчики добавляют новую функциональность — красота!
  • Система адаптируется к ожиданиям пользователей. Инкрементная разработка предполагает, что вы получаете обратную связь по кусочкам. Не на всю систему сразу, а на каждое обновление отдельно. Благодаря этому вы сможете учесть критику и пожелания при разработке следующих обновлений.

4. Эффективное решение проблемы технического долга

Паттерн Strangler Fig помогает управлять техническим долгом сразу с трёх сторон:
  • Систематический рефакторинг. Постепенная миграция — это фактически последовательный и глубокий рефакторинг. Каждый микросервис можно спроектировать и разработать с использованием лучших практик и современных технологий. Это затормозит накопление технического долга.
  • Замена устаревших компонентов в первую очередь. Миграцию можно начать с компонентов, у которых самый большой технический долг. Тогда каждое обновление вы будете повышать производительность системы и упрощать её обслуживание.
  • Разработка документации и поддержание стандартов. По мере разработки микросервисов вы сможете обеспечить надлежащее документирование и соблюдение стандартов кодирования. В результате вы получите систему, которая удобна в обслуживании и легко масштабируется.

Задание 2

Перед вами несколько ситуаций. Выберете то преимущество паттерна Strangler Fig, которое раскрывается в конкретной ситуации.
Онлайн-магазин внедряет новую функциональность через микросервисы. Монолитная система не меняется, но пользователи получают новые функции.
Инкрементная доставка новых функций
Компания поэтапно переводила свои финансовые системы в микросервисную архитектуру. Это позволило избежать значительных сбоев в процессе миграции и обеспечило непрерывность предоставления услуг.
Постепенная замена монолита
Компания тестирует каждый микросервис на отдельном сервере, чтобы избежать сбоев в системе.
Снижение рисков
Компания заменила устаревший монолит современными миросервисами. Каждый из них разрабатывали с использованием новейших стандартов и технологий.
Управление техническим долгом

Итоги

  • У монолитного бэкенда такие проблемы: в производительности приложения появляются узкие места, развёртывание занимает много времени, обслуживание обходится дорого, монолитная архитектура недостаточно гибкая. Всё это приводит к тому, что компании сложно адаптироваться к изменениям на рынке и внедрять инновации.
  • Чтобы уйти от проблем монолита, компания может перейти на микросервисы. В микросервисной архитектуре приложение разбивают на несколько сервисов, которые можно разрабатывать, развёртывать и масштабировать независимо друг от друга.
  • Есть разные стратегии для перехода от монолитной системы к микросервисам. Подходы, которые помогают снизить риски, называют паттернами. А подходы, которые риски увеличивают, — антипаттернами.
  • Стратегия «Большой взрыв» — это антипаттерн. В рамках этой стратегии компания переносит в микросервисную архитектуру сразу всё приложение. Такой переход может привести: к длительному простою после релиза, к ошибкам в новой системе, к утрате информации из монолитной базы данных, к росту технического долга.
  • Паттерн Strangler Fig — это, напротив, безопасная стратегия миграции. Он предлагает итеративный подход к замене устаревшей системы. Новую систему постепенно создают по краям старой: компоненты по очереди извлекают из монолита и заменяют на микросервисы.
  • У паттерна Strangler Fig четыре преимущества: постепенная замена монолита, снижение рисков и управление ими, инкрементная доставка новых функций в процессе миграции, эффективное решение технического долга.
В следующем уроке продолжим разбирать паттерн. Расскажем, как его реализовать и из каких шагов состоит процесс миграции.