Обратное давление на уровне запросов для Spring Reactive Webclient?

Question

Это похоже на Как сделать противодавление уровня запроса akka-http? , но для системы эхо-поиска Spring.

Я думаю о том, как реализовать обратное давление для клиентов HTTP при реактивном использовании Spring WebClient.Для меня это звучит так, как если бы WebClient знал о семантике HTTP и давил обратное давление, например, на статус «429 - Too Many Requests».Я не нашел какой-либо документации по этому вопросу, что вызывает у меня некоторые сомнения в том, стоит ли идти по этому пути.

Вопросы:

1. Имеет ли смысл обратное давление на основе заголовков ответа HTTP(например, на основе кода состояния 429 или 503 и заголовка Retry-After)?Или есть лучший способ сделать обратное давление по HTTP для не потоковых (запрос-ответ) сценариев использования ?
2. Реализовано ли что-то подобное в Webclient или другой работающей библиотекехорошо с реактивной эхо-системой Spring?
3. Если ничего подобного в настоящее время не существует и, учитывая, что это имеет смысл, имеет ли смысл просто повторить попытку с таймаутом, установленным в заголовке Retry-After?

Answer 1

TL; DR: Spring Framework и Reactor Netty не предоставляют такую ​​поддержку, и я не знаю ни одной библиотеки, которая делает это.

Вы можете реализовать описанное вами поведение с помощьюWebFilter, который перехватывает входящие запросы перед их отправкой обработчикам и отвечает любым HTTP-статусом / заголовком по вашему выбору.

Единственная сложная задача - решить, следует ли отклонить запрос или нет.Вы можете настроить фиксированную пропускную способность таким образом, чтобы она не превышала или полагаться на какой-либо другой показатель JVM?

Теперь я бы не назвал это «противодавлением», по крайней мере, в контексте Spring.В реактивных потоках обратное давление примерно означает, что потребитель дает производителю информацию о количестве сообщений, которые он может отправить.Согласно спецификации, клиент не может отправить больше сообщений, чем разрешено.

В контексте HTTP в Spring мы не применяем противодавление при приеме новых соединений, но эта информация используется при чтении / записи в буферы TCP.Эта информация не пересекает сеть, поэтому мы просто полагаемся здесь на управление потоком TCP.

Если вы хотите, чтобы в протоколе была реальная поддержка противодавления, вам нужно, чтобы она поддерживалась в самом протоколе.В этом и заключается смысл будущей поддержки RSocket в Spring.