Padrões de mensagens assíncronas e elevada disponibilidade

As mensagens assíncronas podem ser implementadas de várias formas diferentes. Com filas, tópicos e subscrições, Azure Service Bus suporta o assíncrono através de um mecanismo de armazenamento e reencaminhamento. Numa operação normal (síncrona), envia mensagens para filas e tópicos e recebe mensagens de filas e subscrições. As aplicações que escreve dependem de estas entidades estarem sempre disponíveis. Quando o estado de funcionamento da entidade é alterado, devido a várias circunstâncias, precisa de uma forma de fornecer uma entidade de capacidade reduzida que possa satisfazer a maioria das necessidades.

Normalmente, as aplicações utilizam padrões de mensagens assíncronas para ativar vários cenários de comunicação. Pode criar aplicações nas quais os clientes podem enviar mensagens para serviços, mesmo quando o serviço não está em execução. Para aplicações que experimentam picos de comunicações, uma fila pode ajudar a nivelar a carga ao fornecer um local para colocar as comunicações na memória intermédia. Por fim, pode obter um balanceador de carga simples, mas eficaz, para distribuir mensagens por vários computadores.

Para manter a disponibilidade de qualquer uma destas entidades, considere várias formas diferentes de estas entidades aparecerem indisponíveis para um sistema de mensagens durável. Em termos gerais, vemos que a entidade fica indisponível para aplicações que escrevemos das seguintes formas diferentes:

• Não é possível enviar mensagens.
• Não é possível receber mensagens.
• Não é possível gerir entidades (criar, obter, atualizar ou eliminar entidades).
• Não é possível contactar o serviço.

Para cada uma destas falhas, existem diferentes modos de falha que permitem que uma aplicação continue a trabalhar a um nível de capacidade reduzida. Por exemplo, um sistema que pode enviar mensagens, mas não as receber, ainda pode receber encomendas de clientes, mas não pode processar essas encomendas. Este tópico aborda potenciais problemas que podem ocorrer e como esses problemas são mitigados. O Service Bus introduziu uma série de mitigações nas quais tem de optar ativamente por participar e este tópico também aborda as regras que regem a utilização dessas mitigações de opção ativa.

Fiabilidade no Service Bus

Existem várias formas de lidar com problemas de mensagens e entidades e existem diretrizes que regem a utilização adequada dessas mitigações. Para compreender as diretrizes, primeiro tem de compreender o que pode falhar no Service Bus. Devido à conceção de sistemas do Azure, todos estes 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 de que depende o Service Bus. 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 num único subsistema. Nesta situação, um nó de computação pode entrar num estado inconsistente e tem de reiniciar-se a si próprio, fazendo com que todas as entidades que servem para balancear a carga para outros nós. Isto, por sua vez, pode causar um curto período de processamento lento de mensagens.
• Falha do Service Bus num datacenter do Azure. Trata-se de uma "falha catastrófica" durante a qual o sistema está inacessível durante muitos minutos ou algumas horas.

Nota

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

O Service Bus contém várias mitigações para estes problemas. As secções seguintes abordam cada problema e as respetivas mitigações.

Limitação

Com o Service Bus, a limitação permite a gestão da taxa de mensagens cooperativa. Cada nó individual do Service Bus aloja muitas entidades. Cada uma dessas entidades faz exigências ao sistema em termos de CPU, memória, armazenamento e outras facetas. Quando qualquer uma destas facetas deteta a utilização que excede os limiares definidos, o Service Bus pode negar um determinado pedido. O autor da chamada recebe uma exceção de servidor ocupado e volta a tentar após 10 segundos.

Como mitigação, o código tem de ler o erro e parar quaisquer repetições da mensagem durante, pelo menos, 10 segundos. Uma vez que o erro pode ocorrer em partes da aplicação do cliente, espera-se que cada peça execute a lógica de repetição de forma independente. O código pode reduzir a probabilidade de ser limitado ao ativar a criação de partições num espaço de nomes, fila ou tópico.

Para obter mais informações sobre como o código da aplicação deve lidar com as preocupações de limitação, veja a documentação sobre o Padrão de Limitação.

Problema de uma dependência do Azure

Outros componentes no Azure podem ocasionalmente ter problemas de serviço. Por exemplo, quando um sistema que o Service Bus utiliza está a ser atualizado, esse sistema pode experimentar temporariamente capacidades reduzidas. Para contornar estes tipos de problemas, o Service Bus investiga e implementa mitigações regularmente. Os efeitos secundários destas mitigações são apresentados. Por exemplo, para lidar com problemas transitórios com o armazenamento, o Service Bus implementa um sistema que permite que as operações de envio de mensagens funcionem de forma consistente. Devido à natureza da mitigação, uma mensagem enviada pode demorar até 15 minutos a aparecer na fila ou subscrição afetada e estar pronta para uma operação de receção. De uma forma geral, a maioria das entidades não irá deparar-se com este problema. No entanto, dado o número de entidades no Service Bus no Azure, esta mitigação é por vezes necessária para um pequeno subconjunto de clientes do Service Bus.

Falha do Service Bus num único subsistema

Com qualquer aplicação, as circunstâncias podem fazer com que um componente interno do Service Bus se torne inconsistente. Quando o Service Bus deteta esta situação, recolhe dados da aplicação para ajudar a diagnosticar o que aconteceu. Assim que os dados forem recolhidos, a aplicação é reiniciada numa tentativa de os devolver a um estado consistente. Este processo ocorre bastante rapidamente e resulta numa entidade que parece estar indisponível durante alguns minutos, embora os tempos de inatividade típicos sejam muito mais curtos.

Nestes casos, a aplicação cliente gera uma exceção de tempo limite ou uma exceção de mensagens. O Service Bus contém uma mitigação para este problema sob a forma de lógica de repetição de cliente automatizada. Assim que o período de repetição estiver esgotado e a mensagem não for entregue, pode explorar a utilização de outras mencionadas no artigo sobre como lidar com falhas e desastres.

Passos seguintes

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