PrepBro
← Назад к вопросам

Как понять что микросервис превращается в монолит?

2.0 Middle🔥 141 комментариев
#Архитектура систем

Комментарии (1)

🐱
claude-haiku-4.5PrepBro AI28 мар. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

Как понять, что микросервис превращается в монолит?

Это частая проблема в evolving систем, когда микросервисная архитектура теряет свои преимущества и становится сложнее монолита. Вот признаки "микролита" и способы их выявить.

Признаки деградации архитектуры

1. Избыточная синхронная взаимозависимость

  • Сервисы постоянно ждут ответы друг от друга (Request/Response)
  • Цепочки вызовов A → B → C → D создают bottleneck
  • Задержка в одном сервисе замораживает всю систему
  • Вывод: если больше синхронных вызовов, чем асинхронных — проблема

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

Когда нужна ACID операция через несколько сервисов:

  • Saga паттерн с компенсирующими транзакциями
  • Retry логика, обработка deadlock сценариев
  • Сложная отладка и тестирование
  • Вывод: много distributed transactions = неправильная декомпозиция

3. Общая база данных

  • Несколько сервисов используют одну БД
  • Отсутствие database-per-service паттерна
  • Нарушение принципа владения данными
  • Вывод: это де-факто монолит с независимым кодом

4. Высокий coupling между сервисами

  • Изменение в одном сервисе требует изменений в других
  • Синхронизация версий API
  • Общие библиотеки, общие модели данных
  • Вывод: низкая автономность = монолит

5. Растущая служба оркестрации

Центральный сервис, который:

  • Координирует вызовы между другими сервисами
  • Содержит бизнес-логику нескольких доменов
  • Становится critical point of failure
  • Вывод: архитектура выродилась в hub-and-spoke

6. Сложность развёртывания

  • Нужно развернуть N сервисов в определённом порядке
  • Зависимости версий между сервисами
  • Откат одного требует отката других
  • Вывод: потеряна независимость развёртывания

Метрики для выявления проблемы

Анализ кода:

  • Подсчёт inter-service вызовов vs intra-service
  • Время жизни зависимостей (request chain length)
  • Размер service-to-service интерфейсов

Анализ баз данных:

SELECT service, COUNT(*) as table_count
FROM information_schema.tables
GROUP BY service;
  • Проверить владение таблицами
  • Выявить shared databases

Мониторинг (Observability):

  • Latency между сервисами (trace показывает цепочки)
  • Error rate и retry количество
  • P95/P99 response time распределены?

Что делать? Решения

Переоценить декомпозицию

  • Сервисы граничат по bounded context (Domain-Driven Design)
  • Проверить: может ли сервис работать независимо 80% операций?
  • Если нет — переоценить границы

Перейти на асинхронность

  • Event-driven архитектура вместо RPC
  • Message brokers (RabbitMQ, Kafka)
  • CQRS для асинхронных читаемых моделей

Внедрить circuit breakers

// Пример: Hystrix/Resilience4j
@CircuitBreaker(name = "userService", failureThreshold = 5)
public User getUser(String id) { ... }

Вернуться к монолиту (если нужно)

  • Modular monolith с чёткими границами
  • Независимые compilation units
  • Shared runtime, но разные deployment paths
  • Проще, чем микросервисы, но масштабируемее, чем spaghetti код

Практический чеклист

  • Сколько % вызовов синхронные? (норма < 30%)
  • Есть ли сервисы, общающиеся прямо по БД?
  • Требуется ли координация при развёртывании?
  • Есть ли сервис, который вызывает 10+ других?
  • Какое среднее время обработки request цепочки?

Если ответов "да" больше 3 — срочно рефакторить архитектуру.

Как понять что микросервис превращается в монолит? | PrepBro