Exportar (0) Imprimir
Expandir Tudo

Práticas recomendadas para maximizar a escalabilidade e a relação custo-benefício de soluções de mensagens baseadas em fila no Azure

Atualizado: fevereiro de 2015

Autor: Amit Srivastava

Revisores: Brad Calder, Sidney Higa, Christian Martinez, Steve Marx, Curt Peterson, Paolo Salvatori e Trace Young

Este artigo oferece diretrizes prescritivas e práticas recomendadas para a criação de soluções de mensagens baseadas em fila escalonáveis, econômicas e altamente eficientes na plataforma Azure. O público-alvo deste artigo inclui arquitetos e desenvolvedores de soluções que criam e implementam soluções baseadas em nuvem que utilizam os serviços de armazenamento em fila da plataforma Azure.

Uma solução tradicional de mensagens baseada em fila utiliza o conceito de um local de armazenamento de mensagens conhecido como fila de mensagens, que é um repositório para os dados que serão enviados a um ou mais participantes ou recebidos deles, normalmente por meio de um mecanismo de comunicação assíncrona.

A finalidade deste artigo é examinar como os desenvolvedores podem se beneficiar de padrões específicos de design em conjunto com os recursos fornecidos pela plataforma Azure para criar soluções de mensagens baseadas em fila otimizadas e econômicas. O artigo analisa em detalhes as abordagens mais comuns de implementação de interações baseadas em fila em soluções do Azure, e fornece recomendações para melhorar o desempenho, aumentar a escalabilidade e reduzir despesas operacionais.

A discussão subjacente é mesclada com práticas recomendadas, dicas e recomendações relevantes quando apropriado. O cenário descrito neste artigo realça uma implementação técnica baseada em um projeto de um cliente real.

Uma solução comum de mensagens que troca dados entre os componentes distribuídos usando filas de mensagens inclui publicadores depositando mensagens nas filas, e um ou mais assinantes que devem receber essas mensagens. Na maioria dos casos, os assinantes, às vezes chamados de ouvintes de fila, são implementados como processos únicos ou multi-threaded, continuamente em execução ou iniciados sob demanda de acordo com um padrão de agendamento.

Em um nível mais alto, há dois mecanismos primários de expedição usados para habilitar um ouvinte de fila a receber mensagens armazenadas em uma fila:

  • Sondagem (modelo baseado em pull): um ouvinte monitora uma fila verificando-a em intervalos regulares para ver se há novas mensagens. Quando a fila estiver vazia, o ouvinte continuará a sondá-la, parando periodicamente ao entrar em um estado de suspensão.

  • Disparo (modelo baseado em push): um ouvinte assina um evento que é disparado (pelo próprio publicador ou por um gerente de serviços de fila) sempre que uma mensagem chega a uma fila. O ouvinte, por sua vez, pode iniciar o processamento da mensagem sem precisar sondar a fila para determinar se algum novo trabalho está disponível.

Também é válido mencionar que há diferentes características em ambos os mecanismos. Por exemplo, a sondagem pode ser com bloqueio e sem bloqueio. O bloqueio mantém uma solicitação em espera até uma nova mensagem aparecer em uma fila (ou o tempo limite ser atingido), enquanto uma solicitação sem bloqueio é concluída imediatamente caso não haja nada em uma fila. Com um modelo de disparo, uma notificação pode ser enviada por push aos ouvintes de fila para cada nova mensagem somente quando a primeira mensagem chega a uma fila vazia ou quando a profundidade da fila atinge um determinado nível.

noteObservação
As operações de remoção da fila com suporte da API do Serviço de Fila do Azure são sem bloqueio. Isso significa que métodos da API, como GetMessage ou GetMessages, retornarão imediatamente se nenhuma mensagem for encontrada em uma fila. Por outro lado, as filas do Azure Service Bus oferecem operações de recebimento que bloqueiam o thread de chamada até uma mensagem chegar a uma fila ou um determinado tempo limite expirar.

A abordagem mais comum atualmente para implementar ouvintes de fila em soluções do Azure pode ser resumida como a seguir:

  1. Um ouvinte é implementado como um componente de aplicativo que é instanciado e executado como parte de uma instância de função de trabalho.

  2. O ciclo de vida do componente de ouvinte de fila geralmente estaria associado ao tempo de execução da instância de função de hospedagem.

  3. A lógica de processamento principal é composta de um loop no qual as mensagens são removidas da fila e expedidas para processamento.

  4. Se nenhuma mensagem for recebida, o thread de escuta entrará em um estado de suspensão cuja duração geralmente é controlada por um algoritmo de retirada específico ao aplicativo.

  5. O loop de recebimento é executado e uma fila é sondada até que o ouvinte seja notificado para sair do loop e encerrar.

O fluxograma a seguir descreve a lógica normalmente usada ao implementar um ouvinte de fila com um mecanismo de sondagem em aplicativos do Azure:

Best-Practices-Messaging-Solutions-Azure2
noteObservação
Para a finalidade deste artigo, não são usados padrões mais complexos de design, por exemplo, aqueles que exigem o uso de um gerenciador de fila central (agente).

O uso de um ouvinte de fila clássico com um mecanismo de sondagem pode não ser a escolha ideal ao usar filas do Azure, pois o modelo de preços do Azure mede as transações de armazenamento em termos de solicitações do aplicativo realizadas na fila, independentemente de a fila estar vazia ou não. A finalidade das seções a seguir é discutir algumas técnicas para maximizar o desempenho e minimizar os custos de soluções de mensagens baseadas em fila na plataforma Azure.

Nesta seção, examinaremos como melhorar os aspectos relevantes de design para obter maior desempenho, melhor escalabilidade e redução de custos.

Talvez a maneira mais fácil de qualificar um padrão de implementação como “solução mais eficiente” seja por meio do design que atende aos seguintes objetivos:

  • Reduz as despesas operacionais removendo uma parte significativa das transações de armazenamento que não geram nenhum trabalho aproveitável.

  • Elimina a latência excessiva imposta por um intervalo de sondagem ao verificar se há novas mensagens em uma fila.

  • É ampliada e reduzida dinamicamente adaptando o poder de processamento aos volumes de trabalho voláteis.

O padrão de implementação também deve atender a esses objetivos sem introduzir um nível de complexidade que efetivamente supera os benefícios associados.

Ao avaliar o TCO (custo total de propriedade) e o ROI (retorno do investimento) de uma solução implantada na plataforma Azure, o volume de transações de armazenamento é uma das principais variáveis na equação do TCO. Reduzir o número de transações em filas do Azure reduz os custos operacionais, já que eles estão relacionados às soluções em execução no Azure.

O custo do espaço de armazenamento associado ao Azure Queue pode ser calculado como –

Espaço da fila: 24 bytes + Len(QueueName) * 2 +  For-Each Metadata(4 bytes + Len(QueueName) * 2 bytes + Len(Value) * 2 bytes)

Espaço das mensagens: 12 bytes + Len(Message)

No contexto de uma solução de mensagens baseada em fila, o volume de transações de armazenamento pode ser reduzido com uma combinação dos seguintes métodos:

  1. Ao colocar mensagens em uma fila, agrupe as mensagens relacionadas em um único lote maior, compacte e armazene a imagem compactada em um armazenamento de blob e use a fila para manter uma referência ao blob que contém os dados reais. Essa abordagem ajuda a otimizar o custo relacionado a transações e a espaço de armazenamento.

  2. Ao recuperar mensagens de uma fila, agrupe várias mensagens em um lote em uma única transação de armazenamento. O método GetMessages na API do Serviço da Fila permite a remoção de fila do número de mensagens especificado em uma única transação (consulte a observação abaixo).

  3. Ao verificar a presença de itens de trabalho em uma fila, evite intervalos de sondagem agressivos e implemente um atraso de retirada que aumente o tempo entre as solicitações de sondagem se uma fila permanecer continuamente vazia.

  4. Reduza o número de ouvintes de fila – ao usar um modelo baseado em pull, use somente um ouvinte de fila por instância de função quando uma fila estiver vazia. Para reduzir ainda mais o número de ouvintes de fila por instância de função a zero, use um mecanismo de notificação para instanciar ouvintes de fila quando a fila receber itens de trabalho.

  5. Se as filas permanecerem vazias na maior parte do tempo, reduza automaticamente o número de instâncias de função e continue a monitorar a métrica do sistema relevante para determinar se e quando o aplicativo deve aumentar o número de instâncias para lidar com a carga de trabalho crescente.

  6. Implemente um mecanismo para remover mensagens suspeitas. A mensagens suspeitas normalmente são mensagens corrompidas que o aplicativo não pode processar. Caso permaneçam sem processamento, essas mensagens poderão acumular e gerar custos de processamento e transação repetidos. Um mecanismo de implementação simples pode ser usado para remover da fila mensagens mais antigas que um limite de duração e gravá-las em um sistema de arquivamento para uma avaliação mais detalhada.

  7. Reduza falhas de tempo limite esperadas. Ao enviar uma solicitação para o serviço, você pode especificar seu próprio tempo limite e configurá-lo para ser menor que o tempo limite do SLA. Dessa forma, o tempo limite da solicitação se esgota, ele é classificado como um tempo limite esperado e conta como transações cobradas.

A maioria das recomendações acima pode ser traduzida em uma implementação razoavelmente genérica que manipula os lotes de mensagens e encapsula muitas das operações subjacentes de armazenamento de filas/blobs e gerenciamento de threads. Mais adiante neste artigo, veremos como fazer isso.

ImportantImportante
Ao recuperar mensagens pelo método GetMessages, o tamanho máximo de lote aceito pela API do Serviço de Fila em uma única operação de remoção da fila é limitado a 32.

Em linhas gerais, o custo de transações de fila do Azure aumenta de forma linear conforme aumenta o número de clientes do serviço de fila, por exemplo, com o aumento do número de instâncias de função ou do número de threads de remoção da fila. Para ilustrar o impacto potencial no custo de um design de solução que não se beneficia das recomendações acima, fornecemos um exemplo baseado em números concretos.

Se o arquiteto da solução não implementar otimizações relevantes, a arquitetura do sistema de cobrança descrita acima provavelmente incorrerá em despesas operacionais excessivas, uma vez que a solução está implantada e em execução na plataforma Azure. Os motivos da possível despesa excessiva são descritos nesta seção.

Conforme observado na definição do cenário, os dados de transações comerciais chegam em intervalos regulares. Entretanto, vamos supor que a solução esteja ocupada processando a carga de trabalho apenas 25% do tempo durante um dia útil padrão de 8 horas. Isso resulta em 6 horas (8 horas * 75%) do “tempo ocioso” quando não pode haver nenhuma transação chegando pelo sistema. Além disso, a solução em nenhuma hipótese receberá dados durante as 16 horas não úteis a cada dia.

Durante o período ocioso, que totaliza 22 horas, a solução ainda faz tentativas de remover trabalhos da fila, pois ela não tem um conhecimento explícito de quando chegarão novos dados. Durante essa janela de tempo, cada thread individual de remoção da fila executará até 79.200 transações (22 horas * 60 min * 60 transações/min) em uma fila de entrada, presumindo-se um intervalo de sondagem padrão de 1 segundo.

Conforme mencionado anteriormente, o modelo de preços na plataforma Azure baseia-se em “transações de armazenamento” individuais. Uma transação de armazenamento é uma solicitação feita por um aplicativo de usuário para adicionar, ler, atualizar ou excluir dados de armazenamento. Quando este white paper era redigido, as transações de armazenamento eram cobradas a uma taxa de US$ 0,01 para 10.000 transações (não levando em consideração ofertas promocionais ou planos de preços especiais).

ImportantImportante
Ao calcular o número de transações de fila, tenha em mente que colocar uma única mensagem em uma fila seria contado como 1 transação, ao passo que consumir uma mensagem é geralmente um processo de 2 etapas que envolve a recuperação seguida por uma solicitação para remover a mensagem da fila. Consequentemente, uma operação bem-sucedida de remoção da fila envolverá 2 transações de armazenamento. Observe que, se uma solicitação de remoção da fila resultar em nenhuma transferência de dados, ela ainda será contada como uma transação faturável.

As transações de armazenamento geradas por um único thread de remoção da fila no cenário acima adicionarão aproximadamente US$ 2,38 (79.200 /10.000 * US$ 0,01 * 30 dias) a uma conta por mês. Em comparação, 200 threads de remoção da fila (ou, alternativamente, 1 thread de remoção da fila em 200 instâncias de função de trabalho) aumentarão o custo em US$ 457,20 por mês. Esse é o custo incorrido quando a solução não estava executando absolutamente nenhuma computação, apenas verificando as filas para ver se havia itens de trabalho disponíveis. O exemplo anterior é abstrato porque ninguém implementaria seu serviço dessa forma, e por isso é importante fazer as otimizações descritas a seguir.

Para otimizar o desempenho de soluções de mensagens do Azure baseadas em fila, uma abordagem é usar a camada de mensagens de publicação/assinatura fornecida com o Azure Service Bus, conforme é descrito nesta seção.

Nessa abordagem, os desenvolvedores precisarão se concentrar na criação de uma combinação de sondagem e notificações baseadas em push em tempo real, permitindo que os ouvintes assinem um evento de notificação (gatilho) que é gerado em determinadas condições para indicar que uma nova carga de trabalho é colocada em uma fila. Essa abordagem aprimora o loop de sondagem de fila tradicional com uma camada de mensagens de publicação/assinatura para expedir notificações.

Em um sistema distribuído complexo, essa abordagem necessitaria do uso de um “barramento mensagens” ou “middleware orientado a mensagens” para assegurar que as notificações possam ser retransmitidas para um ou mais assinantes de forma confiável com um acoplamento fraco. O Azure Service Bus é uma opção natural para requisitos de endereçamento de mensagens entre serviços de aplicativos distribuídos com um acoplamento fraco que são executados no Azure e localmente. Ele também é perfeito para uma arquitetura de “barramento de mensagens” que permitirá a troca de notificações entre processos envolvidos na comunicação baseada em fila.

Os processos envolvidos em uma troca de mensagens baseada em fila poderiam empregar o seguinte padrão:

Best-Practices-Messaging-Solutions-Azure3

Especificamente, e como eles se referem à interação entre publicadores de serviços de fila e assinantes, os mesmos princípios que se aplicam à comunicação entre instâncias de função do Azure atenderiam à maioria dos requisitos para a troca de mensagens de notificação baseada em push.

ImportantImportante
O uso do Azure Service Bus está sujeito a um modelo de preços que leva em consideração o volume das operações de mensagens em uma entidade de mensagens do Service Bus, como uma fila ou um tópico.

Portanto, é importante executar uma análise de custo-benefício para avaliar os prós e os contras de introduzir o Service Bus em uma determinada arquitetura. Ao longo dessas linhas, vale a pena avaliar se a introdução ou não da camada de expedição de notificações com base no Service Bus resultaria de fato na redução do custo que pode justificar os investimentos e os esforços de desenvolvimento adicionais.

Para obter mais informações sobre o modelo de preços do Service Bus, consulte as seções relevantes em Perguntas frequentes sobre o Azure.

Quando o impacto na latência é razoavelmente fácil de ser resolvido com uma camada de mensagens de publicação/assinatura, uma redução de custo adicional pode ser percebida com o uso do dimensionamento dinâmico (elástico), conforme é descrito na próxima seção.

O armazenamento Azure define metas de escalabilidade em um nível de conta geral e um nível por partição. Uma fila no Azure é sua própria partição única e, consequentemente, pode processar até 2000 mensagens por segundo. Quando o número de mensagens excede essa cota, o serviço de armazenamento responde com uma mensagem HTTP 503 Servidor Ocupado. Essa mensagem indica que a plataforma está limitando a fila. Os designers de aplicativos devem executar o planejamento de capacidade para garantir que um número apropriado de filas possa sustentar a taxa de solicitações do aplicativo. Se apenas uma fila for incapaz de lidar com a taxa de solicitações de um aplicativos, projete uma arquitetura de fila particionada com várias filas para garantir a escalabilidade.

Um aplicativo também pode usar várias filas diferentes para tipos de mensagens diferentes. Isso garante a escalabilidade do aplicativo, permitindo que várias filas coexistam sem inibir uma fila única. Isso também permite um controle separado do processamento das filas com base na sensibilidade e prioridade das mensagens que são armazenadas em diferentes filas. Filas com prioridade alta devem ter mais profissionais dedicados a elas do que filas com baixa prioridade.

A plataforma Azure possibilita que os clientes aumentem ou reduzam a escala com mais rapidez e facilidade do que nunca. A capacidade de adaptação a cargas de trabalho voláteis e ao tráfego variável é uma das principais propostas de valor da plataforma em nuvem. Isso significa que a “escalabilidade” não é mais um termo dispendioso do vocabulário de TI; ela é agora um recurso pronto para uso que pode ser habilitado de forma programática sob demanda em uma solução em nuvem bem-arquitetada.

Dimensionamento dinâmico é o recurso técnico que uma determinada solução tem de se adaptar a cargas de trabalho flutuantes aumentando e reduzindo a capacidade de trabalho e o poder de processamento em tempo de execução. A plataforma Azure oferece suporte nativo ao dimensionamento dinâmico por meio do provisionamento de uma infraestrutura de computação distribuída, na qual é possível comprar horas de computação conforme necessário.

É importante diferenciar entre os dois seguintes tipos de dimensionamento dinâmico na plataforma Azure:

  • Dimensionamento de instância de função se refere a adicionar e remover instâncias de função de trabalho e web adicionais para lidar com a carga de trabalho pontual. Isso geralmente inclui alterar a contagem de instâncias na configuração do serviço. Aumentar a contagem de instâncias fará com que o tempo de execução do Azure inicie novas instâncias, ao passo que diminuir a contagem de instâncias fará com que ele desligue instâncias em execução.

  • Dimensionamento de processo (thread) refere-se à manutenção da capacidade suficiente em termos de threads de processamento em uma determinada instância de função com o ajuste do número de threads para cima e para baixo, dependendo da carga de trabalho atual.

O dimensionamento dinâmico em uma solução de mensagens baseada em fila atrairia uma combinação das seguintes recomendações gerais:

  1. Monitorar indicadores chave de desempenho, incluindo utilização de CPU, profundidade de fila, tempos de resposta e latência do processamento de mensagens.

  2. Aumentar ou diminuir dinamicamente o número de instâncias de função para lidar com os picos na carga de trabalho, previsíveis ou imprevisíveis.

  3. Expandir e reduzir o número de threads de processamento de forma programática para adaptar-se a condições de carga variáveis manipuladas por uma determinada instância de função.

  4. Particionar e processar cargas de trabalho refinadas simultaneamente usando a Biblioteca paralela de tarefas no .NET Framework 4.

  5. Manter uma capacidade viável em soluções com carga de trabalho altamente volátil em antecipação a picos repentinos, para poder lidar com eles sem a sobrecarga de configurar instâncias adicionais.

A API do Gerenciamento de Serviços possibilita que um serviço hospedado no Azure modifique o número de suas instâncias de função em execução alterando a configuração de implantação em tempo de execução.

noteObservação
O número máximo de instâncias de computação pequenas do Azure (ou o número equivalente de instâncias de computação de outros tamanhos em termos de número de núcleos) em uma assinatura típica é limitado a 20, por padrão. Qualquer solicitação para aumentar essa cota deve ser gerada com a equipe de Suporte do Azure. Para obter mais informações, consulte as Perguntas frequentes sobre a plataforma Azure.

Com a introdução do Azure Auto Scaling, a plataforma pode ampliar ou reduzir o número de instâncias com base na profundidade das mensagens da fila. Isso é um ajuste muito natural para colocação em escala dinâmica. A vantagem adicional é que a plataforma Azure monitora e dimensiona tarefas para o aplicativo.

O dimensionamento dinâmico da contagem de instâncias de função nem sempre pode ser a opção mais apropriada para lidar com picos de carga. Por exemplo, uma nova instância de função pode levar alguns segundos para ser ativada, e não há atualmente métricas de SLA fornecidas em relação à duração desse processo. Em vez disso, pode ser necessária uma solução para simplesmente aumentar o número de threads de trabalho para lidar com o aumento da carga de trabalho volátil. Enquanto a carga de trabalho é processada, a solução monitora a métrica relevante de carga e determina se precisa reduzir ou aumentar dinamicamente o número de processos de trabalho.

ImportantImportante
Atualmente, a meta de escalabilidade para uma única fila Azure está "restrita" a 2000 transações por segundo. Se um aplicativo tentar exceder essa meta, por exemplo, executando operações de fila de várias instâncias de função que executam centenas de threads de remoção da fila, o resultado poderá ser a resposta HTTP 503 "Servidor ocupado" do serviço de armazenamento. Quando isso ocorre, o aplicativo deve implementar um mecanismo de repetição usando algoritmo de atraso de retirada exponencial. Entretanto, se os erros HTTP 503 estiverem ocorrendo regularmente, é recomendável usar várias filas e implementar uma estratégia baseada em particionamento para fazer o dimensionamento em várias filas.

Na maioria dos casos, o dimensionamento automático dos processos de trabalho é responsabilidade de uma instância de função individual. Por outro lado, o dimensionamento de instância de função geralmente envolve um elemento central da arquitetura de solução que é responsável por monitorar a métrica de desempenho e executar as ações de dimensionamento adequadas. O diagrama a seguir mostra um componente de serviço chamado Agente de Dimensionamento Dinâmico, que coleta e analisa as métricas de carga para determinar se precisa provisionar novas instâncias ou desativar instâncias ociosas.

Best-Practices-Messaging-Solutions-Azure4

Vale observar que o serviço do agente de dimensionamento pode ser implantado como uma função de trabalho em execução no Azure ou como um serviço local. Independentemente da topologia de implantação, o serviço poderá acessar as filas do Azure.

Para implementar um recurso de dimensionamento dinâmico, considere o uso do Microsoft Enterprise Library Autoscaling Application Block, que habilita o comportamento de dimensionamento automático nas soluções executadas no Azure. O Autoscaling Application Block fornece toda a funcionalidade necessária para definir e monitorar o dimensionamento automático em um aplicativo do Azure.

noteObservação
Como uma alternativa à colocação em escala dinâmica manual, considere usar o recurso de colocação em escala automática interna do Azure.

Agora que nós abordamos o impacto da latência, os custos de transações de armazenamento e os requisitos de dimensionamento dinâmico, é um bom momento para consolidar nossas recomendações em uma implementação técnica.

Para a finalidade de um exemplo concreto, generalizaremos um cenário de cliente real como a seguir.

Um provedor de soluções SaaS inicia um novo sistema de cobrança implementado como um aplicativo do Azure que atende às necessidades empresariais de processamento de transações de clientes em escala. A premissa básica da solução é centralizada na capacidade de descarregar a carga de trabalho de computação intensa para a nuvem e aproveitar a elasticidade da infraestrutura do Azure para executar esse trabalho.

O elemento local da arquitetura ponta a ponta consolida e expede regularmente grandes volumes de transações para um serviço hospedado do Azure ao longo do dia. Os volumes variam de alguns milhares a centenas de milhares de transações por envio, atingindo milhões de transações por dia. Além disso, suponha que a solução deva satisfazer um requisito controlado por SLA para uma latência de processamento máxima garantida.

A arquitetura da solução é baseada no padrão de design de redução de mapa distribuído, e é composta de uma camada em nuvem baseada em função de trabalho de várias instâncias que usa o armazenamento de filas do Azure para expedição de trabalho. Os lotes de transações são recebidos pela instância de função de trabalho Iniciador de Processo, desmembrados (desfeitos os lotes) em itens de trabalho menores e enfileirados em uma coleção de filas do Azure para fins de distribuição de carga.

O processamento de carga de trabalho é tratado por várias instâncias da função de trabalho de processamento buscando itens de trabalho das filas e passando-os por meio de procedimentos computacionais. As instâncias de processamento utilizam ouvintes de fila multi-threaded para implementar o processamento de dados paralelo a fim de obter o desempenho ideal.

Os itens de trabalho processados são encaminhados para uma fila dedicada, da qual são removidos pela instância de função de trabalho Controlador de Processo, agregados e mantidos em um repositório de dados para mineração de dados, relatório e análise.

A arquitetura da solução pode ser descrita como a seguir:

AzureGuidance_MaxScale

O diagrama acima descreve uma arquitetura comum para expandir cargas de trabalho de computação grandes ou complexas. O padrão de troca de mensagens baseado em fila adotado por essa arquitetura também é muito comum para muitos outros aplicativos e serviços do Azure que precisam se comunicar entre si por meio de filas. Isso permite utilizar uma abordagem canônica para examinar os componentes específicos fundamentais envolvidos em uma troca de mensagens baseada em fila.

Para maximizar a eficiência e o custo-benefício de soluções de mensagens baseadas em fila em execução na plataforma Azure, os arquitetos de soluções e desenvolvedores devem considerar as recomendações a seguir.

Como um arquiteto de soluções, você deve:

  • Provisionar uma arquitetura de mensagens baseada em fila que use o serviço de armazenamento em fila do Azure para comunicação assíncrona de grande escala entre camadas e serviços em soluções híbridas baseadas em nuvem.

  • Recomende a arquitetura de fila particionada para tratar mais de 2000 mensagens por segundo.

  • Entender os fundamentos do modelo de preços do Azure e otimizar a solução para baixar custos de transações usando uma série de práticas recomendadas e padrões de design.

  • Considerar os requisitos de dimensionamento dinâmico provisionando uma arquitetura que seja adaptável a cargas de trabalho voláteis e flutuantes.

  • Usar as técnicas e abordagens de dimensionamento automático para expandir e reduzir de forma elástica a capacidade de computação para otimizar ainda mais a despesa operacional.

  • Avalie a colocação em escala automática do Azure para ver se ela se enquadra nas necessidades do aplicativo relacionadas a esses recurso

  • Avaliar a relação custo-benefício de reduzir a latência usando a dependência no Azure Service Bus para a expedição de notificação baseada em push em tempo real.

Como desenvolvedor, você deve:

  • Criar uma solução de mensagens que utilize o envio em lote ao armazenar e recuperar dados de filas do Azure.

  • Avalie a colocação em escala automática do Azure para ver se ela se enquadra nas necessidades do aplicativo relacionadas a esses recurso

  • Implementar um serviço de ouvinte de fila eficiente garantindo que as filas serão sondadas por um máximo de um thread de remoção da fila quando vazia.

  • Reduzir dinamicamente o número de instâncias de função de trabalho quando as filas permanecerem vazias por um longo período de tempo.

  • Implementar um algoritmo de retirada exponencial aleatória específico ao aplicativo para reduzir o efeito da sondagem de fila ociosa em custos de transações de armazenamento.

  • Adotar as técnicas certas que evitam que as metas de escalabilidade para uma única fila sejam excedidas na implementação de publicadores e consumidores de filas de várias instâncias altamente multi-threaded.

  • Utilizar uma política robusta de repetição capaz de manipular uma variedade de condições temporárias ao publicar e consumir dados de filas do Azure.

  • Usar o recurso de eventos unidirecional fornecido pelo Azure Service Bus para dar suporte a notificações baseadas em push para reduzir a latência e melhorar o desempenho da solução de mensagens baseada em fila.

  • Explorar os novos recursos do .NET Framework 4, como TPL, PLINQ e o padrão Observer para maximizar o grau de paralelismo, melhorar a simultaneidade e simplificar o design de serviços multi-threaded.

O exemplo de código associado está disponível para download na galeria de códigos do MSDN. O código de exemplo também inclui todos os componentes de infraestrutura necessários, como a camada de abstração com reconhecimento de genéricos para o serviço de filas do Azure, que não foram fornecidos nos trechos de código acima. Observe que todos os arquivos de código-fonte são regidos pela licença pública da Microsoft, como explicado nos avisos legais correspondentes.

Mostrar:
© 2015 Microsoft