Паттерны взаимодействия микросервисов

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

[1.] Паттерн Saga → Обеспечение согласованности

Вы бронируете авиабилет и номер в отеле.

Вам нужно, чтобы было подтверждено либо всё, либо ничего.

Именно для этого и существуют Saga.

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

Два варианта реализации:
* Хореография — сервисы обмениваются сообщениями через события («Билет забронирован!», «Отель забронирован!», «Ой, билет отменён!») для поддержания синхронизации.
* Оркестрация — центральный «менеджер» указывает каждому сервису, что делать, и выполняет откат в случае ошибок.

[2.] API Композиция

Персональный помощник для вашего приложения.

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

* API Gateway или BFF (Backend for Frontend) взаимодействует с несколькими микросервисами, собирает данные и предоставляет их клиенту в едином пакете.

[3.] CQRS → Разделение операций чтения и записи

Как два повара на кухне: один готовит (записывает данные), а другой подаёт блюда (читает данные).

* Используются отдельные модели для чтения и записи данных.
* Это позволяет оптимизировать каждую сторону под конкретную задачу.
* Сложная настройка, требуется синхронизация двух моделей.

[4.] Event-Driven Collaboration → Взаимодействие на основе событий

Групповой чат, где сервисы обмениваются обновлениями.

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

* Сервисы публикуют события («Заказ оформлен!»).
* Другие сервисы подписываются на эти события и выполняют свои задачи при получении релевантных уведомлений.
* Может быть сложно отлаживать, требуется обеспечение правильной последовательности обработки сообщений.

[5.] Command-Side Replica → Локальная копия для ускорения

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

* Сервис хранит локальную, доступную только для чтения копию данных другого сервиса.
* Это ускоряет операции чтения и снижает зависимость от доступности другого сервиса.
* Данные могут быть немного устаревшими (задержка репликации), требуется сложность для поддержания синхронизации копий.

[6.] Shared Database (антипаттерн) → Общая база данных

* Несколько микросервисов используют одну и ту же базу данных.

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