Load balancing

Клиентская балансировка grpc-вызовов начинается не с алгоритма «распределить по бэкендам», а с разбора строки цели. grpc.NewClient из пятого урока принимает target — URI со схемой резолвера; пакет resolver держит реестр «схема → Builder» (resolver.Register заполняет его в init(), resolver.Get ищет по имени), а Target — это структура с единственным полем URL url.URL, разобранным по RFC 3986. Док-комментарий Target обещает поведение на всякий случай: если схемы нет или она не зарегистрирована, клиент подставит схему по умолчанию и перепарсит цель заново. Дальше резолвер отдаёт resolver.State — и это не «список строк»: там лежат Addresses и Endpoints, а также ServiceConfig; документация service_config формулирует контракт целиком: name resolver, когда его просят разрешить имя сервера, «will return both the resolved addresses and the service config». Третий этаж — балансер: «Package balancer defines APIs for load balancing in gRPC». Builder.Build получает ClientConn-фасад и создаёт SubConn'ы: «A SubConn represents a single connection to a gRPC backend service» — внутри это HTTP/2-соединение, на котором мультиплексируются все вызовы. Важная деталь из док-комментария SubConn: «All SubConns start in IDLE, and will not try to connect. To trigger a connection attempt, Balancers must call Connect» — соединяться балансер заставляет сам. Четвёртый этаж — пикер: «Picker is used by gRPC to pick a SubConn to send an RPC», и вызывается он на каждый RPC. Балансер собирает новый пикер из текущего снимка состояния и отдаёт каналу через UpdateState(State{ConnectivityState, Picker}). Итого: канал — диспетчер, резолвер — источник данных, балансер — стратегия, пикер — мгновенное решение на конкретный вызов. Ниже пройдём по этажам с исходниками в руках.

В service config живёт пара полей, и разница между ними — источник тихих сюрпризов. Устаревшая форма — строка: «loadBalancingPolicy»: «round_robin»; каноническая — массив: «loadBalancingConfig»: [{ «round_robin»: {} }]. Механика разбора в service_config.go: если массива нет, берётся имя из строкового поля, а если и его нет — name := pickfirst.Name, то есть дефолтная политика называется pick_first. Дальше самое интересное: «if balancer.Get(name) == nil { name = pickfirst.Name }» — незнакомое имя в строковом поле НЕ роняет конфиг: канал молча подставит pick_first и поедет дальше. Вы написали «round_robn» с опечаткой? Ошибки не будет — просто балансировка не включится, и искать это придётся по поведению, а не по логам. С массивом правила другие: gracefulswitch.ParseConfig проходит по списку объектов, требует, чтобы в каждом был ровно один ключ («expected a JSON struct with one entry»), и для незнакомых имён говорит «Skip unregistered balancer names» — пропустить и смотреть следующего. Массив [{ «fancy_lb»: {} }, { «round_robin»: {} }] возьмёт round_robin: первый кандидат не зарегистрирован, второй — да. Но если НЕ зарегистрирован никто, разбор падает уже с ошибкой: «no supported policies found in config». Сам реестр политик — тот же паттерн, что у резолверов: balancer.Register в init(), и док-комментарий предупреждает: «If multiple Balancers are registered with the same name, the one registered last will take effect» — последний побеждает. В базовой поставке grpc зарегистрированы ровно две политики: pick_first и round_robin — второй импортируется в clientconn.go с честным комментарием «// To register roundrobin». Остальные — least_request_experimental, ring_hash_experimental, weighted_target и компания — лежат в репозитории, но регистрируются при импорте своих пакетов и в обычный канал без этого импорта не попадают; большинство из них рассчитано на xDS-инфраструктуру.

Что происходит, когда вы вообще не думали о балансировке? Работает pick_first — политика из balancer/pickfirst с const Name = «pick_first». Её стратегия — не распределение нагрузки, а живучесть: соединение устанавливается с первым доступным адресом и используется для всех вызовов. Правило порядка адресов сформулировано в док-комментарии SubConn: «gRPC will try to connect to the addresses in sequence, and stop trying the remainder once the first connection is successful» — адреса пробуются по очереди, и на первом успешном попытки прекращаются. Под этим комментарием стоит приписка «However, this behavior is deprecated. SubConns should only use a single address» — в современной модели каждый адрес получает собственный SubConn, а не один общий со списком; смысл остался тем же: один активный канал связи, остальные адреса — запасные. Детали из исходников pickfirst. Первый проход по списку — «happy eyeballs»: между попытками держится пауза connectionDelayInterval = 250 * time.Millisecond, чтобы не долбить все адреса разом; неудача первого прохода запоминается в connectionFailedInFirstPass. Список можно перемешать конфигом: pfConfig с полем ShuffleAddressList, json-ключ «shuffleAddressList» — полезно, когда резолвер возвращает адреса в одинаковом порядке для всех клиентов и первый адрес собрал бы всю нагрузку. Провал соединения вводит SubConn в TransientFailure с «липким» поведением из gRFC A62 — канал ждёт, пока политика не решит переподключиться. Для ваших вызовов это означает: упал единственный активный бэкенд — канал уходит в TransientFailure, и дальше включается знакомый по пятому уроку расклад: fail fast вернёт Unavailable сразу, WaitForReady(true) — подождёт восстановления. Смысл дефолта честный: одной SubConn хватает подавляющему большинству приложений, а «балансировать» начинают, когда бэкендов становится несколько и нагрузка перестаёт помещаться в одно соединение.

Вторая политика из коробки — round_robin из balancer/roundrobin. Регистрация классическая: const Name = «round_robin» и balancer.Register(builder{}) в init(); док-комментарий пакета объясняет, почему импортировать его руками не нужно: «Roundrobin balancer is installed as one of the default balancers in gRPC, users don't need to explicitly install this balancer». За словом «roundrobin» в исходниках стоит двухэтажная конструкция. Внешний этаж — endpointsharding: пакет, который держит по дочернему балансеру на каждый endpoint из resolver.State. Внутренний этаж — pickfirst-лист на каждый endpoint: dns-резолвер отдаёт адреса без Endpoints, и сработает правило из resolver.go — «If a resolver sets Addresses but does not set Endpoints, one Endpoint will be created for each Address», то есть один адрес = один endpoint = один pickfirst-лист = одно соединение. Итог: round_robin по dns-адресам держит по одному соединению на каждый бэкенд. Само чередование делает пикер endpointsharding — два этажа механики в его исходнике: старт со случайного индекса next: uint32(randIntN(len(pickers))) и шаг на каждый вызов: «nextIndex := atomic.AddUint32(&p.next, 1)», затем «p.pickers[nextIndex%uint32(len(p.pickers))]» — атомарный счётчик и деление по модулю на число готовых детей. Дети делятся по состояниям: если есть хоть один Ready, пикер собирается только из готовых; нет готовых — из Connecting, затем Idle, затем TransientFailure. Два следствия, которые стоит осознать. Первое: распределение идёт по RPC, а не по соединениям — один вызов за другим честно обходят все живые бэкенды, включая HTTP/2-мультиплексирование внутри каждого соединения. Второе: старт со случайного индекса нужен, чтобы десять клиентов не начали с одного и того же первого бэкенда — та же идея, что у shuffleAddressList, только встроенная.

Пикер — самая короткая функция в конвейере и самая важная: док-комментарий Picker требует «Pick should not block» — блокироваться в нём нельзя. Что может вернуть Pick? Три исхода. Первый — SubConn: вызов уезжает на выбранное соединение. Второй — balancer.ErrNoSubConnAvailable, и его док-контракт проговаривает ожидание: «ErrNoSubConnAvailable indicates no SubConn is available for pick(). gRPC will block the RPC until a new picker is available via UpdateState()» — вызов замирает до появления нового пикера; тот же эффект даёт SubConn, который ещё не Ready. Третий — ошибка: статусная ошибка завершает RPC немедленно с этим кодом, прочие ошибки при fail fast дают Unavailable, а с WaitForReady — ожидание; док-комментарий pick в picker_wrapper.go перечисляет случаи, когда вызов блокируется, и заканчивает фразой «pick blocks until the picker gets updated». Теперь то, ради чего стоило читать про пикер в уроке про ретраи. Статусная ошибка из пикера оборачивается в dropError — «dropError is a wrapper error that indicates the LB policy wishes to drop the RPC and not retry it», и getTransport в stream.go ставит попытке флаг a.drop = true. Этот флаг попадает в самую первую ветку shouldRetry, которую пятнадцатый урок цитировал как «… || a.drop { // RPC is finished or committed or was dropped by the picker; cannot retry» — пикер отбросил вызов, ретрая нет. Спека A6 фиксирует правило для обеих пикер-ошибок: если результат пикера DROP — «the RPC will fail immediately, without any retries», если TRANSIENT_FAILURE — «the RPC will be handled by the configured retry policy». Практический источник DROP — gRPCLB, lookaside-балансировщик: его пикер отдаёт статус Unavailable с сообщением «request dropped by grpclb» по drop-токенам из списка серверов. Вывод для дизайна: политика балансировки — единственное место, где вызов может умереть ДО ретрай-механики и умышленно, без второй попытки.

Пятый урок зафиксировал развилку: NewClient использует dns-резолвер по умолчанию, Dial — passthrough, «It sends the target name without scheme back to gRPC as resolved address». Док-комментарий GetDefaultScheme фиксирует дефолт дословно: если SetDefaultScheme не вызывался, «the default scheme used by grpc.NewClient is "dns" instead». Теперь внутрь dns. Регистрация — в init(): resolver.Register(NewBuilder()), Scheme возвращает «dns», а док-комментарий пакета честно зовёт его «to be installed as the default resolver». Порт: const defaultPort = "443" — цель без порта получит 443, а не ваш 50051, поэтому dns:///orders.internal означает orders.internal:443; всегда пишите порт явно. IP-цель обрабатывается без DNS-запроса: formatIP распознаёт литеральный адрес, резолвер сразу отдаёт его в State — и на этом заканчивается: для IP-цели возвращается deadResolver, который ничего не делает, watcher не запускается, переразрешений не бывает. Authority из цели работает: «dns://8.8.8.8/foo.googleapis.com» — часть между вторым и третьим слэшем выбирает DNS-сервер (newNetResolver строит net.Resolver с PreferGo и Dial на выбранную пару host:port; порт самого DNS — defaultDNSSvrPort "53"). Дальше — то, что делает dns-резолвер союзником балансировки: он не «разрешил и забыл», а живёт в горутине watcher и переразрешает имя по подсказкам ResolveNow — канал дёргает их, когда соединения в беде; повторное разрешение ограничено снизу MinResolutionInterval = 30 time.Second — «the minimum interval at which re-resolutions are allowed. This helps to prevent excessive re-resolution», на сам запрос отведено ResolvingTimeout = 30 time.Second, а после неудачи watcher уходит в экспоненциальный бэкофф из backoff.DefaultExponential. И главное для service config: резолвер запрашивает TXT-запись с префиксом txtPrefix = "_grpc_config." и ожидает атрибут «grpc_config=» — «In DNS, service config is encoded in a TXT record via the mechanism described in RFC-1464», схема из gRFC A2. Так конфиг с retryPolicy и loadBalancingConfig доезжает до клиента без единой строки кода; TXT-поиски включены по умолчанию — переменная окружения GRPC_ENABLE_TXT_SERVICE_CONFIG со значением false их отключает, как и WithDisableServiceConfig. Не хотите конфиг из сети — WithDisableServiceConfig: «causes gRPC to ignore any service config provided by the resolver and provides a hint to the resolver to not fetch service configs», причём дефолтный конфиг из WithDefaultServiceConfig продолжит работать.

Интерфейс резолвера намеренно крошечный: Builder с методами Build(target Target, cc ClientConn, opts BuildOptions) и Scheme(), плюс Resolver с ResolveNow и Close. Реализация подписывается на источник правды и пушит resolver.State через cc.UpdateState — ошибка возврата просит повторить позже с бэкоффом, ReportError сообщает о проблеме разрешения. На этом строится discovery-стиль эксплуатации: резолвер опрашивает каталог сервиса — health-чеки Consul, etcd, Kubernetes Endpoints — и превращает список ЗДОРОВЫХ инстансов в Addresses. Клиент при этом ничего не знает о каталоге: для него «dns» и «consul» — просто схемы в target; док-пример NewClient даже показывает чужую схему «zookeeper://zk.example.com:9900/example_service» как легальную форму цели. Полезно посмотреть, что вы получаете бесплатно: Target.URL — обычный url.URL, значит query-параметры цели доступны резолверу (для опций вида consul://catalog?dc=dc1), метод Endpoint() отдаёт путь без ведущего слэша, а String() собирает каноническую строку scheme://host/endpoint. Ровно на этом стыке живёт тизер: в отдельном курсе по go-kit есть урок про discovery, где каталог и health-check'и становятся главным героем — там эта схема разбирается с Consul по-настоящему, от регистрации сервиса до фильтрации нездоровых инстансов; здесь же достаточно понимать: ваш резолвер — это сорок строк Go между каталогом и каналом. Отдельно запомните ограничение из док-комментария manual: каждый экземпляр резолвера работает только с одним каналом — «Every instance of the manual resolver may only ever be used with a single grpc.ClientConn». Забавная кухня напоследок: внутри resolver/map.go endpoint'ы сравниваются как множества, для чего адреса кодируются в base64 — «base64 encoding the address strings restricts the characters present within the strings», чтобы разделитель не требовал экранирования.

Классический вопрос после внедрения round_robin: «а как направлять сессию пользователя всегда на тот же инстанс?» Честный ответ: в gRPC это не бесплатная опция, и вот почему. Первый слой проблемы — сам транспорт: HTTP/2 мультиплексирует все вызовы в одно TCP-соединение, поэтому L4-балансировщик, привыкший в мире HTTP/1 распределять соединения и «липнуть» к ним, здесь видит один длинный поток на клиента — балансировать по соединениям бессмысленно, все вызовы уже внутри. Второй слой — балансировка grpc на клиенте по определению бессессионна: round_robin кладёт соседние вызовы одного пользователя на разные бэкенды атомарным счётчиком, и никакого «пользователь ↔ соединение» не существует. Третий слой — куки не работают: в HTTP-мире sticky реализуют cookie-инъекцией, но куки — механизм веб-приложений; gRPC-прокси читают метаданные и :path, а решать по ним умеют далеко не все балансировщики. Что делать. Первый путь — перестать хотеть: сделать сервис stateless, состояние вынести в общее хранилище; это главная рекомендация, и балансировка по RPC тогда безопасна. Второй путь — консистентное хеширование: одинаковый ключ уезжает на одинаковый бэкенд при живых адресах; в репозитории grpc-go есть ring_hash_experimental (balancer/ringhash), рассчитанный на xDS-конфигурацию, где хеш-ключи задаются политиками hash по заголовкам. Третий путь — свой пикер: кастомная политика, которая читает PickInfo.Ctx, достаёт ключ сессии из метаданных десятого урока и возвращает всегда один и тот же SubConn — API балансера для этого открыт (Builder, ClientConn, Picker), а балансер-обёртки вроде endpointsharding показывают, как строить составные политики. Просто помните цену: sticky возвращает проблему «умёр бэкенд с сессиями» — держите под ней репликацию состояния, иначе отказоустойчивость, которую давал round_robin, исчезнет вместе с привязкой.

Честная оговорка про формат, одна на урок: в самоучителе есть песочница с интерпретатором Go, но сеть в браузере недоступна — поднять резолвер и три бэкенда в браузере нельзя, поэтому runner-ов в этом уроке, как и во всём gRPC-курсе, нет. Всё разобранное проверяется локально за вечер на паре из четвёртого и пятого уроков. Три эксперимента. Первый: поднимите два инстанса сервера на разных портах, включите round_robin через service config и посчитайте в перехватчике из одиннадцатого урока, как распределились вызовы; затем выключите один инстанс и убедитесь, что вызовы перетекли без ошибок клиента. Второй: уберите порт из цели dns:///orders.internal и прочитайте ошибку соединения — там всплывёт 443; верните порт и сравните. Третий: возьмите manual-резолвер из этого урока, опубликуйте список из «мёртвого» первого адреса и живого второго, включите pick_first — по логам соединений увидите happy-eyeballs-проход и выбор второго адреса; затем поменяйте список через UpdateState и понаблюдайте переключение. Дальше по маршруту: семнадцатый урок — health checking protocol: grpc_health_v1, серверные health-сервисы и probes; связь с сегодняшним материалом прямая — балансировщики умеют слушать здоровье бэкендов через health listener (round_robin включает его для своих pickfirst-детей комментарием «Enable the health listener in pickfirst children for client side health checks»), и нездоровый инстанс исчезает из пикера, не дожидаясь обрыва соединения. Перед ним перечитайте урок про ретраи — DROP-ветку shouldRetry вы теперь видели с обеих сторон, и урок про клиент — target-синтаксис и состояния канала. Полный маршрут курса — на странице gRPC-Go.