de Pulkit Kumar

O introducere în arhitecturi orientate spre servicii și micro-servicii

Am parcurs un drum lung de la arhitectura tradițională pe trei niveluri monolit. Pentru a obține un model de dezvoltare rapid, robust și scalabil, ați putea încerca să vă aliniați arhitectura aplicației cu anumite filozofii și tipare de dezvoltare, în speranța că ar putea facilita gestionarea echipei și a calendarelor de dezvoltare.

Dar când vă dați seama de fapt că există atât de multe modele de dezvoltare, încât nu puteți decide asupra vreunui anume, deoarece fiecare altul pare mai bun, ați putea dori să citiți această postare.

Să începem cu elementele de bază și să obținem o anumită claritate asupra jargonului.

Ce este arhitectura orientată spre microservicii?

În afară de faptul că microserviciul este un cuvânt cheie, din principiile de proiectare ale microserviciilor, acesta poate fi definit pur și simplu ca:

Un serviciu extrem de coeziv, unic și descentralizat.

Adică un serviciu care are un singur și un singur scop și este autosuficient.

Orice serviciu care se potrivește cu proprietățile menționate în definiție poate fi denumit microserviciu. Principiile de proiectare menționate sunt:

1. Scop unic: Serviciul ar trebui să se concentreze asupra unui singur scop. Serviciul ar trebui să fie axat pe domeniu și obiectiv. De exemplu, un microserviciu poate fi concentrat doar pe un mecanism de autentificare.
2. Coeziune ridicată: Serviciul ar trebui să fie autosuficient în ceea ce privește cerințele domeniului și infrastructura domeniului. Serviciul ar trebui să aibă toate caracteristicile de care are nevoie pentru îndeplinirea scopului unic. De exemplu, un microserviciu de conectare poate avea propria bază de date.
3. Descentralizat: Serviciul ar trebui să fie descentralizat din alte servicii și infrastructură dintr-un punct de vedere logic, astfel încât orice modificare necesară în microserviciu să nu implice modificări în niciun alt microserviciu. De exemplu, un microserviciu de conectare ar trebui să aibă propriul set de componente de infrastructură, iar modificările necesare în microserviciul de conectare nu ar trebui să implice modificări în niciun alt microserviciu.

Folosind modelul de arhitectură microservice, vă puteți împărți echipa de aplicații în mai multe echipe axat pe microserviciu. De exemplu, un microserviciu de căutare poate avea propria echipă și un microserviciu de conectare poate avea propria echipă. Ambele echipe pot include persoane cu experiență în aceleași domenii, cum ar fi baza de date, frontend și backend, dat fiind faptul că ambele microservicii pot avea propria bază de date, frontend și backend.

Pro-urile utilizării arhitecturii orientate spre microservicii includ:

• Echipele pot fi aranjate în jurul caracteristicilor / componentelor din produs.

Modificările într-o caracteristică / componentă necesită o schimbare numai în setul respectiv.

• Indicarea și localizarea erorilor sunt ușoare.
• Simfonia domeniilor poate aduce soluții inovatoare.
• Gestionarea funcției devine ușoară.
• Mai multe resurse pentru o anumită caracteristică pot fi adăugate dacă este nevoie să adăugați ceva push.

Contra utilizării arhitecturii orientate spre microservicii include:

• Microserviciul-mesh poate fi un cost suplimentar de gestionat.
• Resursele din punct de vedere al dezvoltatorilor pot fi costisitoare.
• Echipele ar putea crește pe măsură ce componentele / caracteristicile din aplicație o fac.
• Localizarea soluțiilor se poate întâmpla dacă cunoștințele nu sunt împărtășite frecvent între echipe.
• Calitatea codului este diferită între microservicii.

Ce este arhitectura orientată spre servicii?

Într-o arhitectură orientată spre servicii, serviciile sunt împărțite pe baza rolului lor în stratul aplicației.

De exemplu, serviciul de baze de date, serviciul frontend, serviciul backend etc. sunt segregări logice ale serviciilor. Aceste servicii sunt utilizate de diferite componente ale aplicației.

Arhitecturile orientate spre servicii ar putea fi o alegere mai bună atunci când aplicația nu are un ecosistem foarte mare de caracteristici / componente diverse, iar componentele pot partaja în mod logic serviciile.

Folosind modelul de arhitectură orientat spre servicii, echipele pot fi ușor împărțite în ceea ce privește expertiza domeniului lor.

De exemplu, echipele pot fi împărțite pur și simplu în backend, devops, bază de date, mobil etc. Dacă orice componentă necesită un serviciu, clientul (care dezvoltă componenta) va contacta echipa de service și, astfel, toate informațiile de bază despre serviciu rămân localizat cu echipa de service.

Pro-urile utilizării arhitecturii orientate spre servicii includ:

• Calitatea codului este consecventă prin domeniu.
• Partajarea cunoștințelor este ușoară în cadrul domeniului.
• Greșelile nu sunt repetate, deoarece echipa domeniului este conștientă de eșecurile anterioare.
• Mai multe resurse pot fi puse în funcțiune dacă este nevoie.

Contra utilizării arhitecturii orientate spre servicii include:

• Bug / break într-un singur serviciu poate afecta mai multe servicii / straturi.
• Simfonia domeniilor lipsește din cauza căreia ar putea lipsi inovația.
• Echipele ar putea ajunge să lucreze pe un singur strat dacă nu sunt gestionate corect.
• Gestionarea mai multor funcții este dificilă, deoarece ar putea implica schimbări în mai multe servicii.
• Un serviciu ar putea ajunge să se schimbe foarte mult.

Ce este comun în ambele?

Ambele modele de dezvoltare diferă de monolitul tradițional într-un mod semnificativ.

Dar ambele necesită ca echipele și componentele să se concentreze asupra unui singur lucru.

Conceptele de segregare și localizare sunt la baza ambelor modele. Ambele tipare sunt în general aliniate cu filosofia DevOps pentru a oferi o creștere rapidă între echipe.

Concluzie

Deoarece monolitul nu poate satisface nevoile dezvoltării moderne și agile, este posibil să doriți să vă aliniați practicile de dezvoltare, precum și echipele, cu una dintre cele două abordări.

Microserviciul este un cuvânt cheie în zilele noastre, dar asta nu înseamnă că este cea mai bună soluție la problemele tale.

Dacă aplicația dvs. necesită separarea echipelor pe baza domeniului de expertiză, cum ar fi baza de date, frontend, backend, știința datelor, etc., atunci abordarea orientată spre servicii ar putea fi cea mai bună pentru dvs.

Dacă aplicația dvs. are nevoie de multe funcții de plug-in diferite, care necesită propriile resurse, cum ar fi propria bază de date, frontend, backend etc., poate doriți să mergeți cu arhitectura orientată spre microservicii și să vă concentrați echipele pe anumite seturi de caracteristici.

Cu toate acestea, puteți merge și cu abordarea hibridă. Abordarea hibridă ar putea fi utilă atunci când construiți o platformă cu mai multe aplicații.

De exemplu, dacă doriți să construiți un magazin de aplicații intern, echipa care dezvoltă platforma (magazin de aplicații / echipa de platformă) poate fi împărțită în continuare într-un model orientat spre servicii; întrucât echipele care construiesc aplicații (app-teams) pot fi concentrate și împărțite în microservicii.

Înscrieți-vă la newsletter-ul meu a obține acces liber la consultanță software, cursuri, articole, rezumate săptămânale și oferte exclusive de listă.