Arquitectura de Microservicios - Fundamentos de Diseno de Sistemas Distribuidos

Que son los Microservicios

La arquitectura de microservicios es un enfoque de diseno que construye aplicaciones como un conjunto de servicios pequenos e independientes. Cada servicio tiene una responsabilidad unica y puede desplegarse y escalarse de forma independiente.

Grandes servicios web como Netflix, Amazon y Uber han adoptado esta arquitectura.

Diferencia con Monolito: En la arquitectura monolitica (de una sola pieza), todas las funcionalidades estan contenidas en una unica aplicacion. En microservicios, las funcionalidades se dividen en servicios separados.

De Monolito a Microservicios

flowchart TB
    subgraph Mono["Arquitectura Monolitica"]
        subgraph App["Aplicacion Unica"]
            M1["Autenticacion"]
            M2["Productos"]
            M3["Pedidos"]
            M4["Pagos"]
        end
        SharedDB["Base de Datos Compartida"]
        App --> SharedDB
    end

    subgraph Micro["Arquitectura de Microservicios"]
        Auth["Servicio de<br/>Autenticacion"] --> AuthDB["DB"]
        Product["Servicio de<br/>Productos"] --> ProductDB["DB"]
        Order["Servicio de<br/>Pedidos"] --> OrderDB["DB"]
        Payment["Servicio de<br/>Pagos"] --> PaymentDB["DB"]
    end

Principios de Diseno de Microservicios

1. Principio de Responsabilidad Unica

Cada servicio se especializa en una funcion de negocio.

Buen ejemplo:
- Servicio de autenticacion: Login, gestion de tokens
- Servicio de productos: Informacion de productos, gestion de inventario
- Servicio de pedidos: Procesamiento de pedidos, gestion de historial

Mal ejemplo:
- Servicio de usuarios: Autenticacion + Perfiles + Notificaciones + Configuracion
  → Demasiadas responsabilidades

2. Autonomia

Los servicios deben poder desplegarse y operarse independientemente sin depender de otros servicios.

3. Gestion de Datos Distribuida

Cada servicio posee sus propios datos y no accede directamente a la base de datos de otros servicios.

4. Aislamiento de Fallos

Disenar para que el fallo de un servicio no se propague a todo el sistema.

Patrones de Comunicacion entre Servicios

Comunicacion Sincrona (REST/gRPC)

Cliente → API Gateway → Servicio A → Servicio B
                              ↑
                         Espera respuesta

• REST API: Simple, basado en HTTP
• gRPC: Comunicacion eficiente con Protocol Buffers

Comunicacion Asincrona (Colas de Mensajes)

Servicio A → [Cola de Mensajes] → Servicio B
            (RabbitMQ, Kafka)
               ↑
            Respuesta inmediata, procesamiento posterior

• Orientado a eventos: Logra bajo acoplamiento entre servicios
• Confiabilidad: Persistencia y reenvio de mensajes

Enfoques de Division de Servicios

Diseno Orientado al Dominio (DDD)

Dividir servicios por Contextos Delimitados (Bounded Context).

flowchart TB
    subgraph EC["Ejemplo de Sitio E-Commerce"]
        subgraph ProductCtx["Contexto de Productos"]
            P1["Producto"]
            P2["Categoria"]
            P3["Inventario"]
        end

        subgraph OrderCtx["Contexto de Pedidos"]
            O1["Pedido"]
            O2["Detalle de Pedido"]
            O3["Envio"]
        end

        subgraph CustomerCtx["Contexto de Clientes"]
            C1["Cliente"]
            C2["Direccion"]
        end

        subgraph PaymentCtx["Contexto de Pagos"]
            Pay1["Pago"]
            Pay2["Facturacion"]
        end
    end

Criterios de Division

Desafios y Soluciones de Microservicios

Complejidad de Sistemas Distribuidos

Patron Circuit Breaker

Operacion normal:
Cliente → Servicio A → Servicio B
                ↓
           Respuesta normal

Fallo (Circuit abierto):
Cliente → Servicio A ✕ Servicio B (fallo)
                ↓
           Respuesta fallback
           (cache o valor por defecto)

Cuando Elegir Microservicios

Casos Adecuados

• Equipos grandes que necesitan desarrollo paralelo
• Necesidad de usar diferentes stacks tecnologicos por servicio
• Escalar solo funcionalidades especificas de forma independiente
• Dominios claramente separables

Casos No Adecuados

• Aplicaciones pequenas
• Equipos pequenos (5 personas o menos)
• Conocimiento de dominio insuficiente
• Infraestructura operacional no preparada

Monolith First: Frecuentemente se recomienda comenzar con un monolito y dividir en microservicios conforme el sistema crece.

Resumen

Los microservicios son un poderoso patron de arquitectura para gestionar la complejidad de sistemas a gran escala. Sin embargo, conllevan desafios propios de los sistemas distribuidos. Es importante elegir la arquitectura apropiada considerando el tamano del equipo, la complejidad del negocio y la capacidad operacional.