Load balancer и прокси

Последние три урока надели на stringsvc обёртки: спаны из 08-tracing, лимитер из 09-rate-limit, предохранитель из 10-circuit-breaker. Все они защищали один процесс. Но смысл микросервисов — в горизонтальном масштабировании: endpoint Uppercase поднимается в N копиях, и запросы надо размазывать по копиям так, чтобы ни одна не задыхалась, а упавшая молча исключалась из ротации. Кто это делает? Если перед сервисами стоит внешний балансировщик — это server-side discovery, и твой Go-код о нём не знает. А если копии ищут друг друга сами — client-side discovery: вызывающий сервис держит список адресов соседей, выбирает один на каждый вызов и повторяет попытку при сбое. go-kit реализует именно вторую схему, потому что она не требует инфраструктуры за пределами процессов и остаётся в твоих руках. Ключевая идея уже звучала в уроке 02-endpoint: исходящий вызов — это тоже endpoint, та же сигнатура func(ctx, request) (response, err). Урок 04 показал клиентский транспорт мельком, а теперь обещание выполняется целиком: под каждым из N инстансов прячется endpoint, построенный клиентским транспортом, а сверху стоят те же обёртки, к которым ты привык, — breaker из урока 10, лимитер из 09, спаны из 08. Сверху над всем этим — load balancer: стратегия выбора и ретраи. Соберём снизу вверх.

Прежде чем выбирать между инстансами, нужен endpoint на каждый инстанс. Роль играет клиентский HTTP-транспорт из урока 04 — там ты видел kithttp.NewServer, а зеркальный kithttp.NewClient ещё не встречали. Он принимает HTTP-метод, адрес, EncodeRequestFunc и DecodeResponseFunc — и возвращает объект с методом Endpoint(): замыкание, которое кодирует request-структуру в HTTP-запрос, отправляет его по адресу и декодирует ответ обратно в response-структуру. EncodeRequestFunc — func(ctx, http.Request, request interface{}) error: она пишет тело и заголовки в исходящий запрос; DecodeResponseFunc — func(ctx, http.Response) (interface{}, error): читает ответ соседа. Для stringsvc это те же JSON-структуры, что и на серверной стороне: encodeRequest сериализует uppercaseRequest в буфер и подставляет в r.Body, decodeUppercaseResponse разбирает uppercaseResponse. Адрес соседа arrive строкой-инстансом вроде localhost:8081 — приведём её к *url.URL: если нет префикса http, допишем, а путь зададим /uppercase. Получившуюся функцию и называют прокси-endpoint: для вызывающей стороны она неотличима от локального endpoint'а — та же сигнатура, те же структуры, только исполнение происходит в другом процессе. Именно поэтому все обёртки курса работают и здесь: оберни прокси-endpoint в instrumentingMiddleware из урока 07, и латентность сетевого вызова попадёт в ту же гистограмму, только с меткой method=uppercase_proxy.

Над набором endpoint'ов стоит балансировщик. Открой sd/lb/balancer.go — там двадцать строк, и контракт в них умещается в один метод: lb.Balancer — это интерфейс Endpoint() (endpoint.Endpoint, error), «дай мне один endpoint для следующего вызова». Никаких Select, Pick, стратегий в аргументах: стратегия — это конкретная реализация интерфейса, а не флаг. Вторая половина контракта — ошибка lb.ErrNoEndpoints: если под балансировщиком пусто, он не выбирает случайный индекс через панику и не возвращает nil молча, а возвращает ErrNoEndpoints. Это важно для всего, что стоит выше: ретраи решают, пробовать ли снова, метрики считают сбой, breaker'ы размыкаются — все они читают ошибку из одного честного канала. Слой под балансировщиком — sd.Endpointer: интерфейс Endpoints() ([]endpoint.Endpoint, error), поставщик актуального набора. Разделение обязанностей точное: Endpointer знает, КАКИЕ endpoint'ы сейчас живы, Balancer знает, КАКОЙ из них выбрать для следующего вызова, а Retry знает, ЧТО делать при ошибке. Три маленьких интерфейса вместо одного большого — тот же ход, что и во всём go-kit, и в этом смысле go kit load balancer — не монолитная библиотека, а три строчки контрактов и несколько готовых реализаций рядом.

Кроме round robin в пакете есть lb.NewRandom(s sd.Endpointer, seed int64) — та же пара «Endpointer + ошибка», но индекс выбирается rand.Intn по переданному источнику случайности. Что выбрать? Round robin даёт идеально равномерное распределение на длинном горизонте и предсказуемость: N запросов — по одному на каждый инстанс, разница между самыми нагруженными не больше одного запроса. Он же даёт воспроизводимость в тестах: при известном порядке вызовов ты знаешь, какой инстанс получит запрос. Random проще в объяснении, устойчив к «резонансу» — ситуации, когда два сервиса со синхронизированными round-robin-счётчиками бьют в один и тот же инстанс одновременно, — и позволяет изолировать тесты: одинаковый seed даёт одинаковую последовательность выборов без реальной сети. На практике для service-to-service вызовов дефолт — round robin: равномерность важнее, а резонанс лечится тем, что у каждого клиента свой счётчик и своя фаза. Random берут, когда список endpoint'ов дёргается часто: при постоянных добавлениях и удалениях равномерность round robin всё равно размывается, а random не даёт ложного чувства порядка. Важно понимать общий знаменатель: обе стратегии — client-side, состояние (счётчик или rand) живёт в твоём процессе, никакой координации между экземплярами вызывающего сервиса нет. Балансировка go kit — это выбор, который делается локально за микросекунды, а не сетевой прыжок к балансировщику.

В main прокси встаёт раньше всех остальных service middleware: svc = proxyingMiddleware(*proxy, logger)(svc), затем loggingMiddleware, затем instrumentingMiddleware — ровно как в stringsvc3. Почему именно так: лог из урока 06 и метрики из урока 07 должны видеть НАСТОЯЩИЙ исход вызова. Если прокси стоит первым, то loggingMiddleware пишет took с учётом сетевой задержки к соседу, а счётчик request_count с меткой error=true загорается, когда сосед отказал, — и дежурный видит правду о том, что тормозит весь вызов. Переставь прокси внутрь — и наблюдаемость станет врать: локальный вызов «успешен», потому что прокси успел положить задачу в сеть. Второе решение — где обёртки из уроков 08-10: они цепляются к КАЖДОМУ прокси-endpoint до добавления в список, а не поверх retry. Разница существенная: breaker на отдельном endpoint размыкается для одного больного соседа, а не для всего набора; лимитер на endpoint считает попытки конкретного инстанса; спан client-ноги пишется на каждый реальный сетевой вызов. Третье — контекст: ctx запроса проходит через proxymw в endpoint'ы соседей, поэтому дедлайн из урока 04, request_id из урока 06 и trace id из урока 08 доезжают до конечного исполнителя — вся цепочка наблюдаемости остаётся сквозной, и Jaeger соберёт два сервиса в одно дерево.

Механизм ретраев обманчиво прост, и в нём три ловушки. Первая — идемпотентность: retry повторяет запрос при ошибке, а значит вызов может выполниться дважды. Uppercase — чистая функция, повторять безопасно; списание денег или отправка письма — нет. Правило то же, что и в 10-circuit-breaker: ретраи только на идемпотентных операциях или на операциях с idempotency-key. Вторая ловушка — «потерянные» попытки: когда первая попытка вернула ошибку и запустилась вторая, первая горутина никуда не девается; если её ответ всё-таки придёт, select в lb.Retry уже закрыт — результат выбросится, но ресурсы соседа будут потрачены. Отсюда бюджет: maxTime меньше клиентского дедлайна, а попыток мало — три, не тридцать. Третья ловушка — ретрай-лавина: сосед моргнул, все клиенты разом сделали по три попытки, нагрузка утроилась в худший момент. Лечение многослойное: breaker из урока 10 на каждом прокси-endpoint размыкает больных, лимитер из урока 09 держит темп исходящих вызовов, а сам lb.Retry стоит последним — и его ошибка RetryError уезжает в трейс: в уроке 08 ты видел, как TraceEndpoint пишет каждую попытку отдельным полем gokit.retry.error.N, так что «три попытки к двум инстансам» видно в Jaeger без догадок. Вот почему порядок «breaker и лимитер на endpoint, retry сверху» — не вкус, а инженерное решение.

Обещание урока 02-endpoint выполнено: исходящий вызов стал endpoint'ом по всем правилам курса — клиентский транспорт из урока 04-http-transport построил ноги, а сверху стоят знакомые обёртки: спаны из 08-tracing, лимитер из 09-rate-limit, breaker из 10-circuit-breaker. Балансировка go kit собралась из трёх маленьких интерфейсов: Endpointer поставляет, Balancer выбирает, Retry повторяет, — и весь этот каркас уже работает, пока список инстансов задаётся флагом. Но флаг — это руками: при деплое, автоскейлинге и падении соседа кто-то должен обновить список, пока retry долбит в мёртвый адрес. Дальше — урок 12-discovery: Registrar, Instancer и Factory, адаптеры Consul и etcd, health checks, которые вычёркивают больных автоматически. Карта курса — на странице курса.