Padrões de mensagens assíncronas e elevada disponibilidade

As mensagens assíncronas podem ser implementadas de várias maneiras diferentes. Com filas, tópicos e assinaturas, o Barramento de Serviço do Azure dá suporte ao assincronismo por meio de um mecanismo de armazenamento e encaminhamento. Na operação normal (síncrona), você envia mensagens para filas e tópicos e recebe mensagens de filas e assinaturas. Os aplicativos que você escreve dependem de essas entidades estarem sempre disponíveis. Quando a integridade da entidade muda, devido a uma variedade de circunstâncias, você precisa de uma maneira de fornecer uma entidade de capacidade reduzida que possa satisfazer a maioria das necessidades.

Os aplicativos normalmente usam padrões de mensagens assíncronas para habilitar vários cenários de comunicação. Você pode criar aplicativos nos quais os clientes podem enviar mensagens para serviços, mesmo quando o serviço não está em execução. Para aplicativos que experimentam picos de comunicações, uma fila pode ajudar a nivelar a carga , fornecendo um local para armazenar comunicações em buffer. Finalmente, você pode obter um balanceador de carga simples, mas eficaz, para distribuir mensagens em várias máquinas.

A fim de manter a disponibilidade de qualquer uma dessas entidades, considere várias maneiras diferentes pelas quais essas entidades podem parecer indisponíveis para um sistema de mensagens durável. De um modo geral, vemos que a entidade se torna indisponível para aplicativos que escrevemos das seguintes maneiras diferentes:

• Não é possível enviar mensagens.
• Não é possível receber mensagens.
• Não é possível gerenciar entidades (criar, recuperar, atualizar ou excluir entidades).
• Não é possível contactar o serviço.

Para cada uma dessas falhas, existem diferentes modos de falha que permitem que um aplicativo continue a executar o trabalho em algum nível de capacidade reduzida. Por exemplo, um sistema que pode enviar mensagens, mas não recebê-las, ainda pode receber pedidos de clientes, mas não pode processar esses pedidos. Este tópico discute possíveis problemas que podem ocorrer e como esses problemas são atenuados. O Service Bus introduziu uma série de mitigações nas quais você deve optar, e este tópico também discute as regras que regem o uso dessas mitigações de aceitação.

Fiabilidade no Service Bus

Há várias maneiras de lidar com problemas de mensagens e entidades, e há diretrizes que regem o uso apropriado dessas atenuações. Para entender as diretrizes, você deve primeiro entender o que pode falhar no Service Bus. Devido ao design dos sistemas Azure, todos esses problemas tendem a ser de curta duração. A um nível elevado, as diferentes causas de indisponibilidade aparecem da seguinte forma:

• Limitação a partir de um sistema externo do qual o Service Bus depende. A limitação ocorre a partir de interações com recursos de armazenamento e computação.
• Problema para um sistema do qual o Service Bus depende. Por exemplo, uma determinada parte do armazenamento pode encontrar problemas.
• Falha do Service Bus em um único subsistema. Nessa situação, um nó de computação pode entrar em um estado inconsistente e deve reiniciar a si mesmo, fazendo com que todas as entidades que ele serve balanceiem a carga para outros nós. Isso, por sua vez, pode causar um curto período de processamento lento de mensagens.
• Falha do Service Bus em um datacenter do Azure. Esta é uma "falha catastrófica" durante a qual o sistema fica inacessível por muitos minutos ou algumas horas.

Nota

O termo armazenamento pode significar o Armazenamento do Azure e o SQL Azure.

O Service Bus contém várias atenuações para esses problemas. As seções a seguir discutem cada problema e suas respetivas mitigações.

Limitação

Com o Service Bus, a limitação permite o gerenciamento cooperativo da taxa de mensagens. Cada nó individual do Service Bus abriga muitas entidades. Cada uma dessas entidades faz exigências ao sistema em termos de CPU, memória, armazenamento e outras facetas. Quando qualquer uma dessas facetas deteta um uso que excede os limites definidos, o Service Bus pode negar uma determinada solicitação. O chamador recebe uma exceção de servidor ocupado e tenta novamente após 10 segundos.

Como atenuação, o código deve ler o erro e interromper qualquer repetição da mensagem por pelo menos 10 segundos. Como o erro pode acontecer em partes do aplicativo do cliente, espera-se que cada peça execute independentemente a lógica de repetição. O código pode reduzir a probabilidade de ser limitado habilitando o particionamento em um namespace, fila ou tópico.

Para obter mais informações sobre como o código do aplicativo deve lidar com preocupações de limitação, consulte a documentação sobre o padrão de limitação.

Problema para uma dependência do Azure

Outros componentes dentro do Azure podem ocasionalmente ter problemas de serviço. Por exemplo, quando um sistema que o Service Bus usa está sendo atualizado, esse sistema pode experimentar temporariamente recursos reduzidos. Para contornar esses tipos de problemas, o Service Bus investiga e implementa atenuações regularmente. Os efeitos secundários destas atenuações aparecem. Por exemplo, para lidar com problemas transitórios com armazenamento, o Service Bus implementa um sistema que permite que as operações de envio de mensagens funcionem de forma consistente. De um modo geral, a maioria das entidades não enfrentará este problema. No entanto, dado o número de entidades no Service Bus no Azure, essa atenuação às vezes é necessária para um pequeno subconjunto de clientes do Service Bus.

Falha do Service Bus em um único subsistema

Com qualquer aplicativo, as circunstâncias podem fazer com que um componente interno do Service Bus se torne inconsistente. Quando o Service Bus deteta isso, ele coleta dados do aplicativo para ajudar no diagnóstico do que aconteceu. Depois que os dados são coletados, o aplicativo é reiniciado na tentativa de retorná-lo a um estado consistente. Esse processo acontece de forma bastante rápida e resulta em uma entidade que parece estar indisponível por até alguns minutos, embora os tempos de inatividade típicos sejam muito mais curtos.

Nesses casos, o aplicativo cliente gera uma exceção de tempo limite ou uma exceção de mensagens. O Service Bus contém uma atenuação para esse problema na forma de lógica de repetição automatizada do cliente. Uma vez esgotado o período de repetição e a mensagem não for entregue, você pode explorar usando outros mencionados no artigo sobre como lidar com interrupções e desastres.

Próximos passos

Agora que você aprendeu as noções básicas de mensagens assíncronas no Service Bus, leia mais detalhes sobre como lidar com interrupções e desastres.