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 ultima întâlnire, am discutat despre diferitele tipuri de monolite și despre utilizarea componentelor pentru construirea acestora, incluzând atât componentele de asamblare, cât și cele de distribuire. Am înțeles arhitectura orientată pe servicii.
Acum, în sfârșit, vom defini principalele caracteristici ale arhitecturii microservicelor.
Relația dintre arhitecturi
Este necesar să înțelegem că, pe baza datelor din articolele anterioare, orice serviciu este o componentă, dar nu orice serviciu este un microserviciu.
Caracteristicile arhitecturii microservicelor
Principalele caracteristici ale arhitecturii microservicelor sunt:
- Organizare în funcție de capacitățile de afaceri (Organized around Business Capabilities)
- Produse, nu proiecte (Products not Projects)
- Puncte de intrare inteligente și canale simple (Smart endpoints and dumb pipes)
- Guvernare descentralizată (Decentralized Governance)
- Gestionarea descentralizată a datelor (Decentralized Data Management)
- Automatizarea infrastructurii (Infrastructure Automation)
- Asigurare împotriva defecțiunilor (Design for failure)
- Arhitectura cu evoluție (Evolutionary Design)
Primul punct provine din arhitectura orientată pe servicii, deoarece microserviciile sunt un caz particular al serviciilor. Celelalte puncte merită o atenție separată.
Organizare în funcție de capacitățile de afaceri (Organized around Business Capabilities)
Acum este necesar să ne amintim de legea lui Conway: organizațiile care creează sisteme își structurează arhitectura pentru a reflecta modul de interacțiune din interiorul acestor organizații. Ca exemplu, putem menționa cazul creării unui compilator: o echipă formată din șapte persoane a dezvoltat un compilator cu șapte treceri, iar o echipă din cinci persoane a realizat un compilator cu cinci treceri.
Dacă vorbim despre monolite și microservicii, atunci, în cazul în care dezvoltarea este organizată pe departamente funcționale (backend, frontend, administratori de baze de date), rezultatul este un monolit clasic.
Pentru a obține microservicii, echipele trebuie organizate în funcție de capacitățile de afaceri (echipa de comenzi, echipa de livrări, echipa de catalog). Această organizare va permite echipelor să se concentreze pe crearea unor părți specifice ale aplicației.
Produse, nu proiecte (Products not Projects)
Abordarea de proiect în care echipa transferă funcționalitatea dezvoltată altor echipe, în cazul arhitecturii microservis, este complet inadecvată. Echipa ar trebui să susțină sistemul pe parcursul întregului său ciclu de viață. Compania Amazon, unul dintre liderii implementării microservicelor, a declarat: „creați un produs și voi îl lansați” („you build, you run it”). Abordarea orientată pe produs permite echipei să simtă nevoile afacerii.
Puncte de intrare inteligente și canale simple (Smart endpoints and dumb pipes)
Arhitectura SOA a acordat o mare atenție canalelor de comunicare, în special Enterprise Service Bus (busul de servicii al întreprinderii). Acest lucru duce adesea la Erroneous Spaghetti Box, adică complexitatea monolitului se transformă în complexitatea relațiilor dintre servicii. În arhitectura microservicelor, se utilizează doar metode simple de interacțiune.
Guvernare descentralizată (Decentralized Governance)
Deciziile cheie privind microserviciile trebuie să fie luate de persoanele care dezvoltă cu adevărat microserviciile. Aici, prin decizii cheie se înțelege alegerea
limbajelor de programare, metodologiilor de desfășurare, contractelor pentru interfețele publice etc.
Gestionarea descentralizată a datelor (Decentralized Data Management)
Abordarea standard, în care aplicația se bazează pe o singură bază de date, nu poate lua în considerare specificitățile fiecărui serviciu în parte. MSA implică gestionarea descentralizată a datelor, inclusiv utilizarea diferitelor tehnologii.
Automatizarea infrastructurii (Infrastructure Automation)
MSA susține procesele de desfășurare și livrare continuă. Acest lucru este posibil doar prin automatizarea proceselor. În acest context, desfășurarea unui număr mare de servicii nu mai pare ceva înfricoșător. Procesul de desfășurare ar trebui să devină plictisitor. Al doilea aspect se referă la gestionarea serviciilor în medii de producție. Fără automatizare, gestionarea proceselor care funcționează în medii operaționale diferite devine imposibilă.
Asigurare împotriva defecțiunilor (Design for failure)
Numeroasele servicii MSA sunt susceptibile la eșecuri. Totuși, gestionarea erorilor într-un sistem distribuit este o sarcină destul de complexă. Arhitectura aplicațiilor trebuie să fie rezistentă la astfel de eșecuri. Rebecca Parsons consideră foarte important că nu mai folosim nici măcar interacțiuni intra-proces între servicii, în schimb, pentru comunicare recurgem la HTTP, care nu este nici pe departe la fel de fiabil.
Arhitectura cu evoluție (Evolutionary Design)
Arhitectura sistemului MSA trebuie să evolueze în mod evolutiv. Este recomandabil să se limiteze modificările necesare la limitele unui singur serviciu. De asemenea, trebuie să se țină cont de influența asupra altor servicii. Abordarea tradițională constă în a încerca să rezolve această problemă prin gestionarea versiunilor, dar MSA presupune utilizarea gestionării versiunilor ca
măsură extremă.
Concluzie
După toate cele spuse, putem formula ce sunt microserviciile. Arhitectura microserviciilor este o abordare pentru dezvoltarea unei aplicații individuale sub forma unui set de servicii mici, fiecare dintre ele funcționând în propriul său proces și interacționând prin mecanisme simplificate, adesea prin intermediul API-urilor HTTP. Aceste servicii sunt construite pe baza oportunităților de afaceri și pot fi desfășurate independent folosind un mecanism complet
automatizat de desfășurare. Există un nivel minim de management centralizat al acestor servicii, care pot fi scrise în diferite limbaje de programare și pot folosi diverse tehnologii de stocare a datelor.
Sursa: habr.com
