Tutorial microservicii: Ce este, Architectură și Exemplu

Termenul „micro” se referă la dimensionarea unui microserviciu care trebuie să fie gestionabil 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 profani, puteți spune că arhitectura monolitică este ca un container mare în care toate componentele software ale unei aplicații sunt reunite într-un singur pachet.

Să discutăm un exemplu de magazin de comerț electronic în contextul unei arhitecturi monolitice.

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

În monolitic Architectură, toate componentele se unesc într-un singur modul. Dar, în Microservicii ArchiAcestea 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 Architehnică, datele sunt federate. Fiecare microserviciu are un depozit de date separat. Următorul în asta Java Tutorial de microservicii, vom afla despre diferența dintre microservicii și arhitectura monolitică.

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 bază de cod unică 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 scade, altul poate continua să funcționeze.	Izolarea erorilor este dificilă. Dacă vreo caracteristică specifică nu funcționează, sistemul complet se defectează. Pentru a rezolva această problemă, aplicația trebuie să fie reconstruită, re-testată și, de asemenea, re-implementată.
Toate microserviciile ar trebui să fie ușor cuplate, astfel încât modificările făcute într-unul să nu afecteze pe celălalt.	Arhitectura monolitică este strâns cuplată. Modificările într-un modul de cod îl afectează pe celălalt
Companiile pot implementa mai multe resurse pentru serviciile care generează un ROI mai mare	Deoarece serviciile nu sunt izolate, alocarea individuală a resurselor nu este posibilă
Mai multe resurse hardware ar putea fi alocate serviciului care este utilizat frecvent. În exemplul de comerț electronic de mai sus, un număr mai mare de utilizatori verifică lista de produse și caută în comparație cu plățile. Deci, mai multe resurse ar putea fi alocate microserviciului de căutare și listare de produse.	Scalarea aplicațiilor este provocatoare, precum și risipitoare.
Microserviciile rămân întotdeauna consistente și disponibile în permanență.	Instrumentele de dezvoltare sunt suprasolicitate, deoarece procesul trebuie să înceapă de la zero.
Datele sunt federate. Acest lucru permite microservicii individuale să adopte un model de date cel mai potrivit pentru nevoile sale.	Datele sunt centralizate.
Echipe mici concentrate. Dezvoltare paralelă și mai rapidă	Este necesar o echipă mare și un efort considerabil de management al echipei
Modificarea modelului de date al unui microserviciu nu afectează celelalte microservicii.	Modificarea modelului de date afectează întreaga bază de date
Interacționează cu alte microservicii folosind interfețe bine definite	Nu se aplică
Microserviciile funcționează pe principiul care se concentrează pe produse, nu pe proiecte	Pune accent 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

• MicroServices se bazează unul pe celălalt ș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.
• Serviciile diferite vor avea un mecanism separat, 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 dispare într-o singură versiune și revine în cea mai recentă versiune.
• Implementarea independentă este complicată cu microservicii.
• Arhitectura de microservicii aduce o mulțime de operațiuni.

• Este dificil de gestionat aplicația atunci când noi servicii sunt adăugate la sistem
• Este necesară o gamă largă de profesioniști calificați pentru a susține microservicii 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 menținute în organizație printr-un registru care acționează ca o listă de director. Aplicațiile trebuie să caute serviciile în registru și să invoce serviciul.

În altă lume, 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.

Pe de altă parte, microservicii sunt o formă de stil de arhitectură orientat spre servicii, în care aplicațiile sunt construite ca o colecție de diferite servicii mai mici în loc de un software sau aplicație.

Microservicii sunt la fel ca o trupă în care fiecare dansator este independent și știe ce trebuie să facă. Deci, dacă ratează niște pași, știu cum să revină la secvența corectă. Acum, în acest tutorial privind arhitectura microserviciilor, să învățăm despre diferența dintre SOA și microservicii.

Iată o comparație detaliată între SOA și microservicii

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 orice software convențional	Dimensiunea Software-ului este întotdeauna mică în Microservicii
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ă	Stiva completă î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ă 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 afaceri sunt stocate în interiorul unui singur domeniu de servicii Protocoale simple (HTTP cu XML JSON) API-ul este condus de SDK-uri/Clienți	Logica de afaceri poate trăi pe domeniile întreprindere Service Bus ca straturi între servicii Middleware

Instrumente pentru microservicii

1) Wiremock: testarea microserviciilor

WireMock este o bibliotecă flexibilă pentru stubbing și batjocorirea serviciilor web. Poate configura răspunsul returnat de API-ul HTTP atunci când primește o cerere specifică. Este, de asemenea, folosit 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. Vă permite să expediați biblioteci și alte dependențe într-un singur pachet.

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

3) Hystrix

Hystrix este o bibliotecă Java cu toleranță la erori. Acest instrument este conceput pentru a separa punctele de acces la servicii la distanță, sisteme și biblioteci terță parte într-un mediu distribuit precum Microservicii. Îmbunătățește sistemul general prin izolarea serviciilor care defectează și prevenind efectul în cascadă al defecțiunilor.

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

Cele mai bune practici ale microserviciilor Architectură

• Magazin de date separat pentru fiecare microserviciu
• Păstrați codul de un nivel similar de maturitate.
• Compilare separată pentru fiecare serviciu Micro.
• Tratează întotdeauna – sever ca apatrid.

Rezumat

• Microservicii 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.
• Microserviciu Architectura este un stil de dezvoltare arhitecturală care permite construirea unei aplicații ca o colecție de mici servicii autonome dezvoltate pentru un domeniu de afaceri.
• Arhitectura monolitică este ca un container mare în care toate componentele software ale unei aplicații sunt reunite într-un singur pachet
• Într-un microserviciu, fiecare unitate a întregii aplicații ar trebui să fie cea mai mică și ar trebui să poată îndeplini un obiectiv de afaceri specific
• În arhitectura monolitică, baza de cod mare poate încetini întregul proces de dezvoltare. Noile lansări pot dura luni de zile. Întreținerea codului este dificilă
• Două tipuri de microservicii sunt 1) Stateless 2) Stateful
• Microservicii în Java se bazează unul pe altul și vor trebui să comunice între ei. Vă ajută să puneți accent pe o caracteristică specifică și pe nevoile de afaceri
• Arhitectura orientată spre servicii, cunoscută în scurt timp ca SOA, este o evoluție a calculului distribuit bazată pe modelul de proiectare de cerere sau răspuns pentru aplicații sincrone și asincrone
• În SOA, componentele software sunt expuse lumii exterioare pentru utilizare sub formă de servicii, în timp ce Micro Service face parte din SOA. Este o implementare a SOA
• Wiremock, Docker și Hystrix sunt câteva instrumente populare pentru microservicii