Azure Service Bus para mensagens desacopladas

Em arquiteturas fortemente acopladas, os serviços chamam uns aos outros de forma síncrona — se o serviço downstream estiver lento ou indisponível, o chamador também ficará bloqueado ou falhará. As filas de mensagens introduzem um buffer assíncrono entre produtores e consumidores, evitando que um serviço downstream lento cause uma cascata de falhas nos serviços upstream. O Azure Service Bus é o serviço de mensagens empresarial da Microsoft, oferecendo filas (ponto a ponto) e tópicos (publicação-assinatura), com recursos de entrega garantida, ordenação e encaminhamento para a fila de mensagens não entregues.

Um namespace do Service Bus é o contêiner de nível superior para todas as entidades de mensagens (filas e tópicos) e fornece o endpoint FQDN (por exemplo, myns.servicebus.windows.net). Os namespaces estão disponíveis em três camadas: Basic (somente filas, sem tópicos, tamanho máximo de mensagem de 256 KB), Standard (filas e tópicos, máximo de 256 KB) e Premium (filas e tópicos, mensagens de até 100 MB, capacidade dedicada, integração com VNet e recuperação de desastre geográfico). A camada Premium é necessária para cargas de trabalho de produção que exigem desempenho respaldado por SLA.

Uma fila do Service Bus armazena mensagens na ordem FIFO e entrega cada mensagem a exatamente um consumidor. Os consumidores recebem mensagens usando um mecanismo de bloqueio ao consultar: a mensagem fica temporariamente oculta para outros consumidores enquanto é processada. Se o consumidor concluir o processamento com êxito, ele chama CompleteMessage() para remover a mensagem da fila. Se o processamento falhar, o consumidor chama AbandonMessage(), e a mensagem volta a ficar visível para outra tentativa. Após um número configurável de tentativas de entrega, as mensagens que não puderem ser processadas serão movidas para a fila de mensagens não entregues (DLQ).

Tópicos implementam o padrão de publicação-assinatura: um produtor envia uma mensagem para um tópico, e qualquer número de assinaturas desse tópico recebe uma cópia da mensagem. As assinaturas podem ter filtros (expressões SQL ou de correlação) para receber apenas um subconjunto das mensagens — por exemplo, uma assinatura HighPriority que recebe somente mensagens cuja propriedade Priority seja igual a High. Isso permite que um único tópico distribua mensagens para vários serviços downstream, cada um interessado em um subconjunto diferente de eventos.

O SDK do Azure Service Bus fornece um ServiceBusClient para enviar e receber mensagens. Para enviar, crie um ServiceBusSender e chame SendMessageAsync(). Para receber, crie um ServiceBusReceiver e chame ReceiveMessageAsync() (baseado em pull) ou use um ServiceBusProcessor com um manipulador de eventos para o processamento contínuo baseado em push. Usar DefaultAzureCredential com o SDK do Service Bus elimina a necessidade de cadeias de conexão, mantendo o padrão sem senha.

A fila de mensagens não entregues (DLQ) é uma subfila que recebe automaticamente as mensagens que não podem ser entregues. As mensagens são encaminhadas para a fila de mensagens não entregues quando: excedem a contagem máxima de entregas, expiram (o TTL é atingido) ou falham na avaliação de um filtro de assinatura de tópico. Monitorar a DLQ é essencial — uma DLQ em crescimento indica uma falha sistemática de processamento. As mensagens da DLQ mantêm seu conteúdo original, além das propriedades de motivo do encaminhamento para a fila de mensagens não entregues e descrição, adicionadas pelo Service Bus para ajudar a diagnosticar a causa raiz.

Sessões permitem a ordenação rigorosa de mensagens que pertencem ao mesmo grupo lógico. Cada mensagem recebe um SessionId (por exemplo, um ID de cliente ou order ID), e um consumidor que reconhece sessões recebe exclusivamente todas as mensagens de uma determinada sessão na ordem FIFO. As sessões são essenciais para fluxos de trabalho cujas etapas precisam ser executadas em sequência — como processar todos os eventos de um pedido específico: Criado → PaymentReceived → Enviado → Entregue. As sessões são habilitadas no momento da criação da fila ou da assinatura.

Esses três serviços de mensagens do Azure costumam ser confundidos: o Service Bus é voltado para mensagens empresariais confiáveis e transacionais, com ordenação, sessões e DLQ — adequado para processamento de pedidos, transações financeiras e orquestração de fluxos de trabalho. O Event Grid é voltado para o roteamento reativo de eventos (um blob foi carregado, uma VM foi excluída), com distribuição para vários manipuladores, mas sem ordenação ou reprodução. O Event Hubs é voltado para transmissão de eventos com alto rendimento (milhões de eventos por segundo), com capacidade de reprodução — adequado para telemetria de IoT e ingestão de registros. Escolha com base nos requisitos de ordenação, rendimento e durabilidade.

A recuperação de desastre geográfico (Geo-DR) do Service Bus replica os metadados do namespace (filas, tópicos, assinaturas e políticas de acesso) para uma região secundária. As regiões emparelhadas compartilham um único nome de host de alias; se a região primária falhar, você inicia um failover, e o alias passa a resolver para a região secundária. Observe que os dados das mensagens (mensagens em trânsito) não são replicados na camada Standard — somente a Geo-DR da camada Premium replica mensagens. Para mensagens essenciais à operação, use Premium + Geo-DR para atender aos requisitos de RTO e RPO.

Para cenários de alto rendimento, habilite o particionamento de filas e tópicos no momento da criação. As entidades particionadas usam internamente vários agentes de mensagens e fragmentos de armazenamento, multiplicando a capacidade de rendimento. Na camada Standard, as entidades particionadas têm tamanho total de até 80 GB. Cada mensagem é roteada para uma partição com base em sua propriedade PartitionKey (por padrão, o ID da sessão, se as sessões estiverem habilitadas). O particionamento é uma decisão única tomada durante a criação — não é possível particionar uma fila existente. Use a camada Premium para obter o maior rendimento garantido sem a complexidade do particionamento.

Principais métricas do Service Bus a serem monitoradas no Azure Monitor: Active Messages (profundidade da fila — uma profundidade crescente indica atraso do consumidor), Dead-lettered Messages (falhas de processamento), Server Errors e User Errors (problemas de autenticação e limitação) e Incoming Requests (rendimento geral). Configure alertas de métricas para que as equipes de operações sejam notificadas quando a fila de mensagens não entregues crescer além de um limite ou quando as mensagens ativas não forem consumidas durante um período prolongado.

Teste sua compreensão dos conceitos do Microsoft Azure Fundamentals (AZ-900) desta lição.

Nesta lição, você aprendeu que: as filas do Service Bus fornecem mensagens ponto a ponto com entrega por bloqueio ao consultar e uma fila de mensagens não entregues para mensagens com falha; os tópicos e as assinaturas distribuem mensagens para vários consumidores usando regras de filtro; e as sessões permitem o processamento ordenado de mensagens pertencentes ao mesmo grupo lógico. A seguir, exploraremos o Azure Container Apps para implantar microsserviços modernos.