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.
Dans Nous avons examiné le monolithe et conclu qu'il présente plusieurs problèmes : taille, couplage, déploiement, évolutivité, fiabilité et rigidité.
Cette fois, je vous propose de parler des possibilités d'organisation du système sous forme d'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 que le système soit réalisé sous forme d'un ensemble de composants qui peuvent être utilisés tant dans des projets actuels que futurs. Lors de la décomposition d'un système en composants, il est tenu compte de : leur réutilisabilité, leur remplaçabilité, leur indépendance par rapport au contexte, leur extensibilité, leur encapsulation et leur autonomie.
Lorsqu'ils sont utilisés correctement, les composants résolvent le problème du « gros tas de saleté » (grande taille + fort couplage), et ces composants peuvent représenter à la fois des unités de construction (modules, bibliothèques) et des unités de déploiement (services). Les unités de déploiement ne correspondent pas toujours à un processus d'exécution : par exemple, une application web et une base de données sont déployées ensemble.
Les monolithes sont le plus souvent développés sous forme d'un ensemble de modules. Cette approche permet d'assurer l'indépendance du développement, mais elle laisse persister des problèmes d'évolutivité et de déploiement indépendants, de résilience et d'indépendance par rapport à une pile technologique commune. C'est pourquoi un module est un composant partiellement indépendant.
Le principal problème de ce type de monolithe réside dans le fait que la séparation en modules est purement logique et peut facilement être perturbée par les développeurs. Un module core peut apparaître, qui se transforme progressivement en un fourre-tout, le graphe des dépendances entre les modules peut croître, etc. Pour éviter ces problèmes, le développement doit être mené soit par une équipe très expérimentée, soit sous la direction d'un « architecte », qui se consacre à plein temps à la revue de code et qui sanctionne les développeurs qui enfreignent la structure logique.
Un monolithe « idéal » se compose d'un ensemble de modules logiquement séparés, chacun accédant à sa propre base de données.
Architecture orientée services
Si une organisation de système sous la forme d'un ensemble de services est envisagée, on parle alors d'architecture orientée services. Ses principes incluent : l'interopérabilité des applications centrées sur l'utilisateur, la réutilisation des services métier, l'indépendance par rapport à un ensemble de technologies et l'autonomie (évolution, évolutivité et déploiement indépendants).
L'architecture orientée services (SOA = service oriented architecture) résout tous les problèmes identifiés du monolithe : lors d'un changement, seule un service est affecté, et une API clairement définie permet une bonne encapsulation des composants.
Cependant, tout n'est pas si simple : la SOA entraîne l'émergence de nouveaux problèmes. Les appels distants sont plus coûteux que les locaux, et la redistribution des responsabilités entre les composants est devenue considérablement plus coûteuse.
Il est à noter que la possibilité de déploiement indépendant est une caractéristique très importante pour le service. Si les services doivent être déployés ensemble ou, pire, dans un ordre spécifique, le système ne peut pas être considéré comme orienté services. On parle alors de monolithe distribué (considéré comme un antipattern tant du point de vue de la SOA que de l'architecture microservices).
L'architecture orientée services est bien soutenue par la communauté architecturale et les fournisseurs. Cela se traduit par de nombreux cours et certifications, ainsi que des modèles bien élaborés. Parmi ces derniers se trouve, par exemple, le célèbre bus de services d'entreprise (ESB = enterprise service bus). Notez que l'ESB est un héritage des fournisseurs, il n'est pas nécessaire qu'il soit utilisé dans une SOA.
Le pic de popularité de l'architecture orientée services a eu lieu vers 2008, après quoi elle a commencé à décliner, et son déclin s'est accentué avec l'émergence des microservices (~2015).
Conclusion
Après avoir discuté des possibilités d'organisation des systèmes d'information sous forme de services et de modules, je propose enfin de passer aux principes de l'architecture microservices et de prêter une attention particulière à la distinction entre l'architecture microservices et l'architecture orientée services dans la prochaine partie.
Source : habr.com
