MICROSERVICIOSJOAN SEBASTIÁN RAMÍREZ PÉREZ2017

AGENDA

• ¿Qué son los microservicios?• ¿Por qué usar microservicios?• Microservicios vs monolíticos • Arquitectura microservicios• Patrones usados en microservicios• Herramientas para implementarlo• Bibliografía

¿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.

CASOS DE ÉXITO

¿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.

¿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.

MICROSERVICIOS VS MONOLÍTICOS

ARQUITECTURA MICROSERVICIOSHTTPS://MARTINFOWLER.COM/VIDEOS.HTML#MICROSERVICES

ARQUITECTURA MICROSERVICIOSHTTPS://MARTINFOWLER.COM/VIDEOS.HTML#MICROSERVICES

PATRONES DE DISEÑOHTTP://MICROSERVICES.IO/PATTERNS/INDEX.HTML

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

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)

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

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

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.

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.

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.

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

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

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

SEGURIDAD

• Token de acceso: un token que almacena de manera segura la información sobre el usuario y que se intercambia entre los servicios

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.

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

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

HERRAMIENTAS

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/Hystrix

SPRING BOOT

• Permite crear fácilmente aplicaciones stand-alone, aplicaciones que solo se necesita ejecutar.

• https://projects.spring.io/spring-boot/

NO TODO ES COLOR ROSAALGUNAS CONSIDERACIONES

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.

“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 FOWLERHTTPS://MARTINFOWLER.COM/MICROSERVICES/

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]