Escolher uma plataforma de mensagens
Muitas plataformas de comunicação estão disponíveis para ajudar a melhorar a confiabilidade de um aplicativo distribuído, incluindo várias no Microsoft Azure. Cada plataforma é uma ferramenta que serve um propósito diferente. É importante escolher a ferramenta certa para cada requisito em seu aplicativo. Dê uma olhada em suas opções no Barramento de Serviço do Azure.
A arquitetura distribuída do aplicativo de pedido e rastreamento de bicicletas Contoso proposta requer vários componentes, incluindo um site, armazenamento de dados e um serviço back-end. Você pode unir os componentes do seu aplicativo de muitas maneiras diferentes, e um único aplicativo pode tirar proveito de várias técnicas.
Você precisa decidir quais técnicas usar no novo aplicativo Contoso Bicycles. O primeiro passo é avaliar cada local onde há comunicação entre várias partes. Alguns componentes devem ser executados em tempo hábil para que seu aplicativo esteja fazendo seu trabalho. Alguns podem ser importantes, mas não críticos em termos de tempo. Finalmente, outros componentes, como notificações de aplicativos móveis, são um pouco mais opcionais.
Decidir entre mensagens e eventos
Tanto as mensagens como os eventos são datagramas: pacotes de dados enviados de um componente para outro. Eles são diferentes de maneiras que, a princípio, parecem sutis, mas as diferenças podem fazer diferenças significativas na forma como você arquiteta seu aplicativo.
Mensagens
Na terminologia de aplicativos distribuídos, a característica definidora de uma mensagem é que a integridade geral do aplicativo pode depender de mensagens recebidas. Pode considerar o envio de uma mensagem como um componente, passando a tarefa de um fluxo de trabalho para um componente diferente. Todo o fluxo de trabalho pode ser um processo de negócios vital, e a mensagem é a argamassa que mantém os componentes juntos.
Uma mensagem geralmente contém os dados reais, não apenas uma referência (como um ID ou um URL) aos dados. Enviar dados como parte de um datagrama é menos frágil do que enviar uma referência. A arquitetura de mensagens garante a entrega de mensagens e, como não são necessárias pesquisas extras, a mensagem é tratada de forma confiável. No entanto, o aplicativo de envio precisa saber exatamente quais dados incluir para evitar o envio de muitos dados, o que exigiria que o componente recetor fizesse um trabalho desnecessário. Neste sentido, o emissor e o recetor da mensagem são muitas vezes acoplados por um contrato de dados rigoroso.
Na nova arquitetura da Contoso Bicycles, quando um pedido é feito, a empresa provavelmente usará mensagens. O front-end da Web ou o aplicativo móvel enviará uma mensagem para os componentes de processamento de back-end. No back-end, serão realizadas etapas como o encaminhamento para a loja mais próxima do cliente e a cobrança de um cartão de crédito.
Eventos
Um evento aciona uma notificação a indicar que ocorreu algo. Os eventos são mais "leves" do que as mensagens e são utilizados com mais frequência para comunicações de difusão.
Os eventos têm as seguintes características:
- O evento pode ser enviado para vários recetores ou para nenhum.
- Os eventos destinam-se, muitas vezes, a "fan-out" (distribuição) ou têm um grande número de subscritores para cada publicador.
- O editor do evento não tem nenhuma expectativa sobre a ação que um componente recetor realiza.
Uma cadeia de peças de bicicleta provavelmente usaria eventos para notificações do usuário sobre alterações de status. Os eventos de alteração de status podem ser enviados para a Grade de Eventos do Azure e, em seguida, para o Azure Functions e para os Hubs de Notificação do Azure para obter uma solução completamente sem servidor.
Esta diferença entre eventos e mensagens é fundamental porque, geralmente, as plataformas de comunicações são concebidas de modo a processar uns ou outras. O Service Bus foi concebido para processar mensagens. Se quiser enviar eventos, provavelmente escolheria Grade de Eventos.
O Azure também tem Hubs de Eventos do Azure, mas é usado com mais frequência para um tipo específico de fluxo de comunicações de alto fluxo usado para análise. Por exemplo, se você tivesse sensores em rede em seus armazéns de fabricação, poderia usar Hubs de Eventos acoplados ao Azure Stream Analytics para observar padrões em mudanças de temperatura que possam indicar um incêndio indesejado ou desgaste de componentes.
Tópicos e filas do Service Bus
O Barramento de Serviço do Azure pode trocar mensagens de duas maneiras diferentes: filas e tópicos.
O que é uma fila?
Uma fila do Barramento de Serviço é um local de armazenamento temporário simples para mensagens. Um componente emissor adiciona uma mensagem à fila. Um componente recetor obtém a mensagem no início da fila. Em circunstâncias normais, cada mensagem é recebida apenas por um recetor.
As filas desassociam os componentes recetores e de origem para isolar os componentes recetores de uma procura elevada.
Durante os horários de pico, as mensagens podem chegar mais rápido do que os componentes de destino podem lidar com elas. Como os componentes de origem não têm conexão direta com o destino, a origem não é afetada e a fila cresce. Os componentes de destino removerão as mensagens da fila à medida que forem capazes de lidar com elas. Quando a demanda cai, os componentes de destino podem recuperar o atraso e a fila diminui.
Uma fila responde à alta demanda sem a necessidade de adicionar recursos ao sistema. No entanto, para mensagens que precisam ser tratadas rapidamente, a criação de mais instâncias do componente de destino pode permitir que eles compartilhem a carga. Cada mensagem é tratada por apenas uma instância. Essa é uma maneira eficaz de dimensionar todo o seu aplicativo adicionando apenas recursos aos componentes que realmente precisam dele.
O que é um tópico?
Um tópico do Service Bus é semelhante a uma fila, mas um tópico pode ter várias assinaturas. Isso significa que vários componentes de destino podem se inscrever em um tópico específico, para que cada mensagem seja entregue a vários recetores. As subscrições também podem filtrar as mensagens no tópico para receberem apenas as mensagens relevantes. As subscrições fornecem as mesmas comunicações desacopladas que as filas e respondem a uma procura elevada da mesma forma. Se quiser que cada mensagem seja entregue a mais do que um componente recetor, utilize um tópico.
Nota
Os tópicos não são suportadas no escalão de preço Básico.
Filas do Service Bus e filas de armazenamento
Dois serviços do Azure incluem filas de mensagens: Barramento de Serviço e Armazenamento do Azure. Como guia geral, as filas de armazenamento são mais simples de usar, mas são menos sofisticadas e menos flexíveis do que as filas do Service Bus.
As principais vantagens das filas do Service Bus incluem:
- Suporta tamanhos de mensagens maiores de 256 KB (camada padrão) ou 100 MB (camada premium) por mensagem contra 64 KB para mensagens de fila do Armazenamento do Azure.
- Suporta entrega no máximo uma vez e pelo menos uma vez. Escolha entre uma chance muito pequena de que uma mensagem seja perdida ou uma chance muito pequena de que ela seja manipulada duas vezes.
- Garante a ordem "primeiro a entrar, primeiro a sair" (FIFO). As mensagens são tratadas na mesma ordem em que são adicionadas. Embora o FIFO seja a operação normal de uma fila, o padrão FIFO padrão é alterado se a organização configurar mensagens sequenciadas ou agendadas ou durante interrupções como uma falha do sistema. Para obter mais informações, consulte Comparar filas de Armazenamento do Azure e filas do Barramento de Serviço do Azure.
- Pode agrupar várias mensagens em uma transação. Se uma mensagem na transação não for entregue, todas as mensagens na transação não serão entregues.
- Suporta segurança baseada em funções.
- Não requer componentes de destino para sondar continuamente a fila.
Vantagens das filas de armazenamento:
- Suportam tamanho ilimitado de filas (por oposição ao limite de 80 GB das filas do Service Bus)
- Mantêm um registo de todas as mensagens
Como escolher uma tecnologia de comunicações
Você viu os diferentes conceitos e as implementações que o Azure oferece. Em seguida, considere como deve ser o seu processo de decisão para cada uma das suas comunicações.
Considerações
Ao escolher um método para enviar e receber mensagens, considere as seguintes perguntas:
A comunicação é um evento? Se assim for, considere utilizar o Event Grid ou Hubs de Eventos.
Uma única mensagem deve ser entregue a mais do que um destino? Se assim for, utilize um tópico do Service Bus. Caso contrário, use uma fila do Service Bus.
Filas: Service Bus vs. armazenamento
Se decidir que precisa de uma fila, diminua ainda mais a sua escolha.
Escolha uma fila do Service Bus se:
- Você precisa de uma garantia de entrega no máximo uma vez.
- Você precisa de uma garantia FIFO (se nenhuma outra configuração antecipar a ordem FIFO padrão).
- Precisa de agrupar mensagens em transações.
- Quer receber mensagens sem consultar a fila.
- Você precisa fornecer acesso baseado em função para as filas.
- Você precisa lidar com mensagens maiores que 64 KB, mas menores que 256 KB para a camada padrão ou 100 MB para a camada premium.
- O tamanho da fila não aumentará mais do que 80 GB.
- Você gostaria de poder publicar e consumir lotes de mensagens.
Escolha uma fila de armazenamento se:
- Você precisa de uma fila simples sem requisitos extras específicos.
- Precisa de um registo de auditoria de todas as mensagens que passam pela fila.
- Espera que a fila ultrapasse os 80 GB de tamanho.
- Você deseja acompanhar o progresso do processamento de uma mensagem dentro da fila.
Embora os componentes de um aplicativo distribuído possam se comunicar diretamente, você geralmente pode aumentar a confiabilidade dessa comunicação usando uma plataforma de comunicação intermediária, como Hubs de Eventos do Azure ou Grade de Eventos do Azure.
Os Hubs de Eventos e a Grade de Eventos são projetados para eventos, que notificam os destinatários apenas de um evento e não contêm os dados brutos associados a esse evento. Os Hubs de Eventos do Azure foram concebidos para tipos de eventos analíticos de alto fluxo.
O Barramento de Serviço do Azure e as filas de armazenamento são para mensagens, que você pode usar para vincular as partes principais de qualquer fluxo de trabalho de aplicativo.
Se seus requisitos forem simples, se você quiser enviar cada mensagem para apenas um destino ou se quiser escrever código o mais rápido possível, uma fila de armazenamento pode ser a melhor opção. Caso contrário, as filas do Service Bus disponibilizam muito mais opções e flexibilidade.
Se quiser enviar mensagens para múltiplos subscritores, utilize um tópico do Service Bus.