Паттерны микросервисов
(продолжение предыдущего поста)

Реализация микросервисов часто сопроваждается применением ряда паттернов. Рассмотрим некоторые ключевые из них.

1. Database Per Service Pattern (база данных на сервис)

- Суть: каждый микросервис имеет собственную базу данных, изолированную от других сервисов. Взаимодействие между сервисами происходит через API, а не напрямую с БД.
- Схема (на изображении): показаны два микросервиса, каждый со своей базой данных.
- Преимущества:
- слабая связанность сервисов (изменения в БД одного сервиса не влияют на другие);
- возможность использовать разные типы БД для разных сервисов;
- упрощение масштабирования и развёртывания.
- Недостатки:
- усложнение обмена данными между сервисами;
- увеличение затрат на инфраструктуру (множество БД);
- сложность обеспечения транзакционной целостности.
- Подходит для: крупномасштабных проектов с большим числом микросервисов.

2. API Gateway Pattern (паттерн API-шлюза)

- Суть: создание единой точки входа для клиентских запросов. Шлюз маршрутизирует запросы к соответствующим микросервисам, агрегирует ответы и возвращает их клиенту.
- Схема (на изображении): клиент отправляет запрос к API Gateway, который перенаправляет его к нужным микросервисам.
- Функции API Gateway:
- маршрутизация запросов;
- агрегация ответов;
- аутентификация и авторизация;
- кэширование;
- ограничение скорости запросов (rate limiting).
- Преимущества:
- упрощение взаимодействия клиента с системой;
- централизованное управление безопасностью и логированием;
- оптимизация числа сетевых вызовов.
- Недостатки:
- риск единой точки отказа;
- необходимость дополнительного обслуживания шлюза.
- Подходит для: сложных систем с множеством микросервисов и разных клиентских приложений.

3. BFF Pattern (Backends for Frontends — бэкенды для фронтендов)

- Суть: создание отдельных бэкендов (шлюзов) для разных типов клиентов (веб, мобильное приложение, десктоп). Каждый BFF адаптирует API под специфические требования клиента.
- Схема (на изображении): показаны Web UI BFF и App BFF, которые взаимодействуют с микросервисами и адаптируют данные для соответствующих клиентов.
- Преимущества:
- оптимизация ответов под конкретный интерфейс пользователя;
- уменьшение объёма данных, передаваемых клиенту;
- изоляция изменений в клиентских приложениях от бэкенда.
- Недостатки:
- увеличение числа компонентов системы;
- дублирование логики для разных BFF.
- Подходит для: систем с разными требованиями к API у клиентов (например, веб и мобильное приложение).

4. CQRS (Command Query Responsibility Segregation — разделение команд и запросов)

- Суть: разделение операций изменения данных (команды — Command) и чтения данных (запросы — Query). Используются отдельные модели для записи и чтения данных.
- Схема (на изображении): показаны потоки Command (запись в Write DB) и Query (чтение из Read DB).
- Преимущества:
- оптимизация операций чтения и записи;
- возможность использовать разные хранилища для чтения и записи;
- повышение производительности и масштабируемости.
- Недостатки:
- увеличение сложности системы;
- необходимость синхронизации между хранилищами.
- Подходит для: систем с интенсивными операциями чтения (например, аналитические системы).

5. Event Sourcing Pattern (паттерн источника событий)

- Суть: хранение состояния приложения в виде последовательности событий, а не в виде текущего состояния. Все изменения системы записываются как события в Event Store.
- Схема (на изображении): показаны события (Event Profile Created, Event Hobbies Updated и т. д.), которые сохраняются в Event Store, а затем используются для чтения данных.
- Преимущества:
- полный журнал истории изменений системы;
- возможность отката состояния системы к любой точке во времени;
- упрощение реализации сложных бизнес-процессов.
- Недостатки:
- высокая сложность реализации;
- увеличение объёма хранилища данных.
- Подходит для: систем с критическими бизнес-процессами, где важна история изменений (например, финансовые системы).

6. Saga Pattern (паттерн саги)