Programmation réactive avec Spring 5 et Reactor

Introduction à la programmation réactive et exemples de mise en oeuvre avec Spring 5 et la librairie Reactor.

Transcript

1. Programmation réactive avec Spring 5 et Reactor Florian Beaufumé @fbeaufume 11/2017 v1.1
2. Florian Beaufumé • Architecte logiciel et expert Java • Freelance • Brown bag lunch • @fbeaufume
3. • Montée en charge • C10K (= 10K connexions) • Comment supporter 10000 connexions simultanées ? • Robustesse • Que faire si la base ou les systèmes tiers sont (très) lents ? Objectifs Server DB @fbeaufume
4. • Modèle standard de nos serveurs • Est bloquant avec pool de thread : • En charge : • Multiplier les serveurs ? • Multiplier les threads ? Modèle « thread-per-request » Server Requests Threads pool @fbeaufume
5. • Cout mémoire et CPU (context switches) • Contention Limitations des threads Server thread Database Client HTTP request SQL request #1 SQL request #2 @fbeaufume
6. • Montée en charge et robustesse • Exemples : Node.js, Vert.x, Redis, HAProxy Modèle non bloquant Event queue Events Event loop HTTP requests SQL responses … Few worker threads @fbeaufume
7. Callback hell
8. Exemple Spring 5
9. Types réactifs Eléments Bloquant Réactif 0..N Collection<Book> Flux<Book> 0..1 Book Mono<Book> 0 void Mono<Void> @fbeaufume
10. WebClient @fbeaufume
11. Spring Framework 5 Spring Framework Tomcat Netty Reactor Spring Web MVC Spring WebFlux Bloquant Réactif Reactive Streams @fbeaufume
12. Ecosystème Spring réactif Spring Framework 5 Spring Boot 2 Spring Data 2 Spring Security 5 Spring Integration 5 Spring Cloud @fbeaufume
13. Spring Data 2 @fbeaufume
14. • "Programming with asynchronous data streams" • Basé sur des étapes asynchrones et non bloquantes • API orientées callback et/ou déclaratives par composition de fonctions • Programmation réactive ≈ streams + CompletableFuture + backpressure • Bénéfices : • Montée en charge • Robustesse Programmation réactive @fbeaufume
15. • Code • Logs Reactor @fbeaufume
16. Construction @fbeaufume
17. Opérateurs @fbeaufume
18. Marble diagrams
19. • Pour donner du contrôle au consommateur sur le producteur Backpressure Producer Consumer Data flow Data request @fbeaufume
20. Conversions @fbeaufume
21. • Cas simple • Manipulation de l’échelle de temps Tests avec reactor-test @fbeaufume
22. • "Standard for asynchronous stream processing with non-blocking backpressure" • Implémentations : RxJava, Reactor, Akka Streams, etc. Reactive streams @fbeaufume
23. Comparaison de performance VS Bloquant Réactif @fbeaufume
24. Scénario Time Concurrent users 2 min 10 sec http://localhost:8080/pause/1000 @fbeaufume
25. Charge Bloquant Réactif 300 users injectés => 189 req/s mesuré 3000 users injectés => 2664 req/s mesuré @fbeaufume
26. Temps de réponse Bloquant Réactif Moyenne=1462, médiane=1579, σ=297 Moyenne=1036, médiane=1013, σ=59
27. Threads Bloquant Réactif @fbeaufume
28. • Syntaxe déroutante • Commencer par les streams Java 8 et la programmation fonctionnelle • API contaminante • Plus facile pour de nouvelles applications ou microservices Difficultés @fbeaufume
29. • JDBC pas encore supporté • Mono.fromCallable(() -> { … }).subscribeOn(Schedulers.elastic()) • Attendre JDK 10 • ThreadLocal perdent leur intérêt (MDC logging par exemple) • Pas encore de scope request ou session • myFlux.subscriberContext(Context.of("key", "value"))… Limitations @fbeaufume
30. • Supporter une forte charge • Pour fiabiliser des applications très communicantes • Microservices • Applications sensibles à la contention Cas d’usages @fbeaufume
31. Merci @fbeaufume