Arhitectura Microservice:
Din a mea , trebuie să aveți o înțelegere de bază a arhitecturii Microservice.Dar, fiind un profesionist cu va necesita mai mult decât doar elementele de bază. În acest blog, veți intra în profunzimea conceptelor arhitecturale și le veți implementa folosind un studiu de caz UBER.
În acest blog, veți afla despre următoarele:
- Definiția arhitecturii Microservice
- Concepte cheie ale arhitecturii Microservice
- Pro și contra ale arhitecturii Microservice
- UBER - Studiu de caz
Puteți face referire la , pentru a înțelege fundamentele și beneficiile Microserviciilor.
Va fi corect doar dacă vă dau definiția Microservicii.
Definiția Microserviciilor
Ca atare, nu există o definiție adecvată a Microserviciilor, numită Microservice Architecture, dar puteți spune că este un cadru care constă din servicii mici, implementabile individual, care efectuează operațiuni diferite.
Microserviciile se concentrează pe un singur domeniu de afaceri care poate fi implementat ca servicii depline independente și implementabile pe diferite stive de tehnologie.
Figura 1: Diferența dintre arhitectura monolitică și cea de microserviciu - Microservice Architecture
Consultați diagrama de mai sus pentru a înțelege diferența dintre arhitectura monolitică și cea de microservire.Pentru o mai bună înțelegere a diferențelor dintre ambele arhitecturi, puteți consulta blogul meu anterior
Pentru a vă face să înțelegeți mai bine, permiteți-mi să vă spun câteva concepte cheie ale arhitecturii microservice.
Concepte cheie ale arhitecturii Microservice
Înainte de a începe să creați propriile aplicații folosind microservicii, trebuie să fiți clar cu privire la domeniul de aplicare și funcționalitățile aplicației dvs.
Următoarele sunt câteva linii directoare care trebuie urmate în timpul discutării microserviciilor.
Îndrumări în timpul proiectării microserviciilor
- Ca dezvoltator, atunci când decideți să creați o aplicație, separați domeniile și fiți clar cu funcționalitățile.
- Fiecare microserviciu pe care îl proiectați se va concentra numai pe un singur serviciu al aplicației.
- Asigurați-vă că ați proiectat aplicația astfel încât fiecare serviciu să poată fi implementat individual.
- Asigurați-vă că comunicarea dintre microservicii se realizează prin intermediul unui server fără stat.
- Fiecare serviciu poate fi suplimentat refactorizat în servicii mai mici, având propriile lor microservicii.
Acum, că ați citit liniile directoare de bază în timp ce proiectați microservicii, să înțelegem arhitectura microservicilor.
Cum funcționează arhitectura Microservice?
O arhitectură tipică de microserviciu (MSA) ar trebui să conțină următoarele componente:
- Clienți
- Furnizori de identitate
- API Gateway
- Formate de mesagerie
- Baze de date
- Conținut static
- Management
- Descoperirea serviciului
Consultați diagrama de mai jos.
Figura 2: Arhitectura Microservicilor - Microservice Architecture
Știu că arhitectura arată cam complexă, dar haiEusimplifică-l pentru tine.
1. Clienți
Arhitectura începe cu diferite tipuri de clienți, de la diferite dispozitive care încearcă să realizeze diverse capabilități de gestionare, cum ar fi căutarea, construirea, configurarea etc.
2. Furnizori de identitate
Aceste solicitări de la clienți sunt apoi transmise furnizorilor de identitate care autentifică solicitările clienților și comunică solicitările către API Gateway. Solicitările sunt apoi comunicate serviciilor interne prin intermediul API Gateway bine definit.
3. Gateway API
Deoarece clienții nu apelează direct serviciile, API Gateway acționează ca un punct de intrare pentru clienți pentru a redirecționa cererile către microserviciile corespunzătoare.
Avantajele utilizării unui gateway API includ:
- Toate serviciile pot fi actualizate fără ca clienții să știe.
- Serviciile pot utiliza, de asemenea, protocoale de mesagerie care nu sunt compatibile cu web-ul.
- Gateway-ul API poate îndeplini funcții transversale, cum ar fi asigurarea securității, echilibrarea sarcinii etc.
După primirea cererilor clienților, arhitectura internă constă din microservicii care comunică între ele prin mesaje pentru a gestiona cererile clientului.
4. Formate de mesagerie
Există două tipuri de mesaje prin care comunică:
- Mesaje sincrone: În situația în care clienții așteaptă răspunsurile de la un serviciu, Microserviciile tind să folosească de obicei REST (Transfer de stat reprezentativ) deoarece se bazează pe un apatrid, client-server și Protocol HTTP . Acest protocol este utilizat întrucât este un mediu distribuit, fiecare funcționalitate fiind reprezentată cu o resursă pentru a efectua operațiuni
- Mesaje asincrone: În situația în care clienții nu așteaptă răspunsurile de la un serviciu, Microserviciile tind să folosească de obicei protocoale precum AMQP, STOMP, MQTT . Aceste protocoale sunt utilizate în acest tip de comunicare, deoarece natura mesajelor este definită și aceste mesaje trebuie să fie interoperabile între implementări.
Următoarea întrebare care vă poate veni în minte este cum își gestionează datele aplicațiile care utilizează Microservice?
5. Manipularea datelor
Ei bine, fiecare Microservice deține o bază de date privată pentru a-și captura datele și a implementa funcționalitatea comercială respectivă. De asemenea, bazele de date ale Microservicilor sunt actualizate numai prin API-ul lor de servicii. Consultați diagrama de mai jos:
Figura 3: Reprezentarea datelor de manipulare a microserviciilor - Arhitectura microserviciului
Serviciile furnizate de Microservices sunt transferate către orice serviciu la distanță care acceptă comunicarea inter-proces pentru diferite stive de tehnologie.
6. Conținut static
După ce Microserviciile comunică în interiorul lor, implementează conținutul static într-un serviciu de stocare bazat pe cloud care le poate livra direct clienților prin Rețele de livrare de conținut (CDN) .
În afară de componentele de mai sus, există și alte componente care apar într-o arhitectură tipică de microservicii:
7. Management
Această componentă este responsabilă pentru echilibrarea serviciilor pe noduri și identificarea eșecurilor.
8. Descoperirea serviciului
analizând un fișier XML în java
Acționează ca un ghid pentru Microservicii pentru a găsi calea de comunicare între ei, deoarece menține o listă de servicii pe care sunt amplasate nodurile.
Abonați-vă la canalul nostru YouTube pentru a primi noi actualizări ..!
Acum, să analizăm avantajele și dezavantajele acestei arhitecturi pentru a înțelege mai bine când trebuie folosită această arhitectură.
Pro și dezavantaje ale arhitecturii Microservice
Consultați tabelul de mai jos.
| Avantaje ale arhitecturii Microservice | Contra Microserviciului Arhitectură |
| Libertatea de a utiliza diferite tehnologii | Crește provocările de depanare |
| Fiecare microserviciu se concentrează pe capacitatea unei singure companii | Crește întârzierea din cauza apelurilor la distanță |
| Suportă unități individuale implementabile | Eforturi sporite pentru configurare și alte operațiuni |
| Permite lansări frecvente de software | Greu de menținut siguranța tranzacțiilor |
| Asigură securitatea fiecărui serviciu | Este dificil să urmăriți datele peste diferite limite ale serviciilor |
| Mai multe servicii sunt dezvoltate și implementate în paralel | Este dificil de mutat codul între servicii |
Să înțelegem mai multe despre Microservicii comparând arhitectura anterioară UBER cu cea actuală.
STUDIU DE CAZ UBER
Arhitectura anterioară a UBER
La fel ca multe start-up-uri, UBER și-a început călătoria cu o arhitectură monolitică construită pentru o singură ofertă într-un singur oraș. Având o singură bază de coduri părea curățată la acel moment și a rezolvat principalele probleme de afaceri ale UBER. Cu toate acestea, pe măsură ce UBER a început să se extindă în întreaga lume, s-au confruntat riguros cu diverse probleme în ceea ce privește scalabilitatea și integrarea continuă.
Figura 4: Arhitectura monolitică a UBER - Microservice Architecture
Diagrama de mai sus ilustrează arhitectura anterioară a UBER.
- Este prezent un API REST cu care se conectează pasagerul și șoferul.
- Trei adaptoare diferite sunt utilizate cu API în interiorul lor, pentru a efectua acțiuni precum facturare, plăți, trimiterea de e-mailuri / mesaje pe care le vedem atunci când rezervăm un taxi.
- O bază de date MySQL pentru a stoca toate datele lor.
Deci, dacă observați aici toate caracteristicile, cum ar fi gestionarea pasagerilor, facturarea, caracteristicile de notificare, plăți, gestionarea călătoriilor și gestionarea șoferului au fost compuse într-un singur cadru.
Declarație problemă
În timp ce UBER a început să se extindă în întreaga lume, acest tip de cadru a introdus diverse provocări. Următoarele sunt câteva dintre provocările proeminente
- Toate caracteristicile au trebuit să fie reconstruite, implementate și testate din nou și din nou pentru a actualiza o singură caracteristică.
- Remedierea erorilor a devenit extrem de dificilă într-un singur depozit, deoarece dezvoltatorii au trebuit să schimbe codul din nou și din nou.
- Scalarea caracteristicilor simultan cu introducerea de noi funcții în întreaga lume a fost destul de dificilă pentru a fi manipulate împreună.
Soluţie
Pentru a evita astfel de probleme, UBER a decis să-și schimbe arhitectura și să urmeze celelalte companii cu creștere mare, cum ar fi Amazon, Netflix, Twitter și multe altele. Astfel, UBER a decis să-și rupă arhitectura monolitică în mai multe baze de cod pentru a forma o arhitectură de microserviciu.
Consultați diagrama de mai jos pentru a analiza arhitectura de microservicii UBER.
Figura 5: Microservice Architecture Of UBER - Microservice Architecture
- Schimbarea majoră pe care o observăm aici este introducerea API Gateway prin care sunt conectați toți șoferii și pasagerii. De la API Gateway, toate punctele interne sunt conectate, cum ar fi gestionarea pasagerilor, gestionarea șoferilor, gestionarea călătoriei și altele.
- Unitățile sunt unități individuale desfășurate separat care efectuează funcționalități separate.
- De exemplu: dacă doriți să schimbați ceva în microserviciile de facturare, trebuie doar să implementați numai microservicii de facturare și nu trebuie să le implementați pe celelalte.
- Toate caracteristicile au fost acum scalate individual, adică interdependența dintre fiecare caracteristică a fost eliminată.
- De exemplu, știm cu toții că numărul de persoane care caută taxiuri este mai comparativ mai mare decât cel care efectiv rezervează un taxi și efectuează plăți. Aceasta ne deduce că numărul proceselor care lucrează la microserviciul de gestionare a pasagerilor este mai mare decât numărul proceselor care lucrează la plăți.
In acestcale, UBER a beneficiat de schimbareestearhitectura de la monolitic la Microservicii.
Sper că v-a plăcut să citiți această postare pe Microservice Architecture.Voi veni cu mai multe bloguri, care vor conține și hands-on.
Vrei să afli mai multe despre Microservicii?
Dacă doriți să învățați microservicii și să vă creați propriile aplicații, consultați care vine cu instruire live condusă de instructor și experiență de proiect din viața reală. Această instruire vă va ajuta să înțelegeți microserviciile în profunzime și vă va ajuta să obțineți stăpânirea asupra subiectului.
Ai o întrebare pentru noi? Vă rugăm să o menționați în secțiunea de comentarii din ” Arhitectura Microservice ”Și mă voi întoarce la tine.