如何在Spring WebClient中管理/创建连接池?

时间:2018-12-16 06:10:45

标签: spring connection-pooling spring-webflux

我们正在使用Spring WebClient调用使用该服务的Web服务。

但是,我不知道如何在Spring WebClient中创建/管理连接池。

我知道我们已经使用了'ReactorClientHttpConnector',但没有任何示例代码。

基本上,我想拥有带有maxTotal,maxWaitMillis等的WebClient池。

1 个答案:

答案 0 :(得分:1)

Spring WebClient是无阻塞IO http客户端,而ReactorClientHttpConnector是基于Reactor-Netty的实现。说我可以建议不要担心连接池,而应该专注于完整的无阻塞服务调用。成功使用这种技术的关键是着重于完整的无阻塞服务调用链,该模型不涉及每个请求的线程,就像浏览器或节点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))

} 

更新

考虑到对应用程序级别进行限制的请求,Web客户端当然可以使用反压功能来处理有时可能太大而无法可靠处理的数据流,或者在诸如带有Flux limitRate()运算符的Flux可以用于以下官方文档:

/**
     * 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的优势之一在于其使用资源的效率极高,并且限制了资源的使用,这似乎违反了范式精神