Início / coding / Perguntas / 79590945
Accepted
Timo B.
Asked: 2025-04-24 23:11:41 +0800 CST

Threads virtuais na integração Spring para chamadas de serviço externo de longa duração

  • 772

Estamos trabalhando em um fluxo de integração com o Spring em que cada mensagem recebida precisa acionar uma chamada para um serviço HTTP externo. A chamada externa pode levar até 20 segundos para ser concluída e a resposta pode ser bem grande — ela precisa ser mantida totalmente na memória para processamento posterior.

Para melhorar a escalabilidade e reduzir o número de threads de plataforma bloqueadas, queremos aproveitar as threads virtuais do Java (Projeto Loom, Java 21+). Nossa abordagem atual é usar:

Executors.newVirtualThreadPerTaskExecutor()

como executor do canal no fluxo de integração:

IntegrationFlow.from(adapter).channel(c -> c.executor(virtualThreadExecutor)).handle(processingService)

Quando as mensagens chegam, já podemos verificar no processingService que elas são processadas por uma Thread virtual.

Aqui está o que estamos nos perguntando:

  • Essa é a maneira correta de usar threads virtuais no Spring Integration ou existem maneiras melhores de integrar threads virtuais nesse tipo de fluxo?

  • Quais são as potenciais armadilhas, limitações ou problemas de desempenho dos quais devemos estar cientes ao usar threads virtuais neste contexto?

  • Existem componentes específicos no Spring Integration (como gateways, ativadores de serviço, etc.) que ainda não são compatíveis com threads virtuais?

  • Para evitar ficar sem memória, pensamos em limitar o número de requisições externas simultâneas. Existem práticas recomendadas para isso?

Estamos especialmente interessados ​​em quaisquer práticas recomendadas ou experiências reais que alguém possa ter. Agradecemos antecipadamente!

Atualmente, estamos usando SpringBoot 3.4.4 e Java 21.

spring-boot

1 respostas

  1. Best Answer

    Essa é a maneira correta de usar threads virtuais no Spring Integration ou existem maneiras melhores de integrar threads virtuais nesse tipo de fluxo?

    Sim, é assim. Sempre que você puder injetar um Executor, ele será um candidato para threads virtuais.

    Quais são as potenciais armadilhas, limitações ou problemas de desempenho dos quais devemos estar cientes ao usar threads virtuais neste contexto?

    Esta é uma pergunta mais geral sobre a natureza das threads virtuais. Nada específico do Spring. Portanto, se houver uma fixação da thread da plataforma em algum ponto da chamada, nada que possamos fazer da perspectiva do Spring. Acho que este artigo explica bem quais problemas e onde podem ocorrer: https://medium.com/@phil_3582/java-virtual-threads-some-early-gotchas-to-look-out-for-f65df1bad0db

    Existem componentes específicos no Spring Integration (como gateways, ativadores de serviço, etc.) que ainda não são compatíveis com threads virtuais?

    Todo o código no portfólio Spring foi otimizado para evitar synchronizedbloqueios. Mantemos nossas dependências atualizadas, mas isso não significa que algumas bibliotecas das quais dependemos sejam compatíveis com threads virtuais. Por exemplo, o Apache Kafka (mesmo a versão atual 4.0.0) usa um for regular Threadpara tarefas para cada instância do consumidor. Veja ApplicationEventHandlercomo ele é usado no AsyncKafkaConsumer.

    Para evitar ficar sem memória, pensamos em limitar o número de requisições externas simultâneas. Existem práticas recomendadas para isso?

    Provavelmente é isso que chamamos de rate limiting. Veja mais informações na documentação: https://docs.spring.io/spring-integration/reference/handler-advice/classes.html#rate-limiter-advice

    • 0

relate perguntas