CodeGym /Cursos /Módulo 5. Spring /Lección 164: Principios básicos de la arquitectura de mic...

Lección 164: Principios básicos de la arquitectura de microservicios (SLA, despliegue independiente)

Módulo 5. Spring
Nivel 11 , Lección 3
Disponible

Hoy profundizaremos en los principios de la arquitectura de microservicios, como Service Level Agreement (SLA) y despliegue independiente, y también tocaremos la gestión descentralizada de datos.


Service Level Agreement (SLA): una promesa para tu mundo

El SLA se puede ver como un contrato entre un microservicio y sus consumidores (otros servicios, clientes o la empresa en general). En ese contrato se especifican garantías claras: qué tan rápido debe responder el servicio, con qué disponibilidad debe operar y qué niveles de fiabilidad debe mantener. El SLA es tu KPI personal para el microservicio.

Por ejemplo: si desarrollas un servicio de procesamiento de pagos, el SLA puede incluir requisitos como:

  • 99.9% de tiempo de disponibilidad (tiempo de inactividad no mayor a 43 minutos al mes).
  • Tiempo de respuesta del API menor a 200 milisegundos.
  • Procesamiento de al menos 1000 peticiones por segundo en picos de carga.

¿Cómo establecer un SLA?

  1. Comprender el valor del negocio: averigua cuánto impacta cada microservicio en la compañía. Por ejemplo, el sistema de autorización es crítico, mientras que el servicio de recomendaciones puede permitirse "cojear" de vez en cuando.
  2. Métricas medibles: define métricas claras: tiempo de respuesta, disponibilidad, throughput.
  3. Monitorización: el sistema de monitorización debe registrar el cumplimiento del SLA.

ejemplo de SLA


⚙️ Servicio de pago (Payment Service):
- Disponibilidad: 99.95%
- Tiempo de respuesta: menos de 250 ms para el 95% de las transacciones
- Tiempo máximo de recuperación tras fallo: 5 minutos

Importante: si uno de los microservicios incumple el SLA, ¡eso puede afectar a todo el ecosistema de la aplicación!


Despliegue independiente: microservicios de forma autónoma

Cuando desarrollas una aplicación monolítica, cualquier cambio requiere reconstruir todo el proyecto, ejecutar todos los tests y desplegar en el servidor. Si tu proyecto pesa un par de gigabytes y hay 200 desarrolladores trabajando en paralelo —prepárate para noches infernales de releases.

Los microservicios te libran de esas pesadillas nocturnas. Cada servicio es una mini-aplicación que puedes desplegar, actualizar y revertir independientemente de los demás. Es como mandar a un equipo de agentes especiales en lugar de un ejército enorme.

Cómo organizar el despliegue independiente

1. Divide en bloques funcionales. Cada microservicio debe representar una funcionalidad completa, por ejemplo:

  • Servicio de autorización
  • Servicio de procesamiento de pagos
  • Servicio de notificaciones

2. Minimiza los acoplamientos entre servicios. Usa REST o colas asíncronas, como Kafka. Si los servicios están demasiado acoplados, llevarás los problemas del monolito al mundo de los microservicios.

Ejemplo de interacción asíncrona:


@Service
public class PaymentProducer {

    private final KafkaTemplate<String, String> kafkaTemplate;

    public PaymentProducer(KafkaTemplate<String, String> kafkaTemplate) {
        this.kafkaTemplate = kafkaTemplate;
    }

    public void notifyPaymentProcessed(String paymentId) {
        kafkaTemplate.send("payment-topic", paymentId);
    }
}

El servicio de pagos envía un mensaje a Kafka sin preocuparse de quién ni cuándo lo recibirá.

3. Usa CI/CD. La nueva versión del microservicio se despliega automáticamente tras los tests. Ejemplo de configuración del pipeline de CI/CD para un microservicio:


stages:
  - build
  - test
  - deploy

build:
  stage: build
  script: mvn clean package
  artifacts:
    paths:
      - target/*.jar

test:
  stage: test
  script: mvn test

deploy:
  stage: deploy
  script: |
    scp target/*.jar user@server:/apps/microservice
    ssh user@server "sudo systemctl restart microservice"

Gestión descentralizada de datos: nada de bases "ricas" compartidas

La modularidad de los datos es la piedra angular de los microservicios. Lo ideal es que cada microservicio tenga su propia base de datos, para evitar la contención de recursos y los riesgos de que diferentes servicios modifiquen la misma tabla al mismo tiempo.

Enfoques para la gestión de datos:

  1. División de datos por microservicio Cada servicio controla su base de datos. Por ejemplo:
    • El servicio de pedidos gestiona las tablas orders y order_items.
    • El servicio de usuarios gestiona las tablas users y profiles.
  2. CQRS y Event Sourcing Usa el enfoque CQRS (Command Query Responsibility Segregation) para separar lectura y escritura. Por ejemplo, un comando que cambia el estado de un pedido emite un evento que luego procesa otro servicio.

Ejemplo de CQRS usando eventos:


// Envío de evento
public void updateOrderStatus(Order order) {
    order.setStatus(OrderStatus.PROCESSING);
    orderRepository.save(order);
    eventPublisher.publish(new OrderUpdatedEvent(order.getId(), order.getStatus()));
}

Aplicación práctica

Acabas de aprender cómo SLA, el despliegue independiente y la descentralización de datos convierten a los microservicios en una herramienta potente de desarrollo. Estos principios proporcionan la flexibilidad, escalabilidad y fiabilidad que son tan importantes para las aplicaciones modernas.

Pero ten en cuenta: cada una de estas ideas requiere herramientas serias. Por ejemplo, para implementar SLA y la gestión descentralizada de datos necesitarás sistemas de monitorización, como Prometheus, para seguir métricas de rendimiento, así como soluciones arquitectónicas como Kafka o RabbitMQ para la comunicación asíncrona.

Los microservicios ayudaron a Netflix y Uber a alcanzar una escala mundial. Teniendo en cuenta que su éxito se basa en principios como SLA, independencia de despliegue y una buena gestión de datos, estos mismos enfoques pueden ayudar a tu proyecto —ya sea una startup o una aplicación corporativa.

Comentarios
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION