Как реализовать Strangler Fig

Итак, у онлайн-магазина «Шайба» есть монолитное приложение, которое команда решила разделить на микросервисы с использованием паттерна Strangler Fig. Сосредоточившись на постепенном извлечении и постоянном совершенствовании, магазин сможет модернизировать своё приложение и свести к минимуму сбои в его работе.
В этом разделе вы погрузитесь подробнее в практические шаги, необходимые для реализации паттерна Strangler Fig. Узнаете, как преобразовать монолитное приложение в современную масштабируемую архитектуру микросервисов. Изучите методы декомпозиции монолита, стратегии маршрутизации и лучшие практики.
В общих чертах применение паттерна выглядит так:
Но обо всём по порядку.

Как реализовать паттерн Strangler Fig?

Шаг 1. Определение доменной области

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

Шаг 2. Проектирование и разработка новых микросервисов

После того как компоненты определены, нужно спроектировать и разработать новые микросервисы. На этом шаге полезно следить за обновлениями в сфере разработки, чтобы перенимать лучшие современные практики.
Сейчас основные принципы проектирования микросервисов можно сформулировать так:
  1. Принципы проектирования сервисов
    • Убедитесь, что у каждого микросервиса есть единственная, чётко определённая зона ответственности.
    • Проектируйте микросервисы с минимальной зависимостью от других сервисов.
    • Группируйте связанную функциональность в рамках одного сервиса для поддержания высокой согласованности.
  2. Технологический стек
    • Выбирайте технологии, которые больше всего соответствуют требованиям сервиса и общим архитектурным целям.
    • Определяйте чёткие контракты API для каждого микросервиса, чтобы облегчить взаимодействие и интеграцию.
  3. Практики разработки
    • Используйте технику TDD, чтобы обеспечить тщательное тестирование каждого микросервиса.
    • Внедряйте конвейеры CI/CD для автоматизации процессов тестирования и развёртывания.
Например, на этом этапе команда магазина «Шайба» создала микросервисы с единой ответственностью — специализированный сервис каталога товаров и сервис пользователей. Так получилось обеспечить их свободное взаимодействие и высокую согласованность. Для автоматизации тестирования и развёртывания этих сервисов разработчики внедрили конвейеры CI/CD.
После этого можно переходить к третьему шагу.

Шаг 3. Перенаправление трафика

Перенаправление трафика с монолитных компонентов на вновь созданные микросервисы важно для плавного перехода. Стратегий перенаправления трафика существует несколько, и их можно использовать одновременно.
  1. Маршрутизация на основе прокси
    • Обратный прокси-сервер можно использовать для маршрутизации запросов либо к монолиту, либо к новым микросервисам на основе определённых правил.
    • API-шлюз реализуется для управления и маршрутизации трафика, обеспечивая единую точку входа для всех клиентских запросов.
  2. Фича-тогглы
    • Переключатели функций нужны для управления развёртыванием новых функций, чтобы постепенно перенаправлять трафик на новые сервисы.
  3. Канареечные релизы, или инкрементальное смещение трафика
    • Канареечные релизы постепенно переводят трафик на новые услуги, отслеживая производительность и стабильность перед полным развёртыванием.
В магазине «Шайба» для маршрутизации трафика между монолитом и новыми микросервисами был настроен обратный прокси-сервер. Дополнительно команда настроила переключатели функций, которые позволяли постепенно внедрять новые возможности и контролировать перенаправление трафика.

Шаг 4. Мониторинг и верификация микросервисов

Теперь, когда микросервисы созданы и берут на себя какой-то объём работы, нужно оставаться уверенным, что это надёжно и эффективно, а в обратном случае оперативно исправлять ошибки. Четвёртым шагом в паттерне Strangler Fig устанавливаются метрики производительности и настраивается мониторинг и верификация микросервисов.
Что считать эффективной работой микросервисов, команда решает заранее и определяет значения, которые будут свидетельствовать, что все процессы проходят как надо.
Для оценки производительности и надёжности микросервисов используются количественные показатели — метрики производительности. Эти показатели помогают выявить области, нуждающиеся в улучшении, и подтвердить соответствие новых сервисов стандартам производительности.
  1. Ключевые показатели эффективности (Key Performance Indicators, KPI). К этим показателям относятся время отклика, частота ошибок, пропускная способность, количество запросов в секунду.
    KPI определяют для каждого микросервиса и устанавливают пороговое значение уровня производительности. Затем эти показатели отслеживаются с помощью инструментов мониторинга.
  2. Цели уровня сервиса (Service-Level Objectives, SLO) — это чётко определённые цели в области производительности и доступности сервиса.
    SLO ставятся на основе бизнес-требований, таких как время безотказной работы или время отклика. Затем соответствие SLO контролируют с помощью инструментов APM.
  3. Индикаторы уровня обслуживания (Service Level Indicator, SLI) — это количественная оценка работы сервиса, показывающая, выполняются ли SLO. Эти индикаторы определяются для критических показателей и отслеживаются на соответствие с заданными SLO.
    К SLI относятся, например, латентность — время, необходимое для обработки запроса, доступность — доля времени, в течение которого сервис работает, и частота ошибок.
«Шайба» для каждого микросервиса определила KPI — время отклика, частоту ошибок и пропускную способность. А в качестве SLO разработчики установили время безотказной работы, равное 99,9%, и время отклика менее 200 мс. Так будут обеспечиваться высокая доступность и стандарты производительности.
Теперь поговорим собственно о средствах мониторинга.
Средства мониторинга
Средства мониторинга — это программное обеспечение, предназначенное для отслеживания производительности, работоспособности и доступности сервисов. Они собирают и анализируют данные, чтобы помочь обнаружить проблемы и обеспечить бесперебойную работу служб.
В рамках развёртывания мониторинга основные компоненты настраивают постепенно, и в идеале нужно пройти через все шаги.
  1. Мониторинг производительности приложений (Application Performance Monitoring, APM). Инструменты APM отслеживают производительность приложений и отдельных микросервисов в режиме реального времени, предоставляют информацию о времени отклика, количестве ошибок и взаимодействии с пользователями.
    Примерами таких инструментов являются системы New Relic, Datadog, Dynatrace.
  2. Централизованное логирование. Инструменты централизованного протоколирования объединяют журналы различных служб в одном месте, что упрощает поиск, анализ и устранение проблем.
    К таким относятся системы ELK Stack (Elasticsearch, Logstash, Kibana), Splunk, Fluentd.
  3. Мониторинг инфраструктуры. Эти инструменты следят за состоянием и производительностью базовой инфраструктуры, такой как серверы, контейнеры и сетевые компоненты. Благодаря им отслеживается загрузка процессора, потребление памяти, дисковые операции ввода-вывода и сетевая задержка.
    Это, например, системы Prometheus, Grafana, Nagios.
В «Шайбе» на этапе развёртывания мониторинга поступили так: команда Алекса внедрила Datadog для мониторинга производительности новых микросервисов, отслеживая время отклика, количество ошибок и взаимодействие с пользователями. Затем она настроила все микросервисы на отправку логов в ELK Stack — это позволило эффективно агрегировать и анализировать логи. И третье — Prometheus и Grafana использовались для мониторинга состояния базовой инфраструктуры и обеспечения оптимальной работы серверов и контейнеров, поддерживающих микросервисы.
Методы верификации
Методы верификации включают в себя процессы и инструменты, которые обеспечивают правильное функционирование новых микросервисов в соответствии с ожидаемыми стандартами производительности и надёжности.
  1. Автоматизированное тестирование (юнит-тесты, интеграционные тесты, e2e-тесты) проверяет функциональность, производительность и интеграцию микросервисов на их соответствие заданным критериям. Для этого настраиваются конвейеры CI/CD для запуска автоматизированных тестов при каждом коммите кода в системе контроля версий.
    В этом случае можно использовать Jenkins, Travis CI или GitLab CI.
  2. А/B-тестирование позволяет сравнивать производительность и влияние на пользователей двух версий сайта, приложения или сервиса, чтобы определить, какая из них работает лучше. То есть часть трафика направляют на новую версию сервиса, а остальную часть — на старую. Затем анализируют показатели производительности и взаимодействие с пользователями.
В «Шайбе» так и сделали: использовали Jenkins для автоматизации тестирования. Так есть гарантия, что каждый микросервис прошёл модульное, интеграционное и сквозное тестирование перед развёртыванием. А чтобы убедиться, что новые сервисы обеспечивают лучший или, по крайней мере, сопоставимый опыт, команда сравнила производительность и отзывы от пользователей с помощью A/B-тестирования.

Шаг 5. Настройка итерационного процесса

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

Распространённые «подводные камни»

Опыт реализации паттерна Strangler Fig можно обобщить и выделить несколько распространённых проблем. Знание этих проблем поможет избегать их и проводить успешную миграцию.
  1. Недостаточное планирование
    • Проблема: слишком поспешная реализация миграции без чёткого плана может привести к неполному или неэффективному переходу.
    • Как избежать: разработать подробный план миграции с описанием каждого этапа, определить ключевые компоненты для извлечения и установить реалистичные сроки.
  2. Отсутствие поддержки заинтересованных сторон
    • Проблема: сопротивление заинтересованных сторон из-за отсутствия понимания или предполагаемых рисков.
    • Как избежать: все заинтересованные стороны должны чётко представлять преимущества модели фига-душитель — использовать истории успеха и данные, чтобы проиллюстрировать преимущества и обеспечить их поддержку.
  3. Недостаточный мониторинг и тестирование
    • Проблема: неспособность адекватно контролировать новые сервисы может привести к незамеченным проблемам, влияющим на производительность.
    • Как избежать: с самого начала организовать надёжный мониторинг и автоматическое тестирование и настроить механизмы оповещения для раннего выявления проблем.
  4. Игнорирование зависимостей
    • Проблема: игнорирование взаимозависимостей между компонентами приводит к сбоям или неожиданному поведению.
    • Как избежать: провести тщательный анализ зависимостей внутри монолитного приложения, наметить зависимости и устранить их в процессе извлечения, чтобы обеспечить бесшовную интеграцию.
  5. Неполная документация
    • Проблема: отсутствие надлежащей документации может привести к путанице и несогласованным реализациям.
    • Как избежать: вести полную и актуальную документацию на протяжении всего процесса миграции — документировать дизайн, API и рабочие процедуры каждого микросервиса.
  6. Игнорирование проблем управления данными
    • Проблема: невнимание к тому, как будет осуществляться управление данными и обмен ими между монолитом и микросервисами, приводит к несогласованности и проблемам целостности данных.
    • Как избежать: заранее планировать стратегию управления данными, учитывать синхронизацию данных, конечную согласованность и то, как будут обрабатываться транзакции между сервисами.
Как видите, всё не так страшно!

Задание 1

Крупный сервис, построенный по монолитной архитектуре, столкнулся с рядом сложностей — низкая скорость разработки и релизов обновлений, сложность масштабирования, низкая отказоустойчивость. Руководство решило переходить на микросервисную архитектуру. Определите последовательность шагов, которая поможет достичь перехода.
Настроить переключение трафика
Шаг 3
Выбрать компоненты архитектуры, которые будут перепроектированы
Шаг 1
Разделить монолитное приложение на микросервисы и продумать процессы CD
Шаг 5
Оценить производительность и надёжность сервиса
Шаг 4
Спроектировать сервис, у которого будет автономная область ответственности
Шаг 2

Задание 2

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

Итоги

Реализация паттерна Strangler Fig проходит в пять основных шагов.
  1. Определение доменной области — того компонента, который необходимо извлечь из монолита.
  2. Разработка микросервисов.
  3. Настройка маршрутизации и извлечение старого функционала с помощью прокси, переключателей функций или канареечных релизов.
  4. Мониторинг и верификация новых микросервисов — для надёжной работы микросервисов и своевременного реагирования используют инструменты APM, централизованное логирование и настраивают тестирование.
  5. Итерационное повторение процесса — необходимый шаг миграции монолитной структуры до момента полного замещения её микросервисами.
О техниках определения доменной области вы узнаете в следующем уроке.