Arquitectura de microservicios: De monolítico a microservicios
Antes de hablar de los microservicios, es esencial entender qué es una aplicación monolítica. Las arquitecturas monolíticas siguen prevaleciendo en muchos proyectos.
Sin embargo, una arquitectura monolítica implica que la aplicación funcione como una sola unidad con todos los módulos de negocio. Puede contener varios módulos comerciales como pago, autenticación, inventario, etc.
La decisión entre los microservicios y la arquitectura monolítica depende de factores como las necesidades de escalabilidad, la velocidad de desarrollo, la experiencia del equipo y la complejidad del proyecto. Elija los microservicios para obtener escalabilidad, implementación independiente y flexibilidad.
¿Por qué necesitamos microservicios?
Ahora, imaginemos un escenario en el que hay un problema de producción en el módulo de registro de usuarios y el servidor se bloquea, lo que provoca un tiempo de inactividad durante unos minutos. Esto puede tener un impacto significativo en el negocio. Cuando un solo servidor está cargado con muchos módulos, el acoplamiento estrecho entre ellos puede convertirse en un gran problema. Este es solo un ejemplo, varios factores pueden influir en la elección del diseño arquitectónico
Dividir módulos en servicios
Podemos descomponer estos módulos en varios servicios para evitar este tipo de escenarios. Por ejemplo, podemos dividir los módulos de negocio del servidor en los siguientes servicios, y cada uno de estos servicios independientes se denomina microservicio,
1. user_service
2. authentication_service
3. order_service
4. payment_service
Si podemos dividir módulos estrechamente acoplados en servicios separados, podemos desplegarlos de forma independiente. Este enfoque nos permite mantener la funcionalidad de cada servicio, incluso si uno tiene problemas. En el ejemplo mencionado anteriormente, incluso si el servicio de registro de usuarios está inactivo, otros servicios como el pago y el procesamiento de pedidos pueden seguir funcionando.
Escalada
Imaginemos que tu negocio está creciendo y el tráfico de usuarios es alto. Este tráfico de usuarios se puede gestionar de varias maneras. Sin embargo, centrémonos en la escalabilidad del sistema, que tiene dos opciones,
- Escalado vertical: aumenta el tamaño de la instancia añadiendo más RAM y CPU.
- Escalado horizontal: agregue más instancias.
En otras palabras, el escalado vertical implica aumentar el tamaño de sus servidores, mientras que el escalado horizontal agrega más instancias. Al utilizar estos métodos, puede escalar verticalmente su sistema, lo que permite a los usuarios acceder a él sin experimentar problemas de latencia o rendimiento. Sin embargo, los microservicios suelen utilizar el escalado horizontal.
Gestione la complejidad y mejore la comunicación entre servicios.
Los microservicios tienen sus propios patrones de diseño para garantizar una alta disponibilidad y rendimiento. Estos son algunos ejemplos:
- Puerta de enlace de API
- Agregación
- Patrón de disyuntor
- Basado en eventos
- Bases de datos separadas para cada servicio
Ventajas
- La asignación de servicios específicos a equipos separados y la asignación de responsabilidades hace que el desarrollo y la implementación sean más manejables.
- Los servicios se pueden desarrollar utilizando la tecnología más adecuada, eliminando la necesidad de un único lenguaje de programación.
- La escalabilidad de los servidores y el aislamiento de fallos se pueden gestionar fácilmente.
Desventajas
- La configuración de una arquitectura de microservicios puede incurrir en altos costos y aumentar la complejidad en la administración, las pruebas y la depuración.
Arquitectura de microservicios de alto nivel con API Gateway, Message Broker y servicios escalables
En el diagrama siguiente se muestra una vista de alto nivel de un sistema moderno basado en microservicios, destacando componentes clave como la puerta de enlace de API, el equilibrio de carga, la mensajería asincrónica y los servicios escalables.
Punto de entrada y flujo de solicitud
- La CDN (red de entrega de contenido) y el DNS se encargan de la optimización del lado del cliente y la resolución del dominio.
- Todo el tráfico del cliente se canaliza a través de API Gateway, que actúa como un único punto de entrada al sistema. Realiza funciones críticas como:
La autenticación es manejada por el servidor de autenticación, que verifica si los usuarios pueden acceder al sistema.
La limitación de velocidad ayuda a evitar que el sistema se sobrecargue con demasiadas solicitudes a la vez.
La ruptura de circuito evita que las solicitudes vayan a los servicios que ya están fallando, para evitar empeorar las cosas.
Balanceo de carga y servidores de API
- Después de API Gateway, las solicitudes se enrutan a los servicios de backend a través de un equilibrador de carga.
- Dos servidores de API escalables horizontalmente (cada uno con varias instancias) manejan la lógica de negocios sin estado y enrutan los trabajos según sea necesario.
- Estos servidores de API son responsables de producir mensajes a RabbitMQ, lo que permite el procesamiento asíncrono.
Cola de mensajes y procesamiento asincrónico
- El RabbitMQ (Message Broker) se encuentra en el núcleo de la comunicación asíncrona.
- Los mensajes se ponen en cola y luego se consumen en otro conjunto escalable de instancias de servicio.
- Una vez procesado con éxito, los consumidores envían un ACK (acuse de recibo) a RabbitMQ, lo que garantiza la fiabilidad y evita la pérdida de mensajes.
- RabbitMQ se puede implementar dentro de Kubernetes para facilitar la integración o fuera del clúster para una mejor persistencia y alta disponibilidad.
Nota: Para comprender mejor cómo funcionan los agentes de mensajes como RabbitMQ, incluidos conceptos como colas, intercambios y reconocimiento de mensajes, lea este artículo.
Capa de servicio del trabajador
- Un bloque de servicio genérico con varias instancias consume mensajes de RabbitMQ.
- Algunas instancias procesan datos y los almacenan en una base de datos o los envían a un almacenamiento de objetos como Amazon S3.
- Esta separación de la lógica del productor y del consumidor garantiza que el sistema esté desacoplado, sea tolerante a errores y escalable.
Observancia
- La arquitectura incluye registro y monitoreo centralizados a través de herramientas como Grafana y AWS CloudWatch, lo que ayuda a realizar un seguimiento de las métricas y solucionar problemas en los servicios distribuidos.
Resumen
Esta arquitectura promueve la escalabilidad, la resiliencia y la capacidad de mantenimiento. Al aprovechar patrones como API Gateway, la mensajería asíncrona y el escalado horizontal, los sistemas pueden manejar cargas elevadas, aislar errores y evolucionar de forma independiente entre los equipos.
