Reference
Envoy Load Balancing
Практическое описание алгоритмов балансировки и сценариев применения.
Открыть обзор
Алгоритм балансировки напрямую влияет на latency, устойчивость и эффективность использования ресурсов. Один и тот же пул инстансов может работать по-разному в зависимости от того, выбираете ли вы равномерное распределение, адаптацию к текущей нагрузке или маршрутизацию по ключу.
Базовые алгоритмы и визуализация
Round Robin
Запросы распределяются по серверам по кругу: S1 -> S2 -> S3 -> S1.
Плюсы
- Очень простая реализация и предсказуемое поведение.
- Хорошо подходит для stateless backend с одинаковыми узлами.
- Низкий runtime overhead у балансировщика.
Ограничения
- Не учитывает текущую загрузку и медленные узлы.
- При неоднородных серверах может ухудшать latency.
Подходит для: Stateless API, равномерный трафик, похожая мощность инстансов.
Request Queue
REQ-101Web
user:42
REQ-102Mobile
user:77
REQ-103Partner
tenant:acme
REQ-104Web
user:42
Load Balancer
Round Robin
Каждый новый запрос отправляется на следующий сервер по кругу.
Server A
active connections: 0
Server B
active connections: 0
Server C
active connections: 0
Готово
Готово к симуляции. Запусти авто-режим или сделай один шаг.
Последнее решение: —
Сравнение и trade-offs
| Algorithm | State awareness | Failover behavior | Balancing quality | Complexity | Best fit |
|---|---|---|---|---|---|
| Round Robin | Нет | Простое исключение узла | Средняя | Низкая | Stateless, homogeneous pool |
| Least Connections | Active connections | Хорошо при burst + long-lived connections | Высокая | Средняя | Mixed latency workload |
| Consistent Hashing | Key-aware routing | Частичный remap на соседние узлы | Зависит от virtual nodes | Высокая | Stateful/cache-sensitive traffic |
Практика выбора
Быстрые правила
- Начинайте с Round Robin для простых stateless API.
- Переходите на Least Connections при длинных/неравномерных запросах.
- Используйте Consistent Hashing, когда важны locality и sticky state.
- Проверяйте решение на пиковом профиле, а не только на среднем трафике.
Частые ошибки
- Выбирать алгоритм без анализа профиля трафика (длина запросов, burst, key skew).
- Использовать Consistent Hashing без virtual nodes и мониторинга hot keys.
- Игнорировать health checks и slow-start для новых инстансов.
- Считать active connections единственной метрикой загрузки без CPU/RPS/p99 latency.
- Смешивать sticky и non-sticky маршрутизацию без явной политики fallback.
Мини-чеклист перед продом
1. Включены active/passive health checks.
2. Настроены slow-start и graceful connection draining.
3. Есть метрики p95/p99, backend saturation, retry storm rate.
4. Тестирован failover при выключении и деградации узлов.