Архитектура Microservices
Этот материал представляет собой определение понятия Microservices с контрольными вопросами и тегами.
Суть
Microservices это небольшие, независимо развёртываемые сервисы с чётко разделённой ответственностью. Каждый сервис инкапсулирует собственные данные и общается через хорошо определённые интерфейсы.
Краткое техническое описание
В архитектуре Microservices систему разбивают на предметные (business-oriented) сервисы, часто следуя Bounded Context из DDD. Каждый сервис имеет собственную модель данных и хранилище. Взаимодействие предпочтительно асинхронное через события, для синхронных запросов используют простые API вроде REST или gRPC. Развёртывание независимо друг от друга, Continuous Delivery позволяет быстро выпускать изменения. Консистентность обычно eventual, распределённые транзакции координируют через Sagas. Наблюдаемость обязательна: структурированные логи, метрики, трассировка и correlation IDs необходимы для отслеживания вызовов между сервисами.
Ключевые пункты к экзамену
- Разделение по предметной области, один Bounded Context на сервис, данные принадлежат сервису, нет общей схемы БД
- Стили коммуникации: асинхронный messaging для развязки, синхронные вызовы минимизируют
- Консистентность данных: Sagas, Outbox, Inbox, идемпотентная обработка, at-least-once семантика
- Назовите качественные характеристики: изменяемость, доступность, безопасность, прозрачность (SLOs)
- Независимые репозитории, сборка, тесты, развёртывание на сервис, Consumer Driven Contract Tests
- Безопасность: mTLS, OAuth 2/OIDC, управление секретами, Policy Enforcement, Rate Limiting
- Экономика: автономность команд, параллельная разработка, масштабирование отдельных компонентов, выше операционные затраты
- Документирование: C4 модель уровня 1-3, контракты API, ADRs, инструкции по эксплуатации, план на непредвиденные ситуации
Основные компоненты
- Предметный разрез, Bounded Context для каждого сервиса
- Дизайн API: Resource ориентированный или RPC, версионирование, обратная совместимость
- Данные в сервисе: независимое хранилище, стратегия миграции
- Коммуникационный слой: Message Broker, очередь, stream, Request-Response
- Service Discovery и маршрутизация: API Gateway, Ingress
- Устойчивость: Circuit Breaker, тайм-ауты, Retries с exponential backoff, Bulkheads
- Observability: логи, метрики, Tracing, Correlation ID
- Развёртывание и инфраструктура: контейнеры, оркестрация, IaC, CI/CD
- Безопасность: mTLS, аутентификация/авторизация, управление секретами, Audit Logging
- Тестирование: Unit, интеграционные, Contract Tests, Chaos Engineering, нагрузочное тестирование
Практический пример
// Saga, оркестрируемая: процесс заказа с Order Service, Payment Service, Inventory Service
POST order/create { customerId: 42, items: [{ sku: "A1", qty: 2 }] }
Order Service сохраняет заказ со статусом pending, создаёт событие order.created (outbox)
Orchestrator получает order.created, вызывает Payment Service:
POST payments с Idempotency Key: ord-42
Payment Service авторизует платёж, публикует событие payment.authorized
Orchestrator вызывает Inventory Service:
POST reservations { orderId: 42, items: ... }
Inventory резервирует товары, публикует событие inventory.reserved
Orchestrator устанавливает заказу статус confirmed, публикует order.confirmed
Компенсация при inventory.reservation.failed:
- Вызывает Payment Service: POST payments/refund
- Устанавливает заказу статус cancelled
Плюсы и минусы
Плюсы
- Независимое развёртывание, быстрее итерации
- Целевое масштабирование, лучше изоляция отказов
- Технологическое разнообразие на сервис, ясная ответственность
- Автономность команд, параллельная работа
Минусы
- Высокая операционная сложность
- Отладка в распределённой системе, сетевые ошибки и задержки
- Консистентность требует явного моделирования
- Требовательна к Observability и Security
- Риск распределённого монолита
Типичные экзаменационные вопросы (с кратким ответом)
- Как разрезать Microservices по предметной области? По Bounded Context с чёткой Ubiquitous Language, минимальная связанность, максимальная когезия.
- Распределённые транзакции без Two Phase Commit? Через Saga с оркестрацией/хореографией, идемпотентные шаги компенсации, Outbox-pattern.
- Проблема синхронных цепочек вызовов? Усиливают задержки/отказы, эффект каскада, снижают автономность. Решение: асинхронные события, Circuit Breaker.
- Данные на сервис на практике? Каждый сервис владеет собственной схемой персистентности, скрывает её за API, интеграция через события/API.
- Роль API Gateway? Единая точка входа: маршрутизация, аутентификация, Rate Limits, Observability, трансляция протоколов.
- Прозрачность через границы сервисов? Correlation IDs, распределённая трассировка, структурированные логи, согласованная пропаганация через все вызовы.
- Когда экономически оправдано? При больших командах и сложных предметных областях, если независимое развёртывание компенсирует операционные затраты.
- Консистентность vs доступность в CAP? Обычно выше доступность с eventual consistency, локальные инварианты строгие, глобальные координируют Sagas.