Microservice Patterns

Проработать

  1. Saga vs Two face commit
  2. A pattern language for microservices
  3. Архітектурні Патерни у Сучасних Мікросервісах - Java: Про ІТ під каву - #36
  4. Собеседование на Сеньора | Проектирование архитектуры систем | Systems Design
  5. Как подготовиться и пройти System Design Interview. Александр Поломодов
  6. Service Discovery в распределенных системах на примере Consul. Александр Сигачев
  7. Знакомимся с Event Sourcing. Часть 1
  8. Что спрашивают о микросервисах в крупных компаниях | Senior Developer | Jetbulb
  9. Стратегии обработки ошибок: Circuit Breaker pattern
  10. Circuit Breaker паттерн
  11. Шпаргалка по миграции монолита на микросервисы
  12. Database per Microservice паттерн
  13. Top 7 Ways to 10x Your API Performance
  14. API Gateways in System Design Interviews w/ Ex-Meta Staff Engineer

    15. Saga

  15. Как управлять транзакциями в микросервисной архитектуре
  16. Saga паттерн и распределенные транзакции

Основные разделы

System Design Interview

  1. Узнать все требования.
  2. Количество юзеров.
  3. Функциональные требования.

Решение проблем

Durability

Сервис упал, сеть оборвалась, брокер перегружен, сообщение потерялось или выполнилось дважды. Уменьшение риска каскадных отказов.

Поддержка транзакций между микросервисами.

Симметричное распределение нагрузки и сложности бизнес-логики.

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

Saga

Saga - если мы используем паттерн "Database per Microservice" нам нужно обеспечить согласованность данных между сервисами. Управляет распределёнными транзакциями без глобальной блокировки.

Каждый сервис выполняет транзакцию в своей базе и публикует событие.

Ошибки обрабатываются компенсирующими транзакциями.

Реализуется через хореографию или оркестрацию.

Способы координации саг:

Хореография(Choreography)

Хореография(Choreography) - каждая транзакция публикует события, которые запускают транзакции в других сервисах.

Будут выполнены следующие шаги:

  1. Order Service (Сервис Заказа) создает Order (Заказ) в статусе pending (в ожидании) и публикует событие OrderCreated (ЗаказСоздан).
  2. Customer Service (Сервис Клиента) получает событие и пытается зарезервировать кредит для заказа. После чего публикует одно из двух событий: CreditReserved (КредитЗарезервирован) или CreditLimitExceeded (КредитныйЛимитПревышен).
  3. Order Service (Сервис Заказа) получает событие и изменяет состояние заказа в approved (подтвержден) или cancelled (отменен).

Оркестровка (Orchestration)

Оркестровка(Orchestration) - оркестратор говорит участникам, какие транзакции должны быть запущены.

Будут выполнены следующие шаги:

  1. Order Service (Сервис Заказа) создает Order (Заказ) в статусе pending (в ожидании) и создает CreateOrderSaga (СагаСозданияЗаказа).
  2. CreateOrderSaga (СагаСозданияЗаказа) отправляет команду ReserveCredit (ЗарезервироватьКредит) в Customer Service (Сервис Клиента)
  3. Customer Service (Сервис Клиента) пытается зарезервировать кредит для заказа и отправляет назад ответ
  4. CreateOrderSaga (СагаСозданияЗаказа) получает ответ и отправляет ApproveOrder (ПодтвердитьЗаказ) or RejectOrder (ОтменитьЗаказ) команду в Order Service (Сервис Заказа)
  5. Order Service (Сервис Заказа) изменяет состояние заказа в approved (подтвержден) или cancelled (отменен)

Command and Query Responsibility Segregation(CQRS)

CQRS — это стиль архитектуры, в котором операции чтения отделены от операций записи.

Решает проблему - не симметричное распределение нагрузки и сложности бизнес-логики на read(Query) и write(Command) - подсистемы Большинство бизнес-правил и сложных проверок находится во write — подсистеме. При этом читают данные зачастую в разы чаще, чем изменяют.

Недостатки

Event sourcing

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

Помогает эффективно распределять данные между микросервисами.

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

Недостатки:

Database per Microservice

Database per Microservice - микросервисы не имеют доступа к базе соседних сервисов и обращаются между собой средством REST, или через message broker.

Преимущество

Недостатки

Retry pattern

Retry pattern - механизм повторения запросов.

Виды:

Circuit Breaker

pattern - защищает сервисы от избыточной нагрузки и отказов.

Помогает "Retry pattern" не добить нагруженный сервис количеством запросов.

Как работает:

  1. Замеряет ошибки – если система часто отвечает сбоем, то "выключает" запросы.
  2. Блокирует вызовы – на время переключается в режим отказа (open state).
  3. Пробует восстановиться – спустя время делает тестовые запросы и, если сервис снова работает, возвращает его в работу.

Timeout pattern

Timeout pattern - ограничивает время ожидания запросов.

Виды timeout:

Fallback pattern

Fallback pattern - запасное действие в случае ошибки.

Виды fallback:

Bulkhead pattern

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

Применение Bulkhead pattern:

Publisher–Subscriber(Pub/Sub)

Publisher–Subscriber (Pub/Sub) модель - архитектурный паттерн для обмена сообщениями между компонентами системы, где отправители сообщений (publishers) не знают о получателях (subscribers), а доставка обеспечивается через event bus / broker (например, Kafka, RabbitMQ, Redis Pub/Sub).

Основные идеи:

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

Недостатки:

Реализации:

Features flag

Feature flag - это приём в разработке, который позволяет включать или выключать определённые функции приложения без деплоя новой версии.

Зачем они нужны?

Виды feature flags

Где хранятся флаги?

Минусы