Arquitectura de microservicios: muchos servicios pequeños, un sistema
La arquitectura de microservicios en un lienzo interactivo: la capa de cliente, el API gateway, los servicios desplegados por separado, la mensajería, los almacenes de datos por servicio y la observabilidad.
Los microservicios son una arquitectura en la que una aplicación se construye a partir de muchos servicios pequeños, desplegados de forma independiente y dueños cada uno de sus propios datos, coordinados mediante un API gateway (la pasarela de API) y mensajería en lugar de mediante estado compartido.
Arquitectura de microservicios: muchos servicios pequeños, un sistema
El lienzo interactivo de FlowJam de esta explicación: cada carril, cada fila y cada flecha de arriba forma parte de un diagrama real de QueryChart que puedes abrir y editar.
Cómo leer este diagrama
- Lee primero la columna de la izquierda de arriba abajo: de los clientes al gateway y del gateway a los servicios; ese es el camino de la petición.
- Sigue las flechas que salen de cada servicio: al bus de mensajes, a su propia base de datos y a la observabilidad.
- Las bandas de la derecha son la infraestructura compartida del sistema —mensajería, datos y observabilidad—, y por eso cada servicio apunta hacia ellas.
El camino de la petición
«Clientes web y móviles» inicia el flujo, y «El API gateway enruta y agrega» es el único punto de entrada: enruta cada petición al servicio correcto, se encarga de la autenticación y a menudo ensambla las respuestas de varios servicios. El gateway es el único componente que ve todo cliente, y por eso está entre la capa de cliente y los servicios.
Los servicios
«Servicio de pedidos», «Servicio de usuarios» y «Servicio de pagos» son las unidades desplegadas de forma independiente. Cada una tiene su propio equipo dueño y publica a su propio ritmo. El diagrama conecta cada servicio con el bus de mensajes —los servicios se comunican por eventos y no por llamadas directas— y con su propia base de datos, porque ser dueño de sus datos es lo que hace que un servicio se pueda desplegar por separado.
La infraestructura compartida
«El bus de mensajes desacopla los servicios» permite que un servicio publique un evento sin saber quién lo consume. «Cada servicio es dueño de su propia base de datos» es la regla que evita el acoplamiento por estado compartido. «Métricas, logs y trazas alimentan una sola vista» es la observabilidad que hace operativamente manejable un sistema de muchos servicios: sin ella, un fallo es invisible al cruzar las fronteras. Estas tres bandas son el precio y la recompensa de la arquitectura.
Relaciones clave y conclusiones
- Cada servicio se puede desplegar de forma independiente: la propiedad que todo lo demás de la arquitectura existe para proteger.
- Los servicios se comunican a través del bus de mensajes y son dueños de sus propias bases de datos; el estado compartido es el antipatrón.
- El API gateway es la única puerta de entrada del sistema; los clientes nunca hablan directamente con los servicios.
- La independencia hay que pagarla con observabilidad: muchos servicios solo son manejables cuando una sola vista los cubre a todos.
- Los microservicios orquestan los contenedores que empaqueta Docker: los dos diagramas se conectan.
Cuándo usar este diagrama
- Explicar a un equipo por qué existen los microservicios y cuáles son de verdad sus contrapartidas antes de adoptarlos.
- Documentar las fronteras de servicio, los topics de mensajes y la propiedad de los datos de un sistema ya existente para la incorporación de gente nueva.
- Auditar los antipatrones: una base de datos compartida o un servicio que llama directamente a otro son una fuga de frontera.
Cómo funciona
Renombra los servicios con los de tu sistema
Sustituye Pedidos, Usuarios y Pagos por tus servicios reales y añade los que los tres genéricos no cubren, cada uno como su propia caja en la banda de servicios.
Nombra tus topics de mensajes
Anota en el bus de mensajes los eventos reales que tus servicios publican y a los que se suscriben, para que el desacoplamiento sea concreto y no una afirmación.
Traza la propiedad de los datos
En la flecha que va de cada servicio a su base de datos, anota el almacén real (PostgreSQL, una caché, un índice de búsqueda) y de qué es dueño, para comprobar que se cumple la regla de una base de datos por servicio.
Añade las ramas de fallo y de escalado
Inserta los caminos reales —el reintento y el circuit breaker de un servicio sobre el bus, una réplica escalada de un servicio con mucha carga—, cada uno terminando en un estado explícito.
Preguntas frecuentes
¿Qué es la arquitectura de microservicios?
Es un estilo arquitectónico en el que una aplicación se construye a partir de muchos servicios pequeños, cada uno responsable de una capacidad de negocio, desplegados de forma independiente y dueños de sus propios datos. Los servicios se comunican por red —normalmente HTTP y un bus de mensajes— en lugar de compartir memoria o una base de datos. Las ventajas son el despliegue independiente y la autonomía de los equipos; los costes son la complejidad de red y la necesidad de observabilidad.
¿Por qué cada microservicio es dueño de su propia base de datos?
Porque los datos compartidos son el acoplamiento que rompe el despliegue independiente. Si dos servicios leen y escriben en la misma tabla, no pueden cambiar su esquema, escalar ni desplegar sin coordinarse. Ser dueño de su propio almacén de datos es lo que permite a un servicio evolucionar y escalar a su propio ritmo: la regla que impone la banda «Cada servicio es dueño de su propia base de datos» del diagrama.
¿Cuál es el papel del API gateway en los microservicios?
El gateway es el único punto de entrada del sistema. Enruta las peticiones al servicio correcto, se encarga de los aspectos transversales como la autenticación y la limitación de peticiones, y puede agregar en una sola las respuestas de varios servicios. Los clientes hablan con el gateway, nunca directamente con los servicios individuales, lo que deja libre de cambiar la topología de servicios que hay detrás.
¿Cuándo NO deberías usar microservicios?
Cuando el sistema es pequeño o el equipo es pequeño. Los microservicios cambian complejidad arquitectónica —fallos de red, transacciones distribuidas, observabilidad— por despliegue independiente, y ese intercambio solo compensa cuando el equipo es lo bastante grande como para que el despliegue independiente sea la restricción que limita. Los problemas de muchos equipos se resuelven con un monolito bien modularizado, que es el tema del diagrama de la arquitectura monolítica.
Edita este diagrama en QueryChart (FlowJam)
Abre ese mismo lienzo de microservicios como tu propio diagrama, renombra los servicios con los de tu sistema y traza tus fronteras reales.