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 doit évoluer. Aujourd'hui, nous parlerons de l'architecture événementielle, de la concurrence, de la concurrence, de l'asynchronie et de la façon dont vous pouvez vivre en paix avec tout cela à Erlang.
introduction
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 système avec un courtier, par exemple basé sur RabbitMQ ou Kafka. Mais parfois, le flux des événements, les SLA et le niveau de contrôle sur le système sont tels que les messages prêts à l'emploi ne nous conviennent pas. Bien sûr, vous pouvez compliquer un peu le système en assumant la responsabilité de la couche de transport et de la formation du cluster, par exemple en utilisant ZeroMQ ou nanomsg. Mais si le système dispose d'un débit et de capacités suffisants pour 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 sera uniquement les environnements homogènes construits sur Erlang/Elixir. L'écosystème Erlang/OTP vous permet de mettre en œuvre une architecture réactive avec le moins d'effort possible. Mais dans tous les cas, nous aurons besoin d’une couche de messagerie.
Base théorique
La conception commence par la définition des objectifs et des contraintes. L’objectif principal n’est pas dans le domaine du développement pour le développement. Nous avons besoin d'un outil sécurisé et évolutif sur la base duquel nous pouvons créer et, surtout, développer des applications modernes à différents niveaux : à partir d'applications mono-serveur au service d'un petit public, qui peuvent ensuite se développer en clusters allant jusqu'à 50 -60 nœuds, se terminant par des fédérations de clusters. 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.
Soulignons 4 exigences principales pour le système final :
- Сorienté événement.
Le système est toujours prêt à suivre le flux des événements et à effectuer les actions nécessaires ; - Мévolutivité.
Les blocs individuels peuvent être mis à l'échelle verticalement et horizontalement. Le système dans son ensemble doit être capable d’une croissance horizontale infinie ; - Оtolérance aux pannes.
Tous les niveaux et tous les services devraient pouvoir se remettre automatiquement des pannes ; - Гtemps de réponse garanti.
Le temps est précieux et les utilisateurs ne devraient pas attendre trop longtemps.
Vous vous souvenez du vieux conte de fées sur « Le petit moteur qui pouvait » ? Pour que le système conçu puisse sortir avec succès du stade du prototype et être progressif, sa base doit répondre aux exigences minimales. SMOG.
Un point supplémentaire est ajouté à la messagerie en tant qu'outil d'infrastructure et base de tous les services : la facilité d'utilisation pour les programmeurs.
Orienté événementiel
Pour qu'une application passe d'un serveur unique à un cluster, son architecture doit prendre en charge le couplage lâche. Le modèle asynchrone répond à cette exigence. Dans ce document, l'expéditeur et le destinataire se soucient de 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 l’efficacité du système sont côte à côte. Les composants d'application doivent être capables d'utiliser toutes les ressources disponibles. Plus nous pouvons utiliser efficacement nos capacités et plus nos méthodes de traitement sont optimales, moins nous dépensons d’argent en équipement.
Au sein d'une seule machine, Erlang crée un environnement hautement compétitif. L'équilibre entre la concurrence et le parallélisme peut être défini en choisissant le nombre de threads du système d'exploitation disponibles pour la VM Erlang et le nombre de planificateurs qui utilisent ces threads.
Les processus Erlang ne partagent pas d'état et fonctionnent en mode non bloquant. Cela offre une latence relativement faible et un débit plus élevé que les applications traditionnelles basées sur le blocage. Le planificateur d'Erlang garantit une allocation équitable du processeur et des E/S, et l'absence de blocage permet à l'application de répondre même en cas de pic de charge ou de panne.
Au niveau du cluster, le problème de l'élimination existe également. Il est important que toutes les machines du cluster soient chargées de manière égale et que le réseau ne soit pas surchargé. Imaginons une situation : le trafic utilisateur atterrit sur les équilibreurs entrants (haproxy, nginx, etc.), ils répartissent les demandes de traitement aussi uniformément que possible entre l'ensemble des backends disponibles. Au sein de l'infrastructure applicative, le service implémentant l'interface requise ne représente que le dernier kilomètre et devra solliciter un certain nombre d'autres services pour répondre à la demande initiale. Les demandes 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 permettant de gérer le routage et l'équilibrage de charge. Grâce à cela, les développeurs pourront, à l'aide de modèles de microservices (agrégateur, proxy, chaîne, branche, etc.), résoudre aussi bien des problèmes standards que ceux qui surviennent rarement.
D'un point de vue métier, 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 :
- Quand la puissance des équipements augmente grâce au progrès. Il ne restera pas inactif à cause d'un logiciel imparfait. Erlang s'adapte bien verticalement et sera toujours capable d'utiliser tous les cœurs de processeur et la mémoire disponible ;
- Dans les environnements cloud, nous pouvons gérer la quantité d’équipements en fonction de la charge actuelle ou prévue et garantir le SLA.
tolérance aux pannes
Considérons deux axiomes : « Les échecs sont inacceptables » et « Il y aura toujours des échecs ». Pour une entreprise, une panne logicielle signifie une perte d’argent et, pire encore, une perte de réputation. Entre les pertes possibles et le coût de développement de logiciels tolérants aux pannes, un compromis peut souvent être trouvé.
À 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. Ils sont chers et ils ont aussi des bugs.
À long terme, une architecture tolérante aux pannes s’amortit plusieurs fois à toutes les étapes du développement.
La messagerie au sein de la base de code vous permet de déterminer en détail l'interaction des composants au sein du système au stade du développement. Cela simplifie la tâche de réponse et de gestion des pannes, puisque tous les composants critiques gèrent les pannes et que le système résultant sait comment revenir automatiquement à la normale après une panne, dès sa conception.
Réactivité
Quels que soient les échecs, l’application doit répondre aux demandes et respecter le SLA. La réalité est que les gens ne veulent pas attendre et les entreprises doivent donc s’adapter en conséquence. De plus en plus d'applications devraient être très réactives.
Les applications réactives fonctionnent quasiment en temps réel. Erlang VM fonctionne en mode temps réel logiciel. Pour certains domaines, tels que les opérations boursières, la médecine et le contrôle des équipements industriels, le mode temps réel est important.
Les systèmes réactifs améliorent l'UX et profitent à l'entreprise.
Résultat préliminaire
Lors de la planification de cet article, je souhaitais partager mon expérience de création d'un courtier de messagerie et de construction de systèmes complexes basés sur celui-ci. 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 mise en œuvre des points d'échange, des modèles de messagerie et de leur application.
Dans la troisième partie, nous aborderons les questions générales d'organisation des services, de routage et d'équilibrage. 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 .
Source: habr.com