Este cenário descreve como arquitetar uma solução que processa alterações em dados subjacentes em uma exibição da Web, sem a necessidade de uma atualização de página, usando serviços em tempo real. Exemplos que usam esse cenário incluem rastreamento em tempo real de produtos e mercadorias e soluções de mídia social.
Arquitetura
Transfira um ficheiro do Visio desta 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 estão offline.
- O Serviço Azure SignalR facilita a adição de comunicações em tempo real ao seu aplicativo Web.
- 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 lidar com esse cenário, incluindo o Pusher. É líder da categoria em APIs robustas para desenvolvedores de aplicativos que criam recursos de comunicação escaláveis em tempo real.
Há também o PubNub. O PubNub facilita a adição de capacidades em tempo real às suas aplicações, sem se preocupar com a infraestrutura. Crie aplicações que permitam aos utilizadores interagir em tempo real em dispositivos móveis, browsers, computadores e servidores.
Hábil é outra alternativa. Ele fornece mensagens de publicação/assinatura (pub/sub) sem servidor, que são dimensionadas de forma confiável de acordo com suas necessidades. As mensagens são entregues na borda usando WebSockets. A plataforma Ably fornece uma infraestrutura em tempo real altamente disponível, escalável de forma elástica e distribuída globalmente, a pedido de uma API.
Embora Pusher, PubNub e Ably sejam as plataformas mais adotadas para mensagens em tempo real, para este cenário, você fará tudo no Azure. Recomendamos o SignalR como a plataforma go-to, porque permite a comunicação bidirecional entre servidor e cliente. É também uma ferramenta de código aberto, com 7,9 mil estrelas GitHub e 2,2 mil forks GitHub.
Para obter mais informações, consulte o repositório de código aberto SignalR no GitHub.
Detalhes do cenário
Nesse cenário, você verá como configurar um serviço de mensagens em tempo real para compartilhar a localização ao vivo de uma transação de serviço de entrega de comida. Este exemplo também pode ser útil para aqueles que tentam construir uma plataforma de compartilhamento de localização em tempo real para seus aplicativos web ou móveis.
Você usará um serviço SignalR configurado no modo sem servidor para se integrar a um aplicativo do Azure Functions acionado por um barramento de serviço, tudo isso usando o .NET Core.
Potenciais casos de utilização
Esses outros casos de uso têm padrões de design semelhantes:
- Partilhar a localização em tempo real com dispositivos cliente
- Enviar notificações por push aos usuários
- Atualização de cronogramas
- Criação de salas de chat
Considerações
Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que você pode usar para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.
Aqui estão algumas coisas que você deve ter em mente ao desenvolver esse cenário, incluindo 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 se inscrever em um hub para enviar e receber mensagens de e para ele.
- Alvos: Os alvos são como canais de rádio. Eles incluem todos que estão ouvindo o canal de destino e são notificados quando há uma nova mensagem nele.
Se você se lembrar dos dois recursos anteriores da plataforma SignalR, será fácil começar a trabalhar rapidamente.
Disponibilidade, escalabilidade e segurança
Você pode obter alta disponibilidade com esta solução seguindo o que é descrito nas próximas duas seções.
Emparelhamento regional
Cada região do Azure é emparelhada com outra região na mesma geografia. Em geral, escolha regiões do mesmo par regional (por exemplo, E.U.A. Leste 2 e E.U.A. Central). Benefícios desta opção:
- Se houver uma interrupção ampla, a recuperação de pelo menos uma região de cada par é priorizada.
- As atualizações planeadas do sistema Azure são implementadas em regiões emparelhadas sequencialmente, para minimizar a possibilidade de períodos de indisponibilidade.
- Na maioria dos casos, os pares regionais residem na mesma área geográfica para satisfazer os requisitos de residência dos dados.
- No entanto, certifique-se de que ambas as regiões dão suporte a todos os serviços do Azure necessários para seu aplicativo. Veja Serviços por região. Para obter mais informações sobre pares regionais, veja Continuidade do negócio e recuperação após desastre (BCDR): Regiões Emparelhadas do Azure.
Azure Front Door
Transfira um ficheiro do Visio desta arquitetura.
O Azure Front Door é um ponto de entrada dimensionável e seguro para uma rápida entrega das suas aplicações globais. Quando você usa o roteamento de prioridade, ele executa automaticamente failover se a região primária ficar indisponível. Uma arquitetura de várias regiões pode fornecer maior disponibilidade em comparação com a implementação de uma única região. Se uma falha regional afetar a região primária, pode utilizar o Front Door para efetuar a ativação pós-falha para a região secundária.
Esta arquitetura também poderá ajudar se um subsistema individual da solução falhar. Pare os ataques à camada de aplicação e rede no limite com a Firewall de Aplicações Web e o DDoS Protection. Proteja seu serviço usando conjuntos de regras gerenciados pela Microsoft e crie suas próprias regras para proteção personalizada de seu aplicativo.
O Front Door é um ponto de falha possível no sistema. Se o serviço falhar, os clientes não poderão acessar seu aplicativo durante o tempo de inatividade. Analise o contrato de nível de serviço (SLA) do Front Door e determine se o uso exclusivo do Front Door atende aos seus requisitos de negócios para alta disponibilidade. Se não for o caso, pondere adicionar outra solução de gestão de tráfego para fins de contingência. Se o serviço Front Door falhar, altere os registos do nome canónico (CNAME) no DNS para que apontem para outro serviço de gestão de tráfego. Você deve executar essa etapa manualmente e seu aplicativo ficará indisponível até que as alterações de DNS sejam propagadas.
Otimização de custos
A otimização de custos consiste em procurar formas de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Visão geral do pilar de otimização de custos.
Vamos supor que sua empresa tenha 1.000 pedidos por dia e precise compartilhar dados de localização com todos eles simultaneamente. Seu uso estimado do Azure para implantar esse cenário será próximo de USD192 por mês, com base no preço na data de publicação.
| Tipo de serviço | Custo mensal estimado |
|---|---|
| Funções do Azure | USD119.40 |
| Azure SignalR Service | US$ 48,97 |
| Azure Service Bus | USD23.71 |
| Total | USD192.08 |
Implementar este cenário
Desenvolvimento de Funções do Azure
Um aplicativo em tempo real sem servidor criado com o Azure Functions e o Serviço Azure SignalR normalmente requer duas Funções do Azure:
- Uma
negotiatefunção que o cliente chama para obter um token de acesso do Serviço SignalR válido e uma URL de ponto de extremidade do serviço. - Uma ou mais funções que enviam mensagens ou gerem 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
Esta função é acionada por um pedido HTTP. Ele é usado por aplicativos cliente para obter um token do serviço SignalR, que os clientes podem usar para se inscrever em um hub. Esta função deve ser denominada negotiate. Para obter mais informações, consulte Desenvolvimento e configuração do Azure Functions com o Serviço Azure SignalR,
Message.cs
Essa função é acionada por um gatilho do barramento de serviço. Tem um vínculo com o serviço SignalR. Solicita a mensagem da fila e transmite-a a um hub do SignalR.
Instruções
Antes de começar:
- Verifique se você tem uma fila de barramento de serviço provisionada no Azure.
- Verifique se você tem um serviço SignalR provisionado no modo sem servidor no Azure.
- Insira suas cadeias de conexão (Service Bus e SignalR) no arquivo local.settings.json .
- Insira a URL do aplicativo cliente (cliente SignalR) em CORS (Cross-Origin Resource Sharing). Para obter a sintaxe mais recente, consulte Desenvolvimento e configuração do Azure Functions com o Serviço Azure SignalR.
- Insira o nome da fila do barramento de serviço no gatilho do barramento de serviço no arquivo Message.cs .
Agora, vamos configurar o aplicativo cliente para testá-lo. Primeiro, pegue as fontes de exemplo da página GitHub de arquiteturas de solução.
Cliente do SignalR
Este é um aplicativo Web .NET Core simples para assinar o hub criado pelo SignalRFunctionApp. Ele exibe mensagens recebidas na fila do barramento de serviço em tempo real. Embora você possa usar o SignalRFunctionApp para trabalhar com um cliente móvel, vamos nos ater ao cliente da Web para esse cenário neste repositório.
Instruções
Certifique-se de que SignalRFunctionApp está em execução.
Copie o URL gerado pela função de negociação. Tem a seguinte aparência:
http://localhost:7071/api/.Cole o URL no ficheiro chat.js , dentro de
signalR.HubConnectionBuilder().withUrl("YOUR_URL_HERE").build();.Execute a aplicação.
O status é conectado quando o cliente da Web se inscreve com êxito no hub SignalR.
SendToQueue.js
Esse script de node.js envia uma mensagem para o Service Bus, para que você possa testar a implantação que acabou de concluir.
Instruções
Instale o módulo nó do Azure Service Bus (@azure/service-bus).
Introduza as cadeias de ligação e o nome da fila no script.
Execute o script.
Próximos passos
Você pode levar esse cenário para seu ambiente de produção. No entanto, certifique-se de que seus serviços do Azure estão definidos para escalar. Por exemplo, o Azure Service Bus deve estar definido para um plano Standard ou Premium.
Pode implementar o código nas Funções do Azure diretamente a partir do Visual Studio. Para saber como publicar seu código no Azure Functions a partir do Visual Studio, siga o guia É como você cria software.
Veja como trabalhar com associações do Barramento de Serviço do Azure no Azure Functions. O Azure Functions dá suporte a associações de gatilho e saída para filas e tópicos do barramento de serviço.
Veja como autenticar e enviar mensagens em tempo real para clientes conectados ao Serviço SignalR do Azure, usando associações do Serviço SignalR no Azure Functions. As Funções do Azure suportam associações de entrada e saída para o SignalR Service.