Масштабирование ограничивают общая БД или внешний сервис, локальное состояние, последовательный участок работы, неравномерное распределение и дефицит ресурсов. Отдельно проверяют, создаются ли новые реплики и получают ли они трафик. Stateless упрощает горизонтальное масштабирование, но не устраняет общие узкие места.
По каким причинам микросервис может не масштабироваться?
Почему добавление реплик не всегда увеличивает производительность: общие узкие места, состояние, ограничения параллелизма и настройки инфраструктуры.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Сначала разделите две ситуации: система не добавляет экземпляры или добавляет, но общая производительность почти не растёт. Причины и диагностика различаются.
Если экземпляры не появляются, проверьте настройки масштабирования, верхний предел реплик, доступность метрик, квоты и ёмкость узлов. Созданный Pod может оставаться Pending или не проходить readiness. Например, HPA Kubernetes зависит от доступных метрик и заданной политики; он не создаёт бесконечную вычислительную ёмкость.
Если экземпляры есть, а выигрыша нет, ищите общий предел:
- БД упирается в CPU, I/O, блокировки или соединения.
- Внешний сервис ограничивает частоту запросов.
- Слишком много работы проходит через одну блокировку, очередь или partition.
- Локальные сессии и файлы привязывают запросы к конкретному экземпляру.
- Балансировка или распределение ключей создают горячую точку.
- Затраты на синхронизацию и сетевые обмены растут быстрее полезной работы.
Отсутствие auto-scaling само по себе не означает, что сервис принципиально немасштабируем: реплики можно добавлять и другим управляемым способом. И наоборот, наличие Kubernetes не доказывает эффективного параллелизма.
Проверяйте гипотезу измерениями: throughput, задержки, ошибки, очереди и насыщение зависимостей при изменении числа экземпляров. Учитывайте, что каждая новая реплика может увеличить суммарное число соединений к уже перегруженной БД.
Stateless-дизайн, кэш, асинхронность или изменение разбиения данных выбирают под обнаруженное ограничение. Ни распределённая БД, ни дополнительный брокер не являются обязательным универсальным лечением.