Traitement de données en streaming sur Elixir : Architecture et implémentation

Architecture Elixir pour le traitement de flux de données : du Hello World au couplage lâche

Construire un système d'interconnexions d'moteurs en Elixir exige une séparation nette des couches et une intégration fluide avec les dépendances externes. Cet article explore l'implémentation de nœuds centraux pour le traitement de flux de données — incluant sources, puits et un répartiteur central — en mettant l'accent sur des principes architecturaux solides et des solutions pratiques.

Classification des nœuds matériels et sources de données

Dans le traitement de flux de données, les nœuds d'extrémité du graphe sont essentiels : ils interfacent directement avec le matériel. À la couche inférieure se trouvent les sources de données, classées par type d'entrée :

• Clavier (Setpoint) : Pour saisir des données alphanumériques, comme des valeurs de consigne dans les systèmes de contrôle.
• Passerelles régulières (R_gateway) : Pilotes pour bus à flux de données continus, tels que Modbus en automatisation industrielle.
• Passerelles irrégulières (Ir_gateway) : Adaptateurs pour rafales de données sporadiques, comme le bus CAN dans les véhicules modernes connectés à l'unité de contrôle centrale.

À la couche supérieure viennent les consommateurs de données, regroupés sous la classe Stock :

• Écrans pour afficher les informations.
• Systèmes de fichiers pour journaliser événements et erreurs.
• Bases de données ou dépôts comme stockage intermédiaire.
• Systèmes de niveau supérieur qui enchaînent les moteurs via des nœuds passerelle.

Cette configuration forme un graphe de flux de données où les nœuds inférieurs alimentent les informations vers le haut, en sautant la couche moteur intermédiaire au démarrage.

Implémentation des nœuds centraux et simulation de flux

Pour démontrer le système, nous avons créé trois nœuds sources et un nœud puits — sans recourir à GenServer OTP. Ceux-ci utilisent de simples fonctions en boucle loop, pour rester légers et directs :

• Module d'entrée terminal : Permet de saisir des données alphanumériques, comme le classique « Hello, World ! ».
• Simulateur de données régulières : Boucle indéfiniment, injectant « Hello, » dans le flux toutes les secondes.
• Simulateur de données irrégulières : Boucle indéfiniment, envoyant « World ! » dans le flux à intervalles allant jusqu'à 1 seconde.
• Puits de sortie terminal : Affiche à l'écran toutes les données alphanumériques entrantes, quel que soit leur source.

La couche moteur intermédiaire reste vide par conception pour cette version initiale. Le code complet avec moteurs fonctionnels sera publié sur GitHub pour plus de transparence et une extension aisée.

Répartition des terminaux et répartiteur central

Un défi majeur était la gestion des E/S terminal liées aux processus locaux. Par défaut, Erlang redirige toutes les E/S des nœuds vers un seul terminal pour un contrôle centralisé — ce qui ne convient pas toujours aux configurations distribuées. La solution ? Cet opérateur :

:global.register_name(:stock_ldr, :erlang.group_leader)

Il répartit le système sur des terminaux dédiés, bien que le trouver ait pris un temps fou à cause d'une documentation lacunaire.

Pour charger et lancer le système, nous avons ajouté un répartiteur central. Lors de l'intégration de bibliothèques tierces en Elixir, la meilleure pratique consiste en un module interne unique comme porte d'entrée vers l'extérieur — favorisant le couplage lâche. L'architecture hexagonale repousse les dépendances aux bords, isolant la logique métier des effets de bord. En pratique, toutefois, cela devient complexe avec une multitude de modules externes comme les passerelles matérielles et puits de données.

Principes architecturaux et scalabilité

Le système de moteurs est conçu pour s'étendre facilement : tout nœud d'extrémité du graphe agit comme une passerelle vers le monde extérieur. Cela permet d'insérer librement des composants personnalisés, pour évoluer vers des applications réelles. Clé de voûte : le système grandit « vers le bas » dans les applications, inversant la mentalité architecturale top-down habituelle.

Conseils pour les développeurs :

• Les processus basés sur des boucles simples surpassent GenServer OTP pour les nœuds de base — plus faciles à implémenter, mais prévoyez une gestion d'erreurs rigoureuse.
• :global.register_name résout le problème des E/S centralisées d'Erlang.
• Le couplage lâche avec les externes est ardu, même avec les idéaux hexagonaux.

Points clés :

• Les classes de nœuds comme R_gateway, Ir_gateway, Setpoint et Stock structurent clairement le streaming.
• Les simulateurs de données valident le système sans moteurs intermédiaires.
• La répartition des terminaux requiert des astuces Erlang ingénieuses.
• Répartiteur central et intégrations externes privilégient le couplage lâche.
• Les nœuds passerelle rendent le système extensible vers des domaines pratiques.

— Editorial Team