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

Во-первых, это необходимость переработки существующего кода и его разбиения на независимые сервисы, что может быть трудоемким и сложным процессом.

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

Использование в практике таких паттернов как Strangler Fig Pattern, Parallel Run Pattern, Decorating Collaborator Pattern и Change Data Capture позволяет разработчикам значительно снизить риски и проблемы, возникающие при таком сложном переходе.

Давайте рассмотрим основные концепции этих паттернов.

Strangler Fig Pattern

В паттерне Strangler Fig Pattern, который переводиться как «Паттерн удушающего фикуса» используется постепенная миграция функций из монолита в микросервисы при сохранении параллельной работы старого и нового кода.

Паттерн Strangler Fig Pattern получил свое название по аналогии с растением «Удушающий фикус» (Strangler Fig). Это растение начинает свою жизнь на другом дереве и постепенно обвивает его, в конечном итоге заменяя и вытесняя его полностью.

На рис. 1 представлена реализация Strangler Fig Pattern в котором:

1) монолитная система разделена на модули (Feature A, Feature B и Feature C);

2) модуль (например, Feature A) выносится в отдельный микросервис (Service A);

3) прокси (или шлюз) направляет запросы следующим образом:

  • старый код (в монолите) обрабатывает все функции, кроме вынесенной,

  • новые запросы для Feature A перенаправляются в Service A;

4) и далее постепенно остальные модули (Feature B и Feature C) выносятся в аналогичные микросервисы.

Преимущества Strangler Fig Pattern:

  • минимизируется риск: старый код монолита остается в работе;

  • позволяет разделить процесс перевода на отдельные шаги и решать задачу поэтапно.

Рис.1 Strangler Fig Pattern
Рис.1 Strangler Fig Pattern

Parallel Run Pattern

При реализации паттерна Parallel Run Pattern, что в переводе означает «Паттерн параллельного выполнения» — выполняется одновременная работа монолита и нового микросервиса с проверкой результатов.

На рис. 2 демонстрируется применение Parallel Run Pattern в котором:

1) входящий запрос дублируется и отправляется одновременно:

  • в монолитную систему,

  • и в новый микросервис с клонированной функциональностью;

2) результаты обеих систем сравниваются с помощью фреймворка (Comparison Framework);

3) после успешной проверки новый микросервис сервис заменяет старую реализацию.

Преимущества Parallel Run Pattern:

  • обеспечивает плавный переход с минимальными рисками,

  • позволяет проверить новый функционал без влияния на пользователя.

Рис. 2 Parallel Run Pattern
Рис. 2 Parallel Run Pattern

Decorating Collaborator Pattern

Паттерн Decorating Collaborator Pattern, название которого переводится как «Паттерн декорирования коллабораторов» — получил свое название по аналогии с декоратором, который добавляет новые возможности или поведение к существующему объекту.

На рис. 3 показано добавление новых сервисов поверх существующей монолитной системы, в которой:

1) запрос (например, "Place Order Request") поступает через прокси;

2) прокси перенаправляет часть запросов (например, проверку инвентаря) в новый микросервис (Inventory Service);

3) новый микросервис проверяет данные и возвращает результат;

4) монолит обрабатывает остальные части запроса.

Преимущества Decorating Collaborator Pattern:

  • новый функционал добавляется без необходимости переработки монолита,

  • постепенный переход с возможностью тестирования.

Рис. 3 Decorating Collaborator Pattern
Рис. 3 Decorating Collaborator Pattern

Change Data Capture (СDС)

Паттерн Change Data Capture (CDC) получил свое название «Отслеживание изменений данных» из-за своей основной функции — отслеживания и захвата изменений данных в системе.

На рис. 4 демонстрируется использование изменений в данных для синхронизации между монолитом и микросервисами:

1) монолитная база данных отслеживает изменения (вставка, обновление, удаление) через журнал транзакций;

2) процесс CDC (например, через инструмент Debezium) преобразует эти изменения в поток данных;

3) поток отправляется в целевые системы (микросервисы, кеши, хранилища данных).

Преимущества Change Data Capture:

  • данные остаются консистентными между монолитом и микросервисами,

  • ускоряется миграция данных.

Рис. 4 Change Data Capture (CDC)
Рис. 4 Change Data Capture (CDC)

Описанные выше подходы минимизируют риски и позволяют постепенно перейти от монолитной архитектуры к микросервисной, сохраняя стабильность системы и улучшая масштабируемость.

В конечном итоге выбор конкретного паттерна зависит от сложности системы, сроков и бизнес-требований.

Комментарии (9)


  1. atues
    18.01.2025 11:17

    Все это и многое другое есть в книге Сэма Ньюмена "От монолитов к микросервисам". Это во-первых. А во-вторых и главное: когда имеет смысл делать такую трудоемкую и не гарантирующую успех миграцию?


    1. martyncev
      18.01.2025 11:17

      Когда от вас требуют:
      1) Масштабируемость - на больших нагрузках без нее никуда.
      2) Высокую отказоустойчивость - достигается как и аппаратными средствами + средствами виртуализации, так и программными (резервные инстансы)


      1. slava0135
        18.01.2025 11:17

        Я не эксперт, но: я как-то узнал, что Lichess, имея до 100 тыс. пользователей онлайн, крутится на одном сервере (точнее, игровой сервер Lila). Так что масштабируемость довольно спорный момент, если это не сайт с аудиторией всяких социальных сетей.


        1. JordanCpp
          18.01.2025 11:17

          А ведь могли перейти на микросеовисы. Нанять ещё больше людей. Писать каждый микросераис на своем языке. Нанять дополнительно hr отдел, который будет нанимать разных программистов. Программисты бы смогли масштабировать систему на сотни серверов, были бы написаны сотни микросераисов, с отдельным API и его версионированием. Запилить распределенные транзакции. Использовать разные бд для кэширования.

          А они сидят и бздят на одном сервере:)


      1. Dhwtj
        18.01.2025 11:17

        Влияние микросервисов на масштабируемость преувеличена

        Отказоустойчивость там специфическая: одно чиним, другое ломаем


        1. martyncev
          18.01.2025 11:17

          Просто надо иметь очень хорошего архитектора и ревьювера. Ну и грамотную команду разработки (да, дорого)
          Микросервисы штука с одной стороны простая и понятная, а с другой.. межсервисные транзакци и прочие "нюансы" могут поставить весь прод в мечтательную позу, если не будут учтены всевозможные сбои и проблемы. Ни какого ACID - чистый треш.


      1. olku
        18.01.2025 11:17

        Оба качества достигались и до хайпа микросервисов наличием избыточного количества копий приложения. Так при каких условиях имеет смысл его дробить?


  1. ilya-chumakov
    18.01.2025 11:17

    Поскольку иллюстрации взяты из статьи https://blog.bytebytego.com/p/from-monolith-to-microservices-key (за пэйволлом), опубликованной 2 днями ранее, то я предполагаю, что содержимое сдернуто оттуда же.


  1. onets
    18.01.2025 11:17

    Насколько я понимаю микросервисы - это хостинг независимых (ограниченных) модулей.

    То есть если монолит модульный - то переход на микросервисы - это разнести модули по серверам и наладить между ними взаимодействие через различные протоколы синхронного и асинхронного взаимодействия. Плюс подложить соломку в виде рейтрай полиси, циркуль-брейкеров, саг и тп. В конце наслаждаться тоннами денег на девопс, увеличенными задержками в обработке данных и «когда-нибудь оно будет в согласованном состоянии»

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