Escolher se serão usados mensagens ou eventos
Suponha que você esteja planejando a arquitetura de um aplicativo de compartilhamento de músicas distribuído. Você deseja garantir que o aplicativo seja o mais confiável e escalonável possível e pretende usar as tecnologias do Azure para criar uma infraestrutura de comunicação robusta.
Antes de escolher a tecnologia do Azure ideal, você precisa entender cada comunicação individual trocada pelos componentes do aplicativo. Para cada comunicação, você pode escolher uma tecnologia do Azure diferente.
A primeira coisa a entender sobre uma comunicação é se ela envia mensagens ou eventos. Esse conhecimento ajuda você a escolher o serviço do Azure mais apropriado.
Estratégias de comunicação no Azure (APIs)
O que é uma mensagem?
Na terminologia de aplicativos distribuídos, as mensagens têm as seguintes características:
- Uma mensagem contém dados brutos, produzidos por um componente, que serão consumidos por outro componente.
- Uma mensagem contém os dados propriamente ditos, não apenas uma referência a eles.
- O componente de envio espera o componente de destino para processar o conteúdo da mensagem de determinada maneira. A integridade do sistema geral pode depender de um trabalho específico do remetente e do receptor.
Por exemplo, suponha que um usuário carregue uma nova música usando o aplicativo móvel de compartilhamento de músicas. O aplicativo móvel precisa enviar essa música para a API Web, que é executada no Azure. O arquivo de mídia de música propriamente dito precisa ser enviado, não apenas um alerta que indica que uma nova música foi adicionada. O aplicativo para celular espera que a API da Web armazene a nova música no banco de dados e a disponibilize para outros usuários. Este é um exemplo de uma mensagem.
O que é um evento?
Eventos são mais leves do que mensagens e costumam ser usados para comunicação de difusão. Os componentes que enviam o evento são conhecidos como publicadores; os que recebem, como assinantes.
Com eventos, os destinatários do recebimento geralmente decidem em quais comunicações eles estão interessados e se inscrevem nesses eventos. A assinatura é gerenciada por um intermediário, como a Grade de Eventos do Azure ou os Hubs de Eventos do Azure. Quando os fornecedores enviam um evento, o intermediário o encaminha para o assinantes interessados. Esse padrão é conhecido como uma "arquitetura de publicação/assinatura". Não é a única maneira de lidar com eventos, mas é a mais comum.
Os eventos têm as seguintes características:
- Um evento é uma notificação leve que indica a ocorrência de algo.
- O evento pode ser enviado a vários destinatários ou a nenhum.
- Geralmente, os eventos são destinados a “fan-out” ou têm um grande número de assinantes de cada publicador.
- O publicador do evento não tem nenhuma expectativa em relação à ação realizada por um componente de recebimento.
- Alguns eventos são unidades discretas e não estão relacionados a outros eventos.
- Alguns eventos fazem parte de uma série ordenada e relacionada.
Por exemplo, suponha que o upload do arquivo de música tenha sido concluído e a nova música tenha sido adicionada ao banco de dados. Para informar os usuários sobre o novo arquivo, a API Web precisa informar os usuários de aplicativos móveis e de front-end da Web sobre o novo arquivo. Os usuários podem escolher se desejam escutar a nova música e, portanto, a notificação inicial não inclui o arquivo de música, mas somente notifica os usuários da existência dela. O remetente não tem uma expectativa específica de que os receptores do evento façam algo específico em resposta ao recebimento desse evento.
Este cenário é um exemplo de um evento discreto.
Como escolher mensagens ou eventos
É provável que um único aplicativo use eventos para algumas finalidades e mensagens para outras. Antes de escolher, você precisa analisar a arquitetura do aplicativo e todos os seus casos de uso para identificar todas as finalidades diferentes que os componentes têm para se comunicarem entre si.
É mais provável que os eventos sejam usados para transmissões e eles costumam ser efêmero. Isso significa que a comunicação pode não ser tratada por nenhum receptor, se não houver nenhum assinante no momento. As mensagens são mais usadas nos casos em que o aplicativo distribuído exige uma garantia de que a comunicação será processada.
Para cada tipo de comunicação, considere a pergunta: o componente de envio espera que a comunicação seja processada de uma determinada maneira pelo componente de destino?
Se a resposta for sim, opte por usar uma mensagem. Se a resposta for não, talvez você possa usar eventos.
Entender como os componentes precisam se comunicar o ajudará você a escolher as maneiras pelas quais seus componentes se comunicam. Vamos começar com mensagens.