VENDAS: 1-800-867-1389

Padrões de mensagens assíncronas e alta disponibilidade

Atualizado: setembro de 2014

O sistema de mensagem assíncrono pode ser implementado em uma variedade de modos diferentes. Com filas, tópicos e assinaturas, coletivamente chamados de entidades do sistema de mensagens, o Microsoft Azure Service Bus suporta assincronia através de um mecanismo de armazenamento e encaminhamento. Em uma operação (síncrona) normal, são enviadas mensagens para filas e tópicos, e recebidas mensagens de filas e assinaturas. Aplicativos gravados por você dependem dessas entidades em estarem sempre disponíveis. Quando a entidade se torna íntegra, devido a uma variedade de circunstâncias, é necessário um modo para reduzir a capacidade da entidade que possa satisfazer a maior parte das necessidades.

Aplicativos normalmente usam mensagens padrões assíncronas para ativar diversos cenários de comunicação. É possível criar aplicativos nos quais clientes podem enviar mensagens para serviços, até mesmo quando o serviço não está sendo executado. Para aplicativos que sofrerem intermitência de comunicações, uma fila pode ajudar a elevar a carga ao fornecer um lugar para comunicações buffer. Finalmente, é possível obter um simples, porém efetivo, balanceamento de carga para distribuir mensagens através de máquinas múltiplas.

Para manter a disponibilidade de qualquer uma dessas entidades, considere um número de meios diferentes no qual essas entidades podem aparecer indisponíveis para um sistema de mensagens durável. Geralmente, vemos a entidade tornar-se indisponível para aplicativos que gravamos dos seguintes modos:

  1. Não é possível enviar mensagens.

  2. Não é possível receber mensagens.

  3. Não é possível administrar as entidades (criar, recuperar, atualizar ou excluir entidades).

  4. Não é possível entrar em contato com o serviço.

Para cada uma dessa falhas, existe modos de falhas diferentes que ativam um aplicativo para que continuem realizando o trabalho em um nível de capacidade reduzida. Por exemplo, um sistema que pode enviar mensagens, porém não pode recebê-las; e pode receber pedidos de clientes, mas não pode processá-los. Esse tópico discute problemas potenciais que possam ocorre e como esses problemas são minimizados. O Service Bus introduziu um número de mitigações que deve ser escolhido, e esse tópico também discute as regras que regem o uso dessas opções de atenuantes.

Há vários modos de lidar com problemas de mensagem e entidade, e há diretrizes que regem o uso apropriado dessas atenuantes. Para entender essas diretrizes, é necessário primeiro o que pode falhar em Service Bus. Devido ao design dos sistemas do Azure, todos esses problemas tendem a ter vida curta. Em um nível alto, as diferentes causas de indisponibilidade aparecem como a seguir:

  • Limitação de um sistema externo do qual o Service Bus depende. A limitação ocorre da interação entre o armazenamento e os recursos calculados.

  • Problemas para um sistema de que o Service Bus depende. Por exemplo, uma determinada peça de armazenamento pode encontrar problemas.

  • Falha do Service Bus em um subsistema único. Nessa situação, um nó de cálculo pode entrar em um estado inconsistente e deve reiniciar sozinho, fazendo com que todas as entidades no servidor sejam equilibradas para outros nós. Esse por sua vez pode causar um período curto de processamento de mensagem lento.

  • Falha do Service Bus em um data center do Azure. Essa é uma clássica "falha catastrófica" durante a qual o sistema está inalcançável por vários minutos ou algumas horas.

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

O Service Bus contém um número de atenuantes para os problemas acima. As sessões seguintes discutem cada problema e as respectivas atenuantes.

Com o Service Bus, a limitação permite o gerenciamento de taxa da mensagem cooperativa. Cada nó individual do Service Bus abriga várias entidades. Cada uma dessas entidades exige do sistema em termos de CPU, memória, armazenamento e outras facetas. Quando muitas dessas facetas detecta uso que excede o limite definido, o Service Bus pode negar uma solicitação fornecida. O chamador recebe um ServerBusyException e recupera após 10 segundos.

Assim como o código de atenuante deve ler o erro e parar qualquer recuperação da mensagem por ao menos 10 segundos. É esperado que cada pedaço execute independentemente uma recuperação lógica, já que o erro pode ocorrer em pedaços do aplicativo do cliente. O código pode reduzir a possibilidade de estar limitado ao ativar particionamento em uma fila ou tópico.

Outros componentes no Azure podem ocasionalmente ter problemas de serviço. Por exemplo, quando um sistema que o Service Bus usa está sendo atualizado, esse sistema pode reduzir temporariamente os recursos. Para trabalhar com esses tipos de problemas, o Service Bus regularmente investiga e implementa atenuantes. Efeitos colaterais dessas atenuantes de fato aparecem. Por exemplo, para manipular esse problemas temporários com armazenamento, o Service Bus implementa um sistema que permite que as operações de envio de mensagem funcionem constantemente. Devido a natureza da atenuante, uma mensagem enviada pode levar até 15 minutos para aparecer na lista afetada ou assinatura, e estar pronta para receber operação. Geralmente, a maioria das entidades não enfrentarão esse problema. No entanto, devido ao número de entidades no Service Bus no Azure, essa atenuação às vezes é necessária para um subconjunto pequeno de clientes do Service Bus.

Com qualquer aplicativo, circunstâncias podem fazer com que um componente interno do Service Bus torne-se inconsistente. Quando o Service Bus detecta isso, é coletado dados do aplicativo com foco em diagnosticar o que houve. Uma vez que os dados são coletados, a aplicação é reiniciada na tentativa de retorná-lo ao estado consistente. Esse processo acontece de maneira relativamente rápida e resulta em uma entidade que parece não estar disponível por alguns minutos, porém os tempos típicos de inatividade são mais curtos.

Nesses casos, o aplicativo do cliente gera um TimeoutException ou exceção de MessagingException . O SDK .NET do Service Bus contém uma atenuante para esse problema na forma de lógica de repetição do cliente automatizado. Uma vez que o período esgota e a mensagem não é entregue, é possível explorar usando outros recursos como namespaces emparelhados. Namespaces emparelhados possuem outras ressalvas que serão discutidas mais adiante.

A razão mais provável para uma falha em um Azure Data Center é uma falha de implementação de atualização do Service Bus ou um sistema dependente. Como a plataforma está desenvolvida, a probabilidade desse tipo de falha é reduzida. Uma falha de data center pode também acontecer por razões que incluem:

  • Queda de energia (fornecimento de energia e produção de energia desaparecem).

  • Conectividade (queda de Internet entre os clientes e o Azure).

Nos dois casos, um desastre natural ou humano causou do problema. Para trabalhar com esse problema e certificar-se que ainda é possível enviar mensagens, você pode usar namespaces emparelhados para permitir que as mensagens sejam enviadas para uma segunda localização enquanto uma primeira localização torna-se íntegra novamente.

Os recursos de namespaces emparelhados suporta cenários no qual a entidade ou implantação do Service Bus dentro do data center torna-se indisponível . Mesmo que esse evento ocorra raramente, sistemas distribuídos ainda podem estar preparados para manipular os piores cenários. Tipicamente, esse evento acontece porque alguns elementos dos quais o Service Bus depende estão sofrendo um problema de curta duração. Para manter a disponibilidade do aplicativo durante um queda, os usuários do Service Bus podem usar dois namespaces separados, preferencialmente em data centers separados, para hospedar as entidades do sistema de mensagens. A pendência dessa seção usa a seguinte terminologia:

  • Namespace primário: O namespace do aplicativo interage com operações de envio e recebimento.

  • Namespace Secundário: O namespace que atua como um backup para o namespace primário. A lógica de aplicativo não interage com esse namespace.

  • Intervalo de failover: A quantidade de tempo para aceitar falhas normais antes do aplicativo alternar do namespace primário para o namespace secundário.

Namespaces emparelhados suportam disponibilidade de envio. A disponibilidade de envio concentra-se em preservar a habilidade de enviar mensagens. Para usar a disponibilidade de envio, o aplicativo deve seguir os seguintes requisitos:

  1. Mensagens são recebidas apenas do namespace primário.

  2. Mensagens enviadas a uma fila/tópico fornecido podem chegar sem funcionamento.

  3. Se o aplicativo usa seções:

    1. Mensagens dentro de uma seção pode chegar sem funcionamento. Esse é uma pausa da funcionalidade normal das sessões. Isso significa que o aplicativo usa sessões para mensagens agrupadas logicamente.

    2. Estado de sessão é mantido somente no namespace primário.

  4. A fila primária pode ser online e começar ao aceitar mensagens antes da fila secundária entregar todas as mensagens dentro da fila primária.

Essa seção discute a API, como as APIs são implementadas e exibe o código de amostra que usa o recurso. Observe que há implicações de cobranças associadas a esse recurso.

O recurso dos namespaces emparelhados introduz o seguinte método novo à classe MessagingFactory :

public Task PairNamespaceAsync(PairedNamespaceOptions options)

Quando a tarefa é concluída, o emparelhamento do namespace também é concluído e pronto para atuar em qualquer MessageReceiver, QueueClient, ou TopicClient criado com o MessagingFactory. PairedNamespaceOptions é a classe base para diferentes tipos de emparelhamento que estão disponíveis com um MessagingFactory. Atualmente, a única classe derivada é uma chamada SendAvailabilityPairedNamespaceOptions, que implementa os requisitos de disponibilidade de envio. SendAvailabilityPairedNamespaceOptions possui um conjunto de construtores que se constroem sozinhos. Olhando para o construtor com a maioria dos parâmetros, é possível entender o comportamento de outros construtores.

public SendAvailabilityPairedNamespaceOptions(
    NamespaceManager secondaryNamespaceManager,
    MessagingFactory messagingFactory,
    int backlogQueueCount,
    TimeSpan failoverInterval,
    bool enableSyphon)

Esses parâmetros possuem os seguintes significados:

  • secondaryNamespaceManager: Uma instância NamespaceManager inicializada para o namespace secundário que o método PairNamespaceAsync pode usar para configurar o namespace secundário. O gerenciador será usado para obter a lista de filas no namespace e certificar-se de que as filas obrigatórias de registros acumulados existam. Se essas filas não existirem, elas serão criadas. O NamespaceManager exige a habilidade de criar um token com a declaração Gerenciar.

  • messagingFactory: A instância MessagingFactory para o namespace secundário. O MessagingFactory é usado para enviar e, se a propriedade EnableSyphon está definida como true, para receber mensagens das filas de registros acumulados.

  • backlogQueueCount: O número das filas de registros acumulados a serem criadas. Este valor deve ser no mínimo 1. Ao enviar mensagens para registro acumulado, umas dessas filas é escolhida aleatoriamente. Se você definir o valor como 1, somente uma fila pode ser usada. Quando isso acontece a fila de registros acumulados gera erros, o cliente não poderá tentar uma fila de registros acumulados diferente e pode haver falha ao enviar a mensagem. É recomendado configurar esse valor com uma quantia alta e padronizar o valor como 10. É possível alterar para um valor mais alto ou mais baixo dependendo de quantos dados o aplicativo envia por dia. Cada fila de registros acumulados pode manter até 5 GB de mensagens.

  • failoverInterval: A quantidade de tempo que irá aceitar falhas no namespace primário antes de alterar qualquer entidade única para o namespace secundário. Failovers ocorrem em uma base de entidade por entidade. Entidades em um único namespace vivem frequentemente em nós diferentes dentro do Service Bus. Uma falha em uma das entidades não implica falha em outra. É possível definir esse valor como System.TimeSpan.Zero e enviar o failover para o secundário imediatamente após a primeira falha não transigente. Falhas que acionam o timer do failover são qualquer MessagingException em que a propriedade IsTransient é falsa, ou uma TimeoutException. Outras exceções, como a UnauthorizedAccessException não irá causar failover, porque isso indica que o cliente está configurado incorretamente. Uma ServerBusyException não causa failover porque o padrão correto é esperar 10 segundos, e então enviar a mensagem novamente.

  • enableSyphon: Indica que um emparelhamento particular deve também tirar com sifão a mensagem do namespace secundário de volta para o namespace primário. No geral, aplicativos que enviam mensagens devem definir esse valor como false; aplicativos que recebem mensagens devem definir esse valor como true. A razão para isso é que, frequentemente, há menos receptores de mensagens do que emissores de mensagens. Dependendo do número de receptores, é possível escolher possuir uma única instância de aplicativo que manipule as tarefas de sifão. Ao usar muitos receptores existem implicações de cobranças para cada fila de registros acumulados.

Para usar o código, crie uma instância primária MessagingFactory, uma instância secundária MessagingFactory, uma instância secundária NamespaceManager e uma instância SendAvailabilityPairedNamespaceOptions . A chamada pode ser simples como seguinte:

SendAvailabilityPairedNamespaceOptions sendAvailabilityOptions =
    new SendAvailabilityPairedNamespaceOptions(secondaryNamespaceManager, secondary);
primary.PairNamespaceAsync(sendAvailabilityOptions).Wait();

Quando a tarefa retornada por métodos PairNamespaceAsync [e concluída, tudo será configurado e estará pronto para o uso. Antes da tarefa ser retornada, é possível que nem todo o trabalho de segundo plano necessário para o correto funcionamento do emparelhamento tenha sido concluído. Como resultado, não comece a enviar mensagens até a tarefa retornar. Se nenhuma falha ocorrer, assim como credenciais inválidas ou falha ao criar filas de registros acumulados, essas exceções serão lançadas de uma vez quando a tarefa for concluída. Uma vez que a tarefa retornar, confirme se as filas foram encontradas ou criadas ao examinar a propriedade BacklogQueueCount na instância SendAvailabilityPairedNamespaceOptions. Para o código anterior, a operação aparece seguinte:

if (sendAvailabilityOptions.BacklogQueueCount < 1)
{
    // Handle case where no queues were created. 
}

Isso foi útil para você?
(1500 caracteres restantes)
Agradecemos os seus comentários
A Microsoft está realizando uma pesquisa online para saber sua opinião sobre o site do MSDN. Se você optar por participar, a pesquisa online lhe será apresentada quando você sair do site do MSDN.

Deseja participar?
Mostrar:
© 2014 Microsoft