Bună, habr. Înscrierea pentru un nou flux de curs este deschisă chiar acum la OTUS . În ajunul începerii cursului, vreau să vă împărtășesc articolul meu original.
Introducere
Alegerea stilului arhitectural este una dintre deciziile tehnice fundamentale la construirea unui sistem informatic. În această serie de articole, îmi propun să analizez cele mai populare stiluri arhitecturale pentru aplicațiile de construcție și să răspund la întrebarea când care stil arhitectural este cel mai de preferat. În procesul de prezentare, voi încerca să trasez un lanț logic care explică dezvoltarea stilurilor arhitecturale de la monoliți la microservicii.
Un pic de istorie
Dacă încercați să întrebați dezvoltatorii: „De ce avem nevoie de microservicii?”, veți primi o varietate de răspunsuri. Veți auzi că microservicii îmbunătățesc scalabilitatea, fac codul mai ușor de înțeles, îmbunătățesc toleranța la erori și, uneori, veți auzi că vă permit să „curățați codul”. Să ne uităm la istorie pentru a înțelege scopul din spatele apariției microserviciilor.
Pe scurt, microserviciile în înțelegerea noastră actuală au apărut după cum urmează: în 2011, James Lewis, analizând activitatea diferitelor companii, a atras atenția asupra apariției unui nou model de „micro-aplicație”, care a optimizat SOA în ceea ce privește accelerarea implementării Servicii. Ceva mai târziu, în 2012, la un summit de arhitectură, modelul a fost redenumit microserviciu. Astfel, scopul inițial al introducerii microserviciilor a fost îmbunătățirea notoriilor timp pentru comercializare.
Microserviciile au fost pe val de hype în 2015. Potrivit unor studii, nici o singură conferință nu a fost completă fără un raport pe tema microserviciilor. Mai mult, unele conferințe au fost dedicate exclusiv microserviciilor. În zilele noastre, multe proiecte încep să folosească acest stil arhitectural, iar dacă proiectul conține tone de cod moștenit, atunci migrarea la microservicii este probabil realizată în mod activ.
În ciuda tuturor celor de mai sus, un număr destul de mic de dezvoltatori poate încă defini conceptul de „microserviciu”. Dar despre asta vom vorbi puțin mai târziu...
Monolit
Stilul arhitectural care contrastează microservicii este monolitul (sau all-in-one). Probabil că nu are sens să spunem ce este un monolit, așa că voi enumera imediat dezavantajele acestui stil arhitectural, care a inițiat dezvoltarea ulterioară a stilurilor arhitecturale: dimensiune, conectivitate, implementare, scalabilitate, fiabilitate și rigiditate. Mai jos îmi propun să aruncăm o privire la fiecare dintre deficiențele separat.
Dimensiune
Monolitul este foarte mare. Și de obicei comunică cu o bază de date foarte mare. Aplicația devine prea mare pentru ca un dezvoltator să o înțeleagă. Doar cei care au petrecut mult timp lucrând la acest cod pot lucra bine cu monolitul, în timp ce începătorii vor petrece mult timp încercând să descopere monolitul și nu există nicio garanție că îl vor înțelege. De obicei, atunci când lucrezi cu un monolit, există întotdeauna un senior „condițional” care cunoaște monolitul mai mult sau mai puțin bine și bate mâinile altor dezvoltatori noi în decurs de un an și jumătate. Desigur, un astfel de senior condiționat este un singur punct de eșec, iar plecarea sa poate duce la moartea monolitului.
Conexiunea
Monolitul este o „minge mare de noroi”, modificări în care pot duce la consecințe imprevizibile. Făcând modificări într-un loc, puteți deteriora monolitul în altul (același „te-ai zgâriat la ureche, *@ a căzut”). Acest lucru se datorează faptului că componentele din monolit au relații foarte complexe și, cel mai important, neevidente.
Implementare
Desfășurarea unui monolit, datorită relațiilor complexe dintre componentele sale, este un proces lung, cu propriul ritual. Un astfel de ritual nu este de obicei complet standardizat și este transmis „oral”.
Scalabilitate
Modulele Monolith pot avea nevoi de resurse conflictuale, necesitând un compromis în ceea ce privește hardware-ul. Imaginați-vă că aveți un monolit format din serviciile A și B. Serviciul A necesită dimensiunea hard disk-ului, iar serviciul B necesită RAM. În acest caz, fie mașina pe care este instalat monolitul trebuie să suporte cerințele ambelor servicii, fie va trebui să dezactivați manual, artificial unul dintre servicii.
Un alt exemplu (mai clasic): serviciul A este mult mai popular decât serviciul B, așa că doriți să existe 100 de servicii A și 10 servicii B. Din nou, două opțiuni: fie implementăm 100 de monoliți cu drepturi depline, fie pe unele dintre ele. serviciile B vor trebui dezactivate manual.
Încredere
Deoarece toate serviciile sunt situate împreună, dacă monolitul cade, atunci toate serviciile cad simultan. De fapt, acest lucru poate să nu fie atât de rău, cel puțin nu vor exista eșecuri parțiale într-un sistem distribuit, dar, pe de altă parte, din cauza unui bug în funcționalitate care este utilizat de 0.001% dintre utilizatori, puteți pierde toți utilizatorii. a sistemului dvs.
Inerţie
Datorită dimensiunii monolitului, este dificil să treceți la noi tehnologii. Ca rezultat, păstrarea aceluiași senior este o sarcină separată. Stiva tehnologică aleasă la începutul unui proiect poate deveni un bloc care împiedică dezvoltarea produsului.
Concluzie
Data viitoare vom vorbi despre modul în care oamenii au încercat să rezolve aceste probleme trecând la componente și SOA.
Citeste mai mult:
Sursa: www.habr.com