Как происходит взаимодействие в архитектуре микросервисов

Взаимодействие в архитектуре микросервисов

Микросервисная архитектура — это подход, где приложение разделено на маленькие, независимые сервисы, каждый отвечающий за свою бизнес-функцию. Взаимодействие между ними — критичное звено всей системы.

1. Основные паттерны взаимодействия

Синхронное (Synchronous):

• Сервис A отправляет запрос к сервису B и ждёт ответа
• Используется REST API или gRPC
• Плюс: простота отладки, консистентность данных
• Минус: тесная связь, медленнее, проблемы одного сервиса влияют на другой

Асинхронное (Asynchronous):

• Сервис A отправляет событие в очередь сообщений
• Сервис B слушает очередь и обрабатывает событие
• Используется RabbitMQ, Kafka, AWS SQS
• Плюс: слабая связь, масштабируемость, отказоустойчивость
• Минус: сложнее отладить, потенциальная несогласованность данных

2. REST API взаимодействие

Пример:

User Service → GET /api/v1/users/123
                     ↓
User Service обращается к Profile Service
Profile Service → GET /api/v1/profiles/123
                       ↓
                   возвращает {name, email, avatar}
                       ↓
User Service получает данные и возвращает их клиенту

Типичные вызовы:

• Получить данные другого сервиса
• Обновить состояние в другом сервисе
• Удалить ресурс
• Изменить статус заказа

Проблемы:

• Cascading failures (одиот сервис упал → все, кто его вызывают, ломаются)
• Network latency
• Timeout issues

3. Message Queue взаимодействие

Архитектура:

Order Service
    ↓
Энимт: order.created
    ↓
RabbitMQ / Kafka
    ↓
Email Service (слушает order.created)
    ↓
Отправляет Email
    ↓
Payment Service (слушает order.created)
    ↓
Обрабатывает платёж

Преимущества:

• Decoupling: сервисы не знают друг о друге
• Scalability: добавь новый listener — не трогай источник
• Resilience: если Payment Service упадёт, Order Service продолжит работать

Типичные события:

• user.registered
• order.created
• payment.completed
• invoice.generated

4. Service Discovery

Проблема: микросервисы часто запускаются в Docker контейнерах с динамическими IP адресами. Как один сервис найдёт адрес другого?

Решение: Service Registry (например, Consul, Eureka, Kubernetes):

Payment Service стартует
    ↓
Регистрируется в Service Registry: "I am at 192.168.1.5:8080"
    ↓
Order Service нужны данные Payment Service
    ↓
Обращается к Service Registry: "Дай адрес Payment Service"
    ↓
Получает ответ: "192.168.1.5:8080"
    ↓
Отправляет запрос на этот адрес

5. API Gateway

Что это: единая точка входа для всех клиентов. Gateway маршрутизирует запросы нужным микросервисам.

Функции:

• Маршрутизация
• Аутентификация и авторизация
• Rate limiting
• Request/response transformation
• Load balancing

Пример:

Клиент
    ↓
API Gateway (:8000)
    ↓
    ├─ /api/users/* → User Service (:3001)
    ├─ /api/orders/* → Order Service (:3002)
    └─ /api/payments/* → Payment Service (:3003)

6. Типы связи между сервисами

Сильная связь (Tight Coupling):

• Сервис A напрямую вызывает Сервис B
• Если B упадёт или изменится — A сломается
• Сложно тестировать и развивать независимо

Слабая связь (Loose Coupling):

• Сервисы взаимодействуют через асинхронные события
• Каждый сервис может быть развёрнут и обновлён независимо
• Легче масштабировать

7. Транзакции в микросервисах

Проблема: как обеспечить консистентность данных, когда операция затрагивает несколько сервисов?

Решения:

Saga Pattern:

Оформить заказ
    ↓
1. Создать Order (Order Service)
2. Зарезервировать товар (Inventory Service)
3. Обработать платёж (Payment Service)
4. Отправить Email (Email Service)

Если на любом шаге ошибка → откатить предыдущие шаги (компенсирующие транзакции)

Event Sourcing:

• Каждое изменение состояния логируется как событие
• State строится из последовательности событий
• Легко воспроизвести всю историю и отладить

8. Для QA: что тестировать

Интеграционные тесты:

• Вызов одного сервиса → вызов зависимого сервиса → проверка результата
• Обработка ошибок (timeout, 5xx, network error)
• Retry механизм работает ли

End-to-End тесты:

• Полный путь пользователя через несколько сервисов
• Данные синхронизированы ли между сервисами
• Откат (rollback) работает ли

Performance тесты:

• Latency между сервисами
• Throughput при параллельных запросах
• Bottlenecks в сервисной цепочке

Chaos Engineering:

• Что происходит, если сервис B упадёт?
• Сработает ли circuit breaker?
• Восстановится ли система автоматически?

9. Инструменты для тестирования

• Docker Compose: локальный запуск всех сервисов
• Postman/Insomnia: тестирование API вызовов
• TestContainers: тестирование с реальными зависимостями (БД, очередями)
• Wiremock: мокирование других сервисов
• OpenTelemetry: трейсирование запросов между сервисами

Микросервисная архитектура предоставляет гибкость и масштабируемость, но требует глубокого понимания взаимодействий между компонентами. QA должен думать не только об отдельном сервисе, но о системе как едином целом.