Сообщить об ошибкеКороткий ответ
L4-балансировка работает на транспортном уровне, распределяя трафик по IP-адресу и порту назначения без анализа содержимого запроса (быстрее, протокол-агностична), L7-балансировка работает на прикладном уровне (чаще HTTP/HTTPS), анализируя содержимое запроса (путь, заголовки, cookies) для более гибкой маршрутизации; health checks в обоих случаях нужны, чтобы исключать из пула нездоровые backend-серверы и не отправлять им трафик.
Как это работает подробнее
L4-балансировщик принимает решение о распределении на основе заголовков транспортного/сетевого уровня (например, IP:порт, иногда с учётом хэша для consistent hashing), не завершая и не разбирая прикладной протокол, что даёт низкую задержку и возможность работать с любым TCP/UDP-трафиком; L7-балансировщик терминирует соединение, разбирает HTTP-запрос и может принимать решения вроде маршрутизации по пути URL, добавления заголовков, терминации TLS, что требует больше вычислительных ресурсов, но даёт гораздо более гибкую логику.
Пример кода
L4: балансировка по IP:порт, health check = TCP connect на порт 8080
L7: балансировка по URL/заголовкам, health check = GET /healthz -> 200 OK
и проверка, что ответ действительно означает "приложение готово"Что использовать на практике
- Практика. health checks бывают пассивными (наблюдение за реальными ошибками/тайм-аутами живого трафика) и активными (периодические отдельные запросы к endpoint вроде /healthz); для L7 health check может реально проверять логику приложения (например, доступность базы данных), тогда как для L4 обычно проверяется просто открытость TCP-порта, что менее информативно о реальном состоянии сервиса.
Подводные камни
- Риск. Частая ошибка — настроить health check, который проверяет только то, что процесс слушает порт (L4-подобная проверка), хотя приложение уже не может обслуживать запросы из-за недоступности зависимости (например, базы данных), из-за чего балансировщик продолжает слать трафик на нерабочий backend.