ComunicaciÃģn entre microservicios: ð Event-Driven Architecture
āļāļąāļ
- āđāļāļĒāđāļāļĢāđāđāļĄāļ·āđāļ 25 āļĄāļī.āļĒ. 2018
- ðĨ ÂĄAprovecha la oferta del Black Friday de CodelyTV Pro!
âŪ codely.tv/pro/blackfriday?utm...
---
Analizamos los problemas derivados de los monolitos y cuÃĄndo pasar a una arquitectura de servicios.
Revisaremos los pros y contras de las distintas alternativas a la hora de definir nuestra arquitectura de microservicios y quÃĐ nuevos problemas deberemos tener en cuenta.
Este vÃdeo es un pequeÃąo repaso a todo lo que vemos en detalle en el curso sobre comunicaciÃģn entre microservicios de CodelyTV Pro. MÃĄs informaciÃģn de nuestros cursos:
ð Curso comunicaciÃģn entre microservicios: bit.ly/curso-microservicios
ð CatÃĄlogo completo de cursos CodelyTV Pro: codely.tv/pro/cursos
ðļ Descuento 111⎠gratis: codely.tv/pro/celebramos-5k-s...
ðĻâðĐâð§âðĶ Planes para empresas: codely.tv/pro/teams
ðĶ Twitter: / codelytv - āļāļąāļāđāļāļīāļ
Este vÃdeo es un pequeÃąo repaso a todo lo que vemos en detalle en el curso sobre comunicaciÃģn entre microservicios. MÃĄs informaciÃģn:
ð Curso comunicaciÃģn entre microservicios: bit.ly/curso-microservicios
ð CatÃĄlogo completo de cursos CodelyTV Pro: codely.tv/pro/cursos
ðļ Descuento 111⎠gratis: codely.tv/pro/celebramos-5k-subs
Hola muchas gracias por el curso, estuvo genial, lo tome hace un tiempo, hoy volvà a ver este vÃdeo, querÃa preguntarles que libros sobre este tema me pueden recomendar?
He enganchado con su contenido, me viene muy bien saber de arquitectura, soy desarrolladora frontend :) nueva suscriptora âðŧðĻðą
MuchÃsimas gracias! Son muy buenos profesionales, excelente explicaciÃģn.
Muy buena introducciÃģn y la explicaciÃģn, es genial ver como explican estas cosas poniendole una buena cuota de humor.
trabaje en un banco y usabamos circuit breaker y era un desmadre, demasiadas capas, saludos
colle me ajudaron mucho a entender algunos detalles y entender mejor como tomar decisiones de arquitetura mas sabiamente, muchas gracias
Hablan de temas que me interesan muchisimo y, a demÃĄs, me entretiene su forma de contar las cosas. Parece una charla educativa entre amigos
Buenisima la explicacion, clara y sencilla.
Me encanto el video !!!, ideas claras y me han iluminado el camino para entrarle a los microservicios
excelente video, creo que es la mejor explicaciÃģn de architecturas de software que he visto hasta ahora.
Muchas gracias este video me ha dado mucha visibilidad sois geniales
Tienen temas avanzados y vigentes.. excelentes creadores de contenido !
Muy buena explicaciÃģn y ademas entretenida :)
Muy informativo y se ve que la estÃĄn pasando bien.
COmo escuchÃĐ un dÃa "Que camiÃģn de informaciÃģn" super genial este tipo de vÃdeos, una lastima que sea tan por encima pero igual es super instructivo. Mil gracias y ganais un nuevo suscriptor :D
Esto de los microservicios es una pasada y sobre todo es sencillo si lo planteas en un folio :)
Muy buena explicaciÃģn, muchas gracias....
Muy buen video. gracias por tanto conocimiento.
Muy buena explicaciÃģn y los diagramas ayudan a entender mejor todo ðŦĄ
Que genial , clara explicaciÃģn . Saludos desde PerÚ.
Esto es genial! Gracias!
Uno de los mejores videos de codely. Me imagino el curso!
Excelente anÃĄlisis y explicaciÃģn!!
De los mejores canales en mi criterio ððŧ
Jajaja que divertido y educador video.
Super like.
Muy buenos videos, soy Front end developer y actualmente convivo con backends que estÃĄn haciendo microservicios, me sirve mucho porque asi entiendo todo el ecosistema completo. Gracias por los videos, esperamos mas de Front End tambiÃĐn :D Saludos desde MÃĐxico...!!!!
Esa es la actitud! ððð
Gracias por tu comentario!
Justo lo q buscaba
Muy grande la explicaciÃģn cracks. Pareciera que se iba a besar cuando se miraban a los ojos JAJAJAJA. Las mejores energias. Saludos desde Colombia.
Muy bueno y entretenido muchachos!
Excelente, genial explicado, like + subscriptor nuevo.
A la gente que quiera aprender un poco mÃĄs, les comparto un link a un doc Microsoft donde explican muy bien y ademÃĄs tambiÃĐn incluyen explicaciÃģn de los servicios requeridos (como RabbitMQ) por la nueva infraestructura. docs.microsoft.com/en-us/dotnet/architecture/microservices/multi-container-microservice-net-applications/microservice-application-design
Muy buena energia!
ÂĄBuenisimo!
Super interesante !!
Excelente video.. harÃĐ los cursos
las animaciones son tan buenas q me distraÃan de la explicaciÃģn, jaja. Muy bueno!
Hola! tienen alguna guia de las arquitecturas y como combinarlas? quiero usar arquitectura hexagonal y EDA pero no sÃĐ si seria conveniente
Que buen vÃdeo, gracias!! Tengo una pregunta... Si se quisiera agregar un servicio de usuario mÃĄs...por cualquier motivo. Los dos servicios empezarÃan a duplicar info en la db?. Los dos servicios recibirian la misma cantidad de mensajes?
Cracks!
Tambien esta la carga de balanceo en los microservicios?
genial la presentaciÃģn ðð
sÃģlo una aclaraciÃģn de la parte de los subscribers. en el caso de que aumenten x1000 la creaciÃģn de vÃdeos, tb habrÃĄ x1000 invocaciones al callback del user service... y eso Âŋno perjudica porque va directo por el id del usuario? pero aÚn asà hay x1000 peticiones PUT complas quÃĐ procesar... no? un abrazo!!!!
ÂĄBuenas!
En el caso de un x1000 de creaciÃģn de vÃdeos, si el consumidor de eventos del servicio de usuarios no puede procesarlos, simplemente la cola actuarÃĄ como buffer. Es decir, como comentamos en el minuto 24:10, los eventos quedarÃan retenidos en la cola hasta que el servicio de usuarios poco a poco fuera capaz de procesarlos y ponerse al dÃa.
Aquà es cuando se produce lo que se conoce como "consistencia eventual". Es decir, el servicio de usuarios devolverÃĄ un total de vÃdeos creados que no serÃĄ el real durante un espacio de tiempo.
Le pongo las comillas a "consistencia eventual" porque realmente serÃa una mala traducciÃģn del tÃĐrmino en inglÃĐs _Eventual consistency_. En inglÃĐs, _Eventual_ significa que algo tarde o temprano tendrÃĄ lugar. En cambio, que algo sea eventual en castellano quiere decir que estÃĄ sujeto a circunstancias y que por lo tanto no es seguro que pase o que sea constante en el tiempo. A pesar de esto, se suele traducir como consistencia eventual y de tanto usarlo a nivel tÃĐcnico ya nos entendemos ð
Un saludo y gracias por la pregunta. Es algo que no tratamos a fondo en el vÃdeo y seguro que le sirve a alguien mÃĄs ð
Perdonar tengo unas dudas ... si no necesitamos tablas ni BBDD relacionales ... Âŋdonde se guarda la informaciÃģn de los usuarios? ... si tenemos por ejemplo 30 entidades de domino Âŋnecesitaremos 30 instancias de la BD? ... que sea (MongoDB, MySQL, etc) ... un saludo un gran video!!
Me pregunto si la alternativa 2 no se solucionarÃa simplemente poniendo una base de datos distribuida en Comodity Hardware, se evitan sobrecargas en la BBDD, la complejidad en el desarrollo no se dispara, se puede escalar aÃąadiendo mas nodos a la BBDD en caso de aumento de peticiones, y el coste no se dispara. TambiÃĐn recordar que las BBDD's tambiÃĐn se pueden caer y con una BBDD distribuida el servicio no deja de funcionar en ese caso ya que siempre hay otros nodos disponibles. Por poner un par de ejemplos... Cassandra o ArangoDB (del cual soy muy fan).
En todo caso la explicaciÃģn del caso es muy interesante.
Pero esto serÃa "hacer trampa", claro que puedes multiplicar el nÚmero de esclavos de Mysql o usar Cassandra (buena suerte configurando una polÃtica de source of truth o manteniendo integridad referencial), igual que puedes multiplicar el nÚmero de monolitos (con mÃĄquinas o contenedores), pero la ingenierÃa busca resolver problemas de forma eficiente con el mÃnimo de recursos, no poniendo mÃĄs dinero
Excelentes videos y explicaciones. Muchas gracias. Tengo una duda respecto al caso de que yo necesite saber que videos pertenecen a un determinado usuario, para evitar relaciones o llamadas HTTP entre servicios, lo que se harÃa es en cada registro de video agregar la informaciÃģn del dueÃąo del mismo, Âŋcierto?
ÂŋEs decir, replicaria en cada base de datos la informaciÃģn que se necesita?
No replicarias datos ya que no hay necesidad de ello, consultarias los datos al servicio que corresponda. Para replicar datos se necesitarian otras razones, no por eficiencia
ÂŋHola, una pregunta, como se llama el programa que usan en el minuto 24:53 para simular las comunicaciones de la infraestructura?
Buenas Johan!
Es tryrabbitmq.com ð
tienen cursos en udemy?
Tengo una consulta, al hacer que el procesamiento de la cantidad de videos lo haga el servicio del usuario, no estoy agregando columnas innecesarias? es decir, con este enfoque estaria creando una columna por cada calculo a realizar sobre otro servicio.
Asi es, aÃąadirias a los datos del microservicio los derivados de procesar los eventos
CÃģmo hago para dar mÃĄs de un like?
Una consulta y que pasarÃa si todo esto estÃĄ montado con contenedores dentro de un cluster de kubernetes. Y tenemos 3 rÃĐplicas definidas para el microservicio de usuario, al momento de publicar el evento de video creado mis 3 rÃĐplicas estarÃan suscritas a ese evento y por ende leerÃan el evento y podrÃan actualizar 3 veces el campo total de videos creados. ÂŋCÃģmo se gestionarÃa esto?. PensÃĐ en mandar el campo ya actualizado al evento; sin embargo de todas maneras esto se estarÃa actualizando de acuerdo a la cantidad de rÃĐplicas que tenga el microservicio.
ÂĄBuenas Edgar!
Respondiendo a tu pregunta: La gestiÃģn de consumir 1 Única vez el evento vendrÃa dada por el sistema de publicaciÃģn y suscripciÃģn de eventos que usemos (RabbitMQ, Kafka, AWS SNS->SQS, etc.). Es decir, una vez 1 consumidor que estÃĄ suscrito a los eventos de esa cola recoge el evento, el propio sistema marca ese evento/mensaje como "transmitido" a la espera de un ACK del consumidor o un timeout para volverlo a hacer visible a otro consumidor. Esto evitarÃa en un primer momento que otra instancia de nuestros consumidores leyera el mismo evento.
Dicho esto, hay sistemas como SQS que no garantizan el orden de los eventos/mensajes de la cola al consumir, ni tampoco que no puedas llegar a consumir un evento por duplicado. Ahà entramos en temas de hacer nuestros consumidores tolerantes a este tipo de casos a travÃĐs de idempotencia o similares.
Todo esto lo explicamos mucho mÃĄs en detalle y con ejemplos concretos a nivel conceptual y de cÃģdigo en el curso: pro.codely.tv/library/comunicacion-entre-microservicios-event-driven-architecture/about/
Si te interesan estos temasâĶ ÂĄte esperamos! ð
@@CodelyTV Excelente, gracias por el detalle de la respuesta. De todas maneras llevarÃĐ el curso.
20:24
Se agradecen los chascarrillos y las explicaciones previas, pero lo bueno estÃĄ en ese punto.
Solo tengo un pequeÃąa duda, el servicio de creaciÃģn de videos es un PUT y no un POST, porque esta vez los clientes de la aplicaciÃģn son los que generan ese identificador Único para el video y en el caso de los usuarios tambiÃĐn debo usar un PUT? como genero un identificador Único para el caso de video?, un algoritmo amarrado al id del usuario?
Lo que planteas es correcto. Para la generaciÃģn del identificador lo harÃamos de forma aleatoria usando UUIDs.
UUID es un formato de identificador Único aleatorio bastante estÃĄndar. Encontraras librerÃas para generar UUIDs en los principales lenguajes de programaciÃģn sin problema.
Te recomendamos el vÃdeo de preguntas frecuentes de CQRS donde justamente comentamos el tema de la generaciÃģn de IDs desde el cliente: th-cam.com/video/auEhX4WfCRA/w-d-xo.html
Saludos!
Con esto me ha quedado clara la diferencia entre PUT y POST. Gracias!
que mas muchachos como va todo, hey tenes el cupon para inscribirse al pro? estoy usando este CODELYCQDXP y nada tio, la ostia con esa interfaz
Buenas! Tengo una duda, puede la arquitectura por eventos en algÚn caso hacer posible que sea conveniente duplicar informaciÃģn? Por ejemplo, guardar el nombre del video en ambas base de datos, imaginando que tenemos dos pantallas que usan ese dato
La arquitectura orientada a eventos tiene dos cualidades (entre otras): la resiliencia (que se explica en el video) y el desacoplamiento entre el que llama y es llamado (consumidores y productores). No implica que debas duplicar tus datos.
â@@asier6734 Gracias por responder.
Me cuesta mucho imaginarme escenarios que conozco donde un microservicio necesita el dato de otro para su respuesta con EDD .
por ejemplo, front web y front mobile utilizan el mismo dato, cada uno de los front tiene su propio servicio al que llaman para pedirselo.
En mi experiencia estos servicios suelen comunicarse con el mismo servicio "core" que tiene el dato , cada vez que lo necesitan
en EDD esto no seria posible, entonces, cada servicio deberia almacenar el dato que necesitan para cuando los front los consulte, pero de esta forma triplicarias la informaciÃģn.
Es un patrÃģn comun en EDD o es un mal caso de uso para el patron y en este caso seguiriamos usando los tipicos microservicios y consultas http? Saludos!
@@federicomarilungo los datos asociasos a un microservicio no tienen relacion con que sea de eventos o sincrono. Sino con como se hayan definido los microservicios y lo que cada uno sirva y datos que gestione en su bbdd. A microservicios mas pequeÃąos mayor escalabilidad.
Es comun que unos microservicios hagan uso de datos de otros microservicios. EDD solo modifica como se comunica e impone algunas condiciones (para gestionar un evento repetido etc) pero no supone un cambio en que datos gestiona cada microservicio
â@@asier6734 Bueno creo que no supe explicar donde aparece el duplicado de datos.
Microservicio A hace uso de Microservicio B para pedir dato 1
Escenario 1) Usamos arquitectura de comunicacion http
El microservicio A llama cada vez que necesita el dato a microservicio B
Escenario 2) Usamos arquitectura EDD
El microservicio A se entera cuando el dato cambia (cuando el microservicio B lanza un evento) y tiene que almacenarlo para cuando el front se lo pida.
En este ejemplo se puede ver como en el escenario 2, con EDD, necesitas duplicar la informaciÃģn. No hay forma de comunicar los servicios por EDD sin duplicar la informaciÃģn para este caso de uso. O si? Esa es mi pregunta
Gracias.
@@federicomarilungo ok, entiendo. Tal y como lo veo almacenaria el dato pero no es necesariamente un duplicado. B puede no guardar el total ya que puede no necesitarlo (o si). Lo que hace es lanzar el evento para que lo procese A, recalculando el total y almacenandolo). No tiene por que haber duplicados, aunque puede haberlos en EDD. Esto tb tiene relacion con event sourcing, una tecnica donde se registran todos los eventos para el calculo de datos (donde lo que se registra son los eventos en si mismos y no los datos)
Enormes gracias a mi pareja lgtb favorita
Una charla muy interesante, me.ayudo a complementar lo que sabÃa th-cam.com/video/N95W6I_DoRs/w-d-xo.html
Saludos y seguirÃĐ viendo el bueno contenido.
Gracias por el contenido, me da una duda, son pareja? digo, por la forma en la que se miran, se ve raro, perdÃģn si esto les ofende.
Nos queremos.
@@CodelyTV pues tambien la comunidad los queremos por tan buen material de ayuda, saludos!
No me parece razonable, ese ejemplo del contador de videos. Si por ejemplo abro youtube y quiero ver cuÃĄntos videos ha publicado un determinado usuario, estan asegurando que no se necesitara hacer un conteo de los videos. Alguien me puede decir entonces cÃģmo se logra esta cuenta de manera mÃĄs eficiente?
Yo tambien tengo esa duda, lo lograste solucionar?
@@xabierm1609 no, soy ignorante en ese tema. Pero creo que hay un "bus" a donde van las notificaciones y asà en teoria seria mas eficiente llevar la cuenta de algo. Pero me parece que eso implicarÃa mÃĄs recursos porque un servidor debe recibir el dato y notificar, y la aplicaciÃģn recibir y actualizar el contador en el cliente, lo cual es mÃĄs complicado que lo tradicional donde solo se obtiene el conteo en el momento que se necesita conjuntamente con otros datos que puedan ser utiles.
En caso de que requieran la herramienta. del video: tryrabbitmq.com/
EstÃĄ muy buena el contenido, pero me gustarÃa que hablaran muchÃsimo mÃĄs claro porque a Javi se le entiende lo que habla y habla con fuerza y claridad peor al otro chico no se le entiende casi nada hablas muy, pero muy nasal y sin fuerza y es superimportante que hables muy bien me quede asta el final porque Javi me engancho Gracias Javi sos un Genio