Escolher se deve utilizar mensagens ou eventos
Suponha que você esteja planejando a arquitetura de um aplicativo de compartilhamento de música distribuído. Deve certificar-se de que a aplicação é tão fiável e dimensionável quanto possível e de que pretende utilizar tecnologias do Azure para criar uma infraestrutura de comunicação robusta.
Antes de escolher a tecnologia certa do Azure, tem de compreender todas as comunicações individuais que os componentes da aplicação trocam. Para todas as comunicações, pode escolher uma tecnologia diferente do Azure.
A primeira coisa a entender sobre uma comunicação é se 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, as 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 utilizador carrega uma música nova ao utilizar a aplicação móvel de partilha de música. O aplicativo móvel deve enviar essa música para a API Web, que é executada no Azure. O próprio ficheiro de suporte de dados de música tem de ser enviado, e não apenas um alerta que indica que foi adicionada uma nova música. 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?
Os eventos são mais leves do que as mensagens e são mais frequentemente utilizados para comunicações difundidas. Os componentes que enviam o evento são conhecidos como publicadores e os recetores são conhecidos como subscritores.
Com os eventos, os componentes que recebem 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 simples que indica que algo aconteceu.
- O evento pode ser enviado para múltiplos 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 publicador do evento não tem qualquer expectativa sobre a ação de um componente de receção.
- Alguns eventos são unidades discretas e não relacionadas com outros eventos.
- Alguns eventos fazem parte de uma série ordenada e relacionada.
Por exemplo, suponha que o upload do arquivo de música foi concluído e a nova música foi adicionada ao banco de dados. Para informar os utilizadores sobre o novo ficheiro, a API Web deve informar os utilizadores de aplicações móveis e de front-end da Web sobre o novo ficheiro. 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
Uma aplicação única é mais propensa a utilizar eventos para determinados 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. Isso significa que uma comunicação pode não ser tratada por nenhum recetor se nenhum estiver assinando no momento. As mensagens têm maior probabilidade de serem utilizadas quando a aplicação distribuída exige uma garantia de que a comunicação será processada.
Para todas as comunicações, considere a seguinte pergunta: o componente de envio espera que a comunicação seja processada de uma determinada forma pelo componente de destino?
Se a resposta for sim, opte por utilizar uma mensagem. Se a resposta for não, talvez seja possível usar eventos.
Entender como seus componentes precisam se comunicar ajuda você a escolher como seus componentes se comunicam. Comecemos pelas mensagens.