› Routing & Infrastructure (Маршрутизация и инфраструктура)
API Gateway (Шлюз API)
Суть: Единая точка входа для всех внешних клиентов. Клиенты не обращаются к микросервисам напрямую.
Решаемые задачи: Скрытие внутренней архитектуры, маршрутизация запросов (Routing), терминация SSL, централизованная аутентификация/авторизация, агрегация ответов (сбор данных из 3-х сервисов в один ответ для клиента).
Инструменты: Spring Cloud Gateway, Nginx, Kong.
Service Discovery (Обнаружение сервисов)
Суть: Динамический реестр адресов микросервисов. В облачных средах (Docker/K8s) IP-адреса сервисов постоянно меняются.
Решаемые задачи: Позволяет сервисам находить друг друга по логическому имени (например, payment-service), а не по статичному IP-адресу. При старте сервис регистрирует свой IP в реестре, а при остановке — удаляет.
Инструменты: Netflix Eureka, HashiCorp Consul, встроенный DNS Kubernetes.
BFF (Backend for Frontend)
Суть: Эволюция API Gateway. Вместо одного огромного шлюза для всех, создаются отдельные, специализированные шлюзы под каждый тип клиента (один BFF для Web-версии, другой BFF для Mobile-приложения).
Решаемые задачи: Оптимизация полезной нагрузки (Mobile требует меньше данных, чем Web), предотвращение разрастания единого API Gateway (превращения его в монолит).
› Data Management (Управление данными)
Database per Service (База данных на сервис)
Суть: Фундаментальное правило микросервисов. Каждый сервис имеет свою собственную, изолированную БД. Другие сервисы могут получить доступ к этим данным только через API владельца.
Решаемые задачи: Обеспечивает слабую связность (Loose Coupling) и независимость развертывания.
Shared Database (Общая БД) — Anti-pattern
Суть: Несколько микросервисов ходят в одну физическую БД и читают/пишут в одни и те же таблицы.
Проблемы: Жесткая связность. Изменение схемы таблицы одной командой ломает работу других сервисов. Единая точка отказа (SPOF). Допустимо только на ранних этапах распила монолита.
Saga (Сага)
Суть: Паттерн реализации распределенных транзакций. Длинная бизнес-транзакция разбивается на серию локальных ACID-транзакций в разных сервисах. Если один из шагов завершается ошибкой, запускаются компенсирующие транзакции (отменяющие действия предыдущих шагов).
Choreography (Хореография): Децентрализованное управление через события (Kafka). Сервис А выполнил работу -> опубликовал событие -> Сервис Б отреагировал. Подходит для простых процессов (2-4 шага).
Orchestration (Оркестрация): Централизованное управление. Выделяется отдельный сервис-Оркестратор, который синхронно или асинхронно командует другими сервисами и отслеживает статус всей Саги. Подходит для сложных процессов.
CQRS (Command Query Responsibility Segregation)
Суть: Разделение моделей чтения и записи.
Решаемые задачи: Модель записи (Command) оптимизирована для строгой валидации и консистентности (например, реляционная БД). Модель чтения (Query) оптимизирована для быстрого поиска и агрегации (например, денормализованные данные в Elasticsearch). Данные синхронизируются асинхронно через брокер сообщений.
Event Sourcing (Порождение событий)
Суть: Состояние бизнес-сущности хранится не как текущее значение в таблице (например, balance = 100), а как неизменяемая последовательность событий, приведших к этому состоянию (AccountCreated, Deposited 150, Withdrawn 50).
Решаемые задачи: Идеальный аудит (невозможно подделать историю), возможность восстановить состояние системы на любой момент времени в прошлом. Часто используется в связке с CQRS.
Transactional Outbox (Паттерн “Исходящие”)
Суть: Решение проблемы двойной записи (Dual Write), когда нужно сохранить данные в БД и отправить событие в Kafka без риска рассинхронизации при сбоях.
Решаемые задачи: В рамках одной локальной ACID-транзакции бизнес-сущность сохраняется в свою таблицу, а событие — в таблицу outbox в той же БД. Отдельный фоновый процесс (Debezium / Polling) читает таблицу outbox и гарантированно отправляет события в брокер (At-least-once).
› Resilience & Reliability (Отказоустойчивость)
Circuit Breaker (Предохранитель)
Суть: Защита системы от каскадных сбоев. Если зависимый сервис Б начинает тормозить или падать, сервис А перестает отправлять к нему запросы и сразу возвращает ошибку (или fallback-значение).
Состояния:
CLOSED (запросы идут нормально).
OPEN (лимит ошибок превышен, запросы блокируются, fail-fast).
HALF-OPEN (после таймаута пропускается тестовый запрос; если успешен — переход в CLOSED, если нет — возврат в OPEN).
Инструменты: Resilience4j.
Retry (Повторная попытка)
Суть: Автоматический повтор запроса при кратковременных (transient) сетевых сбоях.
Правила применения: Использовать только для идемпотентных операций. Обязательно применять экспоненциальную задержку (Exponential Backoff) и случайный разброс (Jitter), чтобы не устроить DDoS-атаку на “оживающий” сервис.
Timeout (Таймаут)
Суть: Жесткое ограничение времени ожидания ответа от внешнего ресурса.
Решаемые задачи: Предотвращает бесконечное блокирование потоков (Thread Starvation) в вызывающем сервисе, если вызываемый сервис “завис”.
Bulkhead (Переборка)
Суть: Изоляция ресурсов (по аналогии с водонепроницаемыми отсеками на корабле).
Решаемые задачи: Разделение пулов потоков (Thread Pools) или пулов соединений для разных интеграций. Если интеграция с сервисом А исчерпает все свои потоки из-за сбоя, интеграция с сервисом Б продолжит нормально работать на своем независимом пуле потоков.
Rate Limiting (Ограничение скорости)
Суть: Ограничение количества запросов, которые клиент может сделать к API за определенный промежуток времени (например, 100 запросов в минуту).
Решаемые задачи: Защита от DDoS-атак, предотвращение исчерпания ресурсов (Resource Exhaustion) одним агрессивным клиентом, монетизация API (разные лимиты для разных тарифов).