Consistencia eventual en microservicios

Sesión 5: 1h18m

Requerimientos funcionales de MSA (Microservice Architecture)

Una arquitectura orientada a microservicios tiene que cumplir con algunos requisitos técnicos de arquitectura.

• Débilmente acoplado
• Independientemente cambiable
• Desplegable independientemente
• Contratos de apoyo y honor: El equipo tiene que auto-organizarse.
• API agnóstica a la tecnología
• Diseño para fallos

Cómo diseñar microservicios basados en API

• Estilo arquitectónico: Es el diseño de la aplicación en el nivel más alto de abstracción. Un ejemplo de estilo arquitectónico es microservicios.
• Patrón de arquitectura: cómo van a estar estructurados los componentes. Es una forma de implementar un estilo arquitectónico. Ejemplos:
• Estas capas los voy a organizar con MVC
• Voy a usar el patrón de descomposición DDD
• Voy a utilizar el patrón de BD por servicio
• Uso de Clean Architecture
• Patrón de diseño: Aquí ya estamos viendo código. Casos particulares a nivel de desarollo. Ejemplos:
• Patrón Observer
• Patrón Retry
• Patrón Circuit Breaker

Opciones de arquitectura

• Patrones de arquitectura API
• Facade pattern
• Proxy pattern
• Stateless service pattern
• Estilos de arquitectura API
• Pragmatic REST
• HATEOS (True REST)
• RPC
• SOAP

Estilo de arquitectura REST

Es el estilo arquitectónico que complementa a los microservicios es REST quien permite establecer mecanismos de comunicación.

¿Qué es REST?

• Es un estilo que define restricciones.
• Utiliza una infraestructura basada en HTTP
• Hereda las ventajas de la web
• Conceptos clave
• JSON, XML o CUSTOM
• Endpoints de recursos
• Interfaz de recursos uniforme

Consistencia Eventual

La consistencia eventual es un principio en sistemas distribuidos, como los microservicios, donde no se garantiza la consistencia inmediata de los datos en todo el sistema, pero se asegura que, con el tiempo, todos los nodos (o microservicios) llegarán a un estado consistente.

• Existen sitios web que necesitan un poco de paciencia. Haces una actualización de algo, se actualiza la pantalla y falta la actualización. Esperas uno o dos minutos, pulsas Refresh, y ahi está. 
• Incoherencias como esta son lo suficientemente irritantes, pero pueden ser mucho más graves. La lógica empresarial puede terminar tomando decisiones sobre información inconsistente, cuando esto sucede puede ser extremadamente difícil diagnosticar lo que salió mal porque cualquier investigación se producirá mucho después de que se haya cerrado la ventana de incoherencia.
• Los microservicios introducen problemas de coherencia eventuales debido a su loable insistencia en la administración descentralizada de datos. Con un monolito, puede actualizar un montón de cosas juntas en una sola transacción. 
• Los microservicios requieren varios recursos para actualizar y las transacciones distribuidas se fruncen el ceño (por una buena razón). Por lo tanto, ahora, los desarrolladores deben ser conscientes de los problemas de coherencia y averiguar cómo detectar cuándo las cosas están fuera de sincronización antes de hacer cualquier cosas que el código se arrepentirá. 
• La mayoría de aplicaciones necesitan bloqueos sin conexión para evitar transacciones de base de datos de larga duración.
• Los sistemas externos necesitan actualizaciones que no se puedan coordinar con un administrador de transacciones. 
• Los procesos de negocio son a menudo más tolerantes a las incoherencias, porque las empresas a menudo valoran más la disponibilidad.

Consistencia Eventual - Teorema de CAP

El teorema de CAP nos va a indicar 3 aspectos fundamentales para definir como vamos a modelar nuestra BD o nuestros procesos distribuidos.

• La consistencia (consistency): Cualquier lectura recibe como respuesta la escritura más reciente o un error.
• La disponibilidad (availability): Cualquier petición recibe una respuesta no errónea, pero sin la garantía de que contenga la escritura más reciente.
• Tolerancia al particionado (partition tolerance): El sistema sigue funcionando incluso si un número arbitrario de mensajes son descartados (o retrasados) entre nodos de la red.

Consistencia Eventual

• Los datos eventualmente serán consistentes
• BASE (no va haber una protección de transacción)
• BASE vs ACID
• ACID and BASE are two database transaction models, each with their own advantages and trade-offs. 
• Disponibilidad sobre consistencia
• Evitar el bloqueo de recursos
• Ideal para tareas de larga duración
• Preparado para inconsistencias
• Condiciones de carrera
• Replicación de datos
• Basado en eventos
• Transacción/acciones generadas como eventos
• Mensajes usando message brokers

Demo: Introducción a eventos

1h51m

Bus de Mensajes: Es un gestor de colas. Tenemos tecnologías como Rabbit, Kafka, Azure Service Bus, Amazon SNS, etc. Se recomienda Rabbit para la etapa de desarrollo y utilizar Kafka para producción. 

Nota: Para desarrollo multiplaforma se puede usar Microsoft Orleans.