Pourquoi avons-nous écarté l'architecture des systèmes réactifs de notre code ?

Cet article explore notre décision de nous éloigner de l'architecture réactive dans notre projet logiciel. Nous approfondirons les principes fondamentaux des systèmes réactifs, les avantages des E/S non bloquantes et les défis auxquels nous sommes confrontés avec une approche réactive.

Comprendre le style d'architecture réactive

Reactive englobe un ensemble de principes et de lignes directrices visant à construire des systèmes et des applications distribués réactifs, caractérisés par :

1. Réactivité :Capable de traiter rapidement les demandes, même sous de lourdes charges.
2. Résilience :Capable de se remettre des pannes avec un temps d'arrêt minimal.
3. Élasticité :Peut s'adapter à l'évolution des charges de travail en faisant évoluer les ressources en conséquence.
4. Basé sur les messages :Utilise la messagerie asynchrone pour améliorer la tolérance aux pannes et découpler les composants.

L'un des principaux avantages des systèmes réactifs est leur utilisation d'E/S non bloquantes. Cette approche évite de bloquer les threads lors des opérations d'E/S, permettant à un seul thread de gérer plusieurs requêtes simultanément. Cela peut améliorer considérablement l'efficacité du système par rapport au blocage traditionnel des E/S.
Dans le multithreading traditionnel, les opérations de blocage posent des défis importants dans l'optimisation des systèmes (Figure 1). Les applications gourmandes consommant trop de mémoire sont inefficaces et pénalisent les autres applications, nécessitant souvent des demandes de ressources supplémentaires comme de la mémoire, du processeur ou des machines virtuelles plus volumineuses.

Figure 1 – Multi-threading traditionnel

Les opérations d'E/S font partie intégrante des systèmes modernes, et leur gestion efficace est primordiale pour éviter les comportements gourmands. Les systèmes réactifs utilisent des E/S non bloquantes, permettant à un faible nombre de threads du système d'exploitation de gérer de nombreuses opérations d'E/S simultanées.

Modèle d'exécution réactif

Bien que les E/S non bloquantes offrent des avantages substantiels, elles introduisent un nouveau modèle d'exécution distinct des frameworks traditionnels. Une programmation réactive a émergé pour résoudre ce problème, car elle atténue l'inefficacité des threads de plate-forme inactifs pendant les opérations de blocage (Figure 2).

Figure 2 – Boucle d'événement réactif

Quarkus et réactif

Quarkus exploite un moteur réactif alimenté par Eclipse Vert.x et Netty, facilitant les interactions E/S non bloquantes. Mutiny, l'approche privilégiée pour écrire du code réactif avec Quarkus, adopte un paradigme événementiel, dans lequel les réactions sont déclenchées par les événements reçus.

Mutiny propose deux types événementiels et paresseux :

1. Uni :Émet un seul événement (un élément ou un échec), adapté pour représenter des actions asynchrones avec zéro ou un résultat.
2. Multi :Émet plusieurs événements (n éléments, un échec ou un achèvement), représentant des flux d'éléments, potentiellement illimités.

Les défis de Reactive

Bien que les systèmes réactifs offrent des avantages, nous avons rencontré plusieurs défis lors du développement :

• Changement de paradigme :La programmation réactive nécessite un changement fondamental dans la mentalité des développeurs, ce qui peut être un défi, en particulier pour les développeurs habitués à la programmation impérative. Contrairement aux outils auxiliaires comme l'API Streams, l'approche réactive nécessite une refonte complète de l'état d'esprit.
• Lisibilité et compréhension du code :Le code réactif pose des difficultés à comprendre pour les nouveaux développeurs, ce qui entraîne une augmentation du temps passé à le déchiffrer et à le comprendre. La complexité introduite par les paradigmes réactifs aggrave ce problème.

"En effet, le rapport entre le temps passé à lire et à écrire est bien supérieur à 10 pour 1. Nous lisons constamment du vieux code dans le cadre de l'effort d'écrire du nouveau code. ...[Par conséquent,] le rendre facile à lire rend la lecture plus facile. c'est plus facile d'écrire."
―Robert C. Martin, Clean Code : Un manuel d'artisanat logiciel agile

• Défis de débogage :Le débogage du code réactif s'avère presque impossible avec les débogueurs IDE standard en raison des lambdas encapsulant la plupart du code. De plus, la perte de traces de pile significatives lors d'exceptions entrave encore davantage les efforts de débogage.Efforts de développement et de test accrus :La complexité inhérente du code réactif peut conduire à des cycles de développement plus longs en raison du temps requis pour l'écriture, la modification et les tests.

Voici un exemple de code réactif utilisant Mutiny pour illustrer la complexité :

Multi.createFrom().ticks().every(Duration.ofSeconds(15)) .onItem().invoke(() - > Multi.createFrom().iterable(configs()) .onItem().transform(configuration - > { try { return Tuple2.of(openAPIConfiguration, RestClientBuilder.newBuilder() .baseUrl(new URL(configuration.url())) .build(MyReactiveRestClient.class) .getAPIResponse()); } catch (MalformedURLException e) { log.error("Unable to create url"); } return null; }).collect().asList().toMulti().onItem().transformToMultiAndConcatenate(tuples - > { AtomicInteger callbackCount = new AtomicInteger(); return Multi.createFrom().emitter(emitter - > Multi.createFrom().iterable(tuples) .subscribe().with(tuple - > tuple.getItem2().subscribe().with(response - > { emitter.emit(callbackCount.incrementAndGet()); if (callbackCount.get() == tuples.size()) { emitter.complete(); } }) )); }).subscribe().with(s - > {}, Throwable::printStackTrace, () - > doSomethingUponComplete())) .subscribe().with(aLong - > log.info("Tic Tac with iteration: " + aLong));

Future Outlook-Project Loom and Beyond

Project Loom, a recent development in the Java ecosystem, promises to mitigate the issues associated with blocking operations. By enabling the creation of thousands of virtual threads without hardware changes, Project Loom could potentially eliminate the need for a reactive approach in many cases.

"Project Loom is going to kill Reactive Programming"
―Brian Goetz

Conclusion

In conclusion, our decision to move away from reactive architecture style a pragmatic approach to our project's long-term maintainability. While reactive systems offer potential benefits, the challenges they presented for our team outweighed those advantages in our specific context.

Importantly, this shift did not compromise performance. This is a positive outcome, as it demonstrates that a well-designed non reactive(imperative) architecture can deliver the necessary performance without the complexity associated with reactive architecture in our case.

As we look towards the future, the focus remains on building a codebase that is not only functional but also easy to understand and maintain for developers of all experience levels. This not only reduces development time but also fosters better collaboration and knowledge sharing within the team.

In the graph below, theX-axisrepresents the increasing complexity of our codebase as it evolves, while theY-axisdepicts the time required for these developmental changes.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!