Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Microservicios

702 views

Published on

Definición micro servicios y diferencias respecto a aplicaciones monoliticas

Published in: Technology

Microservicios

  1. 1. MICROSERVICIOS JOAN SEBASTIÁN RAMÍREZ PÉREZ 2017
  2. 2. AGENDA • ¿Qué son los microservicios? • ¿Por qué usar microservicios? • Microservicios vs monolíticos • Arquitectura microservicios • Patrones usados en microservicios • Herramientas para implementarlo • Bibliografía
  3. 3. ¿QUÉ SON LOS MICROSERVICIOS? • Una forma particular de diseñar aplicaciones de software como un conjunto de independiente de servicios desplegables. • Conjunción de diversos servicios independientes que se despliegan según se vayan necesitando. Por tanto, tendremos una aplicación modular a base de pequeñas piezas, que podremos ir ampliando o reduciendo a medida que sea necesario.
  4. 4. CASOS DE ÉXITO
  5. 5. ¿POR QUÉ USAR MICROSERVICIOS? • Los servicios en sí son muy simples de construir, pues se centran en hacer solamente una cosa bien, de forma que son fáciles de probar y se puede asegurar mayor calidad. • Cada servicio podría construirse con las tecnologías y herramientas más adecuadas, permitiendo “Polyglot Programming” (las aplicaciones se deben escribir en una mezcla de lenguajes para explotar sus mejores características). • Múltiples equipos pueden trabajar independientemente. Esto fomenta “continuous delivery” debido a que permite actualizaciones frecuentes mientras el resto del sistema se mantiene estable. • Si un servicio deja de funcionar, solo afectará las partes que dependen directamente de él (si las hay). El resto operará normalmente.
  6. 6. ¿POR QUÉ USAR MICROSERVICIOS? • Combinar los servicios como nos interese. • Escalar a nivel de microservicios. • Simplificación del mantenimiento. • Su fallo no arrastra a todo el sistema. • Podemos hacer despliegue progresivo, no necesariamente todo junto.
  7. 7. MICROSERVICIOS VS MONOLÍTICOS
  8. 8. ARQUITECTURA MICROSERVICIOS HTTPS://MARTINFOWLER.COM/VIDEOS.HTML #MICROSERVICES
  9. 9. ARQUITECTURA MICROSERVICIOS HTTPS://MARTINFOWLER.COM/VIDEOS.HTML #MICROSERVICES
  10. 10. PATRONES DE DISEÑO HTTP://MICROSERVICES.IO/PATTERNS/INDEX.HT ML
  11. 11. PATRONES CORE • Arquitectura monolítica: arquitectura de una aplicación como una única unidad desplegable • Arquitectura micro servicio: arquitectura de una aplicación como una colección de servicios sin acoplamiento
  12. 12. PATRONES DESCOMPOSICIÓN • Descomponer por capacidades del negocio: definir servicios correspondientes a las capacidades del negocio • Descomponer por subdominio: definir servicios correspondiente a subdominio DDD (Domain Driven Design)
  13. 13. PATRONES DE DESPLIEGUE • Múltiples instancias de servicio por servidor: desplegar múltiples instancias de un servicio en un único servidor • Instancia de servicio por servidor: desplegar cada instancia de servicio en su propio servidor • Instancia de servicio por máquina virtual :desplegar cada instancia del servicio en su propia VM. • Instancia de servicio por contenedor: desplegar cada instancia del servicio en su propio contenedor • Despliegue Serverless: desplegar un servicio usando una plataforma de despliegue Serverless (aplicaciones que dependen de terceros) • Plataforma de despliegue de servicios: desplegar servicios usando una plataforma de despliegue altamente automatizada que provea servicios de abstracción
  14. 14. PATRONES PREOCUPACIONES TRANSVERSALES • Micro servicio chasis: un framework que permite resolver las preocupaciones transversales y simplifica el desarrollo de servicios • Externalizar configuraciones: dejar de manera externa todas las configuraciones como locación de base de datos y credenciales
  15. 15. PATRONES DE COMUNICACIÓN • Remote Procedure Invocation: una un protocolo basado en RPI para comunicación entre servicios • Messaging: usa mensajes asíncronos para la comunicación entre servicios • Protocolo de dominio específico: una un protocolo de dominio especifico.
  16. 16. API EXTERNA • API gateway: un servicio que provee a cada cliente una interface unificada de servicios • Backend for front-end: un API gateway for each separado para cada tipo de cliente.
  17. 17. API GATEWAY • Es una capa abstracta que oculta a todos los microservicios, dejando un único Endpoint para que los clientes se comuniquen. Las solicitudes que lleguen al Gateway serán procesadas/enrutadas hacia los servicios específicos. El Gateway también nos permite monitorear fácilmente el tráfico y uso de los servicios.
  18. 18. DESCUBRIMIENTO DE SERVICIOS • Descubrimiento en el lado del cliente: consultas en el cliente a un registrador de servicios para descubrir la locación de las instancias de servicios • Descubrimiento en el lado del servidor: consultas a un registrador de servicios para obtener la locación de las instancias de los servicios • Registrador de servicio: una base de datos para encontrar las instancias de los servicios • Registro a si mismo: instancia del servicio que se registra a si mismo con el registrador de servicio • Registro tercera parte: registradores de un tercero que registra la instancia del servicio con el registrador de servicios
  19. 19. CONFIABILIDAD • Cortacircuitos: busca prevenir fallos en cascada de los servicios por problemas de red. Para esto invoca un servicio remoto a través de un proxy que falla de inmediato cuando hay una tasa de fallo o el llamado excede la capacidad
  20. 20. GESTIONAR CONSISTENCIA DE DATOS • Base de datos por servicio: cada servicio tiene su propia base de datos privada • Base de datos compartida: servicios comparten una base de datos • Arquitectura basa en eventos: usar eventos para mantener la consistencia de la información a través de los servicios. • Fuente de eventos: persistir agregados como secuencias de eventos. • Cola de los de transacciones: publicar cambios como se capturan en el registro de transacciones de la base de datos como mensajes • Disparadores de base de datos: usar triggers para capturar cambios en los datos. • Eventos de aplicación: la aplicación inserta eventos en una tabla de la base de datos que es usada como una cola de mensajes • CQRS: mantener una o más vistas materializadas que pueden hacer consultas eficientes
  21. 21. SEGURIDAD • Token de acceso: un token que almacena de manera segura la información sobre el usuario y que se intercambia entre los servicios
  22. 22. TESTING • Service Component Test: un conjunto de pruebas de un servicio aislado usando simulaciones para cualquier otro servicio que invoque. • Service Integration Contract Test: un conjunto de pruebas para un servicio que es escrito por los desarrolladores de otro servicio que consume.
  23. 23. OBSERVABILIDAD • Logs de aplicación: agregar logs a la aplicación • Métricas de aplicación: instrumentar un código de servicio para obtener estadísticas sobre operaciones. • Logging de auditoria: almacenar las actividades del usuario en una base de datos • Traza distribuida: instrumentar servicios con un código que se asigna a cada petición externa con un identificador único que se pasa entre los servicios • Rastreo de excepciones: reporta todas las excepciones en un servicio de monitoreo de excepciones que agrega, deja traza y notifica a los desarrolladores • Validar salud de la API: servicio de la API que retorna la salud de un servicio y al cual se le puede hacer ping
  24. 24. PATRONES UI • Composición fragmento de página en el lado del servidor: construir una página web en el lado del servidor componiendo fragmentos HTML que son pintados por múltiples componentes • Composición UI del lado del cliente: construir una interfaz de usuario en el lado del cliente compuesta por fragmentos que son pintados por múltiples componentes
  25. 25. HERRAMIENTAS
  26. 26. HYSTRIX PARA INGENIERÍA RESILIENTE • Hystrix es una librería , creada por Netflix, diseñada para controlar la interacción entre servicios distribuidos; provee una gran tolerancia a la latencia y a los fallos. • http://github.com/Netflix/H ystrix
  27. 27. SPRING BOOT • Permite crear fácilmente aplicaciones stand-alone, aplicaciones que solo se necesita ejecutar. • https://projects.spring.io/spring-boot/
  28. 28. NO TODO ES COLOR ROSA ALGUNAS CONSIDERACIONES
  29. 29. TENER MUY PRESENTE • Los micro servicios generan mayor complejidad en la arquitectura • Se requiere cluster para conmutación por fallas y resiliencia • Un simple llamado tradicional podría convertirse en un llamado de procedimiento remoto (RPC), un REST o un mensaje asincrónico. Los desarrolladores necesitan pensar más en problemas como la latencia entre servicios, tolerancia a fallos, control de versiones, etc. • Son más fáciles de probar por sí mismos, las pruebas de integración end-to-end son más difíciles. Como el flujo de código es complejo, puede ser difícil identificar en qué parte de la cadena se presentan los errores.
  30. 30. “WHILE OUR EXPERIENCES SO FAR ARE POSITIVE COMPARED TO MONOLITHIC APPLICATIONS, WE'RE CONSCIOUS OF THE FACT THAT NOT ENOUGH TIME HAS PASSED FOR US TO MAKE A FULL JUDGEMENT.” JAMES LEWIS AND MARTIN FOWLER HTTPS://MARTINFOWLER.COM/MICROSERVICES/
  31. 31. BIBLIOGRAFÍA • Microservices [En línea] <https://martinfowler.com/articles/microservices.html> [Consulta: 15 Enero 2017] • ¿Por qué usar un enfoque de microservicios para crear aplicaciones? [En línea] <https://docs.microsoft.com/es-es/azure/service-fabric/service-fabric- overview-microservices> [Consulta: 15 Enero 2017] • [En línea] <http://microservices.io/patterns/> [Consulta: 15 Enero 2017] • [En línea] <https://projects.spring.io/spring-boot/> [Consulta: 15 Enero 2017] • [En línea] <https://github.com/Netflix/Hystrix> [Consulta: 15 Enero 2017]

×