Bună, Habr. Astăzi continui o serie de publicații pe care le-am scris special pentru începerea unui nou flux al cursului. .
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.
В ne-am ocupat de monolit și am ajuns la concluzia că monolitul are o serie de probleme: dimensiune, conectivitate, implementare, scalabilitate, fiabilitate și rigiditate.
De data aceasta imi propun sa vorbim despre posibilitatile de organizare a unui sistem ca un set de module/biblioteci (arhitectura orientata pe componente) sau servicii (arhitectura orientata pe servicii).
Arhitectură orientată pe componente
Arhitectura orientată pe componente presupune executarea unui sistem ca un set de componente care pot fi utilizate atât în proiectele curente, cât și în cele viitoare. La defalcarea unui sistem în componente, se iau în considerare următoarele: reutilizarea lor, înlocuirea lor, independența de context, extensibilitatea, încapsularea și independența.
Cu utilizarea corectă a componentelor, problema „mingii mari de murdărie” (dimensiune mare + cuplare mare) este rezolvată, iar componentele în sine pot fi atât unități de asamblare (module, biblioteci), cât și unități de desfășurare (servicii). Unitățile de implementare nu sunt întotdeauna mapate la procesul care rulează: de exemplu, o aplicație web și o bază de date sunt implementate împreună.
Cel mai adesea, monoliții sunt dezvoltați ca un set de module. Această abordare duce la o dezvoltare independentă, dar problemele de scalare și implementare independente, toleranța la erori și independența față de tehnologia generală rămân. De aceea modulul este o componentă parțial independentă.
Cea mai mare problemă cu un astfel de monolit este că împărțirea în module este pur logică și poate fi spartă cu ușurință de către dezvoltatori. Poate apărea un modul de bază, care se transformă treptat într-o groapă de gunoi, graficul dependențelor dintre module poate crește și așa mai departe. Pentru a evita astfel de probleme, dezvoltarea ar trebui să fie efectuată fie de o echipă foarte matură, fie sub îndrumarea unui „arhitect” care este angajat în revizuirea codului cu normă întreagă și bate mâinile dezvoltatorilor care încalcă structura logică.
Monolitul „ideal” este un set de module separate logic, fiecare dintre ele se uită în propria sa bază de date.
Arhitectura orientată spre servicii
Dacă sistemul ar trebui să fie organizat sub forma unui set de servicii, atunci vorbim de o arhitectură orientată spre servicii. Principiile sale sunt interoperabilitatea aplicațiilor centrate pe utilizator, reutilizarea serviciilor de afaceri, independența stivei de tehnologie și autonomia (evoluție independentă, scalabilitate și implementare).
Arhitectura orientată pe servicii (SOA = arhitectură orientată pe servicii) rezolvă toate problemele identificate ale unui monolit: doar un serviciu este afectat atunci când are loc o schimbare, iar un API bine definit acceptă o bună încapsulare a componentelor.
Dar nu totul este atât de lin: SOA creează noi probleme. Apelurile de la distanță sunt mai scumpe decât cele locale, iar redistribuirea responsabilităților între componente a devenit mult mai costisitoare.
Apropo, posibilitatea implementării independente este o caracteristică foarte importantă a serviciului. Dacă serviciile trebuie implementate împreună sau, în plus, într-o anumită secvență, atunci sistemul nu poate fi considerat orientat către servicii. În acest caz, se vorbește despre un monolit distribuit (considerat un anti-patter nu doar din punct de vedere al SOA, ci și din punct de vedere al arhitecturii microservicii).
Arhitectura orientată spre servicii este bine susținută de comunitatea arhitecturală și de furnizori. Aceasta implică prezența multor cursuri și certificări, modele bine dezvoltate. Acesta din urmă include, de exemplu, binecunoscutul bus enterprise service (ESB = enterprise service bus). În același timp, ESB este un bagaj de la furnizori, nu trebuie neapărat să fie folosit în SOA.
Popularitatea arhitecturii orientate spre servicii a atins apogeul în jurul anului 2008, după care a început să scadă, ceea ce a devenit semnificativ mai dramatic după apariția microserviciilor (~2015).
Concluzie
După ce am discutat despre posibilitățile de organizare a sistemelor informaționale sub formă de servicii și module, îmi propun să trecem în sfârșit la principiile arhitecturii microservicii și să acordăm o atenție deosebită diferenței dintre arhitectura microservicii și arhitectura orientată pe servicii în partea următoare.
Sursa: www.habr.com