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?
- 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.
- Métricas medibles: define métricas claras: tiempo de respuesta, disponibilidad, throughput.
- 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:
- División de datos por microservicio Cada servicio controla su base de datos. Por ejemplo:
- El servicio de pedidos gestiona las tablas
ordersyorder_items. - El servicio de usuarios gestiona las tablas
usersyprofiles.
- El servicio de pedidos gestiona las tablas
- 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.
GO TO FULL VERSION