Este cenário descreve como projetar uma solução que processe alterações nos dados subjacentes dentro de uma exibição da Web, sem a necessidade de atualizar a página, usando serviços em tempo real. Exemplos que usam este cenário incluem rastreamento em tempo real de produtos e mercadorias e soluções para mídias sociais.
Arquitetura
Baixe um Arquivo Visio dessa arquitetura.
Componentes
- O Barramento de Serviço do Azure é um serviço de mensagens na nuvem altamente confiável entre aplicativos e serviços, mesmo quando um ou mais deles estão offline.
- O Serviço do Azure SignaIR facilita adicionar comunicações ao aplicativo Web em tempo real.
- O Azure Functions é uma plataforma de computação sem servidor orientada por eventos que também pode resolver problemas complexos de orquestração.
Alternativas
Existem alternativas para resolver esse cenário, como o Pusher. Ele é o líder da categoria em APIs robustas para desenvolvedores de aplicativos que criam recursos de comunicação escalonáveis em tempo real.
Também há o PubNub. O PubNub torna fácil adicionar funcionalidades em tempo real aos seus aplicativos, sem se preocupar com a infraestrutura. Crie aplicativos que permitam aos seus usuários se envolver em tempo real em dispositivos móveis, no navegador, na área de trabalho e no servidor.
Ably é outra alternativa. Ele fornece um sistema de mensagens de publicação/assinatura (pub/sub) sem servidor, que é dimensionado de modo confiável e de acordo com as suas necessidades. A mensagem é entregue na borda usando WebSockets. A plataforma Ably fornece uma infraestrutura em tempo real altamente disponível, elasticamente escalonável e distribuída globalmente, com uma simples chamada de API.
Embora o Pusher, o PubNub e a Ably sejam as plataformas mais amplamente adotadas para sistema de mensagens em tempo real, neste cenário você fará tudo no Azure. Recomendamos o SignalR como plataforma de referência, pois ele permite a comunicação bidirecional entre servidor e cliente. Ele também é uma ferramenta de código aberto com 7,9 mil estrelas e 2,2 mil forks no GitHub.
Para obter mais informações, consulte o repositório de código aberto do SignalR no GitHub.
Detalhes do cenário
Neste cenário, você examinará como configurar um serviço de mensagens em tempo real para compartilhar a localização dinâmica de uma transação de serviço de entrega de alimentos. Este exemplo também pode ser útil para quem está tentando criar uma plataforma de compartilhamento de localização em tempo real para seus aplicativos Web ou móveis.
Você usará um serviço do SignalR configurado no modo sem servidor para integrar-se a um aplicativo Azure Functions disparado por um barramento de serviço, e tudo isso usando .NET Core.
Possíveis casos de uso
Esses outros casos de uso têm padrões de design semelhantes:
- Compartilhar a localização em tempo real com dispositivos cliente
- Enviar notificações por push aos usuários
- Atualizar linhas do tempo
- Criar salas de chat
Considerações
Essas considerações implementam os pilares do Azure Well-Architected Framework, um conjunto de princípios orientadores que você pode usar para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, confira Microsoft Azure Well-Architected Framework.
Estas são algumas considerações que você deve ter em mente ao desenvolver o cenário, inclusive como configurar parâmetros na cadeia de conexão do Barramento de Serviço do Azure em ServiceBusTrigger:
- Hubs: os hubs podem ser comparados a um serviço de streaming de vídeo. Você pode assinar um hub para enviar e receber mensagens de/para ele.
- Destinos: os destinos são como estações de rádio. Eles incluem todos os que estão ouvindo a estação de destino e são notificados quando há uma nova mensagem.
Se você conseguir se lembrar dos dois recursos anteriores da plataforma SignalR, será fácil colocá-la em operação rapidamente.
Disponibilidade, escalabilidade e segurança
Você pode obter alta disponibilidade com essa solução seguindo o que está descrito nas próximas duas seções.
Emparelhamento regional
Cada região do Azure é emparelhada com outra na mesma área geográfica. Em geral, escolha regiões do mesmo par regional (por exemplo, Leste dos EUA 2 e EUA Central). Os benefícios disso incluem:
- Se houver uma interrupção ampla, a prioridade será recuperar pelo menos uma região em cada par.
- As atualizações planejadas do sistema do Azure são distribuídas em regiões emparelhadas sequencialmente para minimizar o possível tempo de inatividade.
- Na maioria dos casos, pares regionais residem na mesma geografia para atender aos requisitos de residência de dados.
- No entanto, verifique se as duas regiões dão suporte a todos os serviços do Azure necessários para seu aplicativo. Confira Serviços por região. Para saber mais sobre pares regionais, consulte Continuidade dos negócios e recuperação de desastres (BCDR): Regiões Emparelhadas do Azure.
Porta da frente do Azure
Baixe um Arquivo Visio dessa arquitetura.
O Azure Front Door é um ponto de entrada escalonável e seguro para a distribuição rápida de seus aplicativos globais. Quando você usa o roteamento de prioridade, ele faz failover automaticamente se a região principal se torna indisponível. Uma arquitetura de várias regiões pode fornecer uma disponibilidade maior que a implantação em uma única região. Se uma interrupção regional afetar a região primária, você poderá usar o Front Door para fazer failover para a região secundária.
Essa arquitetura também poderá ajudar se um subsistema individual da solução falhar. Interrompa ataques na camada de aplicativo e rede na borda com o Firewall do Aplicativo Web e a Proteção contra DDoS. Proteja o serviço usando os conjuntos de regras gerenciados pela Microsoft e crie suas próprias regras para a proteção personalizada do aplicativo.
O Front Door é um possível ponto de falha no sistema. Se o serviço falhar, os clientes não poderão acessar o aplicativo durante o tempo de inatividade. Examine o contrato de nível de serviço (SLA) do Front Door e determine se usar apenas o Front Door atende aos seus requisitos de negócios para alta disponibilidade. Caso contrário, considere adicionar outra solução de gerenciamento de tráfego como um fallback. Caso o serviço do Front Door falhe, altere os registros CNAME (nome canônico) no DNS para apontar para outro serviço de gerenciamento de tráfego. Você deve executar esta etapa manualmente, e o aplicativo ficará indisponível até que as alterações de DNS sejam propagadas.
Otimização de custo
A otimização de custos é a análise de maneiras de reduzir as despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, confira Visão geral do pilar de otimização de custo.
Vamos supor que sua empresa tenha 1.000 pedidos por dia e precise compartilhar dados de localização com todos eles simultaneamente. O uso estimado do Azure para implantar esse cenário será de cerca de US$ 192 por mês, com base no preço na data de publicação.
| Tipo de serviço | Custo mensal estimado |
|---|---|
| Azure Functions | US$ 119,40 |
| Serviço do Azure SignalR | US$ 48,97 |
| Barramento de Serviço do Azure | US$ 23,71 |
| Total | US$ 192,08 |
Implantar este cenário
Desenvolvimento do Azure Functions
Um aplicativo em tempo real sem servidor criado com o Azure Functions e o Serviço do Azure SignalR normalmente requer dois Azure Functions:
- Uma função
negotiateque o cliente chama para obter um token de acesso válido do Serviço do SignalR e uma URL do ponto de extremidade do serviço. - Uma ou mais funções que enviam mensagens ou gerenciam a associação a um grupo.
SignalRFunctionApp
SignalRFunctionApp é um aplicativo de função que cria uma instância do Azure Functions, com um gatilho de barramento de serviço com SignalR.
Negotiate.cs
A função é disparada por uma solicitação HTTP. Ele é usada por aplicativos cliente para obter um token do serviço do SignalR, que os clientes podem usar para assinar um hub. Essa função deve ser nomeada como negotiate. Para obter mais informações, consulte Desenvolvimento do Azure Functions e a configuração com o Serviço do Azure SignalR.
Message.cs
Essa função é disparada por um gatilho do barramento de serviço. Ela tem uma associação com o serviço do SignalR. Ela efetua pull da mensagem da fila e a passa para um hub do SignalR.
Instruções
Antes de começar:
- Certifique-se de que você tem uma fila do barramento de serviço provisionada no Azure.
- Certifique-se de que você tem um serviço do SignalR provisionado no modo sem servidor no Azure.
- Digite as cadeias de conexão (Barramento de Serviço e SignalR) no arquivo local.settings.json.
- Digite a URL do aplicativo cliente (cliente SignalR) no CORS (Cross-Origin Resource Sharing). Para obter a sintaxe mais recente, consulte Desenvolvimento e configuração do Azure Functions com o Serviço do Azure SignalR.
- Digite o nome da fila do barramento de serviço no gatilho do barramento de serviço do arquivo Message.cs.
Agora, vamos configurar o aplicativo cliente para testá-lo. Primeiro, pegue as fontes de exemplo na página solution-architectures do GitHub.
Cliente do SignalR
Este é um aplicativo Web .NET Core simples para assinar o hub criado por SignalRFunctionApp. Ele exibe as mensagens que são recebidas na fila do barramento de serviço em tempo real. Embora você possa usar SignalRFunctionApp para trabalhar com um cliente móvel, vamos nos ater ao cliente Web para esse cenário nesse repositório.
Instruções
Verifique se SignalRFunctionApp está em execução.
Copie a URL gerada pela função negotiate. É algo semelhante a isto:
http://localhost:7071/api/.Cole a URL no arquivo chat.js, dentro de
signalR.HubConnectionBuilder().withUrl("YOUR_URL_HERE").build();.Execute o aplicativo.
O status é conectado quando o cliente Web consegue assinar o hub do SignalR.
SendToQueue.js
Esse script node js envia uma mensagem por push ao Barramento de Serviço para que você possa testar a implantação que acabou de concluir.
Instruções
Instale o módulo de Barramento de Serviço do Azure do nó (@azure/service-bus).
Insira suas cadeias de conexão e o nome da fila no script.
Execute o script.
Próximas etapas
Você pode levar esse cenário para seu ambiente de produção. No entanto, certifique-se de que os serviços do Azure estejam definidos para dimensionar. Por exemplo, seu Barramento de Serviço do Azure deve ser definido como um plano Standard ou Premium.
Você pode implantar o código no Azure Functions diretamente do Visual Studio. Para saber como publicar seu código no Azure Functions estando no Visual Studio, siga o guia It’s how you make software.
Consulte como trabalhar com associações do Barramento de Serviço do Azure no Azure Functions. O Azure Functions dá suporte a gatilhos e a associações de saída para filas e tópicos do barramento de serviço.
Consulte como autenticar e enviar mensagens em tempo real para clientes conectados ao Serviço do Azure SignalR usando associações do Serviço do SignalR no Azure Functions. O Azure Functions dá suporte a associações de entrada e saída para o Serviço SignalR.