Les progrès technologiques que nous constatons de nos jours ont rendu beaucoup de choses possibles et faciles à faire. Tout le monde a accès à un service en quelques secondes. Avoir un système disponible et robuste a longtemps été un bon défi pour les ingénieurs et les chercheurs et une solution qui a du sens. La réponse à ces questions et à bien d’autres est: Le système distribué. Méfiez-vous, ce n’est pas quelque chose de nouveau, mais nous le voyons de plus en plus ces jours-ci et c’est devenu la référence pour chaque grand système.

Qu’est-ce qu’un système distribué?

Un système distribué est essentiellement un ensemble de Hardwares et de Softwares qui se coordonnent les uns aux autres via des messages sur un réseau pour atteindre un objectif commun. Cet objectif pourrait être de nature complexe, tel que le traitement du Big Data ou la création d’une simulation telle qu’un MMO (jeu en ligne massivement multijoueurs) ou quelque chose de plus compliqué encore, comme un réseau de capteurs pour les tsunamis ou les tremblements de terre qui déclenchent des alertes lorsque certains événements se produisent.

La clé importante dans les systèmes distribués est l’interconnexion entre les composants via un réseau. Cette relation nous amène quelques concepts intéressants à développer:

• Un accès simultané: Chaque membre du système distribué effectue en parallèle, un travail simultané avec les autres.
• Pas d’horloge logique: La synchronisation de l’heure entre les membres n’est pas si simple. Même au sein d’un réseau, il y a des retards dans les messages qui pourraient affecter la synchronisation.
• Des “fails” indépendants les uns des autres: Les membres d’un système distribué peuvent échouer à un moment ou à un autre tandis que d’autres peuvent continuer d’exécuter, sans réel impact.

Pourquoi des systèmes distribués?

Un système distribué est caractérisé par de nombreux critères qui représentent en fait ses avantages, comme par exemple:

• Le partage des ressources
• Un accès simultané
• Une extensibilité
• L’ouverture
• La tolérance aux pannes
• La Transparence
• L’hétérogénéité

Un système distribué est basé sur les principes de partage et de conquête. En répartissant les responsabilités et en réduisant la portée, nous obtiendrons un bon rapport performances/prix, une fiabilité accrue, une croissance incrémentielle et une forte tolérance aux pannes.

Quelles sont les conditions nécessaires?

Afin de construire un système distribué, nous devons garder à l’esprit que tout à un prix. Nous ne pouvons nier que le système distribué ressemble au “prochain sauveur” et au “style de conception” d’avenir; mais pour le maîtriser et le faire dans le bon sens, il y a certaines exigences et conditions qui doivent être remplies, parmi lesquelles:

• Un réseau fiable – Comme le réseau sera largement utilisé pour transmettre des données à travers différents services, un réseau peu fiable ne fera que provoquer le chaos.
• Une latence nulle – Un réseau sans latence permettra au système de traiter les demandes en un temps record, ce qui converge vers un système traditionnel fonctionnant sous faible charge.
• Une bande passante infinie – Si le système de gestion de base de données local (SGBD) comptait des systèmes de bande passante qui s’arrêtent, la même chose s’applique au système distribué dans lequel les services agissent comme source de données alors que les responsabilités sont séparées. La dernière chose que nous voulons est une limite de bande passante dans un système qui aura besoin d’un nombre illimité de transfert de données.
• Un réseau sécurisé – Les applications qui dépendent du réseau doivent être sécurisées et les systèmes distribués en font partie.
• Une topologie fixe, qui ne change pas – Nous devons avoir un système hautement “portable”, qui peut fonctionner dans n’importe quel environnement ou au moins gérer les changements ou les configurations différentes.
• Un coût de transport nul – Afin d’obtenir un rapport performance/coût raisonnable et compte tenu du fait que les informations circulent sur le réseau, nous devons minimiser ce coût autant que possible.
• Un réseau homogène – Habituellement, dans les petites applications, ce n’est pas un problème, mais pour les systèmes complexes, ce serait un problème si des formats et des protocoles standards et uniformes ne sont pas utilisés, car des systèmes complexes utiliseront différents langages, systèmes, appareils…

Ce qu’il faut prendre en considération

Il existe de nombreux types de systèmes distribués, chacun étant conçu pour répondre à des besoins spécifiques. En fonction de la priorité, des exigences, les considérations peuvent changer, mais en général, la plupart des développeurs devront tenir compte des considérations suivantes lors de la conception d’un système distribué:

• Disponibilité – Caractéristique opérationnelle d’un système où il est toujours prêt à traiter les demandes.
• Évolutivité – La capacité d’un système à augmenter sa capacité pour gérer plus de charge. Cela pourrait être réalisé en ajoutant plus de serveurs à un cluster.
• Performances – Vitesse à laquelle un système est capable de gérer les demandes.
• Coût – Coût total pour s’approprier un système. Cela pourrait inclure le matériel, les logiciels, le développement, les tests, l’hébergement et l’infrastructure cloud.
• Gestion- La maintenance, la mise à jour, la migration, la mise à l’échelle et le diagnostic doivent tous pouvoir être gérés.
• Fiabilité – Capable de s’adapter à la charge et de répondre correctement dans des conditions exceptionnelles.
• Hétérogénéité – Capacité à prendre en charge une variété d’appareils et de protocoles.
• Tolérance aux pannes et gestion des pannes – Les systèmes conçus avec une attente de panne les rendront plus tolérants aux pannes.
• Concurrence – Lorsque plusieurs pièces fonctionnent en même temps (une donnée pour les systèmes distribués).
• Migration et équilibrage de charge – Étroitement liés à la fiabilité, la tolérance aux pannes et la gestion des pannes.
• Sécurité – Garantir une autorisation et une authentification appropriées entre les utilisateurs et les composants du système est essentiel pour garantir la confidentialité et l’intégrité des données.
• Modularité – Beaucoup de petits sous-systèmes et modules formant un système plus grand de telle sorte qu’il peut être configuré et réutilisé de différentes manières.

Les éléments essentiels de votre système distribué

Il y a peu d’éléments qui sont essentiels dans un système distribué. Un système complexe qui répondra à toutes les exigences que nous avons énumérées n’est pas simple à mettre en œuvre, mais nous ne sommes pas les premiers à le faire, ce qui nous a permis d’apprendre des choses de nos “pionniers” et “ingénieurs fous”.

Dans cet article, je recommanderai quelques outils qui vous permettront de démarrer votre système distribué, mais une exploration plus approfondie est nécessaire pour la production d’applications de qualité.

Adoptez le DevOps

Afin de mettre en place avec succès votre système, vous devez adopter le DevOps. Pour faire bref, avec les principes DevOps, vous vous assurerez de disposer de pipelines de développement et de livraisons robustes avec une assurance qualité améliorée et un temps réduit. Cela semble très prometteur. (pour mieux comprendre: Lisez cet article)

L’infrastructure essentielle

Nous avons parlé d’infrastructure, je mentionnerai en particulier quelques outils que vous connaissez peut-être déjà, le Combo Docker / Kubernetes.

Pour garantir la portabilité croisée et l’isolement, nous avons besoin de Docker et pour orchestrer nos conteneurs Docker, nous avons besoin de K8.

Si vous êtes nouveau dans l’orchestration et le docker, il suffit de le “Googler” pour trouver un tas de ressources et des vidéos impressionnantes.

Ces outils ne nous permettront pas seulement de faire tout ça, mais ils garantiront également la disponibilité, l’évolutivité, l’équilibrage de charge et la maintenabilité.

Pour configurer votre infrastructure, vous utiliserez: CI / CD, Linux, Docker Image Registry, Kubernetes, Ingress NGINX, LetsEncrypt…

L’infrastructure basée sur les applications
Nous sommes toujours en retard, nous devons configurer beaucoup d’autres choses pour répondre aux exigences minimales pour démarrer un projet de système distribué et pour ce faire, nous avons besoin de:

• Un “courtier de messages” pour échanger des messages et des commandes entre services par exemple (RabbitMq).
• Un SGBD conforme ACID (ou multiple) afin de gérer les données simultanément (SQL Server, MySQL, Neo4j…).
• Un outil de traçage pour tracer les informations circulant dans le réseau à travers les services, cela nous aidera à optimiser et à diagnostiquer efficacement (par exemple: Jaeger).
• Un serveur/récepteur de log à distance pour centraliser log in et, croyez-moi le logging est très important, en particulier dans les systèmes distribués (par exemple: Datalust Seq, MySQL).
• Un service de mise en cache comme REDIS.
• Une base de données chronologiques pour stocker les métriques de service et pour ce faire, vous pouvez implémenter ou utiliser une bibliothèque existante qui vous aidera à y parvenir (par exemple: AppMetrics pour ASP.NET Core) et pour la base de données chronologiques, vous pouvez utiliser InfluxDB par exemple.
• Un tableau de bord pour visualiser les métriques de cluster et de service. Vous pouvez utiliser Grafana car il est facile à utiliser et à personnaliser.

Modèles d’architecture/de conception

Si vous visez un système complexe, vous devrez peut-être jeter un œil à CQRS (Command Query Responsibility Segregation), modèle Sagas.

Vous pouvez également explorer plus de modèles pour différents niveaux sur Microservices.io.

Conclusion

Si vous êtes prêt à mettre en place un système distribué, assurez-vous que cela en vaut la peine, car cela ne sera pas forcement le meilleur choix. Il présente certains inconvénients avec les petits systèmes, et parfois le développer peut être difficile si vous ne faites pas attention aux détails. Étudiez judicieusement les cas dans lesquels vous allez l’utiliser, puis choisissez!