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.
Un peu d'histoire
Si vous essayez de poser une question aux développeurs: «Pourquoi avons-nous besoin de microservices?», Vous obtiendrez alors une variété de réponses. Vous entendrez que les microservices améliorent la mise à l'échelle, facilitent la compréhension de votre code, améliorent la tolérance aux pannes, parfois vous entendrez qu'ils vous permettent de «nettoyer le code». Revenons à l'histoire pour comprendre quel était le but de l'émergence des microservices.
En bref, les microservices dans notre compréhension actuelle ont émergé comme suit: en 2011, James Lewis, analysant le travail de différentes entreprises, a attiré l'attention sur l'émergence d'un nouveau modèle de «micro-application» qui optimisait la SOA en termes d'accélération du déploiement des services. Un peu plus tard, en 2012, lors du sommet de l'architecture, le pattern a été renommé microservice. Ainsi, l'objectif initial de l'introduction des microservices était d'améliorer le fameux time to market .
Les microservices étaient sur la «vague hype» en 2015. Selon certaines études, aucune conférence n'a été complète sans un exposé sur le thème des microservices. De plus, certaines conférences étaient dédiées exclusivement aux microservices. De nos jours, de nombreux projets commencent à utiliser ce style architectural, et si le projet contient des tonnes de code hérité, il est fort probable que la migration vers les microservices soit activement effectuée.
Malgré tout ce qui précède, il existe encore pas mal de développeurs qui peuvent définir le concept de «microservice». Mais nous en reparlerons un peu plus tard ...
Monolithe
Le style architectural opposé aux microservices est monolithe (ou tout-en-un). Cela n'a probablement pas de sens de dire ce qu'est un monolithe, donc je vais immédiatement énumérer les lacunes de ce style architectural qui a initié le développement ultérieur des styles architecturaux: taille, cohérence, déploiement, évolutivité, fiabilité et inertie. Ci-dessous, je propose de connaître chacun des inconvénients séparément.
La taille
Le monolithe est très grand. Et il communique généralement avec une très grande base de données. L'application devient trop volumineuse pour qu'un seul développeur puisse la comprendre. Seuls ceux qui ont passé beaucoup de temps derrière ce code peuvent bien fonctionner avec un monolithe, tandis que les débutants passeront beaucoup de temps à essayer de comprendre le monolithe et non le fait qu'ils le comprendront. Habituellement, lorsqu'on travaille avec un monolithe, il y a toujours un senior «conditionnel» qui connaît plus ou moins bien le monolithe et gifle d'autres nouveaux développeurs pendant un an ou demi. Naturellement, un tel aîné conditionnel est un point d'échec unique, et son départ peut entraîner la mort du monolithe.
Connectivité
Un monolithe est une «grosse boule de boue», dont les changements peuvent entraîner des conséquences imprévisibles. En apportant des modifications à un endroit, vous pouvez endommager le monolithe dans un autre (le même "gratté mon oreille, * @ est tombé"). Cela est dû au fait que les composants du monolithe ont des relations très complexes et, surtout, non évidentes.
Déploiement
Le déploiement d'un monolithe, en raison des relations complexes entre ses composants, est un long processus avec son propre rituel. Ce rituel n'est généralement pas complètement standardisé et est transmis «de bouche à oreille».
Évolutivité
Les modules Monolith peuvent avoir des besoins en ressources contradictoires, ce qui nécessite un compromis en termes de matériel. Imaginez que votre monolithe se compose des services A et B. Le service A est exigeant sur la taille du disque dur, tandis que le service B est exigeant sur la RAM. Dans ce cas, soit la machine sur laquelle le monolithe est installé doit prendre en charge les exigences des deux services, soit vous devrez désactiver manuellement l'un des services.
Autre exemple (plus classique): le service A est beaucoup plus populaire que le service B, vous voulez donc que les services A soient 100 et les services B 10. Encore une fois, deux options: soit nous déployons 100 monolithes à part entière, soit sur certains alors les services B devront être désactivés manuellement.
Fiabilité
Étant donné que tous les services sont réunis, si le monolithe tombe, tous les services tombent en même temps. En fait, ce n'est peut-être pas si grave, au moins il n'y aura pas de pannes partielles dans un système distribué, mais d'un autre côté, en raison d'une erreur dans la fonctionnalité utilisée par 0,001% des utilisateurs, vous pouvez perdre tous les utilisateurs de votre système.
Inertie
En raison de la taille du monolithe, il est difficile de passer aux nouvelles technologies. Par conséquent, le maintien en poste de cette personne âgée conditionnelle est une tâche distincte. La pile technologique choisie au début du projet peut devenir un bloc qui freine le développement du produit.
Conclusion
La prochaine fois, nous parlerons de la manière dont les gens ont essayé de résoudre ces problèmes en passant aux composants et à la SOA.
Lire la suite: