Как стать автором
Обновить

Комментарии 15

Как я понимаю проблема эта может всплыть только когда нужны постоянные соединения. То есть, либо кип элайв, либо http/2 как у вас.

Конкретно в данном случае использовался HTTP/1.1 с Keep-Alive.

В HTTP/2, насколько я знаю, проблема не стоит так остро, поскольку там используется мультиплексирование соединений. Однако чтобы использовать HTTP/2, нужно заморочиться с настройкой TLS. Полагаю, именно по этой причине в моей ситуации использовался HTTP/1.1
Сколько хочу попробовать кип элайв или http/2 во внутренних коммуникациях между сервисами, но у нас балансировка на уровне DNS. У вас нет такой проблемы автоскелинга и балансировки запросов?

Писать балансировку на клиенте не хочется, а ставить лоад балансер чтобы он держал конекшены и балансил все девопс пока не хочет…
Можно поставить sidecar в качестве балансировщика, это прям один из юзкейзов для того же envoy
Спасиб. Ща глянул, он вроде как даже умеет с консулом дружить, где у нас регистрируются сервисы. Надо будет поиграться. Retries, rate limit, circuit breaker. Вкусная штука. Будем обсуждать с девопсами =)
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Прошу извинить за недоразумение. Диаграммы были отрисованы в сервисе WebSequenceDiagrams и стиль «рисования от руки» был выбран намеренно.

Я посчитал, это позволит воспринять статью в более легком стиле.

Буду иметь в виду, что могут быть подобные проблемы при восприятии диаграммы.
НЛО прилетело и опубликовало эту надпись здесь
Насколько я знаю fasthttp от valyala должен решить ваши проблемы описанные в статье, плюс еще много улучшений которые не описаны, рассматривали fasthttp?
К сожалению, не приходилось использовать эту библиотеку.

Насколько я вижу, в ней есть похожая настройка, однако параметр по умолчанию уже совершенно другой:
const DefaultMaxConnsPerHost = 512


Поэтому, как вы верно заметили, описанная в статье проблема невозможна в случае использования FastHTTP.
HTTP-стек из стандартной библиотеки Golang не рассчитан на полноценное использование в продакшен-средах, а тем более для highload-сервисов. Кажется, как минимум миграция на fasthttp поможет улучшить все показатели взаимодействия микросервисов :)
Да, действительно. Я уже выше отметил, что переход на fasthttp решил бы проблему в том плане, что там более удачные настройки пула соединений по умолчанию.

Правда, я не очень понимаю, почему стандартная библиотека не рассчитана на полноценное использование в продакшне. Увы, я не смог найти мнения о том, что net/http вообще не стоит использовать. Буду рад, если подскажете, почему так не стоит делать)
Всё нормально если использовать стандартную net/http, только на highload сервисах надо будет тюнить

Да не очень то и нормально. У дефолтного клиента таймаут бесконечный. Может быть сюрпризом.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.