Какие знаешь проблемы микросервисной архитектуры?

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

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

1. Сложность сетевого взаимодействия

В микросервисах каждый вызов идет по сети:

// Раньше: простой вызов в памяти
OrderService.createOrder(order);

// Теперь: HTTP/gRPC вызов через сеть
restTemplate.postForObject("http://order-service/orders", order, Order.class);

Проблемы:

• Задержки (latency): сетевой вызов медленнее памяти в тысячи раз
• Частичные сбои: сервис B недоступен, но A отправил данные уже
• Timeout: как долго ждать ответа?
• Cascading failures: сбой одного сервиса может обрушить цепочку

Решения: circuit breaker, retry logic, timeout策略.

2. Distributed Transactions (Распределённые транзакции)

// Монолит: одна ACID транзакция
@Transactional
public void transferMoney(Long fromId, Long toId, BigDecimal amount) {
    accountService.debit(fromId, amount);
    accountService.credit(toId, amount);
    // Либо успех, либо всё откатывается
}

// Микросервисы: нет ACID
post("/accounts/{id}/debit", ...)
post("/accounts/{id}/credit", ...)
// Что если второй вызов упадёт?

Решения:

• Saga pattern: цепочка локальных транзакций с компенсирующими действиями
• Event sourcing: хранить историю событий, не состояние
• Two-phase commit: но это медленно и недёжно

3. Мониторинг и отладка

// Запрос проходит через 5 микросервисов
UserService → OrderService → PaymentService → InventoryService → NotificationService
// Где произошла ошибка? В каком сервисе? На каком шаге?

Проблемы:

• Трассировка (tracing): нужно отследить request ID через все сервисы
• Логирование: логи разбросаны по разным серверам/файлам
• Метрики: нужно собирать метрики с каждого сервиса

Решения: ELK stack, Jaeger, Prometheus, центральное логирование.

4. Асинхронность и eventual consistency

// Монолит: данные консистентны сразу
order.setStatus("paid");
db.save(order);

// Микросервисы: асинхронность через события
eventBus.publish(new OrderPaidEvent(orderId));
// Другие сервисы узнают об изменении позже
// Временное несоответствие данных (eventual consistency)

Проблемы:

• Временное несоответствие: как показать пользователю непротиворечивые данные?
• Потерянные события: что если consumer упал?
• Duplicate processing: что если event обработается дважды?

5. Data Management nightmare

В микросервисах каждый сервис имеет свою БД:

// Больше нельзя написать простой JOIN
SELECT * FROM orders o 
JOIN users u ON o.user_id = u.id
JOIN payments p ON o.id = p.order_id;

// Нужно:
// 1. Запрос в OrderService
// 2. Запрос в UserService
// 3. Запрос в PaymentService
// 4. Слить данные в памяти (impedance mismatch)

Проблемы:

• Отсутствие глобальных транзакций
• Денормализация: данные дублируются в разных БД
• Миграции: как обновить схему без downtime?

6. Operational Complexity

# Монолит: 1 приложение
docker run myapp

# Микросервисы: 15+ контейнеров
docker-compose up -d  # Нужно запустить, настроить, обновить, масштабировать

Проблемы:

• Deployment: нужна CI/CD для каждого сервиса
• Версионирование: compatibility между версиями API
• Rolling updates: как обновить без downtime?
• Масштабирование: каждый сервис масштабируется отдельно
• Конфигурация: управление конфигом для 15+ сервисов

Решения: Kubernetes, service mesh (Istio), infrastructure as code.

7. Testing nightmare

// Unit тест просто
@Test
public void testCreateOrder() { ... }

// Integration тест: нужно запустить все зависимые сервисы
@Test
public void testOrderCreationFlow() {
    // Запустить БД, Kafka, 3+ микросервиса
    // Расставить mock'и или реальные instances
    // Проверить consistency
}

Проблемы:

• Количество комбинаций: стремительно растет
• Flaky tests: асинхронность порождает race conditions
• Контрактное тестирование: как убедиться, что API не сломается?

Решения: Contract testing, Consumer-Driven Tests, test containers.

8. Network latency и reliability

Нет гарантии:

• Пакет не потеряется
• Ответ придёт вовремя
• Сервис доступен
• Вызов обработается ровно один раз

// Идемпотентность — критична
@PostMapping("/payments")
public void processPayment(@RequestBody Payment payment) {
    // Что если вызов переотправится? Берём деньги дважды?
    // Должны быть идемпотентные ключи
}

9. Слабая связанность != Easy to change

Микросервисы слабо связаны, но:

• Изменение API одного сервиса требует обновления зависимых
• Версионирование API — сложно
• Breaking changes — опасны

10. Стоимость разработки и содержания

• Нужна более опытная команда
• DevOps infrastructure дороговизна
• Больше сложности → больше ошибок
• ROI не всегда позитивен для малых проектов

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

✅ Используй, если:

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

❌ Не используй, если:

• Команда < 10 человек
• Монолит справляется
• Не нужны независимые развертывания
• Данные сильно связаны