Le monde ne reste pas immobile. Le progrès crée de nouveaux défis technologiques. En fonction de l'évolution des besoins, l'architecture des systèmes d'information devrait également évoluer. Aujourd'hui, nous parlerons de l'architecture événementielle, de la compétitivité, de la concurrence, de l'asynchronie et de la façon de vivre en paix avec tout cela à Erlang.
Présentation
En fonction de la taille du système conçu et de ses exigences, nous, les développeurs, choisissons la méthode d'échange d'informations dans le système. Dans la plupart des cas, pour organiser l'interaction des services, une option de travail peut être un schéma avec un courtier, par exemple, basé sur RabbitMQ ou kafka. Mais parfois, le flux d'événements, le SLA et le niveau de contrôle sur le système sont tels que la messagerie prête à l'emploi ne nous convient pas. Bien sûr, vous pouvez compliquer un peu le système en prenant la responsabilité de la couche de transport et de la formation des grappes, par exemple en utilisant ZeroMQ ou nanomsg. Mais si le système a suffisamment de bande passante et les capacités d'un cluster Erlang standard, la question de l'introduction d'une entité supplémentaire nécessite une étude détaillée et une justification économique.
Le sujet des applications distribuées réactives est assez vaste. Pour rester dans le format de l'article, le sujet de la discussion d'aujourd'hui ne sera que des environnements homogènes construits sur la base d'Erlang / Elixir. L'écosystème Erlang / OTP permet une architecture réactive à faible coût. Mais dans tous les cas, nous avons besoin d'une couche de messagerie.
Base théorique
La conception commence par la définition des objectifs et des limites. L'objectif principal n'est pas le développement pour le développement. Nous devons obtenir un outil sûr et évolutif sur la base duquel nous pouvons créer et, surtout, développer des applications modernes de différents niveaux: de celles à serveur unique desservant un petit public, qui peuvent ensuite évoluer en grappes de 50 à 60 nœuds, se terminant par des fédérations de grappes. Ainsi, l'objectif principal est de maximiser les profits en réduisant les coûts de développement et de propriété du système final.
Il existe 4 exigences principales pour le système final:
- Avec une orientation quotidienne.
Le système est toujours prêt à passer à travers lui-même un flux d'événements et à effectuer les actions nécessaires; - Évolutivité.
Les blocs individuels peuvent être mis à l'échelle verticalement et horizontalement. L'ensemble du système devrait pouvoir croître horizontalement à l'infini; - À propos de la tolérance aux pannes.
Tous les niveaux et tous les services devraient pouvoir se remettre automatiquement des échecs; - Temps de réponse garanti.
Le temps est précieux et les utilisateurs ne devraient pas attendre trop longtemps.
Rappelez-vous le vieux conte de fées sur «Le petit moteur qui pourrait», alias «Le moteur qui pourrait»? Pour que le système conçu émerge avec succès de la phase de prototype et soit progressif, sa fondation doit répondre aux exigences minimales de SMOG .
Une autre chose est ajoutée à la messagerie en tant qu'outil d'infrastructure et base de tous les services: la convivialité pour les programmeurs.
Orientation événementielle
Pour qu'une application puisse passer d'un serveur unique à un cluster, son architecture doit fournir une connectivité faible. Le modèle asynchrone répond à cette exigence. Dans ce document, l'expéditeur et le destinataire prennent en charge la charge d'informations du message et ne se soucient pas de la transmission et du routage au sein du système.
Évolutivité
L'évolutivité et les performances du système se côtoient. Les composants d'application doivent pouvoir utiliser toutes les ressources disponibles. Plus nous pouvons utiliser les capacités efficacement et plus nos méthodes de traitement sont optimales, moins nous dépensons d’argent en équipement.
Erlang crée un environnement hautement compétitif au sein d'une seule machine. L'équilibre entre la concurrence et la concurrence peut être défini en sélectionnant le nombre de threads du système d'exploitation disponibles pour Erlang VM et le nombre de planificateurs utilisant ces threads.
Les processus Erlang n'ont pas d'état commun et fonctionnent en mode non bloquant. Cela fournit une latence relativement faible et une bande passante plus élevée que les applications traditionnelles basées sur le blocage de la synchronisation. L'ordonnanceur Erlang s'occupe de la distribution équitable du CPU et des E / S, et l'absence de verrous permet à l'application de répondre même en cas de charges de pointe ou de pannes.
Au niveau du cluster, un problème de recyclage existe également. Il est important que toutes les machines du cluster soient chargées uniformément et que le réseau ne soit pas surchargé. Imaginez une situation: le trafic des utilisateurs atterrit sur les équilibreurs entrants (haproxy, nginx, etc.), ils répartissent les requêtes de traitement aussi uniformément que possible entre l'ensemble des backends disponibles. Dans le cadre de l'infrastructure d'application, un service qui implémente l'interface requise n'est que le dernier kilomètre, et il devra demander un certain nombre d'autres services afin de 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, la messagerie doit fournir aux développeurs une interface pour contrôler le routage et l'équilibrage de charge. Grâce à cela, les développeurs seront en mesure, à l'aide de modèles de microservices (agrégateur, proxy, chaîne, branche, etc.), de résoudre à la fois des tâches standard et qui surviennent rarement.
D'un point de vue commercial, l'évolutivité est l'un des outils de gestion des risques. L'essentiel est de satisfaire les demandes des clients en utilisant de manière optimale les équipements:
- Avec une augmentation de la capacité des équipements suite aux progrès. Il ne sera pas inactif en raison d'imperfections logicielles. Erlang évolue parfaitement verticalement et peut toujours recycler tous les cœurs de processeur et la mémoire disponible;
- Dans les environnements nuageux, nous pouvons contrôler la quantité d'équipement en fonction de la charge actuelle ou prévue et garantir le SLA.
Tolérance aux pannes
Considérez deux axiomes: «Les échecs sont inacceptables» et «Les échecs le seront toujours». Pour les entreprises, la défaillance d'un logiciel est une perte d'argent et, pire, une réputation. En équilibrant les pertes potentielles et le coût de développement d'un logiciel tolérant aux pannes, vous pouvez souvent trouver un compromis.
A court terme, l'architecture à tolérance de panne permet d'économiser de l'argent sur l'achat de solutions de cluster clé en main. Ils sont chers et comportent également des erreurs.
À long terme, une architecture tolérante aux pannes paie à plusieurs reprises les coûts de son application à tous les stades de développement.
La messagerie à l'intérieur de la base de code au stade de la conception vous permet de définir en détail l'interaction des composants au sein du système. Cela simplifie la tâche de réponse et de gestion des pannes, car tous les composants critiques gèrent les pannes, et le système résultant sait comment revenir automatiquement à la normale après une panne par conception.
Réactivité
Indépendamment des échecs, l'application doit répondre aux demandes et satisfaire aux SLA. La réalité est que les gens ne veulent pas attendre, donc l'entreprise doit s'adapter. Plus d'applications devraient être très réactives.
Les applications réactives fonctionnent en mode proche du temps réel. Erlang VM fonctionne en mode temps réel doux. Pour certains domaines, tels que le commerce de change, la médecine, la gestion des équipements industriels, le mode dur en temps réel est important.
Les systèmes réactifs améliorent l'expérience utilisateur et aident les entreprises.
Résultat préliminaire
En planifiant cet article, j'ai voulu partager l'expérience de la création d'un courtier de messagerie et de la construction de systèmes complexes sur sa base. Mais la partie théorique et motivationnelle s'est avérée assez étendue.
Dans la deuxième partie de l'article, je parlerai des nuances de la mise en œuvre des points d'échange, des modèles de messagerie et de leur application.
Dans la troisième partie, nous examinons les problèmes généraux d'organisation, de routage et d'équilibrage des services. Parlons du côté pratique de l'évolutivité et de la tolérance aux pannes des systèmes.
La fin de la première partie.
Photo @lucabravo .