Escolha se deseja usar mensagens ou eventos
Suponha que você esteja planejando a arquitetura de um aplicativo de compartilhamento de música distribuído. Você deseja garantir que o aplicativo seja o mais confiável e escalá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 certa, você deve entender cada comunicação individual que os componentes do aplicativo trocam. Para cada comunicação, você pode escolher uma tecnologia diferente do Azure.
A primeira coisa a entender sobre uma comunicação é se ela envia mensagens ou eventos . Esse conhecimento ajuda você a escolher o serviço apropriado do Azure a ser usado.
Estratégias de comunicação no Azure (APIs)
O que é uma mensagem?
Na terminologia de aplicações distribuídas, mensagens têm as seguintes características:
- Uma mensagem contém dados brutos, produzidos por um componente e consumidos por outro componente.
- Uma mensagem contém os dados em si, não apenas uma referência a esses dados.
- O componente de envio espera que o componente de destino processe o conteúdo da mensagem de uma determinada maneira. A integridade geral do sistema pode depender de o emissor e o recetor fazerem um trabalho específico.
Por exemplo, suponha que um usuário carregue uma nova música usando o aplicativo de compartilhamento de música móvel. O aplicativo móvel deve enviar essa música para a API Web, que é executada no Azure. O arquivo de mídia da música em si deve ser enviado, não apenas um alerta que indica que uma nova música foi adicionada. O aplicativo móvel 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 as mensagens e são mais frequentemente utilizados para comunicações de difusão. Os componentes que enviam o evento são conhecidos como publishers, e os recetores são conhecidos como assinantes.
Nos eventos, os componentes destinatários decidem em quais comunicações estão interessados e "assinam" esses eventos. Um intermediário gerencia a assinatura, como a Grade de Eventos do Azure ou os Hubs de Eventos do Azure. Quando os editores enviam um evento, o intermediário encaminha esse evento para os assinantes interessados. Esse padrão é conhecido como "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 que algo aconteceu.
- O evento pode ser enviado para vários recetores ou para nenhum.
- Os eventos são muitas vezes destinados a "se espalhar", ou ter um grande número de assinantes para cada editora.
- A editora do evento não tem expectativa sobre a ação que um componente recetor toma.
- Alguns eventos são unidades discretas e não estão relacionados com outros eventos.
- Alguns eventos fazem parte de uma série relacionada e ordenada.
Por exemplo, suponha que o upload do arquivo de música seja concluído e a nova música seja adicionada ao banco de dados. Para informar os usuários sobre o novo arquivo, a API da Web deve informar o front-end da Web e os usuários do aplicativo móvel sobre o novo arquivo. Os usuários podem escolher se querem ouvir a nova música, então a notificação inicial não inclui o arquivo de música, mas apenas notifica os usuários de que a música existe. O remetente não tem uma expectativa específica de que os recetores do evento façam algo em particular em resposta a esse evento.
Este cenário é um exemplo de um evento discreto.
Como escolher mensagens ou eventos
É provável que um único aplicativo use eventos para alguns fins e mensagens para outros. Antes de escolher, você deve analisar a arquitetura do seu aplicativo e todos os seus casos de uso para identificar todas as diferentes finalidades em que seus componentes precisam se comunicar entre si.
Os eventos são mais propensos a serem usados para transmissões, e muitas vezes são efémeros, o que significa que uma comunicação não é tratada por nenhum recetor caso ninguém esteja a assinar no momento. É mais provável que as mensagens sejam utilizadas quando a aplicação distribuída requer uma garantia de que a comunicação é processada.
Para cada comunicação, considere a seguinte pergunta: o componente de envio espera que a comunicação seja processada de uma maneira específica pelo componente de destino?
Se a resposta for sim, opte por usar uma mensagem. Se a resposta for não, você poderá usar eventos.
Entender como seus componentes precisam se comunicar ajuda você a escolher como seus componentes se comunicam. Comecemos pelas mensagens.