Microservices

Этот материал является описанием понятия архитектуры Microservices с вопросами для проверки знаний, ключевыми компонентами и связанными темами.

In a Nutshell

Microservices представляют собой небольшие, независимо развёртываемые сервисы с чётко определённой зоной ответственности. Каждый сервис инкапсулирует свои данные и взаимодействует через хорошо документированные интерфейсы.

Подробное описание

Система разбивается на сервисы, ориентированные на бизнес-домен, часто вдоль границ Bounded Context (из Domain-Driven Design). Каждый сервис владеет собственной моделью данных и собственным хранилищем.

Взаимодействие:

• предпочтительно асинхронное через события
• синхронное — только в исключительных случаях через REST/gRPC

Согласованность данных обычно конечная. Распределённые транзакции координируются через Saga. Надёжность побочных эффектов обеспечивается через Outbox/Inbox и идемпотентные обработчики.

Для эксплуатации критичны CI/CD, оркестрация контейнеров (например, Kubernetes), наблюдаемость (логи, метрики, трассировка) и безопасность по умолчанию (Zero Trust, mTLS, OAuth/OIDC, управление секретами).

Антипаттерн: распределённый монолит (слишком много синхронных зависимостей или общая база данных).

Ключевые вопросы для подготовки

• Разбиение по доменам: Bounded Context; данные на сервис; без общих схем
• Асинхронность предпочтительнее, синхронность минимальна (задержки, каскадные отказы)
• Saga, Outbox/Inbox, идемпотентность
• Указание целевых показателей качества и SLO
• Безопасность: mTLS, OAuth/OIDC, управление секретами, ограничение частоты запросов
• Экономика: автономия vs. увеличенная сложность операций
• Документация: C4 (уровни 1-3), ADR, контракты интерфейсов, эксплуатационные процессы

Основные компоненты

1. Bounded Context
2. Проектирование API и версионирование
3. Данные на сервис
4. Messaging/очереди/потоки
5. Service Discovery и API Gateway
6. Устойчивость (таймауты, повторы, Circuit Breaker)
7. Наблюдаемость и Correlation IDs
8. CI/CD и Infrastructure as Code
9. Безопасность (аутентификация/авторизация, управление секретами)
10. Тестирование (контрактное, хаос-инженерия, нагрузочное)

Практический пример (Saga)

Order Service создаёт заказ (pending) + событие (Outbox)
Оркестратор:
- вызывает Payment Service (Idempotency Key)
- вызывает Inventory Service (резервирование)
- подтверждает заказ или отменяет (возврат платежа/отмена)

Практический пример (онлайн-магазин как Microservices)

Управление пользователями (например, Java + PostgreSQL)
Каталог товаров (например, Node.js + MongoDB)
Обработка заказов (например, Python + Message Broker)
Коммуникация: REST + события

Пояснение: каждый сервис имеет собственное хранилище данных, может масштабироваться и обновляться независимо. Изменения в одном сервисе не должны ломать остальные (чистые контракты и версионирование).

Плюсы и минусы

Плюсы

• Независимые развёртывания
• Масштабирование отдельных сервисов
• Лучшая изоляция ошибок
• Автономия команд

Минусы

• Увеличенная сложность операций и архитектуры
• Поиск ошибок в распределённой системе более сложен
• Согласованность данных требует явного проектирования

Типовые вопросы для проверки (с кратким ответом)

1. По какому принципу разбивать Microservices? По Bounded Context (Domain-Driven Design).
2. Как координировать распределённые транзакции? Saga с компенсацией и Outbox.
3. Почему синхронные цепочки вызовов — это проблема? Задержки и каскадные отказы.
4. Что означает «данные на сервис»? Каждой БД владеет один сервис; доступ других только через API или события.

Развёрнутый ответ

Microservices оправданы только при наличии правильного разбиения по доменам, зрелой платформы/DevOps и наблюдаемости/безопасности. В противном случае легко получить распределённый монолит.

Рекомендуемый подход к обучению

1. Разобрать архитектуру из 3 сервисов (API, события, собственность данных).
2. Нарисовать диаграмму последовательности Saga с путями обработки ошибок.
3. Практиковать таблицы с преимуществами и недостатками.
4. Избегать общих баз данных.

Типичный инструментарий (на практике)

• Docker / Kubernetes
• OpenAPI/Swagger для документирования API
• Мониторинг и метрики (например, Prometheus, Grafana)
• Трассировка (например, Zipkin/Jaeger)

Основные источники

1. https://microservices.io
2. https://martinfowler.com/microservices