Le monde ne reste pas immobile. Le progrès crée de nouveaux défis technologiques. Les architectures des systèmes d'information doivent évoluer en fonction des exigences changeantes. Aujourd'hui, nous allons parler de l'architecture orientée événements, de la concurrence, de la parallélisation, de l'asynchronisme et de la façon dont on peut vivre sereinement avec tout cela en Erlang.
Introduction
En fonction de la taille du système à concevoir et de ses exigences, nous, les développeurs, choisissons le mode de communication au sein du système. Dans la plupart des cas, pour organiser l'interaction des services, une architecture avec un broker, par exemple basé sur RabbitMQ ou Kafka, peut suffire. Mais parfois, le flux d'événements, le SLA et le niveau de contrôle sur le système sont tels qu'un messaging prêt à l'emploi ne nous convient pas. Bien sûr, on peut compliquer un peu le système en prenant la responsabilité du niveau de transport et de la formation d'un cluster, par exemple en utilisant ZeroMQ ou nanomsg. Mais si le système a suffisamment de bande passante et de capacités avec un cluster Erlang standard, la question d'introduire une entité supplémentaire nécessite une étude détaillée et une justification économique.
Le sujet des applications réactives distribuées est assez vaste. Pour respecter le format de l'article, nous allons nous concentrer aujourd'hui uniquement sur les environnements homogènes basés sur Erlang/Elixir. L'écosystème Erlang/OTP permet de mettre en œuvre une architecture réactive avec un minimum d'efforts. Mais dans tous les cas, nous aurons besoin d'une couche d'échange de messages.
Fondements théoriques
La conception commence par la définition des objectifs et des contraintes. L'objectif principal ne réside pas dans le développement pour le développement. Nous avons besoin d'un outil sécurisé et évolutif sur lequel nous pouvons construire, mais surtout – développer des applications modernes de différents niveaux : allant de serveurs individuels, servant un petit public, qui peuvent évoluer ensuite en clusters de 50 à 60 nœuds, jusqu'aux fédérations de clusters. Ainsi, l'objectif principal est la maximisation des profits en réduisant le coût de développement et de possession du système final.
Détaillons les 4 exigences principales pour le système final :
- Avecorientation événementielle.
Le système est toujours prêt à faire passer le flux d'événements et à réaliser les actions nécessaires ; - Mextensibilité.
Les blocs individuels peuvent être évolutifs à la fois verticalement et horizontalement. L'ensemble du système doit être capable de croître horizontalement de manière infinie; - Otolérance aux pannes.
Tous les niveaux et tous les services doivent pouvoir se rétablir automatiquement en cas de défaillance; - Garantir un temps de réponse.
Le temps est précieux et les utilisateurs ne devraient pas avoir à attendre trop longtemps.
Rappelez-vous l'ancienne histoire de "The little engine that could", aussi connue sous le nom de "Le petit train qui pouvait" ? Pour qu'un système en cours de conception réussisse à sortir de la phase de prototypage et soit progressif, sa fondation doit répondre à des exigences minimales. A PU.
À la messagerie comme un outil d'infrastructure et une base pour tous les services, un autre point vient s'ajouter : la convivialité pour les programmeurs.
Orientation événementielle.
Pour qu'une application puisse évoluer d'une petite instance de serveurs à un cluster, son architecture doit assurer un faible couplage. Cette exigence est satisfaite par un modèle asynchrone. Dans ce modèle, l'expéditeur et le récepteur s'occupent de la charge d'information du message sans se soucier de la transmission et du routage au sein du système.
Scalabilité
L'évolutivité et l'efficacité du système vont de pair. Les composants de l'application doivent être capables d'exploiter toutes les ressources disponibles. Plus nous pouvons utiliser efficacement les capacités et plus nos méthodes de traitement sont optimales, moins nous dépensons d'argent en matériel.
Dans le cadre d'une seule machine, Erlang crée un environnement hautement concurrentiel. L'équilibre entre concurrence et parallélisme peut être ajusté en choisissant le nombre de threads du système d'exploitation disponibles pour l'Erlang VM ainsi que le nombre de planificateurs utilisant ces threads.
Les processus Erlang n'ont pas d'état partagé et fonctionnent en mode non-bloquant. Cela permet une latence relativement basse et une bande passante plus élevée que celle des applications traditionnelles basées sur la synchronisation bloquante. Le planificateur d'Erlang veille à une distribution équitable du CPU et de l'IO, et l'absence de verrous permet à l'application de répondre même en période de forte charge ou de défaillances.
Au niveau du cluster, un problème d'utilisation existe également. Il est important que toutes les machines du cluster soient chargées de manière uniforme et que le réseau ne soit pas saturé. Imaginons une situation : le trafic utilisateur arrive sur les équilibreurs de charge entrants (haproxy, nginx, etc.), qui répartissent les demandes le plus uniformément possible entre l'ensemble des backends disponibles. Dans l'infrastructure de l'application, le service qui réalise l'interface requise n'est que le dernier maillon ; il devra interroger plusieurs autres services pour répondre à la demande initiale. Les requêtes internes nécessitent également un routage et un équilibrage.
Pour gérer efficacement les flux de données, le messaging doit fournir aux développeurs une interface pour gérer le routage et la répartition de la charge. Grâce à cela, les développeurs pourront résoudre à la fois des tâches standard et des cas plus rares en utilisant des modèles de microservices (agrégateur, proxy, chaîne, branche, etc.).
D'un point de vue commercial, la scalabilité est un outil de gestion des risques. L'essentiel est de satisfaire les demandes des clients tout en utilisant les équipements de manière optimale :
- Avec l'augmentation des capacités des équipements grâce aux avancées technologiques. Ils ne doivent pas rester inactifs en raison des imperfections du logiciel. Erlang se met très bien à l'échelle verticalement et pourra toujours tirer parti de tous les cœurs de CPU et de la mémoire disponible ;
- Dans des environnements cloud, nous pouvons gérer le nombre d'équipements en fonction de la charge actuelle ou prévue et garantir le SLA.
Résilience
Considérons deux axiomes : 'Les pannes sont inacceptables' et 'Les pannes arriveront toujours'. Pour les affaires, une panne logicielle signifie une perte d'argent, et ce qui est pire, une perte de réputation. En équilibrant les pertes potentielles et le coût de développement d'un logiciel tolérant aux pannes, on peut souvent trouver un compromis.
À court terme, une architecture intégrant la tolérance aux pannes permet d'économiser de l'argent sur l'achat de solutions de clustering prêtes à l'emploi. Elles sont coûteuses et comportent également des erreurs.
À long terme, une architecture tolérante aux pannes rembourse largement les coûts associés à son application à toutes les étapes du développement.
La messagerie au sein de la base de code étant encore en phase de développement, permet de travailler en détail sur l'interaction des composants au sein du système. Cela simplifie la tâche de réaction et de gestion des pannes, car tous les composants responsables traitent les défaillances, et le système final sait comment revenir automatiquement à un état normal après une panne par conception.
Réactivité
Indépendamment des pannes, l'application doit répondre aux demandes et satisfaire les SLA. La réalité est que les gens ne veulent pas attendre, donc l'entreprise doit s'adapter. De plus en plus d'applications sont attendues avec une haute réactivité.
Les applications réactives fonctionnent en mode proche du temps réel. L'Erlang VM fonctionne en mode temps réel doux. Pour certains domaines, tels que le trading boursier, la médecine et la gestion d'équipements industriels, le mode temps réel strict est essentiel.
Les systèmes réactifs améliorent l'expérience utilisateur (UX) et sont bénéfiques pour les entreprises.
Bilan préliminaire
En planifiant cet article, je voulais partager mon expérience de création d'un courtier de messages et de construction de systèmes complexes sur cette base. Cependant, la partie théorique et motivante s'est avérée assez vaste.
Dans la deuxième partie de l'article, je parlerai des nuances de mise en œuvre des points d'échange, des modèles d'échange de messages et de leur application.
Dans la troisième partie, nous examinerons les questions générales d'organisation des services, de routage et d'équilibrage. Nous aborderons le côté pratique de l'évolutivité et de la résilience des systèmes.
Fin de la première partie.
Photo .
Source : habr.com
