Микросервисная архитектура
Микросервисная архитектура
Введение
Когда компания вырастает и одно приложение становится слишком большим и сложным — его разбивают на микросервисы. Сегодня большинство крупных продуктов (Netflix, Amazon, Uber) используют именно эту архитектуру. Как тестировщик, ты должен понимать, что изменяется в твоей работе, когда ты переходишь от монолита к микросервисам.
Монолит vs Микросервисы
Монолитная архитектура
┌─────────────────────────────────────┐
│ Одно приложение │
│ ┌─────────┐ ┌─────────┐ ┌──────┐ │
│ │ Users │ │ Orders │ │ Pay │ │
│ │ module │ │ module │ │ mod │ │
│ └─────────┘ └─────────┘ └──────┘ │
│ Одна база данных │
└─────────────────────────────────────┘
Плюсы монолита: просто разрабатывать, легко тестировать, одно развёртывание. Минусы: при росте — сложнее менять, масштабировать, деплоить.
Микросервисная архитектура
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ user-service │ │order-service│ │ pay-service │
│ (БД 1) │ │ (БД 2) │ │ (БД 3) │
└─────────────┘ └─────────────┘ └─────────────┘
↑ ↑ ↑
└────────────────┴────────────────┘
API Gateway
↑
Клиент
Ключевые характеристики микросервисов
| Характеристика | Описание |
|---|---|
| Собственная БД | Каждый сервис владеет своими данными |
| Независимый деплой | Можно обновить один сервис, не трогая остальные |
| Собственный API | Каждый сервис предоставляет HTTP REST или gRPC API |
| Единственная ответственность | Один сервис = одна бизнес-область |
Примеры микросервисов
Типичное e-commerce приложение:
- user-service — регистрация, профили, аутентификация.
- product-service — каталог, цены, остатки.
- order-service — заказы, статусы, история.
- payment-service — платежи, возвраты.
- notification-service — email, SMS, push-уведомления.
Взаимодействие между сервисами
Синхронное (HTTP/REST)
Сервис A вызывает сервис B и ждёт ответа:
order-service → (POST /payments) → payment-service
← 200 OK {status: "approved"} ←
Минус: если payment-service упал — order-service тоже не работает.
Асинхронное (Message Queue)
Сервис A публикует сообщение в очередь, сервис B читает когда готов:
order-service → [order.created] → Kafka/RabbitMQ
↓
notification-service (отправит email)
inventory-service (спишет товар)
Плюс: сервисы независимы, надёжнее при сбоях.
API Gateway
API Gateway — единая точка входа, которая маршрутизирует запросы к нужным микросервисам:
Клиент → API Gateway → /users/* → user-service
→ /orders/* → order-service
→ /products/* → product-service
Также может: аутентификация, rate limiting, логирование, балансировка.
Что меняется для тестировщика
| Аспект | Монолит | Микросервисы |
|---|---|---|
| Среда | Один сервер | Много сервисов, сложнее поднять локально |
| Данные | Одна БД | Данные размазаны по БД разных сервисов |
| Баг | Чаще локален | Может быть на границе сервисов |
| Контракты | Внутренние | Публичные API-контракты между сервисами |
| Мониторинг | Один лог | Логи distributed, нужен трейсинг |
Contract Testing (контрактное тестирование)
Когда сервисы взаимодействуют через API, важно, чтобы их контракты совпадали. Если order-service ожидает от payment-service поле transactionId, а тот вернул transaction_id — всё сломается.
Contract testing проверяет, что API одного сервиса соответствует ожиданиям другого, без запуска обоих одновременно. Популярный инструмент — Pact.
Типичные баги в микросервисной архитектуре
- Network timeout: сервис B не ответил вовремя — сервис A завис.
- Inconsistent data: order создан, но payment-service упал — данные рассинхронизированы.
- Version mismatch: сервис A обновился, сервис B ожидает старый контракт.
- Cascading failures: сервис A упал → сервис B завис в ожидании → сервис C тоже завис.
Частые ошибки тестировщиков
- Тестировать сервисы только изолированно. Интеграция между сервисами — отдельный уровень тестирования.
- Игнорировать сценарии отказа. Что если сервис B недоступен? Сервис A должен вернуть понятную ошибку, а не зависнуть.
- Не знать карту сервисов. Понимание, какой сервис за что отвечает, — базовое требование.
Что мы запомним
- Монолит — одно большое приложение, микросервисы — много малых независимых сервисов.
- Каждый микросервис имеет собственную БД, API и деплоится независимо.
- Коммуникация: синхронная (HTTP) и асинхронная (Kafka/RabbitMQ).
- API Gateway — единая точка входа, маршрутизирует к нужному сервису.
- Для тестировщика: важно понимать карту сервисов, тестировать интеграцию и сценарии отказа.
- Contract testing — проверка совместимости API-контрактов между сервисами.