Ключевые паттерны микросервисного приложения

В предыдущем уроке мы рассмотрели карту паттернов для проектирования микросервисов. Прошлись по трём уровням карты, а в этом уроке на примере компании CourierTrack детальней рассмотрим применение некоторых паттернов.
Мы будем изучать, как паттерны и подходы помогают решать основные проблемы, с которыми сталкиваются разработчики микросервисных систем, и как их правильное применение может значительно улучшить качество и управляемость проекта. Обсудим CQRS, Saga и API Gateway.
В этом уроке вас ждёт погружение в концепцию CQRS. Мы разберём использование CQRS для разделения чтения и записи данных, плюсы и минусы применения этого паттерна в реальных проектах и документирование.
Представление о работе Saga вы уже получили в первом спринте. А сегодня мы рассмотрим, как она используется для обеспечения согласованности данных на примере реальных проектов и как документировать применение этого паттерна.
Наконец, мы рассмотрим различные подходы к использованию API Gateway и сложности, с которыми можно столкнуться при его реализации.

Паттерн CQRS

В современных приложениях часто возникает проблема высокой нагрузки на базу данных, когда операции чтения и записи конкурируют за ресурсы.
✏️ Command Query Responsibility Segregation (CQRS) — это паттерн проектирования, который разделяет операцию чтения и записи данных в системе на два отдельных интерфейса.
В традиционных системах операции чтения и записи выполняются через один и тот же интерфейс. Это может привести к снижению производительности и увеличению времени отклика системы, особенно при больших объёмах данных и сложных запросах.
В продукте CourierTrack такая проблема особенно актуальна. Например, когда клиенты активно отслеживают местоположение своих посылок, происходят частые запросы к базе данных на чтение. В то же время курьеры и система управления продолжают записывать обновления о статусе и местоположении посылок. Конкуренция между этими операциями может замедлить работу системы, что негативно сказывается на пользовательском опыте и эффективности работы курьеров.
CQRS позволяет оптимизировать и масштабировать операции по отдельности, улучшая производительность и согласованность данных.
Чтобы вы смогли объективно оценивать возможности и пользу использования этого паттерна, стоит традиционно упомянуть его плюсы и минусы.
Плюсы CQRS
  • Масштабируемость. Чтение и запись данных можно масштабировать независимо друг от друга, что улучшает производительность системы.
  • Оптимизация запросов. Запросы на чтение могут быть оптимизированы для быстрого получения данных, а команды записи — для эффективного обновления данных.
  • Улучшенная согласованность. Разделение операций помогает поддерживать согласованность данных, особенно в распределённых системах.
Минусы CQRS
  • Сложность реализации. Паттерн требует больше усилий для реализации и поддержки, так как необходимо поддерживать два отдельных интерфейса и механизмы синхронизации данных.
  • Увеличение объёма кода. Разделение операций может привести к увеличению объёма кода, который необходимо поддерживать.

Разделение чтения и записи данных с CQRS

В системе CourierTrack чтение данных о местоположении курьеров может быть реализовано через отдельный интерфейс, оптимизированный для быстрого получения информации. А запись новых заказов будет осуществляться через интерфейс, оптимизированный для эффективного обновления данных.
При использовании паттерна CQRS операции чтения (запросы) и записи (команды) выполняются через разные модели данных и интерфейсы.
  • Команды (Commands) используются для изменения состояния системы.
В CourierTrack команды включают такие операции, как создание нового заказа, обновление статуса курьера и завершение доставки. Каждая команда изменяет состояние системы и генерирует соответствующие события.
  • Запросы (Queries) используются для получения данных из системы.
В CourierTrack запросы включают операции, такие как получение текущего местоположения курьера, список активных заказов и история доставки. Запросы не изменяют состояние системы и оптимизированы для быстрого получения данных.
В ситуации с CourierTrack использование CQRS целесообразно: разделение операций чтения и записи упрощает управление данными и улучшает согласованность, что особенно важно для распределённых систем с большим количеством одновременно работающих пользователей.

Документирование применения CQRS

Документирование применения CQRS включает описание всех команд и запросов, используемых в системе, а также модели данных, связанные с каждой операцией. Так архитектура системы остаётся прозрачной для команды, а процесс поддержки и развития становится проще.
Документация по применению CQRS в системе CourierTrack
Эта документация описывает применение паттерна CQRS в системе отслеживания курьеров CourierTrack. Документация включает описание команд и запросов, используемых в системе, а также модели данных, связанные с каждой операцией.
Команды (Commands):
  • CreateOrderCommand: Команда для создания нового заказа.
    • Модель данных: Order (id, courierId, status, deliveryTime)
    • Метод: execute()
  • UpdateCourierStatusCommand: Команда для обновления статуса курьера.
    • Модель данных: Courier (id, name, status)
    • Метод: execute()
  • CompleteDeliveryCommand: Команда для завершения доставки.
    • Модель данных: Order (id, courierId, status, deliveryTime)
    • Метод: execute()
Запросы (Queries):
  • GetCourierLocationQuery: Запрос для получения текущего местоположения курьера.
    • Модель данных: Location (courierId, latitude, longitude, timestamp)
    • Метод: execute()
  • GetActiveOrdersQuery: Запрос для получения списка активных заказов.
    • Модель данных: Order (id, courierId, status, deliveryTime)
    • Метод: execute()
  • GetDeliveryHistoryQuery: Запрос для получения истории доставки.
    • Модель данных: Order (id, courierId, status, deliveryTime)
    • Метод: execute()

YAML

@startuml
package "Commands" {
  class CreateOrderCommand {
    +execute()
  }
  class UpdateCourierStatusCommand {
    +execute()
  }
  class CompleteDeliveryCommand {
    +execute()
  }
}

package "Queries" {
  class GetCourierLocationQuery {
    +execute()
  }
  class GetActiveOrdersQuery {
    +execute()
  }
  class GetDeliveryHistoryQuery {
    +execute()
  }
}

class OrderService {
  +handleCommand()
  +handleQuery()
}

OrderService --> CreateOrderCommand : handles
OrderService --> UpdateCourierStatusCommand : handles
OrderService --> CompleteDeliveryCommand : handles
OrderService --> GetCourierLocationQuery : handles
OrderService --> GetActiveOrdersQuery : handles
OrderService --> GetDeliveryHistoryQuery : handles
@enduml

Что почитать о CQRS?

Command Query Responsibility Segregation
A case for CQRS: How CQRS helps a SaaS product process thousands of images asynchronously

Задание 1

Выберите ситуацию, в которой применена концепция CQRS.

Задание 2

Расположите шаги по использованию CQRS для разделения чтения и записи данных в правильном порядке.
Определение команд (Commands) для операций записи данных
Шаг 1
Разработка модели данных для чтения (Read Model), оптимизированной для быстрых операций чтения
Шаг 3
Разработка модели данных для записи (Write Model), оптимизированной для операций записи
Шаг 2
Реализация механизма обработки команд (Command Handler), который будет управлять операциями записи данных
Шаг 4
Реализация механизма обработки запросов (Query Handler), который будет управлять операциями чтения данных
Шаг 5
Настройка системы для использования отдельных хранилищ данных для чтения и записи (если необходимо)
Шаг 6
Тестирование и отладка системы для обеспечения корректной работы разделённых операций чтения и записи
Шаг 7
Использование CQRS начинается с определения команд для операций записи данных и разработки соответствующей модели данных для записи. Затем создаётся модель данных для чтения, оптимизированная для быстрых операций чтения. Реализуются механизмы обработки команд и запросов, после чего настраивается система для использования отдельных хранилищ данных, если это необходимо. Завершающий этап включает тестирование и отладку системы, чтобы убедиться в корректной работе разделённых операций чтения и записи.

Задание 3

Выберите из трёх вариантов наиболее корректное описание и объяснение того, как CQRS был применён в проекте QuickDelivery.

Паттерн Saga

В этом блоке мы вспомним ключевые моменты паттерна Saga и посмотрим, как на примере CourierTrack с его помощью решается проблема согласованности данных. Оценим плюсы и минусы Saga в реальных проектах, а также обсудим документирование применения Saga.
🔹 Паттерн Saga позволяет согласованно управлять состоянием системы, разделяя большую транзакцию на серию меньших шагов, каждый из которых может быть выполнен автономно. Каждый шаг транзакции имеет соответствующую компенсирующую операцию, которая выполняется в случае неудачи.
В продукте CourierTrack проблема распределённых транзакций особенно актуальна. Например, при обработке заказа на доставку посылки система должна взаимодействовать с несколькими микросервисами: управлением заказами, управлением курьерами, управлением оплатой и управлением складом. Если один из микросервисов не выполняет свою часть транзакции (не проходит оплата или не назначается курьер), это может привести к неконсистентному состоянию данных в системе. Традиционные методы управления транзакциями, такие как ACID-транзакции, не могут эффективно решать эту проблему в распределённой архитектуре.
Saga решает эту проблему, разбивая большие транзакции на серию меньших шагов, каждая из которых является отдельной транзакцией. В случае сбоя система может откатить предыдущие шаги или компенсировать их, обеспечивая согласованность данных.
Плюсы Saga
  • Согласованность данных. Обеспечивает согласованность данных в распределённых системах.
  • Устойчивость к сбоям. Каждый шаг транзакции может быть компенсирован, что позволяет системе восстанавливаться после сбоев.
  • Гибкость. Паттерн легко адаптируется к различным бизнес-процессам и сценариям.
Минусы Saga
  • Сложность реализации. Требует тщательного планирования и реализации компенсирующих операций.
  • Временная несогласованность. Возможны временные состояния несогласованности данных до завершения всех шагов транзакции.

Подходы к реализации Saga

В первом спринте вы познакомились с подходами к реализации Saga — оркестрацией и хореографией. Вспомним их и взглянем на диаграммы, построенные для CourierTrack.
Orchestration-based Saga
В оркестровочной реализации Saga есть центральный координатор (оркестратор), который управляет выполнением всех шагов транзакции и вызывает каждый шаг поочерёдно. Оркестратор отслеживает состояние выполнения и в случае ошибки инициирует выполнение компенсирующих операций.
Пример использования в CourierTrack
  1. Принятие заказа. Клиент отправляет запрос на создание заказа оркестратору.
  2. Создание заказа. Оркестратор вызывает OrderService для создания заказа.
  3. Резервирование товара. После успешного создания заказа оркестратор вызывает InventoryService для резервирования товара.
  4. Обработка оплаты. После резервирования товара оркестратор вызывает PaymentService для обработки оплаты.
  5. Отправка уведомления. После успешной обработки оплаты оркестратор вызывает NotificationService для отправки уведомления клиенту о подтверждении заказа.
Choreography-based Saga
В хореографической реализации Saga каждый микросервис отвечает за выполнение своего шага и вызывает следующий микросервис через обмен сообщениями. Здесь нет центрального координатора, и каждый шаг самостоятельно уведомляет следующий шаг о завершении своей работы.
Пример использования в CourierTrack
  1. Принятие заказа. Микросервис OrderService создаёт заказ и отправляет сообщение InventoryService для резервирования товара.
  2. Назначение курьера. InventoryService резервирует товар и отправляет сообщение PaymentService для обработки оплаты.
  3. Подтверждение доставки. PaymentService обрабатывает оплату и отправляет сообщение NotificationService для отправки уведомления.
  4. Завершение заказа. NotificationService отправляет уведомление клиенту о подтверждении заказа.

Обеспечение согласованности данных с помощью Saga

При использовании паттерна Saga выполняется серия шагов, каждый из которых может быть выполнен независимо. В случае неудачи любой из шагов может быть отменён с помощью компенсирующей операции, что обеспечивает целостность данных.
Пример использования в CourierTrack
Процесс доставки заказа в системе CourierTrack включает следующие шаги:
  1. Принятие заказа: создаётся новый заказ.
    • Компенсирующая операция — отмена заказа.
  2. Назначение курьера: курьеру назначается заказ.
    • Компенсирующая операция — отмена назначения курьера.
  3. Подтверждение доставки: курьер подтверждает доставку заказа.
    • Компенсирующая операция — отмена подтверждения доставки.
  4. Завершение заказа: заказ помечается как завершённый.
    • Компенсирующая операция. Отмена завершения заказа.
В системе CourierTrack использование паттерна Saga позволяет управлять процессом доставки заказов, обеспечивая согласованность данных даже в случае сбоев. Хотя реализация компенсирующих операций требует дополнительных усилий, это обеспечивает надёжность и устойчивость системы.

Документирование применения Saga

Документирование применения Saga включает описание всех шагов транзакции, компенсирующих операций и моделей данных, используемых в процессе. Это обеспечивает прозрачность и упрощает процесс поддержки и развития системы.
Пример документации для CourierTrack
Название: Документация по применению Saga в системе CourierTrack
Введение: Эта документация описывает применение паттерна Saga в системе отслеживания курьеров CourierTrack. Документация включает описание шагов транзакции, компенсирующих операций и моделей данных.
Шаги транзакции и компенсирующие операции:
  1. Принятие заказа:
    • Операция: Создание нового заказа.
    • Компенсирующая операция: Отмена заказа.
  2. Назначение курьера:
    • Операция: Назначение курьера на заказ.
    • Компенсирующая операция: Отмена назначения курьера.
  3. Подтверждение доставки:
    • Операция: Подтверждение доставки заказа курьером.
    • Компенсирующая операция: Отмена подтверждения доставки.
  4. Завершение заказа:
    • Операция: Завершение заказа.
    • Компенсирующая операция: Отмена завершения заказа.

YAML

@startuml
start
:Принятие заказа;
if (успешно?) then (да)
  :Назначение курьера;
  if (успешно?) then (да)
    :Подтверждение доставки;
    if (успешно?) then (да)
      :Завершение заказа;
    else (нет)
      :Отмена подтверждения доставки;
      :Отмена назначения курьера;
      :Отмена заказа;
    endif
  else (нет)
    :Отмена назначения курьера;
    :Отмена заказа;
  endif
else (нет)
  :Отмена заказа;
endif
stop
@enduml
Эта документация помогает команде CourierTrack понимать архитектуру и поддерживать, развивать систему с использованием паттерна Saga.

Что почитать о Saga?

Saga и Event Sourcing с Axon. Первое знакомство
SAGA на golang
Паттерн Saga в микросервисной архитектуре
Pattern: Saga

Задание 4

В системе CourierTrack при создании нового заказа необходимо выполнить несколько связанных операций: резервирование товара на складе, подтверждение оплаты и назначение курьера для доставки. Эти операции выполняются последовательно, и каждая из них может вызвать откат предыдущих операций в случае ошибки. Например, если назначение курьера не удалось, то подтверждение оплаты и резервирование товара также должны быть отменены.
Выберите верное описание ситуации.

Задание 5

В системе CourierTrack при создании нового заказа необходимо выполнить несколько связанных операций: резервирование товара на складе, подтверждение оплаты и назначение курьера для доставки. Эти операции должны выполняться последовательно, и в случае ошибки любая из операций должна быть отменена вместе с предыдущими.
Расположите шаги по использованию паттерна Saga для обеспечения согласованности данных в заданном проекте CourierTrack в правильном порядке.
Выполнение операции резервирования товара на складе
Шаг 2
Выполнение операции подтверждения оплаты
Шаг 3
Выполнение операции назначения курьера для доставки
Шаг 4
Определение компенсационных действий для каждой операции
Шаг 5
Запуск процесса создания заказа
Шаг 1
В случае ошибки при назначении курьера выполнение отката подтверждения оплаты и отмены резервирования товара
Шаг 7
В случае ошибки при подтверждении оплаты выполнение отката резервирования товара
Шаг 6

Задание 6

В проекте CourierTrack используется паттерн Saga для управления транзакциями при создании заказов. Разработчики подготовили два варианта документации применения Saga. Выберите наиболее корректный и обоснованный вариант.

API Gateway

В предыдущем спринте мы сравнивали API Gateway, который является единой точкой входа для клиентских запросов, с руководителем в компании, который передаёт задачи и информацию своим сотрудникам и предоставляет результаты работы другим направлениям. Сегодня рассмотрим, как этот подход решает проблему управления многочисленными API-микросервисами, на примере продукта CourierTrack. И чтобы не идеализировать инструменты, традиционно обсудим плюсы и минусы API Gateway.
🔹 API Gateway выполняет функции прокси-сервера, принимая все клиентские запросы и маршрутизируя их к соответствующим микросервисам. Позволяет скрыть внутреннюю структуру микросервисов от клиентов, предоставляет единый интерфейс для взаимодействия с системой. API Gateway также может выполнять множество дополнительных задач, таких как трансформация запросов и ответов, кэширование, мониторинг, логирование, управление сессиями, аутентификация и авторизация.
В продукте CourierTrack возникает проблема управления многочисленными API-микросервисами, которые обслуживают различные функции системы. Без единой точки входа, такой как API Gateway, управление запросами клиентов становится сложным и неэффективным. Например, клиентское приложение, взаимодействующее с несколькими микросервисами напрямую, может столкнуться с проблемами в маршрутизации запросов, балансировке нагрузки и обеспечении безопасности. Это приводит к увеличению времени отклика, повышенной нагрузке на сеть и уязвимостям в безопасности.
API Gateway решает эту проблему, предоставляя централизованную точку управления и контроля за всеми запросами. Он обеспечивает оптимизацию маршрутизации запросов, эффективное распределение нагрузки между микросервисами, а также интеграцию с системами аутентификации и авторизации. Это не только упрощает взаимодействие клиентских приложений с микросервисами, но и повышает общую производительность и безопасность системы.
Плюсы использования API Gateway
  • Единая точка входа. Клиенты взаимодействуют с системой через единый интерфейс, что упрощает управление и мониторинг.
  • Безопасность. API Gateway обеспечивает централизованную аутентификацию и авторизацию запросов.
  • Маршрутизация и балансировка нагрузки. API Gateway маршрутизирует запросы к соответствующим микросервисам и балансирует нагрузку между ними.
  • Мониторинг и логирование. API Gateway собирает и анализирует метрики и логи запросов, что помогает отслеживать производительность и обнаруживать проблемы.
Недостатки использования API Gateway
  • Единая точка отказа. API Gateway может стать единой точкой отказа, если не обеспечены механизмы высокой доступности.
  • Сложность. Управление и настройка API Gateway могут быть сложными и требовать дополнительных ресурсов.
В системе CourierTrack API Gateway используется для маршрутизации запросов от клиентов к микросервисам, отвечающим за управление курьерами, заказами и отслеживанием местоположения.

Управление API микросервисов с помощью API Gateway

API Gateway управляет всеми API вызовами и предоставляет множество функций для оптимизации и защиты API микросервисов. Он может выполнять трансформацию запросов и ответов, обеспечивать кэширование для улучшения производительности, управлять сессиями пользователей и выполнять аутентификацию и авторизацию запросов.
Пример использования в CourierTrack
  1. Маршрутизация запросов: API Gateway принимает запросы от клиентов и маршрутизирует их к соответствующим микросервисам. Например, запрос на создание заказа маршрутизируется к Order Service, а запрос на получение текущего местоположения курьера — к Location Service.
  2. Аутентификация и авторизация: API Gateway выполняет аутентификацию пользователей, проверяя их учётные данные, и авторизует запросы, проверяя права доступа к запрашиваемым ресурсам.
  3. Кэширование: API Gateway кэширует часто запрашиваемые данные, такие как списки доступных курьеров, чтобы уменьшить нагрузку на микросервисы и улучшить производительность системы.
  4. Мониторинг и логирование: API Gateway собирает метрики и логи всех запросов и ответов, что позволяет отслеживать производительность системы, выявлять проблемы и анализировать поведение пользователей.

Оценка различных подходов к использованию API Gateway

Существует несколько подходов к использованию API Gateway в микросервисной архитектуре, каждый из которых имеет свои преимущества и недостатки. Основные подходы включают использование монолитного API Gateway, распределённого API Gateway и Serverless API Gateway.

1. Монолитный API Gateway

  • Плюсы: единая точка управления всеми API запросами, централизованное управление безопасностью и логированием.
  • Минусы: единая точка отказа, возможная сложность управления при масштабировании системы.

2. Распределённый API Gateway

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

3. Многослойный API Gateway

  • Плюсы: улучшенная безопасность, улучшенная масштабируемость, упрощенное управление и мониторинг, повышенная производительность.
  • Минусы: повышенная сложность, трудности настройки, увеличение времени отклика, затраты на инфраструктуру.

4. Serverless API Gateway

  • Плюсы: высокая масштабируемость, отсутствие необходимости управления инфраструктурой, уменьшение затрат на ресурсы.
  • Минусы: возможные ограничения в функциональности и производительности, зависимость от облачного провайдера.
В системе CourierTrack был выбран монолитный API Gateway, чтобы упростить управление и обеспечение централизованного контроля безопасности и логирования. Но в будущем, по мере роста системы, можно рассмотреть возможность перехода на распределённый или Serverless API Gateway для улучшения масштабируемости и производительности.

Что почитать про API Gateway?

Разработка архитектуры для чайников. Часть 2
Простой API gateway на базе PHP и Lumen
Use API gateways in microservices
Building an API Gateway to Get Out of the Monoliths
Pattern: API Gateway

Задание 7

Выберите наиболее правильное описание роли API Gateway в микросервисной архитектуре.

Задание 8

Выберите те сценарии, где использование API Gateway в микросервисной архитектуре уместно и эффективно.

Задание 9

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

Итоги

В этом уроке мы раскрыли системные проблемы, в решении которых помогает интеграция разных паттернов. Стоит лишь помнить, что ни один из них не является идеальным решением и при выборе нужно ориентироваться на ресурсы команды, ограничения самого подхода и лучшие практики.
  • Для распределения нагрузки в системах, где операции чтения и записи конкурируют за ресурсы, используют паттерн CQRS. Он разделяет чтение и запись на два отдельных интерфейса, что позволяет оптимизировать и масштабировать операции по отдельности, улучшая производительность и согласованность данных.
  • Saga решает проблему согласованности данных, разбивая большие транзакции на серию меньших шагов, каждая из которых является отдельной транзакцией. В случае сбоя система может откатить предыдущие шаги или компенсировать их.
  • API Gateway, являясь единой точкой входа всех клиентских запросов, оптимизирует маршрутизацию запросов и обеспечивает эффективное распределение нагрузки между микросервисами, а также интеграцию с системами аутентификации и авторизации. С помощью этого подхода можно решать проблемы производительности и безопасности системы.
В следующем уроке мы затронем проблемы взаимодействия микросервисов и их решение с использованием инструментов Kafka и Kong.