introduction
Le choix d'un style architectural est l'une des solutions techniques fondamentales dans la construction d'un système d'information. Dans cette série d'articles, je propose d'analyser les styles architecturaux les plus populaires pour les applications de construction et de répondre à la question de savoir quand est le style architectural le plus préféré. Dans le processus, je vais essayer de dessiner une chaîne logique qui explique le développement des styles architecturaux des monolithes aux microservices.
La dernière fois, nous avons parlé des différents types de monolithes et de la façon d'utiliser des composants pour les construire, à la fois des composants d'assemblage et des composants de déploiement. Nous avons compris l'architecture orientée services.
Nous allons maintenant définir enfin les principales caractéristiques d'une architecture de microservice.
Relation des architectures
Il faut comprendre que, sur la base des données des articles de définitions précédents, tout service est un composant, mais tous les services ne sont pas un microservice.
Caractéristiques d'une architecture de microservice
Les principales caractéristiques d'une architecture de microservices sont:
- Organisé autour des capacités commerciales
- Produits et non projets
- Points de terminaison intelligents et tuyaux stupides
- Gouvernance décentralisée
- Gestion décentralisée des données
- Automatisation de l'infrastructure
- Conception pour l'échec
- Conception évolutive
Le premier point vient de l'architecture orientée services, car les microservices sont un cas particulier de services. D'autres points méritent d'être examinés séparément.
Organisé autour des capacités commerciales
Nous devons maintenant rappeler la loi de Conway: les organisations qui créent des systèmes organisent son architecture, copiant la structure d'interaction au sein de ces organisations. À titre d'exemple, considérons le cas de la création d'un compilateur: une équipe de sept a développé un compilateur à sept passes et une équipe de cinq a développé un compilateur à cinq passes.
Si nous parlons de monolithes et de microservices, alors si le développement est organisé par des départements fonctionnels (backend, frontend, administrateurs de base de données), alors nous obtenons un monolithe classique.
Pour obtenir des microservices, les équipes doivent être organisées par opportunité commerciale (commande, expédition, équipe catalogue). Cette organisation permet aux équipes de se concentrer sur la création de parties spécifiques de l'application.
Produits et non projets
Une approche projet dans laquelle l'équipe transfère la fonctionnalité développée à d'autres équipes dans le cas d'une architecture de microservice est totalement inadaptée. L'équipe doit soutenir le système tout au long de son cycle de vie. Amazon, l'un des fleurons de l'adoption des microservices, a déclaré: «vous construisez, vous l'exécutez». L'approche produit permet à l'équipe de ressentir les besoins de l'entreprise.
Points de terminaison intelligents et tuyaux stupides
L'architecture SOA a accordé une grande attention aux canaux de communication, en particulier à l'Enterprise Service Bus (Enterprise Service Bus). Ce qui conduit souvent à l'erreur Spaghetti Box, c'est-à-dire que la complexité du monolithe se transforme en complexité des connexions entre les services. L'architecture microsevice utilise uniquement des méthodes de communication simples.
Gouvernance décentralisée
Les décisions clés concernant les microservices doivent être prises par les personnes qui développent réellement les microservices. Ici, les décisions clés signifient le choix
des langages de programmation, la méthodologie de déploiement, les contrats d'interface publique, etc.
Gestion décentralisée des données
L'approche standard, dans laquelle une application repose sur une seule base de données, ne peut pas prendre en compte les spécificités de chaque service spécifique. MSA suppose une gestion décentralisée des données, jusqu'à l'utilisation de diverses technologies.
Automatisation de l'infrastructure
MSA prend en charge les processus de déploiement et de livraison continus. Cela ne peut être fait qu'en automatisant les processus. Dans le même temps, le déploiement d'un grand nombre de services ne ressemble plus à quelque chose d'effrayant. Le processus de déploiement devrait devenir ennuyeux. Le deuxième aspect est lié à la gestion des services dans l'environnement du produit. Sans automatisation, la gestion des processus s'exécutant dans différents environnements d'exploitation devient impossible.
Conception pour l'échec
De nombreux services MSA sont susceptibles de tomber en panne. Dans le même temps, la gestion des erreurs dans un système distribué n'est pas une tâche triviale. L'architecture d'application doit être résiliente à de telles pannes. Rebecca Parsons pense qu'il est très important que nous n'utilisions même plus la communication en cours entre les services, nous utilisons plutôt HTTP pour la communication, qui n'est pas aussi fiable.
Conception évolutive
L'architecture du système MSA doit évoluer. Il est souhaitable de limiter les changements requis aux limites d'un service. Il est également nécessaire de considérer l'impact sur d'autres services. L'approche traditionnelle consiste à essayer de résoudre ce problème avec le contrôle de version, mais MSA suggère d'utiliser le contrôle de version en
dernier recours.
Conclusion
Après tout ce qui précède, nous pouvons formuler ce que sont les microservices. L'architecture des microservices est une approche permettant de développer une application individuelle sous la forme d'un ensemble de petits services, chacun s'exécutant dans son propre processus et interagissant via des mécanismes légers, souvent une API de ressource HTTP. Ces services reposent sur les capacités de l'entreprise et peuvent être déployés indépendamment à l'aide d'un
moteur de déploiement entièrement automatisé. Il existe un niveau minimum de gestion centralisée de ces services, qui peuvent être écrits dans différents langages de programmation et utiliser différentes technologies de stockage. Lire la partie 2
