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.
В nous avons traité du monolithe et sommes arrivés à la conclusion que le monolithe présente un certain nombre de problèmes : taille, connectivité, déploiement, évolutivité, fiabilité et rigidité.
Cette fois je propose de parler des possibilités d'organiser un système comme un ensemble de modules/bibliothèques (architecture orientée composants) ou de services (architecture orientée services).
Architecture orientée composants
L'architecture orientée composants implique l'exécution d'un système comme un ensemble de composants pouvant être utilisés dans les projets actuels et futurs. Lors de la décomposition d'un système en composants, les éléments suivants sont pris en compte : leur réutilisabilité, leur remplaçabilité, leur indépendance du contexte, leur extensibilité, leur encapsulation et leur indépendance.
Avec une utilisation appropriée des composants, le problème de la « grosse boule de terre » (grande taille + couplage élevé) est résolu, et les composants eux-mêmes peuvent être à la fois des unités d'assemblage (modules, bibliothèques) et des unités de déploiement (services). Les unités de déploiement ne sont pas toujours mappées au processus en cours : par exemple, une application Web et une base de données sont déployées ensemble.
Le plus souvent, les monolithes sont développés sous la forme d'un ensemble de modules. Cette approche conduit à un développement indépendant, mais les problèmes de mise à l'échelle et de déploiement indépendants, de tolérance aux pannes et d'indépendance par rapport à la pile technologique globale demeurent. C'est pourquoi le module est un composant partiellement indépendant.
Le plus gros problème avec un tel monolithe est que la division en modules est purement logique et peut être facilement violée par les développeurs. Un module principal peut apparaître, qui se transforme progressivement en un dépotoir, le graphique des dépendances entre modules peut s'agrandir, etc. Pour éviter de tels problèmes, le développement doit être effectué soit par une équipe très mature, soit sous la direction d'un « architecte » qui s'occupe de la révision du code à plein temps et bat les mains des développeurs qui violent la structure logique.
Le monolithe « idéal » est un ensemble de modules logiquement séparés, dont chacun consulte sa propre base de données.
Architecture orientée services
Si le système est censé être organisé sous la forme d'un ensemble de services, on parle alors d'une architecture orientée services. Ses principes sont l'interopérabilité des applications centrées sur l'utilisateur, la réutilisation des services métier, l'indépendance de la pile technologique et l'autonomie (évolution, évolutivité et déploiement indépendants).
L'architecture orientée services (SOA = architecture orientée services) résout tous les problèmes identifiés d'un monolithe : un seul service est affecté lorsqu'un changement survient, et une API bien définie prend en charge une bonne encapsulation des composants.
Mais tout ne se passe pas aussi bien : la SOA crée de nouveaux problèmes. Les appels à distance coûtent plus cher que les appels locaux, et la redistribution des responsabilités entre les composants est devenue nettement plus coûteuse.
À propos, la possibilité de déploiement indépendant est une caractéristique très importante du service. Si les services doivent être déployés ensemble ou, de plus, dans un certain ordre, alors le système ne peut pas être considéré comme orienté services. Dans ce cas, ils parlent d'un monolithe distribué (considéré comme un anti-modèle non seulement du point de vue de la SOA, mais aussi du point de vue de l'architecture des microservices).
L'architecture orientée services est bien prise en charge par la communauté des architectes et les fournisseurs. Cela implique la présence de nombreux cours et certifications, des modèles bien développés. Ce dernier inclut, par exemple, le célèbre Enterprise Service Bus (ESB = Enterprise Service Bus). Dans le même temps, l'ESB est un bagage provenant des fournisseurs ; il ne doit pas nécessairement être utilisé dans la SOA.
La popularité de l’architecture orientée services a culminé vers 2008, après quoi elle a commencé à décliner, ce qui est devenu bien plus dramatique après l’avènement des microservices (~ 2015).
Conclusion
Après avoir évoqué les possibilités d'organiser les systèmes d'information sous forme de services et de modules, je propose de passer enfin aux principes de l'architecture microservice et de porter une attention particulière à la différence entre architecture microservice et architecture orientée services dans la partie suivante.
Source: habr.com