Spring Web-Flux 中的背压机制

Question

我是 Spring Web-Flux 的初学者。我写了一个控制器如下：

@RestController
public class FirstController 
{
    @GetMapping("/first")
    public Mono<String> getAllTweets() 
    {
        return Mono.just("I am First Mono")
    }
}

我知道反应式的好处之一是 Backpressure，它可以平衡请求或响应率。我想了解如何在 Spring Web-Flux.

中实现背压机制

Answer 1

WebFlux 中的背压

为了理解 Backpressure 在 WebFlux 框架的当前实现中是如何工作的，我们必须在这里回顾一下默认使用的传输层。我们可能还记得，浏览器和服务器之间的正常通信（服务器到服务器的通信通常也是如此）是通过 TCP 连接完成的。 WebFlux 还使用该传输在客户端和服务器之间进行通信。然后，为了了解 backpressure control 术语的含义，我们必须从 Reactive Streams 规范的角度回顾一下 backpressure 的含义。

The basic semantics define how the transmission of stream elements is regulated through back-pressure.

因此，根据该陈述，我们可以得出结论，在 Reactive Streams 中，背压是一种通过传输（通知）接收者可以消耗多少元素来调节需求的机制；在这里我们有一个棘手的问题。 TCP 具有字节抽象而不是逻辑元素抽象。我们通常所说的背压控制就是要对网络的逻辑元素个数sent/receivedto/from进行控制。即使 TCP 有自己的流量控制（见含义here and animation there），这个流量控制仍然是针对字节而不是逻辑元素。

在WebFlux模块的当前实现中，背压由传输流量控制来调节，但它并没有暴露接收者的真实需求。为了最终看到交互流程，请看下图：

为简单起见，上图显示了两个微服务之间的通信，其中左侧发送数据流，右侧使用该流。下面的编号列表提供了该图的简要说明：

这是 WebFlux 框架，它会妥善处理逻辑元素与字节之间的转换以及 transferring/receiving 它们 to/from TCP（网络）。
这是元素的长运行处理的开始，作业完成后请求下一个元素。
这里，虽然业务逻辑没有需求，但 WebFlux 会在没有确认的情况下将来自网络的字节排队（业务逻辑没有需求）。
由于 TCP 流量控制的性质，服务 A 可能仍会向网络发送数据。

从上图我们可以看出，接收方暴露的需求与发送方的需求不同（这里的需求是逻辑元素）。这意味着两者的需求是隔离的，仅适用于 WebFlux <-> 业务逻辑（服务）交互，并减少服务 A <-> 服务 B 交互的背压。所有这些都意味着 WebFlux 中的背压控制并不像我们预期的那样公平。

所有这些都意味着 WebFlux 中的背压控制并不像我们预期的那样公平。

但是我还是想知道如何控制背压

如果我们仍然想在 WebFlux 中对背压进行不公平的控制，我们可以在 limitRate() 等 Project Reactor 操作符的支持下做到这一点。以下示例显示了我们如何使用该运算符：

@PostMapping("/tweets")
public Mono<Void> postAllTweets(Flux<Tweet> tweetsFlux) {
    
    return tweetService.process(tweetsFlux.limitRate(10))
                       .then();
}

正如我们从示例中看到的，limitRate() 运算符允许定义一次预取的元素数。这意味着，即使最终订阅者请求 Long.MAX_VALUE 个元素，limitRate 运算符也会将该需求分成多个块，并且不允许一次消耗更多元素。我们可以对元素发送过程做同样的事情：

@GetMapping("/tweets")
public Flux<Tweet> getAllTweets() {
    
    return tweetService.retreiveAll()
                       .limitRate(10);
}

上面的例子表明，即使 WebFlux 一次请求超过 10 个元素，limitRate() 也会将需求限制在预取大小，并防止一次消耗超过指定数量的元素。

另一种选择是实现自己的 Subscriber 或从 Project Reactor 扩展 BaseSubscriber。例如，以下是我们如何做到这一点的简单示例：

class MyCustomBackpressureSubscriber<T> extends BaseSubscriber<T> {

    int consumed;
    final int limit = 5;

    @Override
    protected void hookOnSubscribe(Subscription subscription) {
        request(limit);
    }
    
    @Override
    protected void hookOnNext(T value) {
        // do business logic there 

        consumed++;
        
        if (consumed == limit) {
            consumed = 0;
            
            request(limit);
        }
    }
}

使用 RSocket 协议的公平背压

为了通过网络边界实现逻辑元素背压，我们需要一个合适的协议。幸运的是，有一个叫做RScoket protocol。 RSocket 是一种应用程序级协议，允许通过网络边界传输实际需求。该协议有一个 RSocket-Java 实现，允许设置 RSocket 服务器。在服务器到服务器通信的情况下，相同的 RSocket-Java 库也提供客户端实现。要了解更多如何使用 RSocket-Java，请参阅以下示例 here。对于浏览器-服务器通信，有一个 RSocket-JS 实现，它允许通过 WebSocket 连接浏览器和服务器之间的流式通信。

基于 RSocket 的已知框架

现在有一些框架建立在 RSocket 协议之上。

变形杆菌

其中一个框架是 Proteus 项目，它提供构建在 RSocket 之上的成熟的微服务。此外，Proteus 与 Spring 框架很好地集成，因此现在我们可以实现公平的背压控制（参见示例 there）

Spring Web-Flux 中的背压机制

Backpressure mechanism in Spring Web-Flux

java

reactive-programming

backpressure

spring-webflux

WebFlux 中的背压

但是我还是想知道如何控制背压

使用 RSocket 协议的公平背压

基于 RSocket 的已知框架

变形杆菌

进一步阅读