Назовите основные паттерны микросервисной архитектуры.

1. API Gateway (Шлюз API)

• Назначение: Единая точка входа для всех клиентских запросов.
• Решает: Маршрутизацию, аутентификацию/авторизацию, ограничение скорости запросов (rate limiting), кэширование, преобразование протоколов.
• Инструменты: Spring Cloud Gateway, Netflix Zuul, Kong.

2. Circuit Breaker (Предохранитель)

• Назначение: Предотвращение каскадных сбоев при отказе зависимого сервиса.
• Решает: При повторных ошибках переходит в состояние "разомкнуто" и сразу возвращает fallback-ответ, не нагружая неработающий сервис. Периодически проверяет восстановление.
• Инструменты: Resilience4j, Hystrix (устарел).

// Пример с Resilience4j
CircuitBreaker circuitBreaker = CircuitBreaker.ofDefaults("inventoryService");
Supplier<Product> decoratedSupplier = CircuitBreaker
    .decorateSupplier(circuitBreaker, () -> inventoryClient.getProduct(id));

Try<Product> result = Try.ofSupplier(decoratedSupplier)
    .recover(throwable -> getProductFromCache(id)); // Fallback

3. Service Discovery (Обнаружение сервисов)

• Назначение: Динамическое обнаружение сетевых адресов сервисов.
• Решает: Позволяет сервисам находить друг друга без жёсткой привязки к IP/порту.
• Модели: Клиентская (Eureka) и серверная (Consul, etcd).

4. CQRS (Command Query Responsibility Segregation)

• Назначение: Разделение моделей для операций записи (команд) и чтения (запросов).
• Решает: Позволяет независимо масштабировать и оптимизировать чтение и запись. Часто используется с отдельной денормализованной БД для чтения.

5. Saga

• Назначение: Управление распределёнными транзакциями, охватывающими несколько сервисов.
• Решает: Заменяет двухфазный коммит (2PC). Координирует последовательность локальных транзакций, каждая из которых публикует событие для запуска следующего шага. В случае ошибки выполняются компенсирующие транзакции.
• Типы: Оркестрируемая (центральный координатор) и Хореографическая (сервисы общаются событиями).

6. Event Sourcing (Порождающее события)

• Назначение: Сохранение состояния приложения как последовательности неизменяемых событий.
• Решает: Полный аудит, возможность "переиграть" события для восстановления состояния, естественная интеграция в event-driven системах.

7. Sidecar (Боковой контейнер)

• Назначение: Вынос инфраструктурных задач (логирование, мониторинг, конфигурация) в отдельный процесс/контейнер, работающий рядом с основным сервисом.
• Решает: Единообразие инфраструктурного кода, упрощение основного сервиса.
• Пример: Паттерн реализован в service mesh (например, Envoy proxy в Istio).