Programmation réactive Spring - Notes de lecture

préambule

Bonjour à tous, je suis Bittao. Cet article est les notes de lecture de "Spring Responsive Programming". Une pile technologique réactive peut créer des terminaux extrêmement efficaces, faciles à acquérir et résilients. Dans le même temps, la réactivité peut tolérer les retards du réseau et gérer les pannes avec moins d'impact. Les microservices réactifs isolent également les transactions lentes et accélèrent les plus rapides. Grâce à ce livre, vous pouvez apprendre ce qui suit :

• Principes de base de la programmation réactive et spécification du flux réactif ;
• Utiliser le cadre de développement réactif de Project Reactor intégré à Spring 5 ;
• Utilisez Spring Webflux pour créer des services RESTful réactifs ;
• Utilisez Spring Data Reactive pour créer des composants d'accès aux données réactifs ;
• Utilisez Spring Cloud Stream Reactive pour créer des composants de communication de messages réactifs.

Chapitre 1 Ressort réactif

Commençons par comprendre les termes liés à la programmation réactive :

• Élasticité : extensible horizontalement ;
• Rebond : isolation des défauts, atteindre l'indépendance ;
• Message-driven : ne doit pas être bloquant, réponse instantanée.

Dans le style réactif, la clé est la contre-pression : elle est principalement utilisée pour soutenir la résilience et réaliser le mécanisme complexe de gestion de la charge de travail entre les étapes de traitement, ce qui peut garantir qu'une étape de traitement ne submergera pas l'autre.

Dans le domaine de la JVM, il existe deux frameworks les plus connus pour construire des systèmes réactifs : Akka et Vert.x. En Java traditionnel, la méthode responsive :

1. Fonction de rappel, mais cela apportera un problème d'enfer de rappel ;
2. JDK 8 CompletionStage.

Afin d'être compatible avec l'ancien JDK, Spring 4 ne prenait pas en charge CompletionStage, et cette méthode n'était prise en charge que dans Spring 5. Dans le même temps, Servlet 3.0 a introduit la communication client-serveur asynchrone et 3.1 prend en charge les écritures non bloquantes d'E/S. Mais Spring MVC ne fournit pas de client asynchrone non bloquant prêt à l'emploi. Perte complète du support réactif pour les bagages obsolètes. Cela a également amené Spring à ouvrir une pile technologique distincte pour la réactivité.

Chapitre 2 Concepts de base de la programmation réactive Spring

Le modèle de publication-abonnement, qui peut être vu comme une variante du modèle d'observateur. Dans l'implémentation basée sur RxJava, le capteur de température ne détecte pas les données de température lorsque personne n'écoute. Ce comportement est une conséquence naturelle du fait que la programmation réactive a le concept d'abonnements actifs. Les implémentations basées sur le sujet de publication n'ont pas une telle propriété et sont donc plus restrictives.

La bibliothèque RxJava est une implémentation de machine virtuelle Java d'extensions réactives (extensions réactives, également appelées ReactiveX). Les extensions réactives sont un ensemble d'outils permettant de traiter des flux de données, qu'ils soient synchrones ou asynchrones, dans un langage impératif. ReactiveX est généralement défini comme une combinaison de modèle d'observateur, de modèle d'itérateur et de programmation fonctionnelle.

RxJava s'abonne à un flux observable via un abonné, qui à son tour déclenche un processus asynchrone de génération d'événements. Adopter cette approche est préjudiciable aux objets mutables, et la seule stratégie raisonnable est d'employer l'immuabilité. L'immuabilité est l'un des principes fondamentaux de la programmation fonctionnelle. Une fois qu'un objet est créé, il ne peut plus être modifié. Une règle aussi simple évite d'éventuels problèmes dans les systèmes parallèles.

Sans programmation fonctionnelle, il faudrait créer de nombreuses classes anonymes ou internes qui pollueraient l'application. Et ils créent plus de code passe-partout que de code efficace. En raison de son immuabilité, il est très adapté à la programmation concurrente.

histoire

L'histoire de la programmation asynchrone remonte à ce que Microsoft a fait en 2005 : un modèle de programmation pour une architecture de services Internet asynchrone à grande échelle et gourmande en données . En 2009, Rx.NET était open source.Plus tard, Netflix était confronté au problème complexe du trafic Internet massif, il a donc ouvert RxJava en open source. Et sur cette base, des bibliothèques bien connues telles que : Hystrix, Ribbon, Zuul, RxNetty ont été développées. Mais en fait, c'est Node.js qui a été entièrement implémenté et a apporté avec succès de grandes contributions dans le sens de la programmation réactive.

RxJava n'est pas la seule solution en Java, Vert.x peut également réaliser des fonctions similaires. Vert.x est un cadre de développement piloté par les événements, de conception similaire à Node.js. Il fournit un modèle de concurrence simple et une sémantique primitive pour la programmation asynchrone.

Avec le succès de RxJava, de nombreuses entreprises et projets open source ont lancé une concurrence féroce. Étant donné que le comportement des différentes bibliothèques est globalement très similaire, il existe de légères différences dans l'implémentation. Ainsi, si vous partagez des bibliothèques réactives, des bogues cachés peuvent apparaître. Afin de résoudre ces problèmes de compatibilité, un standard a émergé : Reactive Streams.

Chapitre 3 Flux réactifs - La nouvelle norme

Pour utiliser plusieurs bibliothèques réactives, vous devez écrire des adaptateurs pour la compatibilité. Il n'y a pas d'intégration directe entre ListenableFuture et CompletionStage au printemps 4. Au printemps 5, l'API de ListenableFuture a été étendue à une méthode appelée Comple-table pour résoudre l'incompatibilité. question . Le problème principal est qu'il n'y a aucun moyen pour les fournisseurs de bibliothèques de fournir des API alignées. Vert.x, Ratpack et Retrofit accordent tous plus d'attention à RxJava et fournissent un support.

Dans les premières étapes de l'évolution de l'ensemble de l'environnement réactif, toutes les bibliothèques ont été conçues avec l'idée de pousser les données des sources vers les abonnés. La principale raison d'adopter le modèle push est qu'il optimise le temps de traitement global en réduisant au minimum le volume de requêtes.

C'est pourquoi RxJava1.x et les bibliothèques de développement similaires sont conçues dans le but de pousser les données, et c'est pourquoi la technologie de flux peut être qualifiée de technologie de communication importante entre les composants d'un système distribué. Cependant, si le producteur ne fait pas attention à la capacité de débit du consommateur, il existe les possibilités suivantes :

• producteur lent et consommateur rapide
• Producteur rapide et consommateur lent

La solution à cette situation consiste à collecter les éléments non traités dans une file d'attente.

• File d'attente illimitée : une file d'attente de taille illimitée ;
• File d'attente de dépôt limitée : pour éviter le débordement de mémoire ;
• File d'attente de blocage délimitée : blocage des ordres de paiement ;

En général, la sémantique non contrôlée dans les modèles push purs peut conduire à de nombreuses situations indésirables. Le Manifeste réactif mentionne l'importance des mécanismes qui permettent à un système de répondre intelligemment à la charge, et l'importance de la contre-pression.

La spécification Reactive Streams définit 4 interfaces principales : Publisher, Subscriber, Subscription et Processor.

Parmi eux, Publisher et Observable, Subscriber et Observer sont fondamentalement les mêmes ;

Dans la méthode onSubscribe dans Subscriber, Subscription est référencé, ce qui fournit la base pour la production d'éléments de contrôle. La spécification Reactive Streams introduit la méthode de requête pour étendre l'interaction entre l'éditeur et l'abonné. Afin d'informer l'éditeur de la quantité de données qu'il doit pousser, l'abonné doit signaler via la méthode de requête la quantité souhaitée et s'assurer que le nombre d'éléments entrants ne dépasse pas la limite.

Contrairement à un modèle push pur, cette spécification nous donne un modèle push-pull hybride avec un contrôle raisonnable de la contre-pression.

Le processeur est une combinaison d'éditeur et d'abonné. Son objectif est d'ajouter des étapes de traitement entre l'éditeur et l'abonné.

Chapitre 4 Principes fondamentaux de l'application réactive du réacteur de projet

La spécification des flux réactifs (reactivestreams) rend les bibliothèques réactives compatibles entre elles et résout le problème de contre-pression en introduisant un modèle d'échange de données pull-push. Mais il ne définit que la spécification et ne fournit pas une utilisation quotidienne.Spring implémente Project Reactor (Reactor en abrégé).

La spécification des flux réactifs (reactivestreams) rend les bibliothèques réactives compatibles entre elles et résout le problème de contre-pression en introduisant un modèle d'échange de données pull-push. Mais il ne définit que la spécification et ne fournit pas une utilisation quotidienne.Spring implémente Project Reactor (Reactor en abrégé). La version Reactor1.x inclut les meilleures pratiques pour le traitement des messages, telles que le modèle de réacteur (Reactor Pattern), ainsi que des styles de programmation fonctionnels et réactifs.
Le modèle Reactor est un modèle comportemental qui facilite la réponse aux événements asynchrones et le traitement synchrone. Cela signifie que tous les événements doivent être mis en file d'attente et que le traitement réel des événements est effectué ultérieurement par un conteneur séparé. Un événement est envoyé à toutes les parties concernées (gestionnaires d'événements) et traité de manière synchrone.
Reactor 1.x est bien intégré au framework Spring. Reactor 1.x fournit de nombreux composants supplémentaires avec la bibliothèque de traitement des messages, comme un composant supplémentaire pour Netty. Reactor 2 a été le pionnier du streaming réactif. L'extraction du bus d'événements et de la fonctionnalité de diffusion en continu dans des modules distincts rend la bibliothèque Reactor Streams entièrement conforme à la spécification Reactive Streams. L'API Reactor a une meilleure intégration avec l'API Java Collections. L'API Streams de Reactor est plus similaire à l'API RxJava, avec une prise en charge supplémentaire de la gestion de la contre-pression, de la planification des threads et de la résilience. L'objet Reactor qui envoie le message est renommé EventBus.

Les idées de RxJava et ProjectReactor ont été condensées dans une bibliothèque reactive-stream-commons, qui est devenue plus tard Reactor3.x. Dans le même temps, Reactor3.x a façonné la variante responsive du framework Spring 5 (métamorphose réactive)

La bibliothèque Reactor est conçue pour éviter l'enfer des rappels et le code profondément imbriqué lors de la création de pipelines asynchrones. Nous pouvons considérer les données traitées d'une application réactive comme se déplaçant sur une chaîne de montage. Le Reactor est à la fois un tapis roulant et un poste de travail. L'API Reactor ne déclenche un flux de données réel qu'une fois abonné. Modèles de propagation de contre-pression courants pour cette bibliothèque :

• Push uniquement : lorsqu'un abonné demande un élément de montant sans fil valide via subscription.request(Long.MAX_VALUE).
• Pull-only : lorsqu'un abonné demande l'élément suivant uniquement après avoir reçu le précédent via subscription.request(1).
• Pull-push (parfois appelé hybride) : lorsque les abonnés ont des besoins de contrôle en temps réel et que les éditeurs peuvent s'adapter au taux de consommation de données proposé.

Project Reactor est construit sur la spécification Reactive Streams, et org.reactivestreams:reactive-streams est la seule dépendance obligatoire de Project Reactor. La spécification Reactive Stream définit quatre interfaces, à savoir Publisher, Subscriber, Subscription et Processor<T, R>.

ProjectReactor fournit deux implémentations de l'interface Publisher, Flux et Mono.

Mono est l'un des deux types de cœur de Reactor, l'autre étant Flux. Les deux implémentent l'interface Publisher de Reactive Streams. Un flux représente un pipeline avec zéro, un ou plusieurs éléments de données (éventuellement infinis). Sa formule est : onNext x 0…N [onError | onComplete]. Par exemple : Flux.range(1, 5).repeat();

Mono est un type réactif spécial optimisé pour les scénarios où il n'y a pas plus d'un élément de données. La formule est exprimée comme suit : onNext x 0…1 [onError | onComplete]. Mono est utile lorsque l'API de l'application renvoie au plus un élément. Par conséquent, il peut remplacer comple-tableFuture et fournir une sémantique similaire. CompletableFuture commence le traitement immédiatement, tandis que Mono ne fait rien jusqu'à ce qu'un abonné se présente. L'avantage du type Mono est seulement qu'il fournit non seulement un grand nombre d'opérateurs réactifs, mais qu'il peut également être parfaitement intégré dans un flux de travail réactif plus large. Exemple : Lorsque l'opération est terminée et que le client doit être averti, Mono peut également être utilisé pour envoyer le signal onComplete() lorsque le traitement est terminé et renvoyer onError() lorsqu'un échec se produit. Dans ce scénario, aucune donnée n'est renvoyée, mais un signal de notification est émis, qui à son tour peut être utilisé comme déclencheur pour d'autres calculs.

Flux et Mono sont les blocs de construction les plus basiques fournis par Reactor, et les opérateurs fournis par ces deux types réactifs sont le ciment qui les combine pour construire des pipelines de flux de données. Flux et Mono ont un total de plus de 500 opérations, qui peuvent être grossièrement classées en :
opérations de création ;
opérations de combinaison ;
opérations de conversion ;
opérations logiques.

Chapitre 5 Réactivité avec Spring Boot 2

Project Reactor peut fonctionner sans le framework Spring, et il sera encore meilleur s'il est combiné avec l'injection de dépendances de Spring.

En 2009, l'équipe de Spring a utilisé la méthode de Convention-over-configuration afin de développer rapidement des applications. Spring Boot est sorti en 2012, adoptant le concept d'applications Web sans conteneur et la technologie Fat JAR (Fat JAR) exécutable. Les deux annotations les plus critiques : @SpringBootApplication, utilisé pour exécuter le conteneur IoC ; @spring-boot-autoconfigure, configure automatiquement certains composants de suffixe "-starter-".

Spring 5.x introduit la prise en charge native des flux réactifs et des bibliothèques réactives, notamment RxJava 1/2 et Project Reactor3.

Les adaptateurs pour Servlet API 3.1 fournissent une intégration purement asynchrone et non bloquante contrairement aux adaptateurs WebMVC. Bien sûr, le module Spring WebMVC prend également en charge Servlet API4.0, qui prend en charge HTTP/2.

Au début, Spring Data fournissait principalement un accès bloquant synchrone à la zone de stockage sous-jacente. Heureusement, la cinquième génération de Spring Data fournit l'interface ReactiveCrudRepository, qui expose le type réactif de ProjectReactor pour faciliter l'intégration transparente des flux de travail réactifs.

Le module Spring Sessiong peut utiliser une abstraction efficace pour la gestion des sessions.Spring Sessiong introduit ReactiveSessionRepository, qui peut utiliser le type Mono de Reactor pour effectuer un accès asynchrone non bloquant aux sessions stockées.

L'ancien Spring Security utilise ThreadLocal comme méthode de stockage de l'instance SecurityContext, ce qui est très efficace lorsqu'il est exécuté dans un seul Thread.A tout moment, nous pouvons accéder au SecurityContext stocké dans le ThreadLocal. Mais dans une communication asynchrone, nous devons transférer le contenu ThreadLocal vers un autre Thread. La nouvelle génération actuelle de Spring Security adopte la fonction de contexte Reactor pour transmettre le contexte de sécurité dans les flux Flux ou Mono.

Netflix Zuul est basé sur une API Servlet qui utilise le blocage du routage des requêtes synchrones, et le seul moyen d'invalider les requêtes de traitement et d'obtenir de meilleures performances est de régler le pool de threads de serveur sous-jacent. Heureusement, Spring Cloud a introduit le nouveau module Spring Cloud Gateway, qui est construit sur Spring WebFlux et fournit un routage asynchrone et non bloquant avec le support de Project Reactor 3. En plus des passerelles, Spring Cloud Streams a également obtenu le soutien de Project Reactor et a introduit un modèle de flux plus fin. Il existe également Spring Cloud Function et Spring Cloud Data Flow, qui peuvent construire leur propre FaaS (Function as a service).

Spring Actuator fournit une intégration complète avec WebFlux et utilise son modèle de programmation asynchrone et non bloquant afin d'exposer efficacement les points de terminaison des métriques. Le module Spring Cloud Sleuth prend également en charge la programmation réactive de Project Reactor et le traçage distribué prêt à l'emploi.

Chapitre 6 Communication WebFlux asynchrone non bloquante

La décision d'intégrer le module Web Spring à l'API Servlet de Java EE a commencé lorsque le framework Spring a commencé à évoluer dans l'espace des applications Web. L'infrastructure globale du framework Spring est construite autour de l'API Servet et ils sont étroitement couplés. Par exemple, Spring Web MVC dans son ensemble est basé sur le modèle Front Controller. Ce mode est implémenté par la classe org.springframework.web.servlet.DispatcherServlet dans Spring Web MVC, et l'introduction de cette classe étend la classe javax.servlet.http.HttpServlet.

La conception globale repose sur le conteneur de servlet sous-jacent, qui est responsable de la gestion de tous les servlets mappés dans le conteneur. DispatchServlet sert de point d'intégration pour l'intégration de l'infrastructure Web Spring flexible et hautement configurable avec l'API Servlet lourde et complexe. L'abstraction configurable de HandlerMapping aide à séparer la logique métier finale (telle que les contrôleurs et les beans) de l'API Servlet.

Bien que l'API Servlet prenne en charge la communication asynchrone et non bloquante (à partir de la version 3.1), l'implémentation du module SpringMVC présente non seulement de nombreux défauts, mais ne permet pas non plus d'opérations non bloquantes tout au long du cycle de vie de la requête. Par exemple, il n'a pas de client HTTP non bloquant prêt à l'emploi, toute interaction externe peut entraîner le blocage des appels d'E/S. Un autre inconvénient de l'abstraction Web dans les anciennes versions de Spring est qu'il n'y a aucune flexibilité pour un serveur non Servlet (tel que Netty) pour réutiliser la fonctionnalité Web Spring ou le modèle de programmation.

WebFlux offre la possibilité de développer des applications légères via un mappage de route fonctionnel et une API intégrée dans laquelle nous pouvons écrire une logique de routage de requête complexe. La combinaison de routage purement fonctionnel est suffisante pour de nouvelles approches de programmation réactive. En outre, un remplacement réactif de l'ancien RestTemplate pour WebClient est fourni. Bien que WeboSocket ait été introduit dans Spring en 2013, certaines opérations de blocage, telles que l'écriture de données dans les E/S ou la lecture de données à partir d'E/S, bloquent toujours les opérations. Le module WebFlux introduit une version améliorée de l'infrastructure pour WebSocket et fournit un support client.

Comparaison de WebFlux et WebMVC

Dans le passé, les ordinateurs étaient séquentiels, et tout le monde était habitué à parcourir des contenus simples et statiques, et la charge globale du système était toujours faible. Mais maintenant, le nombre d'utilisateurs Web a atteint plus d'une douzaine de niveaux, et le contenu a commencé à devenir dynamique ou même en temps réel, et les exigences en matière de débit et de délai ont beaucoup changé. Pour calculer comment le nombre d'unités de travail parallèles modifie la latence ou le débit, vous pouvez utiliser la loi de Little : N = X x R. Le nombre moyen de requêtes (ou de requêtes traitées simultanément) (N) résidant dans un système ou une file d'attente est égal au débit (ou au nombre d'utilisateurs par seconde) (X) multiplié par le temps de réponse moyen ou la latence (R) ; par exemple : Réponse moyenne du système Le temps R est de 0,2S, et le débit X est de 100 requêtes par seconde, alors il devrait être capable de gérer 20 requêtes en même temps, ou 20 utilisateurs en parallèle.

Les frameworks Web traditionnels basés sur des servlets, tels que Spring MVC, sont de nature bloquante et multithread, et chaque connexion utilise un thread. Lorsque la demande est traitée, un thread de travail sera extrait du pool de threads pour traiter la demande. Pendant ce temps, le thread de requête est bloqué jusqu'à ce que le thread de travail signale qu'il est terminé.
La conséquence en est que le blocage des frameworks Web ne peut pas évoluer efficacement sous un grand nombre de requêtes. Le délai introduit par un thread de travail lent aggravera la situation, car il faudra plus de temps pour renvoyer le thread de travail au pool, prêt à traiter une autre demande. Dans certains scénarios, cette conception est parfaitement acceptable. En fait, c'est en grande partie ainsi que la plupart des applications Web ont été développées depuis plus d'une décennie, mais les temps changent.
Les clients de ces applications Web étaient autrefois des personnes qui naviguaient occasionnellement sur le site, mais désormais, ces personnes consomment fréquemment du contenu et utilisent des applications qui fonctionnent avec des API HTTP. Aujourd'hui, l'Internet des objets (qui n'a même pas besoin d'humains) a engendré des voitures, des moteurs à réaction et d'autres clients non traditionnels qui échangent constamment des données avec des API Web. Avec de plus en plus de clients utilisant des applications Web, l'évolutivité est plus importante que jamais.
Les frameworks Web asynchrones peuvent atteindre une évolutivité plus élevée avec moins de threads, généralement ils n'ont besoin que du même nombre de threads que les cœurs de processeur. En utilisant ce que l'on appelle le mécanisme de bouclage d'événements (illustré à la figure 11.1), ces frameworks sont capables de gérer de nombreuses requêtes avec un seul thread, de sorte que le coût par connexion sera inférieur.

La case en haut à droite représente un modèle de programmation alternatif qui utilise un paradigme de programmation fonctionnelle pour définir les contrôleurs au lieu d'utiliser des annotations.

Bien que les contrôleurs Spring WebFlux renvoient généralement Mono et Flux, cela ne signifie pas que Spring MVC ne peut pas expérimenter les joies de la frappe réactive. Spring MVC peut également renvoyer Mono et Flux si vous le souhaitez.
La différence ici est la façon dont ces types sont utilisés. Spring WebFlux est un véritable framework Web réactif qui permet de traiter les requêtes dans des boucles d'événements, tandis que Spring MVC est basé sur Servlet et s'appuie sur le multithreading pour gérer plusieurs requêtes.

Web MVC est construit sur le blocage des E/S, ce qui signifie que le Thread traitant chaque requête entrante peut être bloqué en lisant les messages entrants des E/S.

En revanche, WebFlux est construit sur une API non bloquante, ce qui signifie qu'aucune opération n'a besoin d'interagir avec les threads bloquant les E/S. WebFlux peut utiliser un Thread plus efficacement que Web MVC.

Scénarios pour les applications WebFlux :

1. Système de microservice : la caractéristique la plus notable d'un système de microservice typique est un grand nombre de communications d'E / S. L'existence d'E / S, en particulier le blocage des E / S, réduira le délai et le débit de l'ensemble du système.
2. Systèmes qui gèrent des connexions client lentes : si le nombre de clients est élevé, les risques de plantage du système sont élevés. Par exemple, les pirates peuvent facilement rendre nos serveurs indisponibles en utilisant des attaques par déni de service (DoS). En revanche, WebFlux nous permet d'accepter les connexions sans bloquer les threads de travail.
3. Systèmes de diffusion en continu ou en temps réel : ces systèmes se caractérisent par une faible latence et un débit élevé, qui peuvent être obtenus en utilisant une communication non bloquante. Cependant, ce cadre réactif a ses propres inconvénients, à savoir des modèles d'interaction complexes utilisant des canaux et des rappels. Mais nous pouvons créer un flux asynchrone non bloquant avec une bibliothèque réactive tout en nécessitant très peu de temps système.

WebFlux est disponible avec un serveur Web réactif (Netty) et une fonctionnalité Undertow non bloquante

Chapitre 7 Accès réactif à la base de données

Le blocage des E/S est toujours déconseillé dans les applications réactives. Les modules Spring Data accèdent aux données de manière réactive. Même si la base de données sélectionnée ne fournit pas de pilote réactif ou asynchrone, nous pouvons toujours utiliser un pool de threads dédié pour construire un framework autour d'elle. Application réactive.

"Domain-Driven Design: The Way to Cope with the Complexity of Software Core" d'Eric Evans définit et façonne la base théorique importante d'une architecture de microservice réussie. La conception pilotée par le domaine (DDD) établit un vocabulaire commun (c'est-à-dire le contexte, le domaine, le modèle et le langage unifié), et un seul contexte délimité (contexte délimité) défini selon DDD est généralement mappé à un micro distinct en service.

Étant donné que DDD est très préoccupé par le domaine de cœur de métier (core domain), en particulier les artefacts utilisés pour exprimer, créer et récupérer des modèles de domaine, des entités (Entity), des objets de valeur (Value object), une agrégation (Aggregate), un référentiel (Repository), etc. Les objets seront fréquemment mentionnés dans ce chapitre.

Lors de la mise en œuvre d'une application prenant en compte DDD, les objets ci-dessus doivent être mappés à la couche de persistance de l'application. Ce modèle de domaine constitue la base du modèle de données logique et physique.

À suivre...