news
Новый дата-центр TOR3 в Канаде
DC
Darya Chuyko
24 октября 2022
Обновлено 24 октября 2022

Паттерн микросервиса Strangler

Паттерн микросервиса Strangler

Перевод статьи Sameer Shukla.

В статье объясняется один из паттернов декомпозиции, известный как паттерн Strangler. Паттерн Strangler — это подход к постепенной миграции монолитной системы на микросервисы. Strangle = Re-factor.

В статье поднимаются вопросы:

  1. что такое паттерн Strangler с примером использования;
  2. реализация.

Паттерн Strangler

Паттерн Strangler — это паттерн миграции унаследованных монолитов на микросервисы, придуманный Мартином Фаулером. Все архитектуры разные, некоторые модульные, а некоторые нет, поэтому ориентироваться в них нелегко. Вот почему нам нужен общий паттерн, в котором монолиты будут преобразованы сначала в модульные монолиты, а затем в микросервисы. Именно для этого используется паттерн Strangler. Рассмотрим приложение поставщика электроэнергии, в котором есть различные модули, такие как биллинг, профиль клиента, детали потребления электроэнергии, детали плана и т.д. На первом рисунке представлен монолит.

Паттерн микросервиса Strangler_pic_1

Модульный монолит

Паттерн микросервиса Strangler_pic_2

Модульные монолиты являются необходимым условием, если мы используем паттерн Strangler. Первым шагом – это создание модулей в монолитном приложении, чтобы было легче извлекать их и создавать новый микросервис для конкретного модуля. На изображении модульного монолита, проще отделить такие модули, как Billing, Consumption, Plans, поскольку каждый модуль является единичным, и создать новый микросервис не составит труда.

Паттерн микросервиса Strangler_pic_3

Реализация

Как нам выбрать компонент для рефакторинга в отдельный сервис? Самый простой подход – определить компонент, который легко рефакторить, или компонент, который получает меньше трафика по сравнению с другими модулями. В нашем примере Moving / Reference это несколько таких модулей. Под Moving подразумевается клиент, который хочет перенести услугу из одного места в другое, под Reference – ситуация, когда один клиент хочет направить другого клиента к поставщику электроэнергии, является безопасным подходом. Иногда необходимо принять решение, если какой-либо модуль получает наибольшее количество запросов, то этот компонент также должен быть отрефакторен на приоритетной основе.

На данный момент наше приложение выглядит следующим образом,

Паттерн микросервиса Strangler_pic_4

Мы решили выбрать компонент Moving и выделить его в отдельный микросервис. Теперь архитектура выглядит следующим образом:

Паттерн микросервиса Strangler_pic_5

Поскольку компонент Moving преобразован в микросервис, все запросы, предназначенные для компонента Moving, будут направляться в микросервис 'Moving' через вызов HTTP или путем создания события через монолит, поскольку 'Moving' переходит в новый микросервис.

Аналогично, другие компоненты могут быть выведены из монолитной архитектуры и преобразованы в отдельные микросервисы с помощью того же подхода.

Паттерн микросервиса Strangler_pic_6

После преобразования всех компонентов в отдельные микросервисы законченная архитектура выглядит следующим образом:

Паттерн микросервиса Strangler_pic_7

API-шлюз – это инструмент управления, который обеспечивает единую точку входа для сервисов. Он находится между клиентом и сервисами, поэтому им не нужно напрямую взаимодействовать. API-шлюз обеспечивает агрегацию, аутентификацию, кэширование и т.д.

Заключение

Паттерн микросервиса Strangler имеет свои плюсы и минусы:

Плюсы

  • Легче включить новые требования в качестве нового сервиса.
  • Двухэтапный подход облегчает создание микросервиса, монолита в модульный монолит.
  • Безопасный подход, поскольку старые сервисы продолжают работать с новыми отрефакторенными сервисами.

Минусы

  • Разделять приложение на модули непросто, если компоненты тесно связаны друг с другом, требуется много времени на разработку, а также увеличиваются усилия по тестированию.
  • План отката должен быть под рукой на случай, если что-то пойдет не так во время рефакторинга. По опыту автора, производственная среда/сценарии совершенно разные.
  • Увеличение затрат на инфраструктуру.

Вам также может быть интересно...