{"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\/ro\/blog\/administrirovanie\/vybor-arhitekturnogo-stilya-chast-1","title":{"rendered":"Alegerea stilului arhitectural (partea 1)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Salut, Habr. \u00cen acest moment, OTUS a deschis o nou\u0103 perioad\u0103 a cursului. \u201eSoftware Architect\u201d<\/a><\/noindex>. Cu ocazia \u00eenceperii cursului, vreau s\u0103 \u00eemp\u0103rt\u0103\u0219esc cu voi articolul meu autor.<\/i><\/b><\/p>\n

<\/p>\n

Introducere<\/h2>\n

\nAlegerea stilului arhitectural este una dintre deciziile tehnice fundamentale \u00een construirea unui sistem informa\u021bional. \u00cen aceast\u0103 serie de articole, propun s\u0103 analizez cele mai populare stiluri arhitecturale pentru construirea aplica\u021biilor \u0219i s\u0103 r\u0103spund la \u00eentrebarea c\u00e2nd este preferabil un anumit stil arhitectural. Pe parcursul expunerii, voi \u00eencerca s\u0103 urmez un fir logic care explic\u0103 evolu\u021bia stilurilor arhitecturale de la monolite la microservicii.
\n<\/a><\/noindex><\/p>\n

Pu\u021bin istorie<\/h2>\n

\nDac\u0103 \u00eencerci s\u0103 \u00eentrebi dezvoltatorii: \u201eDe ce sunt necesare microserviciile?\u201d, vei primi cele mai variate r\u0103spunsuri. Vei auzi c\u0103 microserviciile \u00eembun\u0103t\u0103\u021besc scalabilitatea, simplific\u0103 \u00een\u021belegerea codului, \u00eembun\u0103t\u0103\u021besc rezilien\u021ba, uneori po\u021bi auzi c\u0103 ele permit \u201ecur\u0103\u021barea codului\u201d. Haide\u021bi s\u0103 ne \u00eentoarcem la istorie pentru a \u00een\u021belege ce scop a avut apari\u021bia microserviciilor.<\/p>\n

Pe scurt, microserviciile, a\u0219a cum le \u00een\u021belegem acum, au ap\u0103rut astfel: \u00een 2011, James Lewis, analiz\u00e2nd lucr\u0103rile diferitelor companii, a observat apari\u021bia unui nou model \u201emicro-app\u201d, care a optimizat SOA \u00een ceea ce prive\u0219te accelerarea desf\u0103\u0219ur\u0103rii serviciilor. Pu\u021bin mai t\u00e2rziu, \u00een 2012, la summitul arhitectural, modelul a fost redenumit microserviciu. Astfel, scopul ini\u021bial al implement\u0103rii microserviciilor a fost \u00eembun\u0103t\u0103\u021birea celebrului time to market<\/b>.<\/p>\n

Pe valul hype-ului, microserviciile au fost \u00een 2015. Conform unor cercet\u0103ri, nicio conferin\u021b\u0103 nu se desf\u0103\u0219ura f\u0103r\u0103 o prezentare pe tema microserviciilor. Mai mult, unele conferin\u021be au fost dedicate exclusiv microserviciilor. Acum, multe proiecte \u00eencep s\u0103 utilizeze acest stil arhitectural, iar dac\u0103 un proiect con\u021bine tone de cod vechi, atunci cu siguran\u021b\u0103 se desf\u0103\u0219oar\u0103 o migrare activ\u0103 c\u0103tre microservicii.<\/p>\n

\u00cen ciuda celor spuse mai sus, \u00een continuare un num\u0103r relativ mic de dezvoltatori poate defini conceptul de \u201emicroserviciu\u201d. Dar despre asta vom vorbi pu\u021bin mai t\u00e2rziu\u2026<\/p>\n

Monolit<\/h2>\n

\nStilul arhitectural, opus microserviciilor, este monolitul (sau \u201etotul \u00eentr-unul\u201d). Probabil c\u0103 nu are sens s\u0103 explic\u0103m ce este un monolit, a\u0219a c\u0103 voi lista imediat dezavantajele acestui stil arhitectural, care au ini\u021biat dezvoltarea ulterior a stilurilor arhitecturale: dimensiune, interdependen\u021b\u0103, desf\u0103\u0219urare, scalabilitate, fiabilitate \u0219i rigiditate. Mai jos, v\u0103 propun s\u0103 ne familiariz\u0103m cu fiecare dintre dezavantaje separat.<\/p>\n

Dimensiune<\/h3>\n

\nMonolitul este foarte mare. De obicei comunic\u0103 cu o baz\u0103 de date foarte extins\u0103. Aplica\u021bia devine prea mare pentru a fi \u00een\u021beleas\u0103 de un singur dezvoltator. Numai cei care au petrecut mult timp cu acest cod pot lucra eficient cu monolitul, \u00een timp ce \u00eencep\u0103torii vor pierde foarte mult timp \u00eencerc\u00e2nd s\u0103 \u00een\u021beleag\u0103 monolitul, f\u0103r\u0103 garan\u021bia c\u0103 vor reu\u0219i. De obicei, \u00een timpul lucrului cu monolitul, exist\u0103 un \u201esenior\u201d \u201econdi\u021bionat\u201d care cunoa\u0219te monolitul destul de bine \u0219i care \u00eei corecteaz\u0103 pe noii dezvoltatori pe parcursul unui an sau a unei perioade de un an \u0219i jum\u0103tate. Evident, acest senior \u201econdi\u021bionat\u201d reprezint\u0103 un punct unic de e\u0219ec, iar plecarea sa poate duce la distrugerea monolitului. <\/p>\n

Leg\u0103tura<\/h3>\n

\nMonolitul este pur \u0219i simplu \u201eo mare bul\u0103 de noroi\u201d (big ball of mud), iar modific\u0103rile \u00een acesta pot provoca consecin\u021be imprevizibile. Schimb\u00e2nd ceva \u00eentr-un loc, po\u021bi afecta monolitul \u00een alt loc (acela\u0219i lucru cu \u201em-am sc\u0103rpinat la ureche, *@ s-a desprins\u201d). Acest lucru este legat de faptul c\u0103 componentele din monolit au rela\u021bii foarte complexe \u0219i, cel mai important, nea\u0219teptate.<\/p>\n

Implementare<\/h3>\n

\nImplementarea monolitului, datorit\u0103 rela\u021biilor complexe dintre componentele sale, este un proces \u00eendelungat cu propriul s\u0103u ritual. Acest ritual nu este de obicei complet standardizat \u0219i se transmite \u201edin gur\u0103 \u00een gur\u0103\u201d. <\/p>\n

Scalabilitate<\/h3>\n

\nMediile monolitului pot avea nevoi conflictuale \u00een ceea ce prive\u0219te resursele, ceea ce face necesar\u0103 g\u0103sirea unui compromis din perspectiva hardware-ului. Imagineaz\u0103-\u021bi c\u0103 monolitul t\u0103u este format din serviciile A \u0219i B. Serviciul A are cerin\u021be mari legate de dimensiunea discului dur, \u00een timp ce servicii B este necesar \u00een ce prive\u0219te memoria RAM. \u00cen acest caz, fie ma\u0219ina pe care este instalat monolitul trebuie s\u0103 sus\u021bin\u0103 cerin\u021bele ambelor servicii, fie va fi necesar s\u0103 dezactivezi manual unul dintre servicii.<\/p>\n

Un alt exemplu (mai clasic): serviciul A este mult mai popular dec\u00e2t serviciul B, a\u0219a c\u0103 vrei s\u0103 ai 100 de instan\u021be ale serviciului A \u0219i 10 instan\u021be ale serviciului B. Din nou, exist\u0103 dou\u0103 op\u021biuni: fie desf\u0103\u0219ur\u0103m 100 de monolite complete, fie va fi nevoie s\u0103 dezactivezi manual anumite servicii B pe unele dintre acestea. <\/p>\n

Fiabilitate<\/h3>\n

\nDeoarece toate serviciile sunt \u00eempreun\u0103, dac\u0103 monolitul se pr\u0103bu\u0219e\u0219te, toate serviciile cedeaz\u0103 simultan. \u00cen realitate, este posibil ca acest lucru s\u0103 nu fie at\u00e2t de r\u0103u, cel pu\u021bin nu vor exista defec\u021biuni par\u021biale \u00eentr-un sistem distribuit, dar, pe de alt\u0103 parte, din cauza unei erori \u00een func\u021bionalitate, folosit\u0103 de 0.001% din utilizatori, ai putea pierde to\u021bi utilizatorii sistemului t\u0103u. <\/p>\n

Rigiditate<\/h3>\n

\nDatorit\u0103 dimensiunii monolitului, este dificil s\u0103 se treac\u0103 la noi tehnologii. Ca urmare, o sarcin\u0103 distinct\u0103 devine p\u0103strarea acelui senior care este condi\u021bionat. Tehnologia aleas\u0103 la \u00eenceputul proiectului poate deveni un blocaj care \u00eempiedic\u0103 dezvoltarea produsului. <\/p>\n

Concluzie<\/h2>\n

\nData viitoare vom discuta despre cum oamenii au \u00eencercat s\u0103 rezolve problemele enun\u021bate, trec\u00e2nd la componente \u0219i SOA.<\/p>\n

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

\n

Cite\u0219te mai mult:<\/h4>\n

<\/p>\n