Spring MVC (async) vs Spring WebFlux

Question

J'essaie de comprendre Spring WebFlux. Les choses que j'ai trouvées jusqu'à présent sont réactives à la base, pas de Servlet API, pas de thread par requête, HTTP 2, server pushes, application/stream+json.

Mais quelle est la différence entre les appels asynchrones dans Spring MVC ? Je veux dire que dans Spring MVC, lorsque vous renvoyez Future, DefferedResult, etc., la logique du gestionnaire de requêtes (méthode du contrôleur) est exécutée dans un thread séparé, ce qui vous permet d'économiser les ressources du pool de threads pour la répartition des requêtes.

Pourriez-vous donc mettre en évidence les différences liées à cela ? Pourquoi WebFlux est-il meilleur ici ?

Merci beaucoup pour votre temps !

Answer 1

Le modèle asynchrone de Servlet introduit une frontière asynchrone entre les threads du conteneur (modèle 1 Servlet request/thread) et le traitement de la demande dans votre application. Le traitement peut se faire sur un autre thread ou attendre. En fin de compte, vous devez renvoyer la requête à un thread du conteneur et lire/écrire de manière bloquante ( InputStream et OutputStream sont par nature des API bloquantes).

Avec ce modèle, vous avez besoin de nombreux threads pour obtenir la simultanéité (car beaucoup d'entre eux peuvent être bloqués en attendant les E/S). Cela coûte des ressources et peut être un compromis, en fonction de votre cas d'utilisation.

Avec un code non bloquant, vous n'avez besoin que de quelques threads pour traiter un grand nombre de demandes simultanément. Il s'agit d'un modèle de concurrence différent ; comme tout modèle, il présente des avantages et des inconvénients.

Pour plus d'informations sur cette comparaison, ce Discussion sur les piles servlet et réactives devrait être intéressant.

Answer 2

L'API des servlets est une entrée/sortie bloquante qui nécessite un thread par requête HTTP. L'asynchronisme de Spring MVC repose sur les API des servlets, qui n'offrent un comportement asynchrone qu'entre les threads du conteneur et les threads de traitement des demandes, mais pas de bout en bout.

Spring WebFlux, quant à lui, permet d'atteindre la concurrence par un nombre fixe de threads en utilisant des sockets HTTP et en poussant des morceaux de données à la fois à travers les sockets. Ce mécanisme est appelé boucle d'événement une idée rendue populaire par Node.js . Une telle approche est évolutive et résiliente. Le spring-webflux de Spring 5 utilise la fonction boucle d'événement pour fournir un comportement asynchrone.

Pour en savoir plus, voir

• Servlet et réactif
• La bataille des performances de Spring Boot
• Comparaison de WebFlux avec Spring Web MVC