Arquitectura de microserveis:
Des del meu , heu de tenir una comprensió bàsica de l'arquitectura de microserveis.Però, ser un professional amb requerirà alguna cosa més que el bàsic. En aquest bloc, aprofundireu en els conceptes arquitectònics i els implementareu mitjançant un cas d’estudi UBER.
En aquest bloc, coneixereu el següent:
- Definició de l'arquitectura de microserveis
- Conceptes clau de l'arquitectura de microserveis
- Avantatges i inconvenients de l'arquitectura de microserveis
- UBER: cas pràctic
Podeu consultar el document , per entendre els fonaments i beneficis dels microserveis.
Només serà just si us dono la definició de microserveis.
Definició de microserveis
Com a tal, no hi ha una definició adequada de Microservices aka Microservice Architecture, però es pot dir que és un framework que consisteix en petits serveis desplegables individualment que realitzen diferents operacions.
Els microserveis se centren en un únic domini empresarial que es pot implementar com a serveis desplegables totalment independents i implementar-los en diferents piles tecnològiques.
Figura 1: Diferència entre l'arquitectura monolítica i la de microserveis - Microservice Architecture
Consulteu el diagrama anterior per entendre la diferència entre l'arquitectura monolítica i la de microserveis.Per obtenir una millor comprensió de les diferències entre ambdues arquitectures, podeu consultar el meu bloc anterior
Per fer-vos entendre millor, permeteu-me explicar-vos alguns conceptes clau de l’arquitectura de microserveis.
Conceptes clau de l'arquitectura de microserveis
Abans de començar a crear les vostres pròpies aplicacions mitjançant microserveis, heu de tenir clar l’abast i les funcionalitats de la vostra aplicació.
A continuació s’ofereixen algunes pautes a seguir mentre es parla de microserveis.
Directrius durant el disseny de microserveis
- Com a desenvolupador, quan decidiu crear una aplicació, separeu els dominis i tingueu clar les funcions.
- Cada microservei que dissenyeu només es concentrarà en un servei de l'aplicació.
- Assegureu-vos que heu dissenyat l'aplicació de manera que cada servei es pugui desplegar individualment.
- Assegureu-vos que la comunicació entre microserveis es faci mitjançant un servidor sense estat.
- Cada servei es pot reformular en serveis més petits, amb els seus propis microserveis.
Ara, ja que heu llegit les directrius bàsiques durant el disseny de microserveis, entenem l’arquitectura dels microserveis.
Com funciona l'arquitectura de microserveis?
Una arquitectura típica de microserveis (MSA) hauria de constar dels components següents:
- Clients
- Proveïdors d’identitat
- API de passarel·la
- Formats de missatgeria
- Bases de dades
- Contingut estàtic
- Gestió
- Descobriment de serveis
Consulteu el diagrama següent.
Figura 2: Architecture Of Microservices - Arquitectura de microserveis
Sé que l'arquitectura sembla una mica complexa, però deixeu-hoemsimplifiqueu-lo per vosaltres.
1. Clients
L’arquitectura comença amb diferents tipus de clients, des de diferents dispositius que intenten realitzar diverses funcions de gestió com ara cercar, construir, configurar, etc.
2. Proveïdors d'identitat
Aquestes sol·licituds dels clients es transmeten als proveïdors d'identitat que autenticen les sol·licituds dels clients i comuniquen les sol·licituds a l'API Gateway. Les sol·licituds es comuniquen als serveis interns mitjançant una passarel·la API ben definida.
3. Passarel·la API
Com que els clients no truquen directament als serveis, l'API Gateway actua com a punt d'entrada perquè els clients reenviïn les sol·licituds als microserveis adequats.
Els avantatges d’utilitzar una passarel·la API inclouen:
- Tots els serveis es poden actualitzar sense que ho sàpiguen els clients.
- Els serveis també poden utilitzar protocols de missatgeria que no són compatibles amb la web.
- L'API Gateway pot realitzar funcions transversals com proporcionar seguretat, equilibri de càrrega, etc.
Després de rebre les sol·licituds dels clients, l'arquitectura interna consisteix en microserveis que es comuniquen entre si mitjançant missatges per gestionar les sol·licituds dels clients.
4. Formats de missatgeria
Hi ha dos tipus de missatges a través dels quals es comuniquen:
- Missatges síncrons: En la situació en què els clients esperen les respostes d'un servei, els microserveis solen utilitzar-se REST (Transferència d'Estat Representacional) ja que es basa en un apàtrid, client-servidor i el Protocol HTTP . Aquest protocol s’utilitza ja que és un entorn distribuït i totes les funcionalitats es representen amb un recurs per dur a terme operacions
- Missatges asíncrons: En la situació en què els clients no esperen les respostes d'un servei, els microserveis solen utilitzar protocols com AMQP, STOMP, MQTT . Aquests protocols s’utilitzen en aquest tipus de comunicació ja que es defineix la naturalesa dels missatges i aquests missatges han de ser interoperables entre implementacions.
La següent pregunta que us pot venir al cap és com gestionen les seves dades les aplicacions que utilitzen Microserveis?
5. Maneig de dades
Bé, cada Microservice posseeix una base de dades privada per capturar les seves dades i implementar la funcionalitat empresarial respectiva. A més, les bases de dades de Microservices només s’actualitzen mitjançant la seva API de servei. Consulteu el diagrama següent:
Figura 3: Representació de manipulació de dades de microserveis: arquitectura de microserveis
Els serveis proporcionats per Microservices es transmeten a qualsevol servei remot que admeti comunicacions entre processos per a diferents piles de tecnologia.
6. Contingut estàtic
Després de comunicar-se els microserveis, implementen el contingut estàtic en un servei d’emmagatzematge basat en el núvol que els pot lliurar directament als clients mitjançant Xarxes de distribució de contingut (CDN) .
A part dels components anteriors, hi ha alguns altres components que apareixen en una arquitectura típica de microserveis:
7. Gestió
Aquest component s’encarrega d’equilibrar els serveis als nodes i identificar fallades.
8. Descobriment de serveis
converteix la data de la cadena en la data
Actua com a guia de microserveis per trobar la via de comunicació entre ells, ja que manté una llista de serveis en què es troben els nodes.
Subscriu-te al nostre canal de youtube per obtenir noves actualitzacions ..!
Ara, analitzem els pros i els contres d’aquesta arquitectura per comprendre millor quan s’ha d’utilitzar aquesta arquitectura.
Pros i contres de l'arquitectura de microserveis
Consulteu la taula següent.
| Avantatges de l'arquitectura de microserveis | Contres del microservei Arquitectura |
| Llibertat d'ús de diferents tecnologies | Augmenta els problemes de resolució de problemes |
| Cada microservei se centra en la capacitat de negoci únic | Augmenta el retard a causa de les trucades remotes |
| Admet unitats desplegables individuals | Esforç més gran per a la configuració i altres operacions |
| Permet versions freqüents de programari | És difícil mantenir la seguretat de les transaccions |
| Assegura la seguretat de cada servei | Difícil fer un seguiment de les dades a través de diversos límits del servei |
| Es desenvolupen i implementen paral·lelament diversos serveis | És difícil moure codi entre serveis |
Entenem més informació sobre els microserveis comparant l’arquitectura anterior d’UBER amb l’actual.
ESTUDI DE CAS UBER
Arquitectura anterior d’UBER
Com moltes empreses emergents, UBER va començar el seu viatge amb una arquitectura monolítica construïda per a una única oferta en una mateixa ciutat. Tenir una base de codis semblava netejat en aquell moment i resolia els problemes bàsics de negoci d’UBER. No obstant això, a mesura que UBER va començar a expandir-se a tot el món, es van enfrontar rigorosament a diversos problemes pel que fa a l’escalabilitat i la integració contínua.
Figura 4: Arquitectura monolítica d'UBER - Arquitectura de microserveis
El diagrama anterior representa l’arquitectura anterior d’UBER.
- Hi ha una API REST amb la qual es connecten el passatger i el conductor.
- S'utilitzen tres adaptadors diferents amb l'API dins d'ells, per dur a terme accions com ara facturació, pagaments, enviament de missatges de correu electrònic / missatges que veiem quan reservem un taxi.
- Una base de dades MySQL per emmagatzemar totes les seves dades.
Per tant, si observeu aquí totes les funcions, com ara la gestió de passatgers, la facturació, les funcions de notificació, els pagaments, la gestió de viatges i la gestió de conductors, es van compondre en un mateix marc.
Plantejament del problema
Mentre UBER va començar a expandir-se arreu del món, aquest tipus de marc va introduir diversos reptes. Els següents són alguns dels reptes més destacats
- Calia reconstruir, desplegar i provar una i altra vegada totes les funcions per actualitzar una sola característica.
- La correcció d’errors es va fer extremadament difícil en un únic dipòsit, ja que els desenvolupadors havien de canviar el codi una i altra vegada.
- Escalar les funcions simultàniament amb la introducció de noves funcions a tot el món va ser molt difícil de manejar junts.
Solució
Per evitar aquest tipus de problemes, UBER va decidir canviar la seva arquitectura i seguir la resta d’empreses d’hipercreixement com Amazon, Netflix, Twitter i moltes altres. Així, UBER va decidir trencar la seva arquitectura monolítica en múltiples bases de codis per formar una arquitectura de microservei.
Consulteu el diagrama següent per veure l’arquitectura de microserveis d’UBER.
Figura 5: Microservice Architecture Of UBER - Microservice Architecture
- El canvi principal que observem aquí és la introducció de l’API Gateway a través del qual es connecten tots els conductors i passatgers. Des de l'API Gateway, es connecten tots els punts interns, com ara la gestió de passatgers, la gestió de conductors, la gestió de viatges i altres.
- Les unitats són unitats desplegables independents que realitzen funcionalitats diferents.
- Per exemple: si voleu canviar qualsevol cosa als microserveis de facturació, només heu de desplegar només els microserveis de facturació i no heu de desplegar els altres.
- Ara totes les funcions es van escalar individualment, és a dir, es va eliminar la interdependència entre totes i cadascuna de les funcions.
- Per exemple, tots sabem que el nombre de persones que busquen taxis és més comparativament superior al de les persones que realment reserven un taxi i fan pagaments. Això ens dedueix que el nombre de processos que treballen en el microservei de gestió de passatgers és superior al nombre de processos que treballen en pagaments.
En aquestmanera, UBER es va beneficiar canviantla sevaarquitectura des del monolític fins als microserveis.
Espero que us hagi agradat llegir aquest post sobre Microservice Architecture.Aniré amb més blocs, que també contindran pràctiques.
T’interessa obtenir més informació sobre els microserveis?
Si voleu aprendre microserveis i crear les vostres pròpies aplicacions, consulteu el nostre que inclou formació en directe dirigida per un instructor i experiència en projectes reals. Aquesta formació us ajudarà a entendre els microserveis en profunditat i us ajudarà a dominar el tema.
Tens alguna pregunta? Esmenteu-lo a la secció de comentaris de ' Arquitectura de microserveis ”I em posaré en contacte amb vosaltres.