С какими HTTP клиентами для межсервисного взаимодействия вы работали

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

Слушают не марки клиентов, а то, как вы настраиваете вызов соседнего сервиса: таймауты, пул, повторы, обработку не-2xx. Вопрос из области надёжности: большинство инцидентов в микросервисах начинается с клиента, который ждёт ответа бесконечно.

Как отвечать

Сначала обзор, коротко и с датировкой по версиям, в которых уверены.

• java.net.http.HttpClient из JDK, доступен начиная с Java 11, поддерживает HTTP/2, не тянет зависимостей.
• Apache HttpClient, гибкий и подробно настраиваемый, исторически стандарт для сложных сценариев.
• OkHttp, быстрый, с пулом соединений, HTTP/2 и перехватчиками.
• В Spring: RestTemplate в режиме поддержки, для новых сервисов не берут; WebClient реактивный, но применим и синхронно; RestClient синхронный и удобный, появился в Spring Framework 6.1.
• Декларативные клиенты: интерфейс с @HttpExchange или OpenFeign, когда важна читаемость контракта.

Дальше главное. Расскажите про настройки, по которым видно опыт: раздельные таймауты на соединение и чтение, пул соединений и его лимиты (у Apache значения по умолчанию очень скромные, на маршрут их почти всегда поднимают), повторы только для идемпотентных методов с ростом паузы и разбросом, предохранитель на падающего соседа, проброс идентификатора трассировки, единый разбор ошибочных ответов и ограничение размера тела.

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

Не ставят таймауты. Без них поток занят, пока сосед думает; пул исчерпывается, и падение одного сервиса становится падением цепочки. Это самая частая причина каскадного отказа.

Повторяют любой запрос при ошибке, включая создание сущности. Повтор без ключа идемпотентности рождает дубли, а повтор во время чужой деградации добивает соседа штормом запросов.

Создают клиент на каждый вызов. Новый пул и новое TLS-рукопожатие на запрос дороже самого запроса, клиент должен быть один и переиспользуемый.