如何在Spring WebClient中管理/创建连接池？[副本]

Question

我们使用Spring WebClient调用web服务。

我知道我们使用了'ReactorClientHTtpConnector'，但没有得到任何示例代码。

基本上，我想有WebClient池与maxTotal、maxWaitMillis等。

Answer 1

Spring WebClient是一个无阻塞的IO http客户机，而ReactorClientHttpConnector是一个基于Reactor-Netty的实现。说，我可以建议不要担心连接池，而是专注于一个完全没有阻塞的服务调用。使用这种技术的succes的关键在于完全不阻塞服务调用链，模型不涉及每个请求的线程，它就像浏览器或节点js开发，如果有东西阻塞了代码，你就阻塞了任何东西。我知道这很不常见，但是基于事件循环模型的基本实现迫使您考虑一个完全不同的模型。我可以安慰你，在一个基于Netty的实现中，通常有许多事件循环，这些循环与内核的数量相同，当然是可配置的，但认为这已经足够了，记住反应式和无阻塞IO编程的强大之处是在所有代码中都使用无阻塞IO，并在每个处理器中添加更多的事件循环，这将使你增加一些并发性，而每个处理器有一个事件循环将使你能够完全并行地使用处理器。

我认为这个倒影能帮助你

小费。对于http服务调用的超时，您可以在下面的测试中添加一个类似的超时：

@Test
@WithMockUser(username = "user")
fun `read basic personal details data`() {
    personalDetailsRepository.save("RESUME_ID", TestCase.personalDetails()).toMono().block();

    val expectedJson = TestCase.readFileAsString("personal-details.json")
    webClient.get()
            .uri("/resume/RESUME_ID/personal-details")
            .accept(MediaType.APPLICATION_JSON)
            .exchange().toMono().timeout(Duration.ofMinutes(1))

} 

考虑到应用程序级别的限制请求，webclient当然可以使用背压特性来处理数据流，该数据流有时可能太大而无法可靠地处理，或者如果流响应像Flux一样，使用Flux limitRate（）操作符可能有用，则可以使用官方文档：

/**
     * Ensure that backpressure signals from downstream subscribers are split into batches
     * capped at the provided {@code prefetchRate} when propagated upstream, effectively
     * rate limiting the upstream {@link Publisher}.
     * <p>
     * Note that this is an upper bound, and that this operator uses a prefetch-and-replenish
     * strategy, requesting a replenishing amount when 75% of the prefetch amount has been
     * emitted.
     * <p>
     * Typically used for scenarios where consumer(s) request a large amount of data
     * (eg. {@code Long.MAX_VALUE}) but the data source behaves better or can be optimized
     * with smaller requests (eg. database paging, etc...). All data is still processed,
     * unlike with {@link #limitRequest(long)} which will cap the grand total request
     * amount.
     * <p>
     * Equivalent to {@code flux.publishOn(Schedulers.immediate(), prefetchRate).subscribe() }.
     * Note that the {@code prefetchRate} is an upper bound, and that this operator uses a
     * prefetch-and-replenish strategy, requesting a replenishing amount when 75% of the
     * prefetch amount has been emitted.
     *
     * @param prefetchRate the limit to apply to downstream's backpressure
     *
     * @return a {@link Flux} limiting downstream's backpressure
     * @see #publishOn(Scheduler, int)
     * @see #limitRequest(long)
     */
    public final Flux<T> limitRate(int prefetchRate) {
        return onAssembly(this.publishOn(Schedulers.immediate(), prefetchRate));
    }

说，我建议使用这些功能，不要试图以强制的方式限制数据的消耗，比如连接限制。反应式编程和无阻塞IO的优点之一是以令人难以置信的效率使用资源，限制资源的使用似乎违背了规范的精神