Padrões de mensagens assíncronas e alta disponibilidade

O serviço de mensagens assíncrono pode ser implementado de diversas 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 encaminhamento e repositório. Na operação normal (síncrona), você envia mensagens para filas e tópicos e recebe mensagens de filas e assinaturas. Os aplicativos escritos por você dependem de essas entidades estarem sempre disponíveis. Quando a integridade da entidade é alterada, devido a diversas circunstâncias, é necessário ter uma maneira de fornecer uma entidade de capacidade reduzida que possa atender à maioria das necessidades.

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

Para manter a disponibilidade de qualquer uma dessas entidades, considere as várias formas diferentes pelas quais essas entidades podem parecer indisponíveis para um sistema de mensagens durável. Em termos gerais, vemos a entidade se tornar indisponível para os aplicativos que escrevemos das seguintes maneiras:

• 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 entrar em contato com o serviço.

Para cada uma dessas falhas, existem modos de falhas diferentes que habilitam um aplicativo a continuar 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 aborda problemas potenciais que podem ocorrer e como eles são atenuados. O Barramento de Serviço introduziu diversas mitigações que você deverá aceitar, e este tópico também descreve as regras que regem o uso dessas mitigações que exigem aceitação.

Confiabilidade no Barramento de Serviço

Há diversas maneiras de lidar com problemas de mensagens e entidades, e há diretrizes que regem o uso apropriado dessas mitigações. Para entender as diretrizes, primeiro você deve entender o que pode falhar no Barramento de Serviço. Devido ao design de sistemas do Azure, todos esses problemas tendem a ter vida curta. Em um alto nível, as diferentes causas de indisponibilidade ocorrem da seguinte maneira:

• A limitação de um sistema externo do qual o Barramento de Serviço depende. A limitação ocorre devido a interações com os recursos de computação e armazenamento.
• Problema para um sistema do qual o Barramento de Serviço depende. Por exemplo, determinado armazenamento pode encontrar problemas.
• Falha do Barramento de Serviço em um único subsistema. Nessa situação, um nó de computação pode entrar em um estado inconsistente e deve se reiniciar sozinho, fazendo com que todas as entidades a que ele serve tenham a carga equilibrada para outros nós. Por sua vez, isso pode causar um curto período de processamento de mensagens lento.
• Falha do Barramento de Serviço dentro do Azure Data Center. Essa é uma "falha catastrófica" durante a qual o sistema não pode ser acessado por vários minutos ou algumas horas.

Observação

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

O Barramento de Serviço contém várias mitigações para esses problemas. As seções a seguir discutem cada problema e as respectivas mitigações.

Limitação

Com o Barramento de Serviço, a limitação possibilita o gerenciamento cooperativo de taxa de mensagens. Cada nó individual do Barramento de Serviço hospeda várias entidades. Cada uma dessas entidades faz demandas ao sistema em termos de CPU, memória, armazenamento e outros aspectos. Quando qualquer um desses aspectos detecta uso que excede os limites definidos, o Barramento de Serviço pode negar determinada solicitação. O chamador recebe uma exceção de servidor ocupado e faz nova tentativa após 10 segundos.

Como uma mitigação, o código deve ler o erro e interromper repetições da mensagem por pelo menos 10 segundos. Como o erro pode ocorrer em várias partes do aplicativo do cliente, espera-se que cada parte execute de forma independente a lógica de repetição. O código pode reduzir a probabilidade de limitação 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

Ocasionalmente, outros componentes do Azure podem ter problemas de serviço. Por exemplo, quando um sistema que usa o Barramento de Serviço está sendo atualizado, esse sistema pode ter os recursos reduzidos temporariamente. Para resolver esses tipos de problemas, o Barramento de Serviço investiga e implementa mitigações regularmente. Ocorrem efeitos colaterais dessas mitigações. Por exemplo, para lidar com problemas temporários com armazenamento, o Barramento de Serviço implementa um sistema que permite que operações de envio de mensagem funcionem constantemente. Em termos gerais, a maioria das entidades não enfrentará esse problema. No entanto, devido ao número de entidades no Barramento de Serviço no Azure, essa mitigação às vezes é necessária para um pequeno subconjunto de clientes do Barramento de Serviço.

Falha do Barramento de Serviço em um único subsistema

Com qualquer aplicativo, circunstâncias podem fazer com que um componente interno do Barramento de Serviço se torne inconsistente. Quando o Barramento de Serviço detecta isso, ele coleta dados do aplicativo para ajudar a diagnosticar o que aconteceu. Depois que os dados são coletados, o aplicativo é reiniciado em uma tentativa de retorná-lo a um estado consistente. Esse processo acontece rapidamente e resulta em uma entidade que parece estar disponível por alguns minutos, embora os tempos de inatividade típicos sejam mais curtos.

Nesses casos, o aplicativo cliente gera uma exceção de tempo limite ou uma exceção de mensagem. O SDK do Barramento de Serviço contém uma mitigação para esse problema na forma de lógica de repetição de cliente automatizada. Depois que o período de repetição se esgota e a mensagem não é entregue, você pode explorar usando outros recursos mencionados no artigo sobre como lidar com interrupções e desastres.

Próximas etapas

Agora que você aprendeu os conceitos básicos sobre mensagens assíncronas no Barramento de Serviço, saiba mais sobre como lidar com interrupções e desastres.