Bonjour Habr. Aujourd'hui, je continue une série de publications que j'ai écrites spécifiquement pour le début d'une nouvelle filière du cours. .
introduction
Le choix du style architectural est l’une des décisions techniques fondamentales lors de 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 quel style architectural est le plus préférable. Dans le processus de présentation, j'essaierai de tracer 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 l'utilisation de composants pour les construire, à la fois des composants de construction et des composants de déploiement. Nous comprenons l’architecture orientée services.
Nous allons maintenant enfin définir les principales caractéristiques d'une architecture microservice.
Relation des architectures
Il est nécessaire de comprendre que sur la base des définitions données dans les articles précédents, tout service est un composant, mais tous les services ne sont pas des microservices.
Caractéristiques de l'architecture des microservices
Les principales caractéristiques de l’architecture des microservices sont :
- Organisé autour des capacités métiers
- Des produits et non des projets
- Points de terminaison intelligents et tuyaux stupides
- Gouvernance décentralisée
- Gestion des données décentralisée
- Automatisation des infrastructures
- Concevoir pour l’échec
- Architecture à développement évolutif (Evolutionary Design)
Le 1er point vient de l’architecture orientée services car les microservices sont un cas particulier de services. D'autres points méritent un examen séparé.
Organisé autour des capacités métiers
Il faut maintenant rappeler la loi de Conway : les organisations qui créent des systèmes organisent son architecture, en copiant la structure d'interaction au sein de ces organisations. A titre d'exemple, on peut rappeler le cas de la création d'un compilateur : une équipe de sept personnes a développé un compilateur en sept passes, et une équipe de cinq a développé un compilateur en 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 bases de données), alors nous obtenons un monolithe classique.
Pour obtenir des microservices, les équipes doivent être organisées par capacité métier (commandes, expéditions, équipe catalogue). Cette organisation permettra aux équipes de se concentrer sur la construction de parties spécifiques de l'application.
Des produits et non des projets
Une approche projet dans laquelle une équipe transfère les fonctionnalités développées à d'autres équipes est totalement inadaptée dans le cas d'une architecture microservice. L'équipe doit soutenir le système tout au long de son cycle de vie. Amazon, l'un des leaders dans la mise en œuvre de 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. Ce qui conduit souvent à une boîte à spaghetti erronée, c'est-à-dire que la complexité du monolithe se transforme en complexité des connexions entre les services. L'architecture des microservices 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 des choix
langages de programmation, méthodologie de déploiement, contrats d'interface publique, etc.
Gestion des données décentralisée
L'approche standard, dans laquelle l'application s'appuie sur une seule base de données, ne peut pas prendre en compte les spécificités de chaque service spécifique. MSA implique une gestion décentralisée des données, y compris l'utilisation de diverses technologies.
Automatisation des infrastructures
MSA prend en charge les processus de déploiement et de livraison continus. Cela ne peut être réalisé qu’en automatisant les processus. Dans le même temps, déployer un grand nombre de services ne fait plus peur. Le processus de déploiement devrait devenir ennuyeux. Le deuxième aspect est lié à la gestion des services dans un environnement produit. Sans automatisation, la gestion des processus exécutés dans différents environnements d'exploitation devient impossible.
Concevoir pour l’échec
De nombreux services MSA sont sujets aux pannes. Dans le même temps, la gestion des erreurs dans un système distribué n’est pas une tâche triviale. L'architecture des applications 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 de processus entre les services ; nous recourions plutôt au HTTP pour la communication, qui n'est pas aussi fiable.
Architecture à développement évolutif (Evolutionary Design)
L'architecture du système MSA devrait évoluer de manière évolutive. Il est conseillé de limiter les modifications nécessaires aux limites d'un seul service. L'impact sur d'autres services doit également être pris en compte. 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 dans
en dernier recours.
Conclusion
Après tout ce qui précède, nous pouvons formuler ce que sont les microservices. L'architecture de microservices est une approche permettant de développer une application unique 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 s'appuient sur des capacités métier et peuvent être déployés indépendamment en utilisant pleinement
mécanisme de déploiement 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 de données.
Source: habr.com