Что такое микросервис?

Микросервисы: архитектура современных приложений

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

Определение и основные характеристики

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

Основные характеристики микросервиса:

• Независимость — каждый сервис разрабатывается, развертывается и масштабируется независимо
• Узкая ответственность — один сервис отвечает за одну область (Principle of Single Responsibility)
• Слабая связанность — сервисы взаимодействуют через API, не через общую базу данных
• Собственная база данных — каждый микросервис может иметь свою БД, если нужно
• Самостоятельность — может быть написан на любом языке программирования
• Асинхронность — часто общаются через очереди сообщений, но могут использовать и синхронные вызовы

Архитектура микросервисов

Клиент
  ↓
API Gateway (точка входа)
  ↓
┌─────────────────┬──────────────────┬─────────────────┐
│  User Service   │  Order Service   │ Payment Service │
│  (Node.js)      │  (Java)          │  (Python)       │
└────────┬────────┴────────┬─────────┴────────┬────────┘
         ↓                 ↓                  ↓
    User DB          Order DB            Payment DB

Примеры микросервисов в реальных системах

Представим онлайн-магазин, разделённый на микросервисы:

1. User Service — управление пользователями, авторизация
2. Product Service — каталог товаров, информация о товарах
3. Order Service — создание, управление заказами
4. Payment Service — обработка платежей
5. Notification Service — отправка уведомлений по почте/SMS
6. Shipping Service — отслеживание доставки
7. Review Service — рецензии и рейтинги

Каждый сервис может быть разработан отдельной командой, на разных технологиях.

Преимущества микросервисной архитектуры

1. Гибкость и масштабируемость

• Масштабируешь только нужный сервис (если Payment Service получает нагрузку, масштабируешь только его)
• Не нужно масштабировать всё приложение целиком
• Быстрое добавление новых функций

2. Независимое развитие и развертывание

• Разные команды работают на разных сервисах
• Можешь развернуть User Service, не трогая Payment Service
• Быстрый цикл разработки и CI/CD

3. Техническая гибкость

• Order Service написан на Java, Payment Service на Python
• Каждая команда выбирает лучший инструмент для своей задачи
• Легче обновлять зависимости

4. Изоляция сбоев

• Если Payment Service упал, остальные сервисы продолжают работать
• В монолите одна ошибка может сломать всё приложение

5. Лучше для больших команд

• Разные команды работают независимо
• Меньше конфликтов в кода
• Каждая команда отвечает за свой сервис

Недостатки микросервисной архитектуры

1. Сложность

• Сеть вместо локальных вызовов функций
• Нужна хорошая инфраструктура (Docker, Kubernetes)
• Сложнее отлаживать проблемы

2. Проблемы с согласованностью данных

• Не можешь использовать ACID транзакции через сервисы
• Нужно реализовать паттерн Saga для распределённых транзакций

Пример проблемы:

Опция 1: Заказ создан, но платёж не прошёл
Опция 2: Платёж обработан, но сервис заказов упал

3. Работа с сетевыми задержками

• API вызовы медленнее, чем локальные функции
• Нужно реализовать timeout, retry, circuit breaker паттерны

4. Управление версиями API

• Нужно поддерживать обратную совместимость
• Сложнее обновлять API, если от него зависят другие сервисы

5. Операционная сложность

• Много сервисов для мониторинга
• Нужны логирование, трейсинг, алерты
• Требуется опытная DevOps команда

Как микросервисы общаются

1. Синхронная коммуникация (REST, gRPC)

Order Service → (HTTP запрос) → Payment Service
                             ↓
Order Service ← (HTTP ответ) ← Payment Service

Преимущества: просто, понятно Недостатки: если Payment Service упал, заказ не создаётся

2. Асинхронная коммуникация (Message Queue)

Order Service → (отправляет событие) → Message Queue (RabbitMQ, Kafka)
                                              ↓
                                    Payment Service (обрабатывает)

Преимущества: слабая связанность, отказоустойчивость Недостатки: сложнее гарантировать порядок, может быть задержка

Тестирование микросервисов

Для QA инженера это сложнее, чем тестирование монолита:

1. Unit тесты

• Тестирование каждого сервиса отдельно
• Используются моки для зависимостей

2. Integration тесты

• Тестирование взаимодействия между сервисами
• Нужны запущенные зависимые сервисы

3. Contract тесты

• Проверка контракта между сервисами (API)
• Например, Payment Service ожидает структуру JSON такую-то

4. End-to-End тесты

• Тестирование полного потока через все сервисы
• Самые сложные и медленные

5. Performance тесты

• Проверка задержек сети
• Нагрузочное тестирование каждого сервиса

Инструменты для микросервисов

• Docker — контейнеризация сервисов
• Kubernetes — оркестрация контейнеров
• API Gateway (Kong, AWS API Gateway) — маршрутизация запросов
• Service Mesh (Istio) — управление сетью сервисов
• Message Queue (RabbitMQ, Kafka, Redis) — асинхронная коммуникация
• Tracing (Jaeger, Zipkin) — отслеживание вызовов
• Monitoring (Prometheus, Grafana) — мониторинг сервисов

Когда использовать микросервисы

✅ Используй микросервисы, если:

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

❌ Не используй микросервисы, если:

• Приложение маленькое (стартап)
• У тебя 1-2 разработчика
• Нет опыта с DevOps
• Не нужна отказоустойчивость

Монолит vs Микросервисы

Пример в коде

Монолитный подход (все в одном сервисе):

app = FastAPI()

@app.post("/orders")
def create_order(order_data):
    # Проверка пользователя
    user = get_user(order_data.user_id)
    # Проверка товара
    product = get_product(order_data.product_id)
    # Обработка платежа
    payment = process_payment(order_data.payment_info)
    # Создание заказа
    order = save_order(user, product, payment)
    return order

Микросервисный подход (разделённо на сервисы):

# Order Service
@app.post("/orders")
def create_order(order_data):
    # Order Service отправляет запросы к другим сервисам
    user_response = http_client.get(f"http://user-service/users/{order_data.user_id}")
    product_response = http_client.get(f"http://product-service/products/{order_data.product_id}")
    payment_response = http_client.post("http://payment-service/payments", order_data.payment_info)
    
    order = save_order(user_response, product_response, payment_response)
    return order

Заключение

Микросервисная архитектура — это мощный подход для больших, сложных приложений. Однако она требует опыта в DevOps, хорошей инфраструктуре и правильного проектирования. Для QA инженера это означает необходимость понимания взаимодействия между сервисами и более сложные стратегии тестирования.