Salut, Habr. În acest moment, OTUS a deschis o nouă perioadă a cursului. . Cu ocazia începerii cursului, vreau să împărtășesc cu voi articolul meu autor.
Introducere
Alegerea stilului arhitectural este una dintre deciziile tehnice fundamentale în construirea unui sistem informațional. În această serie de articole, propun să analizez cele mai populare stiluri arhitecturale pentru construirea aplicațiilor și să răspund la întrebarea când este preferabil un anumit stil arhitectural. Pe parcursul expunerii, voi încerca să urmez un fir logic care explică evoluția stilurilor arhitecturale de la monolite la microservicii.
Puțin istorie
Dacă încerci să întrebi dezvoltatorii: „De ce sunt necesare microserviciile?”, vei primi cele mai variate răspunsuri. Vei auzi că microserviciile îmbunătățesc scalabilitatea, simplifică înțelegerea codului, îmbunătățesc reziliența, uneori poți auzi că ele permit „curățarea codului”. Haideți să ne întoarcem la istorie pentru a înțelege ce scop a avut apariția microserviciilor.
Pe scurt, microserviciile, așa cum le înțelegem acum, au apărut astfel: în 2011, James Lewis, analizând lucrările diferitelor companii, a observat apariția unui nou model „micro-app”, care a optimizat SOA în ceea ce privește accelerarea desfășurării serviciilor. Puțin mai târziu, în 2012, la summitul arhitectural, modelul a fost redenumit microserviciu. Astfel, scopul inițial al implementării microserviciilor a fost îmbunătățirea celebrului time to market.
Pe valul hype-ului, microserviciile au fost în 2015. Conform unor cercetări, nicio conferință nu se desfășura fără o prezentare pe tema microserviciilor. Mai mult, unele conferințe au fost dedicate exclusiv microserviciilor. Acum, multe proiecte încep să utilizeze acest stil arhitectural, iar dacă un proiect conține tone de cod vechi, atunci cu siguranță se desfășoară o migrare activă către microservicii.
În ciuda celor spuse mai sus, în continuare un număr relativ mic de dezvoltatori poate defini conceptul de „microserviciu”. Dar despre asta vom vorbi puțin mai târziu…
Monolit
Stilul arhitectural, opus microserviciilor, este monolitul (sau „totul într-unul”). Probabil că nu are sens să explicăm ce este un monolit, așa că voi lista imediat dezavantajele acestui stil arhitectural, care au inițiat dezvoltarea ulterior a stilurilor arhitecturale: dimensiune, interdependență, desfășurare, scalabilitate, fiabilitate și rigiditate. Mai jos, vă propun să ne familiarizăm cu fiecare dintre dezavantaje separat.
Dimensiune
Monolitul este foarte mare. De obicei comunică cu o bază de date foarte extinsă. Aplicația devine prea mare pentru a fi înțeleasă de un singur dezvoltator. Numai cei care au petrecut mult timp cu acest cod pot lucra eficient cu monolitul, în timp ce începătorii vor pierde foarte mult timp încercând să înțeleagă monolitul, fără garanția că vor reuși. De obicei, în timpul lucrului cu monolitul, există un „senior” „condiționat” care cunoaște monolitul destul de bine și care îi corectează pe noii dezvoltatori pe parcursul unui an sau a unei perioade de un an și jumătate. Evident, acest senior „condiționat” reprezintă un punct unic de eșec, iar plecarea sa poate duce la distrugerea monolitului.
Legătura
Monolitul este pur și simplu „o mare bulă de noroi” (big ball of mud), iar modificările în acesta pot provoca consecințe imprevizibile. Schimbând ceva într-un loc, poți afecta monolitul în alt loc (același lucru cu „m-am scărpinat la ureche, *@ s-a desprins”). Acest lucru este legat de faptul că componentele din monolit au relații foarte complexe și, cel mai important, neașteptate.
Implementare
Implementarea monolitului, datorită relațiilor complexe dintre componentele sale, este un proces îndelungat cu propriul său ritual. Acest ritual nu este de obicei complet standardizat și se transmite „din gură în gură”.
Scalabilitate
Mediile monolitului pot avea nevoi conflictuale în ceea ce privește resursele, ceea ce face necesară găsirea unui compromis din perspectiva hardware-ului. Imaginează-ți că monolitul tău este format din serviciile A și B. Serviciul A are cerințe mari legate de dimensiunea discului dur, în timp ce servicii B este necesar în ce privește memoria RAM. În acest caz, fie mașina pe care este instalat monolitul trebuie să susțină cerințele ambelor servicii, fie va fi necesar să dezactivezi manual unul dintre servicii.
Un alt exemplu (mai clasic): serviciul A este mult mai popular decât serviciul B, așa că vrei să ai 100 de instanțe ale serviciului A și 10 instanțe ale serviciului B. Din nou, există două opțiuni: fie desfășurăm 100 de monolite complete, fie va fi nevoie să dezactivezi manual anumite servicii B pe unele dintre acestea.
Fiabilitate
Deoarece toate serviciile sunt împreună, dacă monolitul se prăbușește, toate serviciile cedează simultan. În realitate, este posibil ca acest lucru să nu fie atât de rău, cel puțin nu vor exista defecțiuni parțiale într-un sistem distribuit, dar, pe de altă parte, din cauza unei erori în funcționalitate, folosită de 0.001% din utilizatori, ai putea pierde toți utilizatorii sistemului tău.
Rigiditate
Din cauza dimensiunii monolitului, este greu să treci la noi tehnologii. Ca urmare, o sarcină separată devine menținerea acelui senior ipotetic. Tehnologia aleasă la începutul proiectului poate deveni un blocaj în evoluția produsului.
Concluzie
Data viitoare vom discuta despre cum oamenii au încercat să rezolve problemele enunțate, trecând la componente și SOA.
Citește mai mult:
Sursa: habr.com
