Azure Service Bus para mensajería desacoplada

En las arquitecturas estrechamente acopladas, los servicios se llaman entre sí de forma síncrona: si el servicio posterior es lento o no está disponible, el servicio que realiza la llamada también se bloquea o falla. Las colas de mensajería introducen un búfer asíncrono entre productores y consumidores, de modo que un servicio posterior lento no provoque un efecto dominó de errores en los servicios anteriores. Azure Service Bus es el servicio de mensajería empresarial de Microsoft, que proporciona colas (punto a punto) y temas (publicación-suscripción), con capacidades de entrega garantizada, ordenación y mensajes en la cola de mensajes fallidos.

Un espacio de nombres de Service Bus es el contenedor de nivel superior para todas las entidades de mensajería (colas y temas) y proporciona el punto de conexión FQDN (por ejemplo, myns.servicebus.windows.net). Los espacios de nombres tienen tres niveles: Basic (solo colas, sin temas y con un tamaño máximo de mensaje de 256 KB), Standard (colas y temas, con un máximo de 256 KB) y Premium (colas y temas, mensajes de hasta 100 MB, capacidad dedicada, integración con VNet y recuperación ante desastres geográficos). Premium es necesario para cargas de trabajo de producción que requieren un rendimiento respaldado por un SLA.

Una cola de Service Bus almacena los mensajes en orden FIFO y entrega cada mensaje exactamente a un consumidor. Los consumidores reciben los mensajes mediante un mecanismo de peek-lock: el mensaje se oculta temporalmente a los demás consumidores mientras se procesa. Si el consumidor finaliza correctamente el procesamiento, llama a CompleteMessage() para eliminar el mensaje de la cola. Si el procesamiento falla, el consumidor llama a AbandonMessage() y el mensaje vuelve a estar visible para otro intento. Después de un número configurable de intentos de entrega, los mensajes que no se pueden procesar se trasladan a la cola de mensajes fallidos (DLQ).

Los temas implementan el patrón de publicación-suscripción: un productor envía un mensaje a un tema y cualquier número de suscripciones de ese tema recibe una copia del mensaje. Las suscripciones pueden tener filtros (expresiones SQL o de correlación) para recibir solo un subconjunto de mensajes; por ejemplo, una suscripción HighPriority que solo recibe mensajes cuya propiedad Priority sea igual a High. Esto permite que un solo tema distribuya mensajes a muchos servicios posteriores, cada uno interesado en un subconjunto diferente de eventos.

El SDK de Azure Service Bus proporciona un ServiceBusClient para enviar y recibir mensajes. Para enviar, cree un ServiceBusSender y llame a SendMessageAsync(). Para recibir, cree un ServiceBusReceiver y llame a ReceiveMessageAsync() (basado en extracción), o use un ServiceBusProcessor con un controlador de eventos para realizar un procesamiento continuo basado en inserción. El uso de DefaultAzureCredential con el SDK de Service Bus elimina la necesidad de cadenas de conexión y mantiene el patrón sin contraseñas.

La cola de mensajes fallidos (DLQ) es una subcola que recibe automáticamente los mensajes que no se pueden entregar. Los mensajes se envían a la cola de mensajes fallidos cuando superan el número máximo de entregas, caducan (transcurre el TTL) o no superan la evaluación de un filtro de suscripción de un tema. Es fundamental supervisar la DLQ: una DLQ que crece indica un fallo sistemático de procesamiento. Los mensajes de la DLQ conservan su contenido original y las propiedades motivo del mensaje fallido y descripción, que Service Bus agrega para ayudar a diagnosticar la causa raíz.

Las sesiones permiten ordenar estrictamente los mensajes que pertenecen al mismo grupo lógico. Cada mensaje se etiqueta con un SessionId (por ejemplo, un identificador de cliente o de pedido), y un consumidor compatible con sesiones recibe exclusivamente todos los mensajes de una sesión determinada en orden FIFO. Las sesiones son esenciales para los flujos de trabajo cuyos pasos deben ejecutarse en secuencia, como el procesamiento de todos los eventos de un pedido específico: Created → PaymentReceived → Shipped → Delivered. Las sesiones se habilitan al crear la cola o la suscripción.

Estos tres servicios de mensajería de Azure suelen confundirse: Service Bus está destinado a la mensajería empresarial fiable y transaccional, con ordenación, sesiones y DLQ; es adecuado para el procesamiento de pedidos, las transacciones financieras y la orquestación de flujos de trabajo. Event Grid está destinado al enrutamiento reactivo de eventos (se cargó un blob o se eliminó una máquina virtual), con distribución a varios controladores, pero sin ordenación ni reproducción. Event Hubs está destinado a la transmisión de eventos de alto rendimiento (millones de eventos por segundo), con capacidad de reproducción; es adecuado para la telemetría de IoT y la ingesta de registros. Elija el servicio según los requisitos de ordenación, rendimiento y durabilidad.

La recuperación ante desastres geográficos (Geo-DR) de Service Bus replica los metadatos del espacio de nombres (colas, temas, suscripciones y directivas de acceso) en una región secundaria. Las regiones emparejadas comparten un único nombre de host de alias; si la región primaria falla, se inicia una conmutación por error y el alias se resuelve en la región secundaria. Tenga en cuenta que los datos de los mensajes (mensajes en tránsito) no se replican en el nivel Standard; solo la Geo-DR del nivel Premium replica los mensajes. Para la mensajería de misión crítica, use Premium + Geo-DR para cumplir los requisitos de RTO y RPO.

En escenarios de alto rendimiento, habilite la partición en las colas y los temas al crearlos. Las entidades particionadas usan internamente varios agentes de mensajes y fragmentos de almacenamiento, lo que multiplica la capacidad de rendimiento. En el nivel Standard, las entidades particionadas tienen un tamaño total de hasta 80 GB. Cada mensaje se enruta a una partición según su propiedad PartitionKey (de forma predeterminada, el identificador de sesión si las sesiones están habilitadas). La partición es una decisión única que se toma durante la creación: no se puede particionar una cola existente. Use el nivel Premium para obtener el máximo rendimiento garantizado sin la complejidad de las particiones.

Métricas clave de Service Bus que debe supervisar en Azure Monitor: Active Messages (profundidad de la cola; una profundidad creciente indica retraso del consumidor), Dead-lettered Messages (fallos de procesamiento), Server Errors y User Errors (problemas de autenticación y limitación), y Incoming Requests (rendimiento general). Configure alertas de métricas para notificar a los equipos de operaciones cuando la cola de mensajes fallidos supere un umbral o cuando los mensajes activos no se consuman durante un periodo prolongado.

Compruebe su comprensión de los conceptos de Microsoft Azure Fundamentals (AZ-900) tratados en esta lección.

En esta lección ha aprendido que las colas de Service Bus proporcionan mensajería punto a punto con entrega mediante peek-lock y una cola de mensajes fallidos para los mensajes que no se procesan correctamente; que los temas y las suscripciones distribuyen mensajes entre varios consumidores mediante reglas de filtrado; y que las sesiones permiten procesar en orden los mensajes que pertenecen al mismo grupo lógico. A continuación, exploraremos Azure Container Apps para implementar microservicios modernos.