Spring Reactive Webclient 的请求级背压? [英] Request-level backpressure for Spring Reactive Webclient?

问题描述

这个类似于如何做akka-http request-level背压? 但对于 Spring 回声系统.

This is similar to How to do akka-http request-level backpressure? but for the Spring echo system.

我正在考虑如何在以响应方式使用 Spring WebClient 时为 HTTP 客户端实现背压.对我来说，似乎要走的路是让 WebClient 意识到 HTTP 语义并对例如应用背压.状态429 - 请求过多".我没有找到任何关于此的文档，这让我有点怀疑这是否是可行的方法.

I'm thinking about how to implement back-pressure for HTTP clients when using Spring WebClient in a reactive fashion. To me it sounds like the way to go would be for the WebClient to be aware of the HTTP semantics and apply back pressure on e.g. status "429 - Too Many Requests". I've not found any documentation on this which makes me somewhat doubtful if this is the way to go.

问题:

1. 基于 HTTP 响应标头的背压是否有意义(例如，基于 429 或 503 状态代码和 Retry-After 标头)?或者有没有更好的方法通过 HTTP 为非流式(请求-响应)用例做背压?
2. 是否在 Webclient 或其他与 Spring 反应式回声系统配合良好的库中实现了类似的功能?
3. 如果目前不存在这样的情况并且考虑到它有意义，那么简单地使用 Retry-After 标头中设置的超时重试是否有意义?

1. Does back pressure based on the HTTP response headers make sense (e.g. based on the 429 or 503 status code and Retry-After header)? Or is there a better way of doing back-pressure over HTTP for non-streaming (request-response) use cases?
2. Is something like this implemented in Webclient or some other library that works well with the Spring reactive echo-system?
3. If nothing like this currently exists and given that it makes sense, would it make sense to simply retry with the timeout set in the Retry-After header?

推荐答案

TL;DR:Spring Framework 和 Reactor Netty 不提供这种支持，我不知道有任何库可以做到这一点.

TL;DR: Spring Framework and Reactor Netty don't provide that kind of support and I'm not aware of any library that does this.

您可以使用 WebFilter 来实现您所描述的行为，该过滤器在传入请求被分派给处理程序之前拦截它们，并使用您选择的任何 HTTP 状态/标头进行回复.

You could implement the behavior you're describing with a WebFilter that intercepts incoming requests before they're dispatched to handlers and reply with any HTTP status/header of your choice.

唯一棘手的部分是决定是否应该拒绝请求.您可以将固定吞吐量配置为不超过或依赖其他一些 JVM 指标吗?

The only tricky part is to decide whether the request should be rejected or not. You could configure a fixed throughtput not to exceed, or rely on some other JVM metric?

现在我不会称之为背压"，至少不是在 Spring 的上下文中.在响应式流中，背压大致意味着消费者向生产者提供有关它可以发送的消息数量的信息.根据规范，客户端不能发送超过允许数量的消息.

Now I wouldn't call that "backpressure", at least not in the context of Spring. In reactive streams, backpressure roughly means that the consumer gives the producer information about the number of messages it can send. Per specification, the client cannot send more messages than the allowed number.

在 Spring 的 HTTP 上下文中，我们在接受新连接时不强制执行背压，但在读取/写入 TCP 缓冲区时会使用此信息.此信息不跨网络，因此我们在这里仅依赖 TCP 流量控制.

In the context of HTTP in Spring, we don't enforce backpressure when accepting new connections, but this information is being used when reading/writing to TCP buffers. This information does not cross the network, so we're merely relying on TCP flow control here.

如果你想在协议中提供真正的背压支持，你需要在协议本身中支持这一点.这就是 Spring 中未来 RSocket 支持的全部内容.

If you want real backpressure support in the protocol, you need this to be supported in the protocol itself. This is what the future RSocket support in Spring is all about.

这篇关于Spring Reactive Webclient 的请求级背压?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！