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.
Ultima dată am vorbit despre diferitele tipuri de monoliți și despre utilizarea componentelor pentru a le construi, atât componente de construcție, cât și componente de implementare. Înțelegem arhitectura orientată spre servicii.
Acum vom defini în sfârșit principalele caracteristici ale unei arhitecturi de microservicii.
Relația dintre arhitecturi
Este necesar să înțelegem că pe baza definițiilor date în articolele anterioare, orice serviciu este o componentă, dar nu orice serviciu este un microserviciu.
Caracteristicile arhitecturii microservicii
Principalele caracteristici ale arhitecturii microservicii sunt:
- Organizat în jurul capacităților de afaceri
- Produse nu Proiecte
- Puncte finale inteligente și țevi proaste
- Guvernare descentralizată
- Managementul descentralizat al datelor
- Automatizarea infrastructurii
- Proiectare pentru eșec
- Arhitectură cu dezvoltare evolutivă (Evolutionary Design)
Primul punct provine din arhitectura orientată pe servicii, deoarece microserviciile sunt un caz special de servicii. Alte puncte merită luate în considerare separat.
Organizat în jurul capacităților de afaceri
Acum este necesar să ne amintim legea lui Conway: organizațiile care creează sisteme își organizează arhitectura, copiend structura interacțiunii din cadrul acestor organizații. Ca exemplu, putem aminti cazul creării unui compilator: o echipă de șapte persoane a dezvoltat un compilator cu șapte treceri, iar o echipă de cinci a dezvoltat un compilator cu cinci treceri.
Dacă vorbim de monoliți și microservicii, atunci dacă dezvoltarea este organizată pe departamente funcționale (backend, frontend, administratori de baze de date), atunci obținem un monolit clasic.
Pentru a obține microservicii, echipele trebuie organizate în funcție de capacitatea de afaceri (comenzi, expedieri, echipă de catalog). Această organizare va permite echipelor să se concentreze pe construirea unor părți specifice ale aplicației.
Produse nu Proiecte
O abordare de proiect în care o echipă transferă funcționalitatea dezvoltată altor echipe este complet nepotrivită în cazul unei arhitecturi de microservicii. Echipa trebuie să susțină sistemul pe tot parcursul ciclului său de viață. Amazon, unul dintre liderii în implementarea microserviciilor, a declarat: „construiți, îl rulați”. Abordarea produsului permite echipei să simtă nevoile afacerii.
Puncte finale inteligente și țevi proaste
Arhitectura SOA a acordat o mare atenție canalelor de comunicare, în special Enterprise Service Bus. Ceea ce duce adesea la Erroreous Spaghetti Box, adică complexitatea monolitului se transformă în complexitatea conexiunilor dintre servicii. Arhitectura microservicii folosește doar metode simple de comunicare.
Guvernare descentralizată
Deciziile cheie cu privire la microservicii ar trebui luate de oamenii care dezvoltă efectiv microservicii. Aici, deciziile cheie înseamnă alegeri
limbaje de programare, metodologia de implementare, contracte publice de interfață etc.
Managementul descentralizat al datelor
Abordarea standard, în care aplicația se bazează pe o singură bază de date, nu poate ține cont de specificul fiecărui serviciu specific. MSA implică gestionarea descentralizată a datelor, inclusiv utilizarea diferitelor tehnologii.
Automatizarea infrastructurii
MSA acceptă procese continue de implementare și livrare. Acest lucru poate fi realizat doar prin automatizarea proceselor. În același timp, implementarea unui număr mare de servicii nu mai arată ca ceva înfricoșător. Procesul de implementare ar trebui să devină plictisitor. Al doilea aspect este legat de managementul serviciilor într-un mediu de produs. Fără automatizare, gestionarea proceselor care rulează în diferite medii de operare devine imposibilă.
Proiectare pentru eșec
Numeroase servicii MSA sunt predispuse la eșec. În același timp, tratarea erorilor într-un sistem distribuit nu este o sarcină banală. Arhitectura aplicației trebuie să fie rezistentă la astfel de eșecuri. Rebecca Parsons crede că este foarte important să nu mai folosim nici măcar comunicarea în proces între servicii, ci să apelăm la HTTP pentru comunicare, care nu este la fel de fiabil.
Arhitectură cu dezvoltare evolutivă (Evolutionary Design)
Arhitectura sistemului MSA ar trebui să se dezvolte evolutiv. Este recomandabil să limitați modificările necesare la limitele unui singur serviciu. Trebuie luat în considerare și impactul asupra altor servicii. Abordarea tradițională este de a încerca să rezolvi această problemă cu versiunea, dar MSA sugerează utilizarea versiunilor în
ca ultimă soluție.
Concluzie
După toate cele de mai sus, putem formula ce sunt microservicii. Arhitectura de microservicii este o abordare a dezvoltării unei singure aplicații ca o colecție de servicii mici, fiecare rulând în propriul proces și interacționând prin mecanisme ușoare, adesea un API de resurse HTTP. Aceste servicii sunt construite pe capacități de afaceri și pot fi implementate independent folosind pe deplin
mecanism de implementare automată. Există un nivel minim de gestionare centralizată a acestor servicii, care pot fi scrise în diferite limbaje de programare și folosesc diferite tehnologii de stocare a datelor.
Sursa: www.habr.com
