Cuando diseñas una aplicación web basada en una arquitectura de microservicios, debes decidir cómo dividir las funciones de tu aplicación en microservicios y cómo se llamarán esos microservicios como parte de la aplicación. Para los servicios de larga duración, se recomienda usar llamadas de servicio asíncronas. En esta arquitectura de referencia, se analiza cómo implementar una aplicación alojada en contenedores que invoque procesos de larga duración de forma asíncrona.
Este documento de arquitectura de referencia está dirigido a desarrolladores y arquitectos que deseen implementar microservicios de manera asíncrona con tecnologías modernas, como Google Kubernetes Engine (GKE) y Pub/Sub. En el documento, se supone que estás familiarizado con los microservicios en general y con Pub/Sub y GKE en Google Cloud.
Arquitectura
En el siguiente diagrama, se muestra un caso de ejemplo en el que una aplicación genera imágenes en miniatura. Generar imágenes en miniatura puede ser una tarea que usa muchos recursos y, por lo tanto, puede ser lenta.
Figura 1. Arquitectura original para el procesamiento de imágenes basada en el uso de VMs.
En el diagrama anterior, la aplicación recibe archivos de imagen de los clientes y, luego, genera las miniaturas. En esta arquitectura, la aplicación se implementa con instancias de máquina virtual (VM) en Compute Engine y con el almacenamiento de archivos de backend en Cloud Storage. La aplicación almacena los metadatos con Cloud Storage. Cloud Load Balancing distribuye solicitudes a varias VM.
Para reducir la sobrecarga operativa y mantener las VM, migra este sistema a una arquitectura nueva que no use VM.
En el siguiente diagrama, se muestra cómo se puede implementar este flujo con servicios administrados que usan notificaciones y microservicios para implementar llamadas asíncronas entre los componentes del sistema.
Figura 2. Arquitectura nueva para el procesamiento de imágenes que se basa en el uso de contenedores y mensajería asíncrona.
En la arquitectura nueva, el cliente envía una imagen a la aplicación y esta la sube a Cloud Storage. Luego, con las notificaciones de Pub/Sub se coloca un mensaje en la cola de mensajes de Pub/Sub. El mensaje llama a un microservicio que se ejecuta en GKE. El microservicio recupera la imagen de Cloud Storage, genera una miniatura y la sube a Cloud Storage.
Consideraciones del diseño
Los siguientes lineamientos pueden ayudarte a desarrollar una arquitectura que satisfaga los requisitos de tu organización respecto de la eficiencia operativa y el rendimiento.
Eficiencia operativa
La arquitectura nueva tiene las siguientes ventajas:
Escalabilidad independiente: En la arquitectura original, la aplicación que se ejecuta en Compute Engine aborda dos tareas principales. Una tarea es recibir archivos y la otra es generar una miniatura a partir de la imagen original. Recibir archivos subidos consume ancho de banda de red, mientras que la generación de miniaturas es una tarea con un consumo intensivo de CPU. Las instancias de Compute Engine pueden quedarse sin recursos de CPU para generar imágenes, pero aún tener suficientes recursos de red para recibir archivos. En la arquitectura nueva, Cloud Storage y GKE comparten estas tareas, lo que las hace escalables de forma independiente.
Facilidad para agregar funciones nuevas: En la arquitectura original, si quieres agregar funciones, debes implementarlas en las mismas instancias de Compute Engine. En la arquitectura nueva, puedes desarrollar una aplicación y agregarla de forma independiente; por ejemplo, puedes agregar una aplicación de envío de correo electrónico para que te notifique cuando se genera una miniatura nueva. Pub/Sub puede conectarse a la aplicación de generación de miniaturas y a la aplicación de envío de correo electrónico de forma asíncrona sin modificar el código original que se ejecuta en GKE.
Acoplamiento reducido: En la arquitectura original, un problema común es el acoplamiento temporal. Si un servidor de retransmisión de correo no está disponible, cuando la aplicación intenta enviar una notificación, esta fallará. Esos procesos están vinculados con acoplamiento alto y es posible que un cliente no obtenga una respuesta exitosa de la aplicación. En la arquitectura nueva, el cliente obtiene una respuesta exitosa porque la generación de una miniatura y el envío de una notificación se vinculan con acoplamiento bajo.
Esta arquitectura nueva tiene las siguientes desventajas:
Esfuerzos adicionales para modernizar la aplicación: Crear contenedores en una aplicación requiere tiempo y esfuerzo. En la arquitectura nueva se usan más servicios y se requiere un enfoque de observabilidad diferente, que incluye cambios en la supervisión de la aplicación, el proceso de implementación y la administración de recursos.
La necesidad de controlar la duplicación en la aplicación: Pub/Sub garantiza la entrega de mensajes al menos una vez, lo que significa que se pueden enviar mensajes duplicados. Tu aplicación debe controlar esta posibilidad.
Rendimiento
La arquitectura nueva puede brindarte un uso eficiente de los recursos: En la arquitectura original, el escalamiento horizontal de las instancias de Compute Engine consume más recursos para ejecutar sistemas operativos. Con GKE, puedes usar de manera eficiente los recursos del servidor que ejecutan varios contenedores en unos pocos servidores (empaquetado en contenedores). Puedes escalar contenedores de forma horizontal y rápida para que la arquitectura nueva pueda manejar los aumentos breves de carga alta y reducir la escala rápidamente cuando finalicen las tareas.
Implementación
Para implementar una aplicación de ejemplo que use esta arquitectura, consulta Implementa microservicios que usen Pub/Sub y GKE.
¿Qué sigue?
- Lee sobre DevOps y obtén más información sobre la capacidad de la Arquitectura relacionada con esta arquitectura de referencia.
- Realiza la verificación rápida de DevOps para comprender cuál es tu posición en comparación con el resto de la industria.
- Para obtener más información sobre las arquitecturas de referencia, los diagramas y las prácticas recomendadas, explora Cloud Architecture Center.