Tutorial microservicii: Ce este, Architectură și Exemplu

Ce sunt microserviciile?

Servicii micro este un model de arhitectură orientat spre servicii în care aplicațiile sunt construite ca o colecție de diferite cele mai mici unități de servicii independente. Este o Inginerie software abordare care se concentrează pe descompunerea unei aplicații în module cu o singură funcție cu interfețe bine definite. Aceste module pot fi implementate și operate independent de echipe mici care dețin întregul ciclu de viață al serviciului.

Termenul „micro” se referă la dimensionarea unui microserviciu, care trebuie să poată fi gestionată de o singură echipă de dezvoltare (5 până la 10 dezvoltatori). În această metodologie, aplicațiile mari sunt împărțite în cele mai mici unități independente.

Ce este monolitic Architectură?

În termeni simpli, putem spune că arhitectura monolitică este ca un container mare în care toate componentele software ale unei aplicații sunt grupate într-un singur pachet. Să discutăm un exemplu de magazin online în contextul unei arhitecturi monolitice.

Monolitic Architectura aplicației de comerț electronic

În orice aplicație de comerț electronic, există câteva caracteristici standard, cum ar fi Căutare, RevVizualizări și evaluări și plăți. Aceste funcții sunt accesibile clienților folosind browserul sau aplicațiile lor. Atunci când dezvoltatorul site-ului de comerț electronic implementează aplicația, aceasta este o singură unitate monolitică. Codul pentru diferite funcții precum Căutarea, RevVizualizări, evaluări și plăți se află pe același server. Pentru a scala aplicația, trebuie să rulați mai multe instanțe (servere) ale acestor aplicații.

Ce este Microservice Architectură?

Microserviciu Architectură este un stil de dezvoltare arhitecturală care permite construirea de aplicații ca o colecție de mici servicii autonome dezvoltate pentru un domeniu de afaceri. Este o variantă a arhitecturii de stil structural care ajută la aranjarea aplicațiilor ca o colecție de servicii slab cuplată. Microserviciul Architectura conține servicii cu granulație fină și protocoale ușoare.

Să luăm un exemplu de aplicație de comerț electronic dezvoltată cu arhitectură de microservicii. În acest exemplu de arhitectură de microservicii, fiecare microserviciu este concentrat pe o singură capacitate de business. Căutare, Evaluare și RevIew și Payment au fiecare instanța (serverul) lor și comunică între ele.

Servicii micro Architectură

În monolitic Archistructură, toate componentele se combină într-un singur modul. Dar în Microservices Archistructură, acestea sunt răspândite în module individuale (microservicii) care comunică între ele, așa cum se arată în exemplul de microservicii de mai sus.

Comunicarea între microservicii este o comunicare fără stat în care fiecare pereche de cerere și răspuns este independentă. Prin urmare, microserviciile pot comunica fără efort. În Microserviciu ArchiÎn structură, datele sunt federate. Fiecare microserviciu are propriul depozit de date.

Microservicii vs. monolitice Architectură

Servicii micro	Monolitic Architectură
Fiecare unitate a întregii aplicații ar trebui să fie cea mai mică și ar trebui să poată îndeplini un obiectiv specific de afaceri.	O singură bază de cod pentru toate obiectivele de afaceri.
Pornirea serviciului este relativ rapidă.	Pornirea serviciului durează mai mult.
Izolarea defecțiunilor este ușoară. Chiar dacă un serviciu se defectează, celelalte pot continua să funcționeze.	Izolarea erorilor este dificilă. Dacă o anumită caracteristică nu funcționează, întregul sistem se defectează. Pentru a rezolva această problemă, aplicația trebuie reconstruită, retestată și implementată din nou.
Toate microserviciile ar trebui să fie strâns legate între ele, astfel încât modificările făcute într-unul să nu le afecteze pe celălalt.	Arhitectura monolitică este strâns cuplată. Modificările unui modul de cod îl afectează pe celălalt.
Companiile pot aloca mai multe resurse serviciilor care generează un ROI mai mare.	Întrucât serviciile nu sunt izolate, alocarea individuală a resurselor nu este posibilă.
Mai multe resurse hardware ar putea fi alocate serviciului utilizat frecvent. În exemplul de comerț electronic de mai sus, mai mulți utilizatori verifică lista de produse și caută în comparație cu plățile, astfel încât mai multe resurse ar putea fi alocate microserviciului de căutare și listare a produselor.	Scalarea aplicațiilor este provocatoare, precum și risipitoare.
Microserviciile rămân întotdeauna consistente și disponibile continuu.	Instrumentele de dezvoltare devin suprasolicitate, deoarece procesul trebuie să înceapă de la zero.
Datele sunt federate. Acest lucru permite microserviciilor individuale să adopte un model de date cel mai potrivit nevoilor lor.	Datele sunt centralizate.
Echipe mici și concentrate. Dezvoltare paralelă și mai rapidă.	Este necesară o echipă numeroasă și un efort considerabil de gestionare a echipei.
Modificarea modelului de date al unui microserviciu nu afectează celelalte microservicii.	Schimbarea modelului de date afectează întreaga bază de date.
Interacționează cu alte microservicii utilizând interfețe bine definite.	Nu se aplică.
Microserviciile funcționează pe principiul concentrării pe produse, nu pe proiecte.	Pune accentul pe întregul proiect.
Fără dependențe încrucișate între bazele de cod. Puteți utiliza tehnologii diferite pentru diferite microservicii.	O funcție sau program depinde de altele.

Provocări pentru microservicii

• Microserviciile se bazează unele pe altele și vor trebui să comunice între ele.
• În comparație cu sistemele monolitice, există mai multe servicii de monitorizat care sunt dezvoltate folosind diferite limbaje de programare.
• Deoarece este un sistem distribuit, este un model inerent complex.
• Servicii diferite vor avea mecanisme separate, rezultând o cantitate mare de memorie pentru date nestructurate.
• Sunt necesare un management eficient și munca în echipă pentru a preveni problemele în cascadă.
• Reproducerea unei probleme va fi o sarcină dificilă atunci când aceasta a dispărut într-o versiune și reapare în cea mai recentă versiune.
• Implementarea independentă este complicată cu Microservices.
• Arhitectura de microservicii aduce o mulțime de operațiuni.
• Este dificil de gestionat aplicația atunci când în sistem sunt adăugate servicii noi.
• O gamă largă de profesioniști calificați este necesară pentru a oferi suport microserviciilor distribuite eterogen.
• Microserviciul este costisitor, deoarece trebuie să mențineți spațiu pe server diferit pentru diferite sarcini de afaceri.

SOA vs. Microservicii

Serviciile SOA sunt întreținute în cadrul organizației de către un registru care acționează ca o listă de directoare. Aplicațiile trebuie să caute serviciile din registru și să invoce serviciul. Cu alte cuvinte, SOA este la fel ca o orchestră în care fiecare artist cântă cu instrumentul său, în timp ce directorul muzical dă instrucțiuni tuturor.

La celălalt capăt, Microservices este o formă de arhitectură orientată pe servicii, în care aplicațiile sunt construite ca o colecție de diferite servicii mai mici, în loc de un singur software sau o aplicație. Microservices este exact ca o trupă în care fiecare dansator este independent și știe ce trebuie să facă. Așadar, dacă ratează anumiți pași, știu cum să revină la secvența corectă. Iată o comparație detaliată între SOA și Microservices.

Parametru	SOA	Servicii micro
Tipul de proiectare	În SOA, componentele software sunt expuse lumii exterioare pentru utilizare sub formă de servicii.	Micro Service face parte din SOA. Este o implementare a SOA.
Dependenţă	Unitățile de afaceri sunt dependente.	Ele sunt independente unele de altele.
Dimensiunea software-ului	Dimensiunea software-ului este mai mare decât a oricărui software convențional.	Dimensiunea software-ului este întotdeauna mică în Microservices.
Stiva de tehnologie	Stiva de tehnologie este mai mică în comparație cu Microservice.	Tehnologia de microservicii ar putea fi foarte mare.
Natura aplicației	De natură monolitică.	Full stack în natură.
Independent și Focus	Aplicațiile SOA sunt create pentru a îndeplini mai multe sarcini de afaceri.	Sunt construite pentru a îndeplini o singură sarcină de afaceri.
Implementare	Procesul de implementare necesită mult timp.	Implementarea este simplă și necesită mai puțin timp.
Eficiența costurilor	Mai rentabil.	Less rentabil.
Scalabilitate	Less comparativ cu microservicii.	Foarte scalabil.
Logica de afaceri	Componentele logicii de business sunt stocate într-un singur domeniu de servicii, cu protocoale simple de conectare (HTTP cu XML sau JSON) și API bazate pe SDK-uri/Clienți.	Logica de business poate exista în mai multe domenii, cu straturi de tip magistrală de servicii între servicii (Middleware).

Instrumente pentru microservicii

1) Wiremock: testarea microserviciilor

WireMock este o bibliotecă flexibilă pentru stubbing și mocking de servicii web. Poate configura răspunsul returnat de API-ul HTTP atunci când primește o cerere specifică. De asemenea, este utilizată pentru testarea microserviciilor.

Download link: http://wiremock.org/

2) Docker

Docker este un proiect open-source care ne permite să creăm, să implementăm și să rulăm aplicații folosind containere. Folosind aceste containere, dezvoltatorii pot rula o aplicație ca un singur pachet. Acesta vă permite să livrați biblioteci și alte dependențe într-un singur pachet.

Download link: https://www.docker.com/

3) Hystrix

Hystrix este o metodă de toleranță la erori Java bibliotecă. Acest instrument este conceput pentru a separa punctele de acces la servicii, sisteme și biblioteci terțe la distanță într-un mediu distribuit, cum ar fi Microservices. Îmbunătățește sistemul în ansamblu prin izolarea serviciilor defecte și prevenirea efectului în cascadă al defecțiunilor.

Download link: https://github.com/Netflix/Hystrix

Cele mai bune practici ale microserviciilor Architectură

• Depozit de date separat pentru fiecare microserviciu.
• Mențineți codul la un nivel similar de maturitate.
• Construcție separată pentru fiecare microserviciu.
• Tratați întotdeauna fiecare server ca fiind fără stare.

Întrebări frecvente