Arquitectura de Microservicios

Colección de pequeños servicios autónomos, autocontenidos y que implementan una funcionalidad muy pequeña del Negocio.

Qué son los microservicios

• Pequeños, independientes, poco acoplados.
• El código fuente de cada servicio es independiente.
• Son responsables de gestionar sus datos y su estado.
• La comunicación entre ellos se basa en APIs bien documentadas.
• La base tecnológica de cada microservicio es independiente.

Componentes de una arquitectura de microservicios

• Orquestación para gestionar el ciclo de vida de los servicios, identificar fallos, reasignar recursos, etc. Por ejemplo Kubernetes o Service Fabric.
• API Gateway: Punto de entrada para los clientes, que redirige la llamada a los servicios correspondientes. Esta solución desacopla la tecnología de comunicación entre microservicios (que puede usar protocolos de mensajería, gRPC, etc. que no sean Web API) y los usuarios.
• Service Mesh: Permite la comunicación entre microservicios, y puede aportar funcionalidad de enrutado, balanceo, circuit-breaker, service discovery, etc. Convierte los microservicios en políglotas.

Ventajas

• Agilidad
• Autonomía
• Equipos pequeños
• Flexibilidad tecnológica
• Tolerancia a fallos
• Escalabilidad
• Aislamiento de la capa de datos

Retos

• Complejidad
• Desarrollo y testing
• Gobierno de servicios distribuidos
• Latencia
• Integridad de los datos
• Trazabilidad de las operaciones
• Transaccionalidad: en aplicaciones tradicionales esto se podía delegar a la capa de datos. Para evitar estos casos, el diseño de entitades y agregados en DDD persigue aislar la transaccionalidad.
• Versionamiento

Diseño de arquitectura de microservicios

A la hora de diseñar, una buena aproximación es el DDD (Domain Driven Design).

Definir el alcance de cada microservicio, sus límites, es todo un reto. Según la definición un microservicio debe ser responsable de una única tarea. Sin embargo en la práctica hay que ser cuidadoso para evitar dependencias inesperadas entre servicios o acoplamiento.

El criterio de diseño debe ser orientado a las funciones de negocio, y no en capas horizontales como el acceso a datos o mensajería.

Microsoft Azure

Hay poco acoplamiento si al realizar un cambio en un servicio no hay impacto en los demás.

Siguiendo domain-driven design (DDD), los pasos serían los siguientes:

• Analizar el dominio de negocio para entender los requisitos funcionales.
• Después se definen los bounded contexts del dominio. Cada dominio contendrá un modelo de dominio. Esto ayuda a evitar que busquemos la delimitación en la tecnología o departamentos.
• Aplicando patrones tácticos DDD se definen entidades, agregados y servicios del dominio.
• Con todo lo anterior se dentifican los microservicios de la aplicación.

Existen retos como la convivencia o integración con sistemas legacy que no sigan las buenas prácticas modernas. Para evitar comprometer el diseño, hay que deliminar estos sistemas en el modelo del dominio y aplicar algún patrón como Strangler o anti-corruption layer.

El tamaño de un microservicio debe estar comprendido entre un agregado (del modelo de dominio) y el propio contexto del dominio.

Construcción

El desarrollo de microservicios plantea algunas diferencias respecto al desarrollo tradicional de aplicaciones.

Orquestador vs serverless

Lo primero es seleccionar el tipo de arquitectura:

• Orquestación de microservicios ejecutándose en nodos dedicados (Kubernetes, VMs,…)
• Arquitectura serverless

Para la elección se deben tener en cuenta los siguientes aspectos:

• Facilidad de gestión
• Flexibilidad y control
• Portabilidad
• Integración de aplicaciones
• Coste
• Escalabilidad

Comunicación entre servicios

Puede ser tanto síncrona como asíncrona. Debemos distinguir los siguientes escenarios:

• Llamadas por parte del cliente a las aplicaciones, generalmente a través de un API Gateway.
• APIs de backend para la comunicación entre microservicios.

La API expuesta hacia los consumidores debe ser una tecnología ampliamente soportada y estandarizada, generalmente se utiliza API REST.

Sin embargo en la comunicación interna, otros protocolos tienen relevancia como por ejemplo gRPC, que aportan eficiencia en la comunicación. También se puede utilizar un service mesh para eliminar la gestión de la comunicación de los propios microservicios.

En comunicación asíncrona, aparece un nuevo componente: el broker de mensajería.