Балансировка трафика

Балансировка трафика перестаёт быть просто прокси перед сервисом, как только начинаются деградации, релизы и переключение на резерв.

Глава связывает выбор между L4 и L7, контроль состояния инстансов, плавный ввод трафика, глобальную маршрутизацию и сервисную сетку в одну операционную картину.

На интервью и в архитектурных обсуждениях такой взгляд помогает объяснять не только схему распределения трафика, но и то, как система переживает релизы, сбои и рост нагрузки.

Практическая польза главы

Путь запроса

Смотрите на балансировку как на весь путь запроса: входная точка, состояние инстансов, тайм-ауты и поведение системы при деградации.

Выбор уровня

Разводите задачи L4 и L7 по характеру трафика, требованиям к маршрутизации и цене дополнительной логики.

Операционная устойчивость

Заранее продумывайте плавный ввод инстансов, вывод соединений и переключение на резерв, чтобы релизы не превращались в инциденты.

Аргументация на интервью

Связывайте бизнес-требование с конкретной схемой балансировки и объясняйте, какие сбои она должна переживать.

Маршрут запроса

Путь трафика через уровни балансировки

Балансировка работает как стек решений: глобальный вход выбирает регион, локальные балансировщики распределяют запросы, а сервисная сетка уточняет внутренний маршрут.

Глобальный вход

DNS, GSLB или anycast выбирают ближайшую или предпочтительную точку входа.

регион и аварийное переключение

L4 / L7

Транспортный или прикладной балансировщик выбирает пул по протоколу, маршруту и состоянию.

куда отправить запрос

Состояние инстансов

Проверки работоспособности, плавный ввод и вывод соединений защищают от резких провалов.

можно ли давать трафик

Сервисная сетка

Внутри кластера политики маршрутизации, ретраи и mTLS применяются к сервис-сервисному трафику.

внутренний контроль

Главная мысль

Хорошая схема балансировки описывает не только нормальный маршрут, но и поведение при релизе, деградации и переключении на резерв.

Reference

Envoy LB Overview

Подробный обзор политик балансировки, выявления аномальных инстансов и распределения трафика с учётом локальности.

Открыть источник

важна не сама по себе, а как способ удержать пользовательский путь предсказуемым во время деградаций, релизов и переключения на резерв. Распределить запросы между узлами — это только половина задачи. Остальное решается заранее: кто принимает маршрутное решение, как система замечает деградирующий инстанс и что происходит с трафиком, пока инфраструктура под ним меняется. Если эти ответы не зафиксированы, первый же релиз или отказ зависимости превращается в пользовательский инцидент.

Точка принятия решения

Заранее определите, где именно балансировщик должен принимать решение о маршрутизации: на транспортном или прикладном уровне.

Контроль состояния

Сочетайте активные и пассивные сигналы, чтобы вовремя выводить из ротации деградирующие инстансы.

Безопасный выпуск

Плавный ввод в трафик и плавный вывод соединений должны быть частью каждого релиза, а не только аварийного сценария.

Глобальная маршрутизация

Разделяйте выбор региона и балансировку внутри него: это два разных уровня архитектурного решения.

Практический план в 4 шага

Определите уровень балансировки

Шаг 1

Для каждого входного потока решите, нужен ли прикладной контроль маршрутизации на L7 или важнее минимальная цена обработки на L4.

Опишите контракт состояния

Шаг 2

Задайте активные проверки, пассивные сигналы и критерии вывода инстанса из ротации, чтобы ловить деградацию до массовых 5xx.

Подготовьте безопасный выпуск

Шаг 3

Используйте плавный ввод в трафик, проверки готовности и плавный вывод соединений, чтобы релизы не ломали долгоживущий трафик.

Разведите глобальную и локальную балансировку

Шаг 4

Глобальная балансировка между регионами (GSLB) и эникаст (anycast) выбирают регион, а локальный балансировщик или сервисная сетка управляет трафиком уже внутри него.

L4 и L7: как выбрать уровень балансировки

Про что это: про выбор уровня, на котором принимается решение о маршрутизации: на транспортном уровне (L4) или на прикладном (L7).

Почему начинаем отсюда: это базовое архитектурное решение для всей остальной главы. Выберешь уровень — и вместе с ним зафиксируешь доступные правила маршрутизации, цену обработки каждого запроса, видимость трафика и устойчивость всей схемы. Переиграть это позже дорого: меняется не настройка, а точка, где вообще принимается решение.

Для каких сценариев подходит: L4 чаще для сервисов с сохранением состояния вроде БД, кэша или брокера, а L7 — для API на прикладном уровне и продуктовых сценариев, где нужно тонкое управление политиками маршрутизации.

Критерий	L4	L7
Уровень модели	L4: маршрутизация по IP и порту без анализа содержимого прикладного запроса.	L7: маршрутизация по пути, хосту, заголовкам и cookie-файлам.
Гибкость роутинга	Ниже: обычно простые алгоритмы вроде хеширования по ключу, наименьшего числа соединений и циклического распределения без правил по содержимому запроса.	Выше: канареечные запуски, A/B-сценарии, липкие сессии и маршрутизация по правилам приложения.
Производительность	Ниже накладные расходы по CPU и задержке, хорошо подходит для транспортной нагрузки с высокой пропускной способностью.	На каждый запрос приходится больше логики, зато контроль трафика становится точнее.
Типовые сценарии	Базы данных, Redis, MQTT, бинарные протоколы и сценарии, где критична минимальная задержка.	Шлюзы API, веб-приложения, gRPC и прикладные правила маршрутизации.

Пример L4 для HAProxy

Подходит для PostgreSQL, Redis и других сервисов с сохранением состояния, где не нужны правила на уровне прикладного запроса.

frontend ft_postgres
  bind *:5432
  mode tcp
  default_backend bk_postgres

backend bk_postgres
  mode tcp
  balance leastconn
  option tcp-check
  default-server inter 2s fall 3 rise 2
  server pg-1 10.0.1.11:5432 check
  server pg-2 10.0.1.12:5432 check

Пример L7 для Nginx

Нужен там, где маршрут зависит от пути, заголовков и продуктовых правил — шлюзы API и решения на уровне отдельного запроса.

upstream api_pool {
  least_conn;
  server 10.0.2.11:8080 max_fails=3 fail_timeout=10s;
  server 10.0.2.12:8080 max_fails=3 fail_timeout=10s;
}

server {
  listen 80;

  location /api/ {
    proxy_pass http://api_pool;
    proxy_set_header X-Request-Id $request_id;
  }

  location /static/ {
    proxy_pass http://static-service:8080;
  }
}

Проверки состояния и безопасный вывод инстансов

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

Зачем это нужно: даже идеальный алгоритм не спасёт, если трафик продолжает идти на деградировавшие или ещё не прогретые инстансы. Здесь сходятся , , , , , а также сценарии и .

Для каких сценариев подходит: кластеры с в ,, и долгоживущие соединения вроде или gRPC-stream, где резкий обрыв особенно болезнен.

Активные проверки состояния

Балансировщик сам опрашивает эндпоинт состояния или проверяет транспортное рукопожатие. Можно настроить интервал, тайм-аут, пороги восстановления и заранее исключать деградирующие инстансы.

Пассивные проверки состояния

Решение о деградации принимается по живому трафику: 5xx, тайм-аутам, разрывам соединений и росту задержки. Это помогает увидеть проблему, когда эндпоинт формально жив, но сервис уже не справляется с нагрузкой.

Плавный ввод инстанса в трафик

Новый инстанс сначала получает небольшую долю запросов. Это снижает риск холодного старта и даёт прогреть кэши, рантайм и пул соединений до полной нагрузки.

Плавный вывод соединений

При выводе инстанса из пула мы перестаём направлять на него новые соединения, но даём завершиться уже активным. Это снижает клиентские ошибки во время релизов и переключения на резерв.

HAProxy: плавный ввод и политика проверки состояния

backend app
  balance leastconn
  option httpchk GET /healthz
  http-check expect status 200
  default-server inter 2s fall 3 rise 2 slowstart 30s
  server app-1 10.0.3.11:8080 check
  server app-2 10.0.3.12:8080 check

Контейнерная платформа: пробы готовности и аккуратное завершение

spec:
  terminationGracePeriodSeconds: 40
  containers:
    - name: app
      readinessProbe:
        httpGet:
          path: /readyz
          port: 8080
      lifecycle:
        preStop:
          exec:
            command: ["/bin/sh", "-c", "sleep 20"]

Глобальная балансировка между регионами (GSLB)

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

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

Для каких сценариев подходит: продукты в нескольких регионах, глобальный клиентский трафик, региональные ограничения и активная схема .

Глобальная балансировка между регионами (GSLB): система доменных имен (DNS)

Авторитативная система доменных имен (DNS) выбирает регион по задержке, географии, весам и состоянию площадок, а затем возвращает ближайшую или предпочтительную точку входа.

Плюсы: Простая интеграция и хороший базовый вариант для поэтапного развития схемы с несколькими регионами.

Ограничения: Скорость реакции ограничена параметром: время жизни (TTL) записи, а также кэшами у клиентов и резолверов, поэтому переключение не всегда происходит мгновенно.

Когда использовать: Веб- и API-трафик, для которого допустимо переключение в пределах секунд или десятков секунд.

Anycast

Один и тот же IP объявляется из нескольких точек присутствия и регионов, а маршрутизация направляет трафик в топологически ближайшую точку.

Плюсы: Быстрое глобальное распределение трафика и высокая устойчивость внешнего контура.

Ограничения: На уровне ответа системы доменных имен здесь меньше L7-контроля; нужна зрелая сеть, хорошая наблюдаемость и аккуратная работа с колебаниями маршрутов.

Когда использовать: Пограничный уровень, L4-вход и глобальные API, где особенно важна минимальная задержка.

Сервисная сетка (service mesh) в кластере

Про что это: в балансировка переносится на уровень сервис-сервисного трафика, где каждый внутренний становится отдельным решением о маршрутизации.

Как этот блок связан с предыдущими: после L4/L7, контроля состояния и глобальной балансировки логично показать, как те же принципы масштабируются внутрь кластера через прокси рядом с сервисом, и .

Для каких сценариев подходит: десятки/сотни сервисов, единые правила маршрутизации, канареечные выкатывания и дробление трафика, и необходимость централизованно применять .

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

Istio DestinationRule

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: payments
spec:
  host: payments.default.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 5s
      baseEjectionTime: 30s

Istio locality failover

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: checkout-locality
spec:
  host: checkout.default.svc.cluster.local
  trafficPolicy:
    localityLbSetting:
      enabled: true
      failover:
        - from: us-east1
          to: us-central1

Частые ошибки

Выбирать циклическое распределение (round robin) без проверки профиля трафика, 99-го перцентиля и длительности соединений.
Считать пробы готовности и живости контейнерной платформы полноценной заменой пассивным проверкам состояния на L7.
Ставить долгое время жизни записи и при этом ожидать быстрого переключения между регионами во время инцидента.
Игнорировать плавный вывод соединений при релизе и получать всплеск 5xx из-за обрыва долгоживущих запросов.

Источники

Связанные главы

Принципы проектирования масштабируемых систем - даёт базовый контекст про компромиссы масштабирования, на который опираются решения по балансировке.
Алгоритмы балансировки - детально сравнивает циклическое распределение, выбор узла с наименьшим числом соединений и согласованное хеширование для разных профилей нагрузки.
Обнаружение сервисов (service discovery) - объясняет, как поддерживать актуальный список живых инстансов, без которого балансировщик быстро теряет точность.
Сервисная сетка (service mesh) - показывает, как L7-балансировка, повторные попытки и выявление аномальных инстансов работают внутри сервисной сетки.
Multi-region / Global Systems - углубляет глобальную маршрутизацию и переключение между регионами, дополняя часть про выбор площадки.
DNS - объясняет ограничения маршрутизации через систему доменных имен: время жизни записи, кэши резолверов и задержку переключения между регионами.
Kubernetes Fundamentals - даёт операционный контекст для проверок готовности, хуков жизненного цикла и безопасного смещения трафика во время релизов.
API Gateway - показывает прикладной L7-сценарий, где правила маршрутизации становятся частью продуктовой архитектуры.