Message As a Service — Service Bus · raffaeleloi

Quando dois componentes, como microsserviços, se comunicam entre si, o mecanismo mais comum é a requisição HTTP síncrona tradicional: o componente A envia uma requisição via HTTP e aguarda a resposta do componente B.

Image description
Essa abordagem tem uma série de benefícios, como:

Resposta imediata: quem chama fica bloqueado até a requisição ser processada
Feedback imediato de erros: ambos os componentes conseguem tratar falhas assim que elas acontecem
Nenhuma infraestrutura extra: você precisa implementar os endpoints, a autenticação, o tratamento de erros e assim por diante, mas não precisa configurar um serviço ou plataforma externa

A abordagem tradicional tem vários benefícios, mas o que acontece se o componente precisar executar um grande número de operações? E se ele não precisar esperar a conclusão de todas as integrações com sistemas externos? E se você não quiser o acoplamento temporal? E as falhas em cascata, quando o componente A chama o componente B, que chama o componente C, e assim por diante? E se você precisar de um estilo de comunicação assíncrono?
É aí que entra o conceito de mensageria assíncrona. Com essa abordagem, você pode construir operações assíncronas. Por exemplo, o componente A pode enviar uma mensagem para um message broker, que a entrega aos listeners interessados.
O message broker é um componente central que recebe todas as mensagens em filas (queues) ou tópicos (topics), e os listeners buscam essas mensagens no broker. Essa abordagem também traz uma série de benefícios, como:

Operação assíncrona: o componente que envia a requisição não precisa esperar até que ela termine
Normalmente o message broker oferece muitos recursos nativos, como mecanismos de retry e dead-letter queues
Desacoplamento
Resiliência: o consumidor pode estar fora do ar e as mensagens ficam aguardando
Nivelamento de carga (load levelling): absorve picos de tráfego

No Azure, uma das opções para implementar esse estilo de comunicação é o Service Bus.
O Azure Service Bus é um message broker corporativo gerenciado, com filas e tópicos de publicação/assinatura (publish-subscribe).
Você pode escolher entre filas e tópicos.
As filas armazenam as mensagens até que o componente receptor esteja disponível para processá-las. Seguem o padrão de consumidores concorrentes (competing consumers): uma mensagem para um consumidor.
Os tópicos suportam múltiplas assinaturas, de modo que cada assinatura do tópico recebe uma cópia da mensagem. No Azure, o tier Basic não suporta tópicos.

Image description
Também é importante estar ciente de algumas desvantagens, como:

Consistência eventual: os dados entre os serviços não estarão sincronizados imediatamente
Complexidade
Depuração e rastreamento mais difíceis
Exige consumidores idempotentes

Para concluir, é importante conhecer os estilos de comunicação, seus benefícios e suas desvantagens, para que esse conhecimento afine e guie nossas decisões, em vez de simplesmente fazermos as coisas sem critério.

Sobre o "exige consumidores idempotentes", no Service Bus a duplicata aparece mesmo sem nenhum erro. No modo padrão (peek-lock) a mensagem fica travada pro consumidor durante o lock duration, que por padrão é 1 minuto. Se o processamento passar disso, o lock expira, a mensagem volta pra fila e outro consumidor pega de novo. O ServiceBusProcessor do SDK renova o lock sozinho até o MaxAutoLockRenewalDuration (5 minutos por padrão), então job mais longo que isso precisa de ajuste.

E a detecção de duplicatas do próprio Service Bus só pega mensagem repetida com o mesmo MessageId dentro da janela configurada. Ela protege contra o produtor reenviando, mas não contra o consumidor processando duas vezes. Também só dá pra ligar na criação da fila e ela não existe no tier Basic.