Il y a 3 semaines -

Temps de lecture 24 minutes

Lost in translation: architectures réactive

 

There are only two hard things in Computer Science: cache invalidation and naming things.

– Phil Karlton

Si je vous dis que le français est une langue riche, je ne vous apprends rien de nouveau. Pour un étranger comme moi, c’est un vrai cauchemar. Si on part de ce principe, pourquoi une «pomme de terre» s’appelle comme ça ? Il n’y avait pas un autre mot plus approprié et plus «classe» ? Bien nommer les choses est très compliqué. Parfois, c’est anodin; mais dans certains cas, mal nommer quelque chose peut porter à confusion et le monde de la technologie n’est pas une exception. Depuis quelque temps, le mot reactive a été profusément utilisé par la communauté car il est un mot qui est puissant et qui évoque «quelque chose de très avancé». Malheureusement, cet abus a provoqué, à mon avis, la perte de signification de ce mot.

Sauriez-vous expliquer ce qu’est une architecture réactive ? Quelle est la relation entre ces architectures et les APIs dites réactives comme RxJava ou Spring Reactor ? Ces deux questions méritent le détour afin de finir, une fois pour toutes, avec la confusion que ces deux concepts génèrent. Dans ce premier article, on abordera la première des questions.

 

En tant que développeurs, nous nous sommes habitués à la conception des applications CRUD. Cependant, dans certains contextes, ce genre d’applications n’est pas adapté au problème à résoudre. Mettons-nous en situation, nous devons monter une application pour une société de trading pour permettre aux traders d’acheter et de vendre des actions. Quelles sont les caractéristiques souhaitables pour notre système ? En voici quelques unes :

  • Accéder aux cotations d’une société et voir son évolution presque en temps réel pour pouvoir dénicher des bonnes affaires
  • Système disponible 24/7 tous les jours où les marchés boursiers sont ouverts
  • Lorsqu’un trader achète des actions, le système doit réaliser l’opération rapidement quelle que soit la charge
  • Supporter le plus d’utilisateurs concurrents possibles : plusieurs marchés boursiers, traders éparpillés dans différents pays, etc

Étant donné que ces problématiques sont communes à d’autres domaines, un nouveau type d’architecture a été créé pour répertorier les bonnes pratiques tirées des réussites et des échecs de ces applications. Ces architectures ont été baptisées architectures réactives pour le bonheur des commerciaux. Ce genre d’architecture est parmi nous depuis longtemps mais ce n’est qu’à partir de l’apparition de Netflix qu’elle est devenue mainstream.

Au-delà du buzzword, qu’y a-t-il derrière ce genre d’architectures ? Pourquoi en parle-t-on aujourd’hui de plus en plus alors que les bases existent depuis longtemps ? Quels sont les outils dont nous avons besoin pour mettre en place une architecture réactive ? Dans cet article, nous allons discuter de la manière dont Internet a permis aux architectures réactives de devenir à la mode pour ensuite parler des caractéristiques de ce genre d’architecture.

Internet has changed everything

Il était une fois, un monde où on se connectait à Internet avec un modem 56k. Où il fallait attendre quelques heures pour télécharger un fichier MP3 de plusieurs Mo. À cette époque-là, Internet était un outil réservé aux plus enthousiastes, les jeunes et les plus geeks. Heureusement, ces temps sont bien derrière nous. L’utilisation d’Internet s’est démocratisée et la bande passante des connexions disponibles au grand public a augmenté considérablement. À ceci, il faut ajouter l’apparition des appareils connectés constamment à Internet comme les smartphones, les wearables et les objets connectés (IoT). Actuellement, nous vivons au sein d’une société hyper-connectée, bien au-delà des rêves les plus fous.

We had dreams about the impact it could have. We talked about a computer on every desk and in every home. It’s been amazing to see so much of that dream become a reality and touch so many lives. I never imagined what an incredible and important company would spring from those original ideas

– Bill Gates

On peut dire qu’Internet a eu un effet disruptif sur la société, et ceci a eu des impacts dans la façon dont on conçoit des applications.

Les utilisateurs: au centre de tout

Depuis l’apparition des smartphones, nous nous sommes habitués, en tant qu’utilisateurs, à avoir un accès immédiat à beaucoup de services en ligne. Poser des questions à un assistant virtuel, consulter la météo du jour ou lire le journal sont des actions quotidiennes que nous faisons avec assiduité. Cette facilité d’accès à l’information a fait évoluer les attentes des utilisateurs. Nous voulons tout et tout de suite.

Mettons-nous en situation, supposons que nous voulons consulter la météo du jour avant de sortir de chez nous pour aller au travail. Que se passe-t-il si la page met plus de 5 secondes à charger ?

  1. Déni : Qu’est-ce que se passe ?
  2. Rage : C’est quoi cette ….
  3. Négociation: Allez, charge s’il te plaît ! Je dois partir au boulot !
  4. Dépression: Ce n’est pas possibleeee !
  5. Acceptation: J’irai voir ailleurs

Ce petit exercice met en évidence une chose: l’attente irrite les utilisateurs. Pourquoi? Parce qu’ils sont habitués à la satisfaction immédiate. Nous voulons l’information dont nous avons besoin tout de suite.

Ceci est spécialement pertinent dans le cadre actuel. Les services en ligne utilisent comme principale source de revenus les informations qu’ils détiennent sur leurs utilisateurs. Une personne qui décide de ne plus utiliser notre service à cause des lenteurs, c’est une personne qui ne fera plus rentrer d’argent. C’est pour cela qu’il faut faire spécialement attention à l’expérience utilisateur : interface agréable, temps de réponse rapide, service client à l’écoute, uptime etc.

Nouveaux types d’applications

Les connexions à Internet dont nous disposons sont assez puissantes pour permettre des applications dont nous ne pouvions pas rêver il y a quelques années. Voici quelques exemples:

  • Stockage sur le cloud: Dropbox, iCloud, Google Drive
  • Réseaux sociaux: Facebook, Twitter
  • VOD: Netflix, Amazon Prime Video
  • Streaming d’audio: Spotify, Apple Music
  • Vidéosurveillance: Nest
  • SAAS: Microsoft Office 365, Adobe Creative Cloud

Malgré leurs différences, ces services ont quelques similitudes:

  • Ubiquité: Tous ces services sont disponibles sur plusieurs supports. À savoir: applications natives, PWA, applications mobiles (iOS/Android) et même sur les box Internet.
  • Ce sont des services orientés flux de données au lieu de ressources.
Ceci implique plusieurs choses:
  • L’ubiquité, pour les utilisateurs, c’est un atout. Néanmoins, du point de vue des architectes logiciel, ceci peut être un vrai cauchemar car le nombre potentiel d’utilisateurs concurrent augmente considérablement
  • Étant donné que l’on travaille avec des flux de données, le modèle CRUD ne s’adapte pas bien aux besoins de ces applications

Prenons l’exemple de Netflix. Quels sont les principaux défis techniques que les ingénieurs de Netflix ont dû relever pour devenir le standard de facto des services VOD à l’échelle mondiale ?

  • Support pour différentes plateformes: smart TV, smartphones, navigateur web, vidéo consoles, etc.
  • Service disponible sur 190 pays et sur tous les continents
  • Service nécessitant beaucoup de ressources : stream de vidéo 4K HDR
  • Très haute disponibilité. Les pannes du service font des trending topics sur Twitter
  • Des milliers d’utilisateurs concurrents

Comme vous pouvez le constater, ceci est un défi de taille. Comment peut-on concevoir un système de ce genre ? Une des réponses possibles sont les architectures réactives. Mais, qu’est-ce qu’une architecture réactive ?

Architectures réactives in a nutshell

réactif, ive adj.
Qui exerce une réaction, répond à une action, à un évènement. Une gestion réactive.

Les principes de la programmation réactive ont été présentés dans The Reactive Manifesto en 2013. Les principes de toute application réactive sont:

Disponible

disponible adj.

adjectif

1 Dont on peut disposer. Il y a des billets disponibles pour Le Bourgeois gentilhomme.

Comme nous l’avons vu dans l’introduction de cet article, l’expérience utilisateur est devenue fondamentale dans le modèle économique des sociétés. Tous ces gens qui ont grandi au sein d’Internet ont vécu l’évolution des services qui ont surgi. Cette expérience a permis une éducation massive des utilisateurs en leur montrant ce qu’est un bon service. Et ils ont appris la leçon. En fin de compte, on s’habitue très rapidement aux bonnes choses et c’est très difficile de revenir en arrière. C’est pour cela que l’expérience utilisateur globale joue un rôle capital dans le cadre de la fidélisation client. Les applications sont devenues la vitrine de l’entreprise. C’est pour cela que le service doit répondre rapidement en toute circonstance. Mais comment faire lorsque notre service doit gérer des milliers d’utilisateurs en parallèle ? Quelles sont les solutions que nous pouvons appliquer pour améliorer la scalabilité de notre application ?

Scalabilité

Comme nous avons discuté dans la section précédente, le principal problème des applications de grande taille est la scalabilité. Quelles sont les options lorsque l’on veut augmenter la bande passante de nos applications ? Nous disposons de deux manières de faire « scaler » notre application. Ces solutions présentent chacune des avantages et des inconvénients:

Scalabilité horizontale

On déploie notre application sur plusieurs machines et on route les requêtes sur les machines disponibles.
Cette approche est très utilisée depuis la popularisation des solutions cloud comme
Amazon Web Services (AWS) ou
Google Cloud Plateform (
GCP). On peut dire que ces plateformes ont révolutionné la façon dont on conçoit et on déploie des applications:

  • On peut imaginer des architectures très complexes à partir de services proposés par ces fournisseurs: stockage distribué, load balancers, DNS, bases des données et même ML. Tout est disponible et prêt à l’emploi et on peut adapter notre infrastructure à la volée pour s’adapter aux pics de charge du système
  • Les clients de ces plateformes peuvent déployer leurs applications rapidement et au moindre coût. Le coût total dépend des ressources consommées par notre application. Cet aspect est spécialement intéressant dès l’optique des PME car, dans la plupart de cas, elles ne peuvent pas s’accorder une équipe IT à l’ancienne
  • On peut déployer notre infrastructure sur des data centers situés dans des régions différentes afin de garantir le services à nos utilisateurs en toute circonstance
  • Ces plateformes permettent des approches intéressantes comme, par exemple, infrastructure-as-code (IaC)

En ce qui concerne le dernier point, mon collègue Alexis Chotard a écrit un dossier à ce sujet pour le magazine Développez. Vous pouvez le lire sur le lien suivant.

Bien entendu, si on est soucieux de la confidentialité des données à traiter, il est possible d’héberger on-premise un service similaire. Néanmoins, il faudrait investir de l’argent pour trouver les gens avec ayant compétences requises. Dans ce slot de la Xebicon 2017, vous trouverez plus d’information de comment répliquer une partie des services AWS sur votre data center.

Scalabilité verticale

La scalabilité verticale consiste à déployer notre application sur une machine plus puissance afin de profiter des évolutions au niveau matériel. Autrement dit, plus la machine est puissante, plus rapidement répondra notre service. Depuis la naissance des microprocesseurs, la technologie d’intégration a évolué à grands pas. Ceci a permis d’avoir des processeurs plus puissants et moins gourmands d’énergie. Cette évolution est encadrée par la
loi de Moore:

La capacité d’intégration des processeurs est doublée tous les 18 mois

Gordon E. Moore (cofondateur d’Intel)

Depuis quelques années, les constructeurs ont simplement ajouté des coeurs dans les processeurs afin de tenir la prédiction de Moore. Cette augmentation de cœurs disponibles dans les processeurs ne permet plus d’appliquer les modèles de calculs mono-thread. La seule option est de paralléliser notre code. Pour bien connaître les gains de performance théoriques que l’on peut obtenir en parallélisant notre application, il faut se rappeler de la fameuse loi d’Amdahl:

 

p s
Pourcentage des tâches parallélisables  Ressources du système: cœurs, processeurs, etc.

 

Qu’est-ce qui se cache derrière cette équation ? Tout simplement l’amélioration maximale que l’on peut avoir lorsque l’on parallélise du code. Cette loi détermine que le gain de performance maximum que nous pouvons obtenir est limité par le code qui ne peut pas être parallélisé. Ce code s’appelle code série et il est défini par l’expression (1-p).

Une fois que nous avons déterminé que nous devrions paralléliser notre application, il faut trouver les bons outils pour ce faire. Quelles sont les alternatives que nous disposons ? On en parlera plus tard lorsque l’on abordera les frameworks réactifs.

Résilient

résilient adj.

adjectif

1 physique Qui offre une grande résistance aux chocs. Des matériaux résilients.

2 psychologie Qui peut surmonter des épreuves, un stress intense et se ressaisir malgré les difficultés. Des enfants résilients.

 

Avez-vous pensé au nombre de choses qui peuvent mal se passer lorsque vous cliquez sur un bouton ? Il se peut qu’un routeur intermédiaire tombe en panne ou qu’un disque dur d’une des machines prenne feu. Au fur et à mesure que les infrastructures deviennent plus complexes, la probabilité que quelque chose se passe mal augmente. Est-ce que ça ne serait pas génial de pouvoir concevoir un système qui tolère les pannes de ses composants ? Les architectures réactives proposent, contrairement aux autres types d’architectures, que les erreurs du système deviennent des « first-class citizen » de notre application.

Anything that can possibly go wrong, does

Loi de Murphy

Voici une liste non-exhaustive de choses qui peuvent mal se passer dans le cadre d’une application:

Problème hardware Problème de ressources Evénements
Ordinateurs
Mémoire
Disque dur
Réseau
Routeurs
Câbles
Mémoire
Processeur surchargé
Stockage
Congestion
Problèmes de configuration
Hackers
Bugs

Cette culture de tolérance aux pannes a été poussée jusqu’au paroxysme par quelques sociétés jusqu’au point de créer des librairies permettant de faire tomber des parties de l’infra d’une manière aléatoire en production. Ce concept vous intrigue ? Vous pouvez avoir plus d’information sur la page du Chaos Monkey sur Wikipedia ou sur le site officiel.

Lorsque l’on a affaire à une application distribuée, il faut être conscient que notre application sera distribuée sur plusieurs machines et, par conséquent, la possibilité que quelque chose se passe mal augmente. Cependant, il existe un nombre réduit de patterns architecturaux qui permettent d’assurer l’architecture d’une application en évitant qu’elle tombe lorsqu’une erreur se produit.

En voici quelques uns:

Timeouts

Les timeouts sont très simples à mettre en place, mais il faut bien le faire. Quand peut-on considérer qu’un service est hors service ? Pourquoi ?

  • Si on fixe des timeouts trop courts, on considérera des appels comme erronés à tort. Le service appelé est un peu surchargé et il met un peu de temps à répondre (ressources consommées pour rien)
  • Si on fixe des timeouts trop longs, notre système sera plus lent pour détecter les services qui sont tombés.
  • Si on ne fixe pas de timeouts, notre système se bloquera lorsqu’un service ne sera plus disponible

Il s’agit d’une bonne pratique de mettre en place de timeouts pour tous les appels vers un service. On peut partir sur un timeout par défaut pour tous les appels et au fur et à mesure que les timeouts se produisent, modifier les timeouts pour chaque appel en conséquence.

Circuit breakers

La mise en place des timeouts est un bon début mais ce n’est pas suffisant pour créer une architecture tolérante à la panne. Supposons que l’un des services externes plante. À partir de ce moment-là, tous les appels vers le service tomberont en timeout. Cette situation est doublement pénalisante:

  1. Le service en question ne fonctionne pas
  2. Cette panne va diminuer la bande passante globale du système. Les clients vont alors appeler bêtement le service en panne, provoquant le timeout associé

Le pattern Circuit Breaker permet d’utiliser plus intelligemment les informations relevées des timeouts.

  1. Lorsqu’un service répond avec un timeout plusieurs fois d’affilée, le système marque le service comme down
  2. Donéravant, tous les appels vers ce service seront marques comme erronées. Pas besoin donc de bloquer en attendant la réponse du service. Ceci est une stratégie nommée fail-fast
  3. De temps en temps, le système vérifie si le service est revenu
  4. Si c’est le cas, on marque le service comme up permettant aux clients de faire des appels à nouveau vers le service

Avant de mettre en place ce pattern, il faut se poser quelques questions:

  • Comment considère-t-on qu’un service est down ? Timeout ? Erreurs 5XX ?
  • Quelle est la limite de requêtes erronées que l’on établit pour marquer un service comme down?

Bulkheads

Cette idée a été adoptée des chantiers navals. Lors de la construction d’un navire, on ajoute des sections inondables. Dans le cas où l’eau rentre dans le bateau suite à une perforation de la coque, l’eau inonde la section affectée mais pas les autres, ce qui pourrait mettre en péril la vie des personnes à bord. Voici un exemple de Bulkhead:

Lorsque l’on parle des bulkheads, on tombe souvent sur l’anecdote du Titanic. Le fameux bateau a coulé car les bulkheads dont il disposait n’étaient pas complètement isolés les uns des autres. C’est la raison pour laquelle Jack est mort. En vrai, Jack aurait pu tenir sur la planche car il y avait assez de place… mais ça c’est une autre histoire.

Revenons à nos moutons, comment peut-on appliquer ce principe d’ingénierie navale aux architectures réactives ? Voici quelques exemples:

  • Utilisation de plusieurs instances du même service derrière un load balancer. L’indisponibilité d’un service n’impacte pas le système et est transparente aux utilisateurs
  • Partitioner les services par rapport au QoS. Dans certains domaines, il y a des utilisateurs plus importants que d’autres
  • Ne pas mutualiser les composants. Par exemple, dans une architecture microservices, utiliser une base de données partagée. Dans ce cas de figure, la base de données devient un SPOF difficile à contourner

Souple

souple adj.

adjectif

1 Agile, flexible. Cette contorsionniste est extraordinairement souple.

2 figuré Qui peut s’adapter facilement à une situation.

 

Depuis quelques années, les applications ont changé. Avant les applications étaient mono-thread et elles étaient lancées sur une seule machine, ce qui permettait d’utiliser une approche de scalabilité verticale : machine plus puissante, plus de performance. Ceci était lié au prix exorbitant du hardware. Aujourd’hui, c’est une autre histoire. Le hardware s’est démocratisé et il est devenu ce que l’on appelle une commodity et il est normal (et conseillé) de déployer des applications sur plusieurs machines.

Imaginons une application de vente sur Internet. Cette application aura une charge normale sauf pour quelques périodes dans l’année: Vacances, Noël, Black Friday, etc. Pensez-vous qu’acheter une quantité astronomique de hardware pour que le système tienne la charge durant ces périodes est une bonne affaire ? La réponse est clairement, NON. Même si le prix du hardware a chuté énormément, il s’agit d’une dépense non négligeable pour des machines qui ne seront pas utilisées la plupart de temps.

Mais alors, quelle est la solution ? La solution est de scaler dynamiquement les ressources allouées pour les applications selon leur charge. Ceci est très facile à dire mais, comment peut-on implémenter ceci ? Voici quelques pistes:

  • Opérations non-bloquantes: Ceci est commun à toutes les situations dans la vie où l’on doit attendre la réponse d’un tiers pour continuer notre travail. Si on bloque pour la réponse d’un service externe, on diminuera le débit de notre application.
  • Composants faiblement couplés: Si on construit notre application à partir de composants faiblement couplés, on pourrait adapter leur nombre au besoin.
  • Location transparency: Lié au point précédent, vu le dynamisme souhaité, on ne peut pas avoir des préjugés par rapport à l’emplacement de chaque composant. Si on a la transparence de localisation, on peut « spawner » (déployer) des nouvelles instances d’un service sans faire aucune modification sur la configuration des autres composants.
  • Penser en pipes-and-filters: Il faut concevoir le traitement global de la donnée comme un enchaînement de transformations de la donnée brute vers la donnée souhaitée. Ce découpage permet de mieux tester chaque transformation ainsi que permet une meilleure réutilisation (plus d’information sur la section suivante)
  • Métrologie: Lorsque l’on a affaire à un système distribué, c’est très important d’avoir des métriques des composants afin de trouver rapidement les dysfonctionnements du système. En plus, l’historisation de ces métriques peut nous permettre d’affiner le paramétrage de chaque composant afin d’augmenter le débit de notre système

Arrivés à ce point, mon cher lecteur, ma chère lectrice, je suppose qu’une question survole votre tête: si notre système est composé de blocs indépendants pour tolérer la panne, comment peuvent-ils communiquer entre eux ? Plus d’info sur le point suivant.

Orienté messages

Pas de définition de dictionnaire. Désolé

Vous êtes toujours là ? Si c’est le cas, je pense que vous vous êtes rendu compte que l’une des caractéristiques fondamentales des architectures réactives est l’isolation des composants. Ceci étant dit, une question s’impose. Comment ces composants peuvent-ils se coordonner? La réponse est de déléguer à un broker de messages. Quelles sont les principales responsabilités de cet élément ? Allons les découvrir.

Allons parler ensemble!

Dans la section précédente, nous avons parlé légèrement des architectures pipes-and-filters. Ce genre de systèmes sont composés de deux types d’éléments:

  • Pipes: Canaux de communication permettant l’envoi des données
  • Messages: Données à transmettre. Chaque message est immuable et il contient un header et un body
  • Filters: Composants permettant de transformer les données reçues dans leur canal d’entrée et de transmettre la donnée transformée vers le canal de sortie

Voici un example d’architecture pipes-and-filters

Bien que la définition académique de cette architecture indique qu’un filter doit avoir un seul canal d’entrée et un canal de sortie, dans la vie réelle on a décidé d’ignorer cette caractéristique. Cet oubli nous permet de définir deux modes de communication différents:

Point-to-point (one-to-one)

Un filter envoie le message et il est réceptionné par un autre filter

 

Publish-subscribe (one-to-many)

Un publisher émet un message qui est capturé par un ou plusieurs subscribers qui vont traiter le message

Avec ces bases, on peut construire des systèmes bien plus complexes à l’aide des
EIP (Enterprise Integration Patterns). Vous pouvez trouver plus d’information à ce sujet sur le livre
« Entreprise Intégration Patterns: Designing, Building and Deploying Messaging Solutions ».

On ne peut pas aller plus rapide que la musique

Comme l’on a dit précédemment, notre système doit se composer de deux types de composants, les pipes et les filters.

  • Les pipes permettent la communication entre deux ou plusieurs filters
  • Les filters transforment la donnée et passent le résultat aux filters suivants via des pipes

Lorsque l’on a affaire à un système distribué, on doit être conscient que tous les traitements ne prennent pas le même temps. Par exemple, si un filtrer nécessite de faire un appel vers un web service tierce qui n’est pas très rapide, le traitement d’un message sera plus lent que celui d’un autre filtre qui doit faire une requête SQL sur un serveur de l’organisation. Ceci peut déboucher sur un goulot d’étranglement qui va ralentir tout le système car le throughput d’un système est toujours limité par le throughput du composant le plus lent. C’est pour cela qu’un système de buffering s’impose, permettant aux filtres plus rapides de continuer à travailler pendant que les filtres les plus lents peuvent traiter leur travail au fur et à mesure. Cette mesure est nommée back-pressure.

Avantages et inconvénients des systèmes message-driven

Comme vous pouvez constater, ce pattern architectural nécessite de changer radicalement la façon dont on traite les donnée. On passe d’une grande
boîte noire (aka monolithe) qui reçoit des entrées et produit des sorties vers une architecture où la donnée est transformée, enrichie en étapes successives. En effet, vous venez de découvrir le principe qui a permis à Henry Ford de concevoir la première chaîne d’assemblage de voitures au début du XX siècle.

Revenons au présent. Quels sont les avantages de ces systèmes? Les voici:

  • Separation of concerns: Cette architecture nous oblige à bien séparer les comportements en filtres différents. Cela a des impacts bénéfiques sur pas mal d’aspects:
    • Asynchones par défaut: Ceci nous permet d’éviter la congestion générale du système lorsque l’un des composants est ralenti par un événement indésirable
    • Testabilité: Les filters deviennent plus petits et, par conséquent, plus facilement testables
    • Résutilisation: Si on crée des filtres génériques, on peut les réutiliser
    • Souplesse: Composer notre chaîne de traitement à partir de petites briques réutilisables nous donne une grande souplesse lors de l’évolution de notre système
  • Isolement: Les filters peuvent évoluer indépendamment des autres et ils peuvent utiliser une stack technique plus adaptée à la fonction qu’ils réalisent.
  • Paraléllisation: Si un traitement est lourd, on peut ajouter plus d’instances du filter en question pour augmenter les troughput du système
  • Intégration avec des systèmes externes:Dans le monde des bisounours, notre système est indépendant du monde, cependant, ce n’est pas la réalité. Dans la plupart de cas, notre système doit interagir avec des autres systèmes legacy. L’utilisation de cette architecture permet d’isoler cette intégration dans un filter.

Bien entendu, rien n’est gratuit. Voici quelques points d’attention:

  • Overhead dû aux messages: Les filtres doivent sérialiser les messages en sortie et desérialiser ceux en entrée.
  • Channel: Les channels embarquent plusieurs services comme, par exemple, le buffering de messages. Ceci est une caractéristique très intéressante car elle permet d’intégrer des filtres rapides et des filtres lents. Néanmoins, cette caractéristique n’est pas gratuite au niveau de ressources consommées.
  • Complexité: Par défaut, un système distribué est beaucoup plus complexe qu’un système centralisé.

TL;DR

  • Les architectures réactives sont des architectures adaptées pour le traitement des flux de données. Inutile de mettre en place une architecture de ce genre pour une application CRUD classique
  • Ce sont des architectures distribuées, donc la possibilité que quelque chose se passe mal augmente. La loi de Murphy dans toute sa grandeur, quoi!
  • Vu leur complexité, LE MONITORING EST OBLIGATOIRE. #pasdarchitecturesreactivessansmonitoring
  • L’idée fondamentale des architectures réactives est le découpage de la logique métier en blocs indépendants. Ces blocs doivent pouvoir être déployés indépendamment. Par conséquent, il faut travailler le déploiement automatique: You build it, you run it
  • Selon le contexte, plusieurs versions d’un composant doivent pouvoir cohabiter. Pour faire ceci, on peut s’appuyer sur le principe de robustesse

    Be conservative in what you send, be liberal in what you accept
    Loi de Postel

  • Étudier les alternatives concernant le broker de messages. Kafka est très en vogue en ce moment, mais il y a d’autres solutions comme par exemple RabbitMQ

 

Commentaire

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.