Bonjour, Habr. Aujourd'hui, je poursuis ma série de publications que j'ai écrite spécialement pour le lancement d'un nouveau cycle de cours .
Introduction
Le choix d'un style architectural est l'une des décisions techniques fondamentales lors de la création d'un système d'information. Dans cette série d'articles, je propose d'examiner les styles architecturaux les plus populaires pour la construction d'applications et de répondre à la question de savoir quand un style architectural particulier est le plus approprié. Au fil de cette exposition, j'essaierai de créer un fil logique expliquant l'évolution 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 leur construction, tant des composants d'assemblage que des composants de déploiement. Nous avons également abordé l'architecture orientée services.
Nous allons maintenant définir les principales caractéristiques de l'architecture de microservices.
Les relations architecturales
Il est nécessaire de comprendre qu'en se basant sur les informations des articles précédents, tout service est un composant, mais tous les services ne sont pas des microservices.
Caractéristiques de l'architecture de microservices
Les principales caractéristiques de l'architecture de microservices sont :
- Organisation autour des capacités métier (Organized around Business Capabilities)
- Produits plutôt que projets (Products not Projects)
- Points d'entrée intelligents et canaux idiots (Smart endpoints and dumb pipes)
- Gouvernance décentralisée (Decentralized Governance)
- Gestion des données décentralisée (Decentralized Data Management)
- Automatisation de l'infrastructure (Infrastructure Automation)
- Conception résiliente (Design for failure)
- Architecture avec évolution (Evolutionary Design)
Le premier point provient de l'architecture orientée services, car les microservices sont un cas particulier des services. D'autres points méritent une attention particulière.
Organisation autour des capacités métier (Organized around Business Capabilities)
Il est maintenant nécessaire de rappeler la loi de Conway : les organisations qui créent des systèmes conforment leur architecture à la structure des interactions au sein de ces organisations. Par exemple, lors de la création d'un compilateur : une équipe de sept personnes a développé un compilateur à sept passes, tandis qu'une équipe de cinq personnes a réalisé un compilateur à cinq passes.
Si nous parlons de monolithes et de microservices, dans le cas où le développement est organisé par départements fonctionnels (backend, frontend, administrateurs de bases de données), on obtient un classique monolithe.
Pour obtenir des microservices, il est nécessaire d'organiser les équipes par opportunités commerciales (équipe des commandes, des livraisons, du catalogue). Cette organisation permettra aux équipes de se concentrer sur la création de parties spécifiques de l'application.
Produits plutôt que projets (Products not Projects)
Une approche projet où une équipe transmet des fonctionnalités développées à d'autres équipes dans le cas d'une architecture microservices ne convient absolument pas. L'équipe doit maintenir le système tout au long de son cycle de vie. Amazon, l'un des pionniers de l'implémentation des microservices, a déclaré : « vous construisez le produit, et c'est vous qui le lancez » ( « you build, you run it »). L'approche produit permet à l'équipe de sentir les besoins de l'entreprise.
Points d'entrée intelligents et canaux idiots (Smart endpoints and dumb pipes)
L'architecture SOA mettait un grand accent sur les canaux de communication, en particulier le bus de services d'entreprise (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 relations entre services. Dans l'architecture microservices, seules des méthodes simples d'interaction sont utilisées.
Gouvernance décentralisée (Decentralized Governance)
Les décisions clés concernant les microservices doivent être prises par les personnes qui les développent réellement. Ici, par décisions clés, on entend le choix
des langages de programmation, des méthodologies de déploiement, des contrats d'interfaces publiques, etc.
Gestion des données décentralisée (Decentralized Data Management)
L'approche standard, où l'application repose sur une seule base de données, ne peut pas tenir compte des spécificités de chaque service. MSA suppose une gestion décentralisée des données, y compris l'utilisation de différentes technologies.
Automatisation de l'infrastructure (Infrastructure Automation)
MSA soutient les processus de déploiement et de livraison continus. Cela ne peut être réalisé que par l'automatisation des processus. Ainsi, le déploiement d'un grand nombre de services ne semble plus être quelque chose d'effrayant. Le processus de déploiement doit devenir ennuyeux. Le deuxième aspect concerne la gestion des services dans un environnement de production. Sans automatisation, la gestion des processus lancés dans différents environnements opérationnels devient impossible.
Conception résiliente (Design for failure)
De nombreux services MSA sont sujets à des pannes. Par conséquent, la gestion des erreurs dans un système distribué est une tâche tout sauf triviale. L'architecture des applications doit être résiliente face à de telles pannes. Rebecca Parsons estime qu'il est très important que nous ne recourions plus même à l'interaction intra-processus entre les services, mais que nous utilisions plutôt HTTP pour la communication, qui n'est pas aussi fiable.
Architecture avec évolution (Evolutionary Design)
L'architecture d'un système MSA doit évoluer de manière progressive. Il est souhaitable de limiter les changements nécessaires aux frontières d'un seul service. Il faut également prendre en compte l'impact sur les autres services. L'approche traditionnelle consiste à tenter de résoudre ce problème par le biais de la gestion des versions, mais MSA suppose d'utiliser la gestion des versions comme
solution ultime.
Conclusion
Après tout ce qui a été dit, on peut définir ce que sont les microservices. L'architecture microservices est une approche de développement d'une application distincte sous forme d'un ensemble de petits services, chacun fonctionnant dans son propre processus et interagissant par le biais de mécanismes allégés, souvent via une API HTTP. Ces services sont construits sur des opportunités commerciales et peuvent être déployés indépendamment à l'aide d'un mécanisme de déploiement entièrement
automatisé. Il existe un niveau minimal 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
