
Architecture Réactive
L’architecture réactive est un sujet que je n’ai découvert que très récemment et qui, avec l’arrivée de Spring 5, a éveillé ma curiosité.
Dans le monde de Java vous connaissez sans doute Akka ou RxJava, qui sont des libraires implémentant la spécification Reactive Streams adoptée dans Java 9 en tant que java.util.concurrent.Flow.

Reactor est un projet récent et facilement implémentable dans un projet Spring, dû à son haut niveau d’abstraction. Il repose sur l’API de Java 8 avec l’exploitation de java.time.Duration, java.util.stream.Stream et java.util.concurrent.CompletableFuture<T>.
Qu’est-ce qu’une architecture réactive ?
Pour faire court, en une image.

Responsive: Votre application se doit de pouvoir répondre en un minimum de temps et de détecter et résoudre les problèmes rapidement.
J’aime comment Kevin Webber illustre ce principe. Imaginez que vous voulez vous faire un café mais qu’il vous manque de la crème et du sucre.
Une approche possible :
- Mettre du café dans la machine.
- Aller faire les courses pendant que la machine fait couler le café.
- Acheter de la crème et du sucre.
- Retournez chez soi.
- Boire le café instantanément.
- Profiter de la vie.
Et en voici une autre :
- Aller faire les courses.
- Acheter de la crème et du sucre.
- Retournez chez soi.
- Mettre du café dans la machine.
- Regarder impatiemment la cafetière se remplir.
- Expérimenter le manque de caféine.
- S’écrouler à cause du manque (oui c’est l’extrême, mais ce n’est que pour illustrer!).
La première approche illustre bien la frontière qui confronte l’espace et le temps de ces deux scénarios, voici donc en quoi consiste le terme “responsive” (réactivité en français).
Elastic: Être en capacité de pouvoir réagir à une charge du système en allouant plus ou moins de ressources. Si votre application devient populaire, il faut pouvoir encaisser une charge plus importante et être en mesure de répondre à la résilience de votre système et donc aussi à sa réactivité.
Message Driven: Chaque action effectuée est transmise de façon asynchrone aux composants de l’application.
Resilient: L’application doit être en capacité de surmonter les potentielles erreurs.
Encore une fois, je vous renvoie à l’article anglophone de Kevin Webber qui explique en détail ces quatre points.
D’après le manifeste, ces changements s’opèrent avec le tournant qu’ont pris les besoins des applications durant ces dernières années.
Seulement quelques années auparavant, une grosse application devait avoir une dizaine de serveurs, quelques secondes de temps de réponse, des heures de maintenance hors connexion et des gigaoctets de données.
Aujourd’hui les applications sont déployées sur toutes sortes de plateformes : des smartphones aux clusters cloud avec des milliers de processeurs multi-core.
Les utilisateurs s’attendent maintenant à un temps de réponse dans la milliseconde et 100 % de disponibilité. Les données se mesurent en petaoctets.
