Bună, Habr. Astăzi continui seria de publicații pe care am scris-o special pentru lansarea noii grupe a cursului .
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.
În am analizat monolitul și am ajuns la concluzia că acesta are o serie de probleme: dimensiune, legătură, desfășurare, scalabilitate, fiabilitate și inflexibilitate.
De data aceasta, propun să discutăm despre modalitățile de organizare a sistemului sub forma unui set de module/biblioteci (arhitectură orientată pe componente) sau servicii (arhitectură orientată pe servicii).
Arhitectura orientată pe componente
Arhitectura orientată pe componente presupune realizarea sistemului sub forma unui set de componente, care pot fi utilizate atât în proiectele curente, cât și în cele viitoare. În procesul de împărțire a sistemului în componente se iau în considerare: adecvarea lor pentru reutilizare, înlocuibilitatea, independența de context, extensibilitatea, încapsularea și independența.
Prin utilizarea corectă a componentelor, se rezolvă problema „muntelui de murdărie” (dimensiune mare + legătură mare), iar componentele pot reprezenta atât unități de construire (module, biblioteci), cât și unități de desfășurare (servicii). Unitățile de desfășurare nu se reflectă întotdeauna în procesul executabil: de exemplu, o aplicație web și o bază de date sunt desfășurate împreună.
Cel mai adesea, monolitele sunt dezvoltate sub forma unui set de module. Acest (approach) conduce la asigurarea independenței în dezvoltare, dar problemele de scalabilitate și desfășurare independentă, reziliență și independență față de stiva tehnologică comună rămân. De aceea, un modul este o componentă parțial independentă.
Cea mai mare problemă a unui monolit de acest tip constă în faptul că divizarea în module este pur logică și poate fi ușor încălcată de către dezvoltatori. Poate apărea un modul core, care treptat devine un haos, iar graficul de dependențe între module poate crește. Pentru a evita astfel de probleme, dezvoltarea ar trebui să fie realizată fie de o echipă foarte matură, fie sub conducerea unui «arhitect» care se ocupă cu code review full-time și îi sancționează pe dezvoltatorii care încalcă structura logică.
Un monolit «ideal» reprezintă un set de module logic delimitate, fiecare dintre acestea având propria bază de date.
Arhitectură orientată pe servicii
Dacă se presupune totuși organizarea sistemului sub forma unui set de servicii, atunci se vorbește despre arhitectura orientată pe servicii. Principiile acesteia sunt: compatibilitatea aplicațiilor centrate pe utilizatori, reutilizarea multifuncțională a serviciilor de afaceri, independența față de setul de tehnologii și autonomia (evoluția, scalabilitatea și desfășurarea independente).
Arhitectura orientată pe servicii (SOA = service oriented architecture) rezolvă toate problemele menționate ale monolitului: la schimbare este afectat doar un singur serviciu, iar un API bine definit susține o bună încapsulare a componentelor.
Dar nu toate sunt perfect curate: SOA induce apariția unor noi probleme. Apelurile de la distanță sunt mai scumpe decât cele locale, iar redistribuirea responsabilităților între componente a devenit semnificativ mai costisitoare.
Apropo, posibilitatea desfășurării independente este o caracteristică foarte importantă a serviciului. Dacă serviciile trebuie desfășurate împreună sau, mai rău, într-o anumită ordine, atunci sistemul nu poate fi considerat orientat pe servicii. În acest caz, se vorbește despre un monolit distribuit (considerat un antipattern nu doar din perspectiva SOA, ci și a arhitecturii microserviciilor).
Arhitectura orientată pe servicii beneficiază de un bun suport din partea comunității arhitecturale și a furnizorilor. Acest lucru duce la existența multor cursuri și certificări, precum și la modele bine elaborate. Printre acestea se numără, de exemplu, binecunoscuta bus de servicii de întreprindere (ESB = enterprise service bus). Totuși, ESB este un bagaj de la furnizori, ea nu trebuie neapărat utilizată în SOA.
Vârful popularității arhitecturii orientate pe servicii a fost în jurul anului 2008, după care a început o declinare, care a devenit semnificativ mai accentuată după apariția microserviciilor (~2015).
Concluzie
După ce am discutat despre posibilitățile organizării sistemelor informaționale sub formă de servicii și module, propun să trecem, în sfârșit, la principiile arhitecturii microservicilor și să acordăm o atenție deosebită diferenței dintre arhitectura microserviciilor și cea orientată pe servicii în următoarea parte.
Sursa: habr.com
