Bonjour, Habr. L'inscription à un nouveau volet de cours est ouverte dès maintenant chez OTUS . A la veille du début du cours, je souhaite partager avec vous mon article original.
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.
Un peu d'histoire
Si vous essayez de demander aux développeurs : « Pourquoi avons-nous besoin de microservices ? », vous obtiendrez diverses réponses. Vous entendrez que les microservices améliorent l'évolutivité, rendent le code plus facile à comprendre, améliorent la tolérance aux pannes, et parfois vous entendrez qu'ils vous permettent de « nettoyer votre code ». Regardons l'histoire pour comprendre le but de l'émergence des microservices.
En bref, les microservices dans notre compréhension actuelle sont apparus comme suit : en 2011, James Lewis, analysant le travail de diverses 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 de prestations de service. Un peu plus tard, en 2012, lors d'un sommet d'architecture, le modèle a été renommé microservice. Ainsi, l’objectif initial de l’introduction des microservices était d’améliorer le fameux les délais de commercialisation.
Les microservices étaient à la mode en 2015. Selon certaines études, pas une seule conférence n'était complète sans un rapport sur le thème des microservices. D’ailleurs, 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 existant, alors la migration vers les microservices est probablement en cours.
Malgré tout ce qui précède, un nombre assez restreint de développeurs peuvent encore définir le concept de « microservice ». Mais nous en reparlerons un peu plus tard...
Monolithe
Le style architectural qui contraste avec les microservices est le monolithe (ou tout-en-un). Cela n'a probablement aucun sens de dire ce qu'est un monolithe, je vais donc immédiatement énumérer les inconvénients de ce style architectural, qui a initié le développement ultérieur des styles architecturaux : taille, connectivité, déploiement, évolutivité, fiabilité et rigidité. Ci-dessous, je propose d'examiner chacune des lacunes séparément.
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 à travailler sur ce code peuvent bien travailler avec le monolithe, tandis que les débutants passeront beaucoup de temps à essayer de comprendre le monolithe et il n'y a aucune garantie qu'ils le comprendront. Habituellement, lorsque l'on travaille avec un monolithe, il y a toujours un senior « conditionnel » qui connaît plus ou moins bien le monolithe et bat les mains d'autres nouveaux développeurs en un an et demi. Naturellement, un tel senior conditionnel est un point d'échec unique, et son départ peut entraîner la mort du monolithe.
Connectivité
Le monolithe est une « grosse boule de boue », dont les modifications peuvent entraîner des conséquences imprévisibles. En apportant des modifications à un endroit, vous pouvez endommager le monolithe à un autre (le même « tu t'es gratté l'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. Un tel rituel n’est généralement pas complètement standardisé et est transmis « oralement ».
Évolutivité
Les modules Monolith peuvent avoir des besoins en ressources contradictoires, nécessitant un compromis en termes de matériel. Imaginez que vous disposez d'un monolithe composé des services A et B. Le service A est exigeant en termes de taille du disque dur et le service B est exigeant en 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 et artificiellement l'un des services.
Autre exemple (plus classique) : le service A est beaucoup plus populaire que le service B, vous souhaitez donc qu'il y ait 100 services A, et 10 services B. Encore une fois, deux options : soit on déploie 100 monolithes à part entière, soit sur certains puis les services B devront être désactivés manuellement.
Fiabilité
Puisque tous les services sont situés ensemble, si le monolithe tombe, alors 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é, à cause d'un bug dans une 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, retenir ce même senior est une tâche distincte. La stack technologique choisie au début d’un projet peut devenir un blocage qui freine le développement du produit.
Conclusion
La prochaine fois, nous parlerons de la façon dont les gens ont essayé de résoudre ces problèmes en passant aux composants et à la SOA.
Lire la suite:
Source: habr.com