Descargado 150 veces
Subido porFederico Damián Lozada Mosto
Implementando una Arquitectura de Microservicios
El documento aborda la implementación de una arquitectura de microservicios, destacando sus ventajas sobre la arquitectura monolítica, como la facilidad para realizar cambios rápidos y el despliegue independiente de servicios. Se mencionan buenas prácticas, desafíos y principios relacionados con el diseño de microservicios, así como la importancia de la documentación y la comunicación a través de APIs. También se discuten herramientas y metodologías para la automatización del desarrollo y la mejora del monitoreo de servicios.
Más contenido relacionado
![[El comercio]php zend framework (speech)](https://cdn.slidesharecdn.com/ss_thumbnails/elcomerciophpzendframeworkspeech-120330144536-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar a Implementando una Arquitectura de Microservicios
Implementando una Arquitectura de Microservicios
- 1.
- 2. FEDERICO LOZADA MOSTO Twitter:@mostofreddy Web: mostofreddy.com.ar Facebook: /mostofreddy Linkedin: ar.linkedin.com/in/federicolozadamosto Github: /mostofreddy
- 4.
- 5. BundleA Data Access BundleB BundleC Browser MonolithicApp Database Arquitectura monolítica UX
- 6.
- 7. $ cd /var/www $tree MyProject -L 2 MyProject ├── app/ ├── src/ │ ├── Bundle1/ │ ├── Bundle2/ │ ├── Bundle3/ │ ├── ... │ ├── BundleN/ ├── web/ ├── vendor/ └── ... Arquitectura monolítica
- 8. Monolithic Arquitectura monolítica -Ups! mobile systems IOT tablet
- 9. Arquitectura Compleja + acoplamiento Difícil documentación Difícilsincronización ¿Cómo afecta un cambio?
- 10.
- 11.
- 12.
- 13.
- 14. U$S + Recursos + Infraestructura +Tiempo para migrar app
- 15.
- 16.
- 17. Public API Microservicios Payment Gateway E-commerce Stock CRM integration Notification Logistic Reports Auth Servicio1 Servicio 2 Servicio 3 Servicio 4 Servicio 5 Servicio 6 Servicio 7 Servicio 8
- 18.
- 19. Is an approachto developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. - Martin fowler http://martinfowler.com/articles/microservices.html
- 20.
- 21.
- 22. Arquitectura Sencilla - acoplamiento +cohesión Comunicación mediante APIs HTTP Pequeños No afecta a otros servicios
- 23. Desarrollo Sencillo Servicios pequeños Independientes Mayor control Implementeuna necesidad de negocio
- 24.
- 25.
- 26.
- 27. Independiente a latecnología
- 28. Eficiente Escalabilidad Auto Scalling Serv 2 LB Serv3 Serv 3 Serv 3 Serv 1
- 29.
- 30.
- 31.
- 32. Principios SOLID ✓ Singleresponsability ✓ Liskov Substitution ✓ Interface Segregation ✓ Dependency inversion ✓ HATEOAS ✓ HAL ✓ JSON-API Automagic service discovery
- 33. DB distribuidas ✓ Cadaservicio con su DB ✓ NO acoplar servicios por DB ✓ Sincronización de datos ✓ Consistencia de datos DB distribuidas
- 34. APIs documentadas ✓ RAML ✓Swagger ✓ Restfull ✓ AMQP (ZeroMQ, RabbitMQ, etc) ✓ NO ESB Comunidación sencilla ✓ Api Blueprint ✓ SNS/SQS ✓ Redis
- 35. Versionado ✓ ¿Se versionapor servicio? ✓ NO acoplar servicios por DB ✓ Un componente puede ser un servicio Componentes Productos ✓ Productos en vez de proyectos
- 36. ✓ Centralizar logs(Loggly, Logstash) ✓ Centralizar monitoreo (Zabix, New Relic) Monitoreo ✓ 1 servidor → N servidores / containers ✓ 1 app → N servicos ✓ Troubleshooting Monitoreo
- 37. ✓ 1 deploy→ N deploy ✓ AWS ✓ Vagrant / Docker ✓ Puppet / Chef Automatizar deploy Testing ✓ ¿Como probar enteramente la solución?
- 39.
- 40. BundleA Data Access BundleB BundleC UX BundleA DataAccess BundleB BundleC UX Composer
- 41.
- 42. BundleA Data Access BundleB UX Lógica API Rest BundleC BundleA DataAccess BundleB UX Lógica API Rest ServicioC
- 43.
- 45. Servicio 1 Servicio 2 Legacy APIGateway Servicio N
- 46.
- 47. Thanks! FEDERICO LOZADA MOSTO TW:@mostofreddy Web: mostofreddy.com.ar FB: mostofreddy In: ar.linkedin.com/in/federicolozadamosto Git: mostofreddy