TEMA 12 - Arquitectura de Microservicios PDF

Preview

Summary

Profesor Sergio Segura...

Description

TEMA 12: ARQUITECTURA DE MICROSERVICIOS 1. INTRODUCCIÓN

Contexto: aplicaciones web desarrolladas como un sistema monolítico donde es necesario aumentar la escalabilidad del sistema y reducir el tiempo de despliegue. Problema: ¿Cómo dividir el sistema en partes que puedan ser desarrolladas y evolucionar de forma independiente, con poca interacción entre ellas y favoreciendo la portabilidad, facilidad de cambio y reutilización? Solución: desarrollar el sistema como un conjunto de servicios pequeños cada uno con su propia funcionalidad y poco acoplados, corriendo en sus propios procesos y comunicándose a través de mecanismos ligeros, a menudo mediante mensajes HTTP (APIs RESTful).

2. CARACTERÍSTICAS Cambios en el sistema: ✓ Monolítico: cualquier cambio requiere compilar y desplegar una nueva versión completa del sistema. ✓ Microservicios: cuando hay algún cambio sólo es necesario desplegar la nueva versión del servicio o servicios afectados. Flexibilidad: ✓ Monolítico: si se necesitan más recursos es necesario escalar la aplicación completa. ✓ Microservicios: cada servicio puede ser escalado de forma independiente. Organización de equipos: ✓ Monolítico: los equipos se centran en una capa concreta: presentación (front-end), servidor (backend), bases de datos, etc. ✓ Microservicios: los servicios se organizan de acuerdo con las funcionalidades del negocio y son abordados por equipos multidisciplinares. Proyecto vs. producto: ✓ Monolítico: desarrollo basado en proyectos; una vez entregado el software, éste es mantenido por un equipo diferente.

✓ Microservicios: desarrollo basado en productos; el equipo de desarrollo es responsable de dar soporte al servicio durante todo su ciclo de vida. Tecnología: ✓ Monolítico: uso de la misma tecnología para todo el sistema (o todos los sistemas de la organización). ✓ Microservicios: cada servicio es desarrollado con la tecnología más adecuada en cada caso. Tamaño de los microservicios: grupos pequeños de 12 personas como mucho, pero no hay número exacto. ¿Cuántos microservicios? Amazon y Netflix tienen más de 500 microservicios.

3. EJEMPLOS Ejemplo 1: plataforma de comercio electrónico.

Ejemplo 2: alquiler de coches con conductor.

4. CASOS DE ÉXITO Netflix: 5 mil millones de llamadas a sus APIs al día y el 99’9% son llamadas internas, hechas por la propia organización. Amazon: Jeff Bezos (fundador y director ejecutivo de Amazon) redactó un informe para sus empleados hace 20 años. Las ideas del informe son las que se usan hoy en día para la arquitectura de microservicios. ✓ Todos los equipos expondrán sus datos y funcionalidad a través de interfaces. ✓ Los equipos deben comunicarse entre sí a través de estas interfaces.

✓ No habrá otra forma de comunicación entre procesos permitida, sin vinculación directa, sin lecturas directas del almacén de datos de otro equipo, sin modelo de memoria compartida, sin puertas traseras de ningún tipo. La única comunicación permitida es a través del servicio llamadas de interfaz a través de la red. ✓ No importa qué tecnología usen HTTP, Corba Pub Sub, protocolos personalizados, no importa. A Bezos no le importa. ✓ Todas las interfaces de servicio, sin excepción, deben diseñarse desde cero hasta que sean externalizable, es decir, el equipo debe planificar y diseñar para poder exponer la interfaz a desarrolladores en el mundo exterior. ✓ Cualquiera que no haga esto será despedido. ✓ Gracias, ¡qué tengan un buen día!

5. VENTAJAS E INCONVENIENTES Ventajas: ✓ Permite abordar principios de diseño clave: modularidad, cohesión, separación de responsabilidades y ocultación de la información. ✓ Desarrollo, despliegue y escalado independiente de cada servicio. ✓ Interfaces bien definidas. ✓ Permite usar la tecnología más adecuada en cada caso. Inconvenientes: ✓ Entorno distribuido: comunicación lenta y riesgo de fallos de comunicación. ✓ Consistencia entre los distintos almacenes de datos. ✓ Aumento de la complejidad en la gestión de muchos servicios interdependientes (pruebas, despliegue, etc).

6. PATRONES RELACIONADOS 6.1.

PASARELA DE APIs (API GATEWAY) Contexto: una aplicación cliente requiere invocar a múltiples servicios para atender las peticiones de los usuarios. Por ejemplo, la visualización de productos Amazon en un dispositivo móvil requiere obtener información de múltiples servicios. Problema: para obtener dicha información es necesario consultar distintos microservicios (ej. cientos en el caso de Amazon). Invocarlos directamente desde el cliente supone varios problemas: ✓ El cliente queda acoplado con cada servicio. ¿Qué pasa si un servicio se divide en dos en el futuro? ✓ Algunos microservicios pueden utilizar protocolos de comunicación diferentes. ✓ Cada cliente y aplicación puede requerir información diferente para mostrar la información del producto. Ej. móvil vs PS4. Solución: emplear una pasarela de APIs que funcione como único punto de entrada al sistema. El API Gateway encapsula la arquitectura del sistema interno y proporciona una API que se adapta a cada cliente. ✓ Puede tener otras responsabilidades como autenticación, monitorización, equilibrio de carga, almacenamiento en caché, etc. ✓ Es similar al patrón de fachada del diseño orientado a objetos. Ventajas: ✓ Bajo acoplamiento entre clientes y servicios. ✓ La pasarela puede proporcionar una API diferente a cada cliente.

✓ Simplifica el código de las aplicaciones cliente. Inconvenientes: ✓ La pasarela puede convertirse en un cuello de botella. ✓ La pasarela se convierte en un punto crítico, el funcionamiento de todo el sistema depende de ella.

6.2.

INSTANCIA DE SERVICIO POR CONTENEDOR Contexto: aplicación con una arquitectura basada en microservicios. Problema: ¿Cómo empaquetar y desplegar cada servicio de manera que sea fácil y rápido lanzar tantas instancias como sea necesario, independientemente del tipo de servicio y la tecnología con la que esté desarrollado? Solución: empaquetar cada servicio como una imagen de contenedor (ej. Docker) y lanzar cada instancia del servicio en un contenedor. ✓ Cada contenedor tiene todo lo necesario para el funcionamiento del servicio. Ej. máquina virtual de Java, Servidor Web, SGBD, etc. ✓ Las instancias no deberían tener estado. Cada servicio realiza una función y debería poder ser replicado tantas veces como sea necesario. Ventajas: ✓ Sólo es necesario usar una herramienta para gestionar el despliegue de todos los servicios. Ej. todos los servicios se inician y apagan de la misma forma. ✓ Facilita monitorizar y limitar los recursos consumidos por cada instancia. ✓ Construir y lanzar contenedores es rápido. Inconvenientes: ✓ Es necesario conocer bien las herramientas para administrar contenedores (o pagar por servicios externos como Google Container Engine y Amazon EC2 Container Service)....