¿Qué son los microservicios?

¿Qué son los microservicios?

Los microservicios son un estilo de arquitectura que construye una aplicación como un conjunto de servicios pequeños. Cada uno se ejecuta en su propio proceso, se encarga de una capacidad de negocio y habla con los demás mediante API bien definidas. Cada servicio puede desplegarse, escalarse y actualizarse sin volver a desplegar el resto. La alternativa es el monolito, donde todas las funciones se entregan juntas como una sola unidad. El intercambio: servicios individuales más simples a cambio de un sistema más complejo en conjunto.

Cómo funciona un sistema de microservicios

• Servicios en torno a capacidades de negocio. Una tienda puede tener servicios separados de catálogo, carrito, pago y envío, cada uno con su código y un equipo responsable.
• Comunicación por red. Los servicios se llaman de forma síncrona mediante endpoints de API (normalmente REST o gRPC) o de forma asíncrona mediante un broker de mensajes como Kafka o una cola.
• Datos propios de cada servicio. Cada servicio tiene su almacén de datos y los demás lo consultan solo a través de su API. Así los servicios son independientes, pero no existe una única transacción de base de datos entre ellos.
• Un API gateway. Los clientes llaman a un único punto de entrada, que enruta las peticiones al servicio adecuado y gestiona tareas comunes como la autenticación.
• Automatización por debajo. El despliegue independiente exige CI/CD, normalmente contenedores y un orquestador como Kubernetes, además de registros centralizados, métricas y trazado distribuido.

Martin Fowler y James Lewis enumeran nueve rasgos habituales, entre ellos la gestión descentralizada de los datos, la automatización de la infraestructura, el diseño ante fallos y el diseño evolutivo. Señalan que no todos los sistemas reúnen los nueve.

Ventajas

• Despliegue independiente. La corrección de un servicio no espera a la publicación de todo lo demás.
• Escalado dirigido. Escalas los servicios sometidos a presión, no toda la aplicación.
• Aislamiento de fallos. Si un servicio cae, los demás pueden seguir funcionando, siempre que quienes lo llaman gestionen el fallo, por ejemplo con timeouts y circuit breakers.
• Autonomía de los equipos. Equipos pequeños son responsables de un servicio de principio a fin y pueden elegir tecnologías distintas.

Los costes

El Azure Architecture Center de Microsoft enumera los inconvenientes con claridad: más piezas móviles, pruebas más difíciles entre servicios dependientes, consistencia de datos sin transacciones ACID entre servicios (consistencia eventual en su lugar), versionado de cada API, latencia de red adicional y necesidad de una cultura DevOps madura. Fowler y Lewis añaden que dividir puede trasladar la complejidad a las conexiones entre servicios, donde es más difícil de ver. Para un equipo pequeño o un producto joven, un monolito bien estructurado suele ser mejor punto de partida.

Errores habituales

• Servicios cortados por capa técnica y no por dominio de negocio. El resultado son cambios que siempre tocan varios servicios.
• Una base de datos compartida. Los esquemas compartidos acoplan los servicios y eliminan gran parte del beneficio.
• Servicios demasiado habladores. Las cadenas largas de llamadas (A llama a B, que llama a C) se suman en latencia y propagan los fallos.
• Sin timeouts, reintentos ni circuit breakers. Una dependencia lenta ralentiza entonces a todos sus clientes.
• Demasiados servicios demasiado pronto. Operar decenas de servicios requiere herramientas que la mayoría de los equipos pequeños no tiene.
• Observabilidad débil. Sin registros y trazas correlacionados, encontrar el servicio que falla en una cadena de peticiones es adivinar.

Microservicios, pruebas de carga y monitorización

Cada servicio tiene su propio límite de capacidad y un servicio lento puede arrastrar a todo lo que lo llama, así que prueba tanto servicios individuales como la cadena completa. Una prueba de carga muestra dónde se estanca el rendimiento y qué servicio llega antes a su límite. LoadFocus ejecuta pruebas JMeter y k6 desde 25 regiones en la nube y el plan gratuito incluye hasta 10 usuarios virtuales. En producción, la monitorización de API comprueba cada endpoint de servicio de forma programada (estado, cuerpo y tiempo de respuesta; cada 5 minutos en el plan gratuito) y las herramientas de observabilidad unen las señales. Consulta la monitorización de API de LoadFocus. Para un enfoque paso a paso, lee la guía sobre pruebas de carga de microservicios en la nube (en inglés). Si primero diseñas los contratos entre servicios, el enfoque API-first encaja bien.

Preguntas frecuentes sobre microservicios

¿Qué diferencia hay entre microservicios y monolito?

Un monolito entrega todas las funciones como una sola unidad desplegable. Los microservicios las dividen en servicios desplegados por separado, con datos propios. Permiten escalar y publicar de forma independiente, pero añaden llamadas de red, datos distribuidos y más trabajo de operación.

¿Cuándo conviene usar microservicios?

Cuando varios equipos necesitan publicar de forma independiente, partes del sistema tienen necesidades de escalado muy distintas y ya cuentas con un CI/CD y una monitorización sólidos. Para un equipo pequeño o un producto en fase inicial, empieza con un monolito modular.

¿Cómo se comunican los microservicios?

De forma síncrona mediante API HTTP (REST o gRPC) o de forma asíncrona mediante mensajes y eventos en un broker o una cola. La mensajería asíncrona reduce el acoplamiento y encaja con flujos que no necesitan respuesta inmediata.

¿Cómo se gestionan los datos en microservicios?

Cada servicio es propietario de sus datos y los expone mediante una API. Los cambios que abarcan varios servicios usan consistencia eventual, por ejemplo con eventos, en lugar de una única transacción ACID.

¿Cómo se prueban los microservicios?

Combinando pruebas unitarias por servicio, pruebas de contrato que verifican el acuerdo entre quien llama y quien responde, pruebas de integración de los flujos clave y pruebas de carga de servicios individuales y de la cadena completa.

¿Un microservicio es lo mismo que una API?

No. Una API es una interfaz. Un microservicio es un servicio desplegable que expone una, y un sistema de microservicios se compone de muchos.