В комментариях к посту про API Gateway мне предложили рассказать про Load Balancer.
Load Balancer (балансировщик нагрузки, LB) — это компонент, который нужен в случае горизонтального масштабирования. Когда у нас поднято несколько копий одного сервиса, возникает вопрос как распределять запросы между ними. Этот вопрос и решает балансировщик.
Например, распродажа в интернет-магазине, пользователи активно оформляют заказы, и мы подняли несколько экземпляров orders-service.
LB поможет:
✅ равномерно распределить трафик, чтобы избежать перегрузки отдельных серверов
✅ повысить производительность (направит трафик на инстансы с меньшей нагрузкой, чтобы запросы обрабатывались быстрее)
✅ повысить отказоустойчивость (если один из серверов вышел из строя, перераспределит нагрузку на остальные, чтобы пользователи не заметили сбоя)
✅ обеспечить масштабируемость (можно добавлять новые копии под возросшую нагрузку)
LB периодически опрашивает сервера, и если какой-то упал, перестаёт туда отправлять трафик (health checks).
Примеры балансировщиков: Nginx, HAProxy, Envoy Proxy.
Алгоритмы распределения трафика
Как балансировщик выбирает, на какой сервер отправить запрос
⭐️ Статические алгоритмы
LB не смотрит, какая нагрузка прямо сейчас на каждом сервере, просто следует заранее заданным правилам.
▶️Round Robin
Распределяем просто по очереди:
1-й запрос → server1
2-й запрос → server2
3-й запрос → server3
4-й → опять server1 и т.д.
Подходит для равномерной нагрузки при одинаковых серверах.
▶️Weighted Round Robin
Например,
server1 — вес 5
server2 — вес 3
server3 — вес 2
Тогда server1 получит 50% трафика, server2 — 30%, server3 — 20%.
Подходит для равномерной нагрузки при разных по мощности серверах.
▶️IP Hash
По IP пользователя считаем хеш и всегда направляем на один и тот же сервер.
Это простая реализация sticky session.
Sticky sessions, то есть прикрепление пользователя к конкретному экземпляру сервера, можно сделать и c другими алгоритмами через куки.
⭐️ Динамические алгоритмы
LB следит за актуальной нагрузкой на сервера и принимает решения на основе этой информации.
▶️Least Connections
Отправляем туда, где сейчас меньше всего активных соединений.
Подходит для сервисов с долгими соединениями (например, WebSocket, большие выгрузки).
▶️Weighted Least Connections
Учитывается и вес сервера и количество активных соединений.
Подходит при неравномерной нагрузке и разной производительности серверов.
▶️Least Response Time
Отправляем туда, где сервер отвечает быстрее всего (на основе измерений response time).
Подходит, когда важна минимальная задержка.
Динамические алгоритмы стоят дороже по ресурсам (нужно следить, измерять, хранить данные).
Нам всем приходилось брать на себя роль LB при выборе кассы в супермаркете 😂
Кто-то выберет самую короткую очередь, кто-то самую быстро движущуюся, а кто-то просто ближайшую.
С точки зрения модели OSI балансировка обычно делается либо на L4 (транспортный уровень, работа с протоколами TCP/UDP), либо на L7 (уровень приложения, протоколы HTTP, HTTPS, gRPC и др.)
Как LB сочетается с API Gateway
1️⃣Запрос от клиента поступает на API Gateway.
2️⃣API Gateway решает, к какому из бэкенд-сервисов направить запрос,
например:
/users → users-service
/orders → orders-service
3️⃣За API Gateway для каждого сервиса стоит LB (или встроенный механизм балансировки kubernetes) который равномерно распределяет запросы между копиями конкретного сервиса.
4️⃣Внутренние взаимодействия (например, orders-service → users-service) тоже идут через LB или Service Mesh.
📌 Если у нас нагруженное приложение и поднято несколько экземпляров API Gateway, то перед ними будет свой LB.
Балансировщики используются не только для API, но и для баз данных (HAProxy, Pgpool-II для PostgreSQL).
😼 Когда на собесе стоит добавлять на схему LB?
Если на бэке предполагается горизонтальное масштабирование сервиса (это часто так для нагруженных систем), то можно озвучить интервьюеру, что нужен LB и уточнить, достаточно ли будет указать его в одном квадратике с API Gateway. Часто оказывается, что достаточно.
#сисдиз