Вопрос проверяет понимание того, как распределяется трафик между несколькими экземплярами сервиса и зачем нужен балансировщик при горизонтальном масштабировании.
Балансировщик нагрузки принимает входящие запросы и распределяет их между несколькими экземплярами backend-сервиса. Это позволяет масштабировать систему горизонтально, добавляя новые серверы без изменения клиента. Балансировщик также может проверять состояние серверов и исключать недоступные. Часто он работает как reverse proxy перед приложением.
Балансировщик нагрузки — ключевой компонент масштабируемой архитектуры, потому что клиент не должен знать, сколько экземпляров сервиса работает.
Определение: Балансировщик нагрузки (Load Balancer) — сервис, который принимает входящие запросы и распределяет их между несколькими backend-узлами.
Типичный поток выглядит так:
Клиент отправляет запрос на один адрес.
Запрос приходит в балансировщик.
Балансировщик выбирает backend-сервер.
Ответ возвращается клиенту через балансировщик.
Это позволяет:
добавлять новые backend-узлы,
удалять узлы,
обновлять сервис без остановки системы.
На практике используются:
Round Robin
запросы распределяются по очереди.
Least Connections
выбирается сервер с наименьшим числом активных соединений.
Hash (IP или ключ)
используется, когда нужна “липкость” сессий.
Балансировщик регулярно:
делает HTTP-запросы к backend,
проверяет статус,
исключает недоступные узлы.
Это предотвращает отправку трафика на упавшие сервисы.
Наиболее частые варианты:
Nginx
HAProxy
Kubernetes Service / Ingress
Cloud Load Balancers
Пример конфигурации (упрощенно):
upstream backend {
server 127.0.0.1:8001;
server 127.0.0.1:8002;
}
server {
location / {
proxy_pass http://backend;
}
}
Балансировщик — это точка входа, которая делает возможным горизонтальное масштабирование, отказоустойчивость и обновления без простоя.