Arquitectura de Microservicios
Este artículo es una explicación de conceptos sobre Microservicios, con preguntas de examen y etiquetas.
En Resumen
Los Microservicios son servicios pequeños e independientemente desplegables, cada uno con una responsabilidad empresarial claramente delimitada. Cada servicio encapsula sus datos y se comunica a través de interfaces bien definidas.
Descripción Técnica Compacta
La arquitectura de Microservicios divide un sistema en servicios organizados por dominio empresarial, frecuentemente siguiendo un Bounded Context del DDD. Cada servicio tiene su propio modelo de datos y su propio almacenamiento de persistencia. La comunicación se realiza preferentemente de forma asíncrona mediante eventos; para necesidades síncronas, se usan APIs simples como REST o gRPC. Los despliegues son independientes y Continuous Delivery permite entregas rápidas. La consistencia es generalmente eventual, y las Sagas coordinan las transacciones distribuidas. La observabilidad es obligatoria: logs estructurados, métricas, traces e IDs de correlación son esenciales para rastrear llamadas distribuidas.
Puntos Clave para el Examen
- División según dominio empresarial, un Bounded Context por servicio, datos por servicio, sin esquemas compartidos
- Estilos de comunicación: mensajería asíncrona para desacoplamiento, síncrono de forma limitada
- Consistencia de datos: Sagas, Outbox, Inbox, procesamiento idempotente, semántica de entrega exacta
- Especificar objetivos de calidad: modificabilidad, disponibilidad, seguridad, trazabilidad (SLOs)
- Repositorios independientes, build, test, deploy por servicio, Consumer Driven Contract Tests
- Aspectos de seguridad: mTLS, OAuth 2/OIDC, Secrets Management, Policy Enforcement, Rate Limiting
- Rentabilidad: autonomía de equipos, desarrollo paralelo, escalado por punto crítico, mayor carga operativa
- Documentación obligatoria: modelo C4 niveles 1-3, contratos de interfaz, ADRs, operación, plan de contingencia
Componentes Principales
- División empresarial, Bounded Context por servicio
- Diseño de API: recursos o RPC, versionado, compatibilidad hacia atrás
- Datos por servicio: persistencia independiente, estrategia de migración
- Capa de comunicación: Message Broker, colas, streams, Request-Response
- Service Discovery y routing: API Gateway, Ingress
- Resiliencia: Circuit Breaker, timeouts, reintentos con backoff, bulkheads
- Observabilidad: logs, métricas, tracing, ID de correlación
- Despliegue e infraestructura: contenedores, orquestación, IaC, CI/CD
- Seguridad: mTLS, AuthN/AuthZ, Secrets Management, audit logging
- Procedimientos de testing: unit, integration, contract tests, chaos engineering, pruebas de carga
Ejemplo Práctico
// Saga orquestada: proceso de pedido con Order Service, Payment Service, Inventory Service
POST order/create { customerId: 42, items: [{ sku: "A1", qty: 2 }] }
Order Service guarda Order con estado: pending, genera evento: order.created (outbox)
Orquestador recibe order.created, llama Payment Service:
POST payments con Idempotency Key: ord-42
Payment Service autoriza el importe, publica evento: payment.authorized
Orquestador llama Inventory Service:
POST reservations { orderId: 42, items: ... }
Inventory reserva artículos, publica evento: inventory.reserved
Orquestador establece Order en estado: confirmed, publica order.confirmed
Compensación si inventory.reservation.failed:
- Llama Payment Service: POST payments/refund
- Establece Order en cancelled
Ventajas y Desventajas
Ventajas
- Despliegues independientes, cambios más rápidos
- Escalado dirigido, mejor aislamiento de fallos
- Diversidad tecnológica por servicio, responsabilidades claras
- Autonomía de equipos, desarrollo paralelo
Desventajas
- Mayor complejidad operativa
- Debugging distribuido, fallos de red y latencias
- La consistencia de datos debe modelarse explícitamente
- Observabilidad y seguridad exigentes
- Riesgo de monolito distribuido
Preguntas Típicas de Examen (con Respuesta Breve)
- ¿División empresarial para Microservicios? A lo largo de un Bounded Context con lenguaje ubicuo claro, mínimo acoplamiento, máxima cohesión.
- ¿Transacciones distribuidas sin Two Phase Commit? Mediante Sagas con orquestación/coreografía, pasos de compensación idempotentes, patrón Outbox.
- ¿Problema de las llamadas síncronas en cadena? Amplifican latencias y fallos, generan efectos en cascada, reducen autonomía. Soluciones: eventos asíncronos, Circuit Breaker.
- ¿Datos por servicio en la práctica? Cada servicio posee su propio esquema de persistencia, lo oculta tras una API, integraciones mediante eventos/APIs.
- ¿Rol del API Gateway? Punto de entrada central: routing, autenticación, rate limits, observabilidad, traducción de protocolos.
- ¿Trazabilidad entre límites de servicios? IDs de correlación, tracing distribuido, logs estructurados, propagación consistente en todas las llamadas.
- ¿Cuándo es económicamente viable? Con equipos grandes y dominios complejos, cuando despliegues independientes justifiquen la carga operativa.
- ¿Consistencia vs. disponibilidad en CAP? Generalmente mayor disponibilidad con eventual consistency, invariantes locales estrictos, globales mediante Sagas.