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 traité du monolithe et sommes arrivés à la conclusion que le monolithe avait un certain nombre de problèmes: la taille, la connectivité, le déploiement, l'évolutivité, la fiabilité et le conservatisme.
Cette fois, je propose de parler des possibilités d'organisation d'un système sous la 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 basée sur les composants implique la mise en œuvre du système en tant qu'ensemble de composants pouvant être utilisés dans les projets actuels et futurs. Lors de la division d'un système en composants, les facteurs suivants sont pris en compte: leur aptitude à la réutilisation, leur remplaçabilité, l'indépendance du contexte, l'extensibilité, l'encapsulation et l'indépendance.
Avec une bonne utilisation des composants, le problème d'une «grosse boule de saleté» (grande taille + connectivité élevée) 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 à un processus en cours d'exécution: par exemple, une application Web et une base de données sont déployées ensemble.
Le plus souvent, les monolithes sont conçus comme un ensemble de modules. Cette approche conduit à garantir l'indépendance du développement, mais en même temps, 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 générale 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 interrompue par les développeurs. Un module de base peut apparaître, qui se transforme progressivement en un tas de déchets, un graphique des dépendances entre les modules peut augmenter, et ainsi de suite. Pour éviter de tels problèmes, le développement doit être réalisé soit par une équipe très mature, soit sous la direction d'un «architecte» qui est engagé dans la révision du code à plein temps et bat les mains des développeurs qui violent la structure logique.
Un monolithe «idéal» est un ensemble de modules séparés logiquement, dont chacun regarde dans sa propre base de données.
Architecture orientée services
Si, néanmoins, il est censé organiser le système sous la forme d'un ensemble de services, alors nous parlons d'une architecture orientée services. Ses principes sont: l'interopérabilité des applications orientées utilisateur, la réutilisabilité des services métiers, l'indépendance par rapport à un ensemble de technologies et l'autonomie (évolution indépendante, évolutivité et déployabilité).
L'architecture orientée services (SOA) résout tous les problèmes décrits du monolithe: un changement n'affecte qu'un seul service et une API bien définie prend en charge une bonne encapsulation des composants.
Mais tout n'est pas si simple: SOA introduit de nouveaux problèmes. Les appels à distance sont plus chers que les appels locaux et la redistribution des responsabilités entre les composants est devenue nettement plus coûteuse.
À propos, la possibilité de se déployer indépendamment est une caractéristique très importante du service. Si les services doivent être déployés ensemble, ou plus encore 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é (il est considéré comme un anti-pattern non seulement du point de vue SOA, mais aussi d'une architecture de microservice).
L'architecture orientée services est bien prise en charge par la communauté de l'architecture et les fournisseurs. Par conséquent, il existe de nombreux cours et certifications, des modèles bien développés. Ce dernier inclut, par exemple, le bus de service d'entreprise non inconnu (ESB = bus de service d'entreprise). Dans le même temps, ESB est le bagage des vendeurs, il n'a pas besoin d'être utilisé dans SOA.
L'architecture orientée services a atteint un sommet de popularité vers 2008, après quoi elle a commencé à décliner, ce qui est devenu beaucoup plus net après 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 de passer enfin aux principes d'une architecture de microservices et de porter une attention particulière à la différence entre une architecture de microservices et une architecture orientée services dans la partie suivante.
