Introduction aux systèmes réactifs

Bonjour et bienvenue dans ce premier article de la Chronique réactive !

Dans ce premier article nous allons parler des systèmes réactifs au travers des services web modernes : qu’est ce qu’un service web, quelles sont ses problématiques, comment les résoudre, ce qu’est un système réactif et pourquoi cette approche permet de créer des systèmes plus robustes, performants et disponibles.

Un peu de lexique – Qu’est ce qu’un service web ?

Un service web peut être défini comme une interface exposant des fonctionnalités sur un réseau. Interface car pouvant être une machine unique aussi bien qu'un cluster de machines.

Cette interface est amenée à échanger avec des clients qui peuvent être locaux comme distants, parfois (et même souvent) avec plusieurs clients en même temps. Ces clients peuvent également être en réalité d'autres services dépendants de celui-ci.

Quelles sont les contraintes d’un service web ?

De cette définition nous pouvons d'ores et déjà définir de nombreuses contraintes :

• un service web étant par essence profondément dépendant du réseau il est sensible à un véritable folklore d'erreurs: coupure internet, erreurs dns, erreurs http en tous genres, timeout, port filtré par un pare feu etc...
• lorsqu'il dépend d'autres services il est naturellement dépendant de leur bon fonctionnement. Si un service dépendance ne répond plus, plus assez vite ou avec des erreurs notre service peut également se mettre à renvoyer des erreurs voire être carrément indisponible
• un service web va généralement servir un front (site web, application mobile, application de bureau) ou même d'autres services web, il doit donc rester disponible au risque d'impacter le bon fonctionnement de ses dépendances
• un service web est amené à recevoir un fort débit de requêtes (nombreux clients, gateways, attaques etc...), et se doit de répondre à chacune d'elles dans un délai décent
• un service web va généralement effectuer des actions coûteuses en temps comme la lecture/écriture depuis un fichier, l'interrogation d'une base de données, d'un autre service etc.

On pourrait sûrement encore trouver de nombreuses problématiques, mais nous avons ici assez d'éléments pour commencer à dresser le portrait et les prérequis auxquels doit répondre un service web moderne.

Un service web devant évoluer dans un univers hautement concurrentiel, il se doit en premier lieu d’être asynchrone (la plupart des librairies et frameworks modernes se sont d’ailleurs dotés d’event loops et de thread pools en tous genres).

Un service web ayant également de fortes dépendances et en étant généralement lui même une, il se doit naturellement d’être résilient aux erreurs.

Un service web pouvant faire face à un fort débit de requêtes il se doit également d’être souple et capable de monter en charge. Pour un gros service web visant la haute disponibilité cette problématique va potentiellement induire la création d’instances multiples et la répartition de charge, pour un système plus modeste on entendra par là la capacité à maintenir un service décent et stable y compris lors de montées en charge.

Qu’est ce qu’un système réactif ?

Le concept de système réactif provient du Manifeste Réactif, un effort conjoint d'une communauté de développeurs ayant fait le constat que les plus grandes architectures informatiques du monde ont dû faire face aux mêmes problématiques et obéissent toutes aux contraintes citées précédemment.

L’objectif de ce manifeste n’est sûrement pas de pousser toutes les infrastructures à développer des services aussi résilients et disponibles que ceux de Google, mais de permettre la démocratisation de ces concepts et le développement des technologies associées afin de permettre une meilleure disponibilité des systèmes quelle que soit leur nature et leur taille.

Le manifeste réactif s’articule autour de 4 composantes clés :

• La disponibilité : c’est en quelque sorte l’objectif ultime recherché par tout  système, où un système répond rapidement en toutes circonstances. Les composantes suivantes découlent ensuite naturellement de celle-ci
• La résilience : le système reste disponible en cas d’erreur, car sans résilience aucune disponibilité ne peut être assurée
• La souplesse (ou élasticité) : le système peut faire face aux montées en charge en ajustant les ressources allouées (sur les gros services web cela peut signifier le déploiement de plusieurs instances par exemple). Souplesse et résilience sont également fortement intriquées, car un système ne peut évidement pas être considéré comme résilient ou disponible si il ne prévoit pas les montées en charge
• L’orientation messages : le système utilise des messages asynchrones pour passer les informations entre ses différents composants. Cette approche est fondamentale pour garantir la résilience en passant les erreurs par message, mais également la souplesse pour faire communiquer les composants entre eux. Cette approche est également à la base de la programmation réactive que  nous aborderons dans de futurs articles, et permet également une meilleure gestion de ressources au travers de concepts très intéressants comme la  contre-pression !

Cette approche marche bien pour les services web, mais qu’en est il des autres logiciels ?

Il est également à noter que bien que ce concept et ses composantes correspondent parfaitement aux besoin des services web, ils peuvent être également extrapolés à tous types de logiciels. Le manifeste réactif ne précise d’ailleurs à aucun moment se limiter aux services web, il s’agit ici d’un pur choix de ma part pour cet article et c’est pourquoi on parle de système réactif.

Dans le cas d’un autre type de logiciel les composantes d’un système réactif vont potentiellement avoir une signification et des implications légèrement différentes. Dans le cas d’un logiciel de bureau avec rendu graphique par exemple, la souplesse signifiera rarement la capacité à déployer de nouvelles instances en réseau comme avec les services web, mais plutôt la capacité à répartir efficacement la charge de travail sur les ressources de calcul de la machine tout en maintenant une boucle de rendu rapide et non bloquante.

C’est pourquoi l’approche réactive est pertinente pour tous types de logiciels.

Conclusion

Dans cet article nous avons découvert un concept logiciel visant à la conception de logiciels plus robustes, fluides et performants.

Bien que cet article ne soit qu’un mince aperçu de l’univers réactif, j’espère avoir su éveiller votre intérêt si vous ne connaissiez par le concept de système réactif. D'autres articles sont à venir pour approfondir le sujet :

• Une présentation de Vert.X, un exemple de librairie d'aide à la conception de systèmes réactifs
• Une introduction à la programmation réactive (à ne pas confondre avec les systèmes réactifs)
• Comment tester un système réactif

Malgré le nom un peu orienté de ce blog je souhaite également écrire des articles sur des sujets très divers, entre autres :

• Un projet open source de benchmark de bases de données dans le même esprit que TechEmpower, car je trouve incroyable en 2023 qu'il n'y ait pas de comparatif objectif des solutions existantes de bases de données
• Un article sur le path tracing et les solutions open source existantes pour développer des moteurs de lancer de rayon temps réel
• Une présentation du langage Rust, une alternative au C/C++ cherchant à résoudre plusieurs problématiques que ces langages bas niveau rencontrent tout en conservant des performances très élevées.

Merci pour votre lecture et à bientôt pour de futurs articles 😉

Références

• Le Manifeste Réactif