Arquitectura de microservicios · Mapas mentales
Arquitectura de microservicios. Un mapa mental editable con ramas de colores, ideas secundarias y conexiones. Las líneas curvas muestran relaciones; las flechas aparecen cuando importa la dirección.
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 · Mapas mentales
El lienzo interactivo de MindMap 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 mapa mental
- Empieza por el tema central y sigue una rama de color para explorar sus ideas.
- Las líneas curvas muestran relaciones; las flechas aparecen cuando importa la dirección.
Clients & gateway
Esta rama reúne “Web and mobile clients”, “The gateway is the single entry point: it routes each request to the right service, handles authentication and often aggregates responses from several services.”.
Independent services
Esta rama reúne “Orders service”, “Payments service”, “Teams deploy and scale services independently”, “Users service”.
Messaging
Esta rama reúne “Services communicate by publishing events rather than calling each other directly — so one service's change or outage never blocks another.”.
Owned data
Esta rama reúne “The defining rule of microservices: no shared schema. Each service's data is private to it, which is what allows teams to deploy independently.”.
Observability
Esta rama reúne “Metrics, logs and traces feed one view”.
Conexiones entre ramas
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.
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
Adapta el tema central
Cambia el nombre del tema para adaptarlo a tu proyecto o clase.
Desarrolla las ramas
Edita las ideas y añade ejemplos o notas.
Conecta ideas relacionadas
Dibuja conexiones entre ramas; usa flechas cuando la dirección importe.
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.
Editar este mapa mental en QueryChart
Abre este mapa mental en un lienzo editable. Mueve ideas, añade ramas y dibuja conexiones.