Как работает балансировщик нагрузки и какие типы используются

Что проверяют

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

Как отвечать

• L4 распределяет TCP и UDP соединения: внутрь не смотрит, дёшев, подходит любому протоколу, но не маршрутизирует по пути и не видит отдельные запросы внутри keep-alive соединения.
• L7 разбирает HTTP: маршрут по хосту и пути, терминация TLS, ретраи, лимиты. Для HTTP/2 и gRPC это принципиально: одно соединение несёт множество стримов, и L4-балансировщик прибьёт весь трафик к одному бэкенду, пока соединение живо.
• Алгоритмы: round robin и взвешенный вариант, least connections (в gRPC least request), выбор по наименьшей задержке, power of two choices как дешёвый компромисс, consistent hashing ради локальности кэша при смене состава пула.
• Проверки здоровья: активные пробы плюс пассивное выведение узла по ошибкам живого трафика; readiness отделяют от liveness, иначе трафик польётся в непрогретый процесс.
• Клиентская балансировка: gRPC-Go держит соединения ко всем адресам от resolver и сам раздаёт запросы политикой round_robin, лишний сетевой хоп исчезает.
• Простой обратный прокси собирается на стандартной библиотеке:

proxy := &httputil.ReverseProxy{
    Rewrite: func(r *httputil.ProxyRequest) {
        r.SetURL(pool.Next()) // выбор бэкенда по алгоритму
        r.SetXForwarded()
    },
}

• Сам балансировщик дублируют: пара узлов с общим VIP через VRRP или anycast. DNS-раздача живёт на TTL и кешах резолверов, аварийное переключение через неё медленное.

Где спотыкаются

Не видят проблемы gRPC за L4-балансировщиком: соединение долгоживущее, распределение по узлам замирает после первого подключения.

Обещают, что балансировщик сам обеспечит отказоустойчивость, и не упоминают ни health checks, ни graceful shutdown с дренажем соединений.

Путают липкость по IP-хешу с сессией: за NAT это целый офис на один адрес, а при изменении пула раскладка ключей едет.