{"id":92810,"date":"2020-08-31T07:42:09","date_gmt":"2020-08-31T05:42:09","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/vybor-arhitekturnogo-stilya-chast-1"},"modified":"2020-08-31T07:42:09","modified_gmt":"2020-08-31T05:42:09","slug":"vybor-arhitekturnogo-stilya-chast-1","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/vybor-arhitekturnogo-stilya-chast-1","title":{"rendered":"Choix du style architectonique (partie 1)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Bonjour, Habr. En ce moment, OTUS ouvre les inscriptions pour un nouveau groupe de cours. \u00abArchitecte Logiciel\u00bb<\/a><\/noindex>. \u00c0 l'approche du d\u00e9but du cours, je souhaite partager avec vous mon article d'auteur.<\/i><\/b><\/p>\n

<\/p>\n

Introduction<\/h2>\n

\nLe choix d'un style architectural est l'une des d\u00e9cisions techniques fondamentales lors de la cr\u00e9ation d'un syst\u00e8me d'information. Dans cette s\u00e9rie d'articles, je propose d'examiner les styles architecturaux les plus populaires pour la construction d'applications et de r\u00e9pondre \u00e0 la question de savoir quand un style architectural particulier est le plus appropri\u00e9. Au fil de cette exposition, j'essaierai de cr\u00e9er un fil logique expliquant l'\u00e9volution des styles architecturaux, des monolithes aux microservices.
\n<\/a><\/noindex><\/p>\n

Un peu d'histoire<\/h2>\n

\nSi vous essayez de poser la question aux d\u00e9veloppeurs : \u00ab \u00c0 quoi servent les microservices ? \u00bb, vous obtiendrez les r\u00e9ponses les plus vari\u00e9es. Vous entendrez que les microservices am\u00e9liorent la scalabilit\u00e9, simplifient la compr\u00e9hension du code, am\u00e9liorent la r\u00e9silience, et parfois, vous entendrez qu'ils permettent de \u00ab nettoyer le code \u00bb. Retournons \u00e0 l'histoire pour comprendre quel but a conduit \u00e0 l'apparition des microservices.<\/p>\n

En r\u00e9sum\u00e9, les microservices tels que nous les comprenons actuellement sont apparus de la mani\u00e8re suivante : en 2011, James Lewis, en analysant les travaux de diverses entreprises, a remarqu\u00e9 l'\u00e9mergence d'un nouveau mod\u00e8le appel\u00e9 \u00ab micro-app \u00bb, qui optimisait le SOA en termes d'acc\u00e9l\u00e9ration du d\u00e9ploiement des services. Peu apr\u00e8s, en 2012, lors du sommet architectural, ce mod\u00e8le a \u00e9t\u00e9 renomm\u00e9 en microservice. Ainsi, l'objectif initial de l'impl\u00e9mentation des microservices \u00e9tait d'am\u00e9liorer le fameux time to market<\/b>.<\/p>\n

Les microservices \u00e9taient \u00e0 la mode en 2015. D'apr\u00e8s certaines \u00e9tudes, aucune conf\u00e9rence ne se passait sans une pr\u00e9sentation sur le th\u00e8me des microservices. De plus, certaines conf\u00e9rences \u00e9taient exclusivement consacr\u00e9es aux microservices. \u00c0 pr\u00e9sent, de nombreux projets commencent avec ce style architectural, et si un projet contient des tonnes de code h\u00e9rit\u00e9, il y a s\u00fbrement une migration active vers les microservices.<\/p>\n

Malgr\u00e9 tout ce qui pr\u00e9c\u00e8de, un nombre encore relativement faible de d\u00e9veloppeurs peut d\u00e9finir le terme \u00ab microservice \u00bb. Mais nous en parlerons un peu plus tard...<\/p>\n

Monolithe<\/h2>\n

\nLe style architectural qui est oppos\u00e9 aux microservices est le monolithe (ou \u00ab tout en un \u00bb). Parler du monolithe n'a probablement pas de sens, donc je vais tout de suite \u00e9num\u00e9rer les inconv\u00e9nients de ce style architectural, qui ont suscit\u00e9 un d\u00e9veloppement ult\u00e9rieur des styles architecturaux : taille, couplage, d\u00e9ploiement, \u00e9volutivit\u00e9, fiabilit\u00e9 et rigidit\u00e9. Ci-dessous, je vous propose de d\u00e9couvrir chacun des inconv\u00e9nients s\u00e9par\u00e9ment.<\/p>\n

Taille<\/h3>\n

\nLe monolithe est tr\u00e8s grand. Il communique g\u00e9n\u00e9ralement avec une tr\u00e8s grande base de donn\u00e9es. L'application devient trop complexe pour qu'un seul d\u00e9veloppeur puisse la comprendre. Seules les personnes ayant pass\u00e9 beaucoup de temps avec ce code peuvent travailler efficacement sur le monolithe, tandis que les nouveaux d\u00e9veloppeurs passeront \u00e9norm\u00e9ment de temps \u00e0 essayer de le comprendre, sans garantie de succ\u00e8s. En g\u00e9n\u00e9ral, il y a toujours un certain senior \u00ab conditionnel \u00bb qui conna\u00eet le monolithe relativement bien et qui corrige les erreurs des nouveaux d\u00e9veloppeurs pendant un an ou un an et demi. Naturellement, ce senior conditionnel constitue un point de d\u00e9faillance unique, et son d\u00e9part peut mener \u00e0 la perte du monolithe. <\/p>\n

Couplage<\/h3>\n

\nLe monolithe repr\u00e9sente une \u00ab grosse boule de boue \u00bb (big ball of mud), dont les modifications peuvent entra\u00eener des cons\u00e9quences impr\u00e9visibles. En modifiant une partie, on peut endommager au passage une autre partie du monolithe (comme l'expression \u00ab on se gratte l'oreille et on se fait mal ailleurs \u00bb). Cela est d\u00fb au fait que les composants du monolithe ont des interrelations tr\u00e8s complexes et, surtout, non \u00e9videntes.<\/p>\n

D\u00e9ploiement<\/h3>\n

\nLe d\u00e9ploiement d'un monolithe, en raison des relations complexes entre ses composants, est un processus long avec ses propres rituels. Ces rituels ne sont g\u00e9n\u00e9ralement pas compl\u00e8tement standardis\u00e9s et se transmettent \u00ab de bouche \u00e0 oreille \u00bb. <\/p>\n

Scalabilit\u00e9<\/h3>\n

\nLes modules du monolithe peuvent avoir des besoins en ressources conflictuels, ce qui n\u00e9cessite de trouver un compromis du point de vue mat\u00e9riel. Imaginez que votre monolithe se compose des services A et B. Le service A n\u00e9cessite beaucoup d'espace sur le disque dur, tandis que le service B exige beaucoup de m\u00e9moire vive. Dans ce cas, soit la machine sur laquelle le monolithe est install\u00e9 doit r\u00e9pondre aux exigences des deux services, soit il faudra d\u00e9sactiver manuellement l'un des services.<\/p>\n

Un autre exemple (plus classique) : le service A est beaucoup plus populaire que le service B, donc vous souhaitez avoir 100 instances du service A et 10 du service B. L\u00e0 encore, il y a deux options : soit nous d\u00e9ployons 100 monolithes complets, soit nous d\u00e9sactivons manuellement certains services B sur quelques-uns d'entre eux. <\/p>\n

Fiabilit\u00e9<\/h3>\n

\nPuisque tous les services sont regroup\u00e9s, si le monolithe tombe, tous les services tombent \u00e9galement. En r\u00e9alit\u00e9, ce n'est peut-\u00eatre pas si mal, du moins il n'y aura pas de pannes partielles dans un syst\u00e8me distribu\u00e9, mais d'un autre c\u00f4t\u00e9, \u00e0 cause d'une erreur dans une fonction utilis\u00e9e par 0,001 % des utilisateurs, vous pourriez perdre tous les utilisateurs de votre syst\u00e8me. <\/p>\n

Rigidit\u00e9<\/h3>\n

\nEn raison de la taille du monolithe, il est difficile de passer \u00e0 de nouvelles technologies. Par cons\u00e9quent, une t\u00e2che distincte se dessine : retenir ce m\u00eame senior. La pile technologique choisie au d\u00e9but du projet peut devenir un obstacle au d\u00e9veloppement du produit. <\/p>\n

Conclusion<\/h2>\n

\nLa prochaine fois, nous parlerons de la fa\u00e7on dont les gens ont tent\u00e9 de r\u00e9soudre les probl\u00e8mes mentionn\u00e9s en passant aux composants et \u00e0 l'architecture orient\u00e9e services.<\/p>\n

\"Choix<\/a><\/noindex><\/p>\n

\n

Lire aussi :<\/h4>\n

<\/p>\n