Este cenário descreve como arquitetar uma solução que processa alterações a dados subjacentes numa vista Web, sem a necessidade de uma atualização de página, através de serviços em tempo real. Os exemplos que utilizam este cenário incluem o controlo em tempo real de produtos e bens e soluções de redes sociais.
Arquitetura
Transfira um ficheiro do Visio desta arquitetura.
Componentes
- Azure Service Bus é um serviço de mensagens na cloud altamente fiável entre aplicações e serviços, mesmo quando um ou mais estão offline.
- Azure SignalR Service facilita a adição de comunicações em tempo real à sua aplicação Web.
- Funções do Azure é uma plataforma de computação sem servidor condicionada por eventos que também pode resolver problemas de orquestração complexos.
Alternativas
Existem alternativas para abordar este cenário, incluindo o Pusher. É o líder de categoria em APIs robustas para programadores de aplicações que criam funcionalidades de comunicação dimensionáveis em tempo real.
Também há 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.
É outra alternativa. Fornece mensagens de publicação/subscrição sem servidor (pub/sub), que são dimensionadas de forma fiável com as suas necessidades. As mensagens são entregues na periferia através de WebSockets. A plataforma Ably fornece uma infraestrutura em tempo real altamente disponível, elasticamente dimensionável e distribuída globalmente, à chamada de uma API.
Embora o Pusher, o PubNub e o Ably sejam as plataformas mais amplamente adotadas para mensagens em tempo real, neste cenário, fará tudo no Azure. Recomendamos o SignalR como plataforma de acesso, uma vez que permite a comunicação bidirecional entre o servidor e o cliente. É também uma ferramenta open source, com 7,9 mil estrelas do GitHub e 2,2 mil forks do GitHub.
Para obter mais informações, veja o repositório open source do SignalR no GitHub.
Detalhes do cenário
Neste cenário, irá ver como configurar um serviço de mensagens em tempo real para partilhar a localização em direto de uma transação de serviço de entrega de alimentos. Este exemplo também pode ser útil para quem tenta criar uma plataforma de partilha de localização em tempo real para as suas aplicações Web ou móveis.
Irá utilizar um serviço SignalR configurado no modo sem servidor para integrar com uma aplicação Funções do Azure que é acionada por um service bus, tudo isto através do .NET Core.
Potenciais casos de utilização
Estes outros casos de utilização têm padrões de design semelhantes:
- Partilhar a localização em tempo real com dispositivos cliente
- Enviar notificações push para os utilizadores
- Atualizar linhas cronológicas
- Criar salas de chat
Considerações
Estas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios de orientação que pode utilizar para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, veja Microsoft Azure Well-Architected Framework.
Seguem-se alguns aspetos a ter em conta à medida que desenvolve este cenário, incluindo como configurar parâmetros no Azure Service Bus cadeia de ligação no ServiceBusTrigger:
- Hubs: os hubs podem ser comparados com um serviço de transmissão em fluxo de vídeo. Pode subscrever um hub para enviar e receber mensagens de e para o mesmo.
- Alvos: os alvos são como canais de rádio. Incluem todas as pessoas que estão a ouvir o canal de destino e são notificadas quando existe uma nova mensagem no mesmo.
Se se lembrar das duas funcionalidades anteriores da plataforma SignalR, será fácil começar a trabalhar rapidamente.
Disponibilidade, escalabilidade e segurança
Pode obter elevada disponibilidade com esta solução ao seguir o que está descrito nas duas secções seguintes.
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 falha geral, a recuperação de, pelo menos, uma região em 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, confirme que ambas as regiões suportam todos os serviços do Azure necessários para a sua aplicação. Veja Serviços por região. Para obter mais informações sobre pares regionais, veja Continuidade de 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 utiliza o encaminhamento prioritário, efetua automaticamente a ativação pós-falha 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 o seu serviço com conjuntos de regras geridos pela Microsoft e crie as suas próprias regras para proteção personalizada da sua aplicação.
O Front Door é um ponto de falha possível no sistema. Se o serviço falhar, os clientes não poderão aceder à sua aplicação durante o período de indisponibilidade. Reveja o contrato de nível de serviço (SLA) do Front Door e determine se utilizar o Front Door apenas cumpre os seus requisitos empresariais para elevada 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. Tem de executar este passo manualmente e a sua aplicação 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, veja Descrição geral do pilar de otimização de custos.
Vamos supor que a sua empresa tem 1000 encomendas por dia e precisa de partilhar dados de localização com todas em simultâneo. A utilização estimada do Azure para implementar este cenário será próxima de USD192 por mês, com base nos preços na data de publicação.
| Tipo de serviço | Custo mensal estimado |
|---|---|
| Funções do Azure | USD119.40 |
| Azure SignalR Service | USD48.97 |
| Service Bus do Azure | USD23.71 |
| Total | USD192.08 |
Implementar este cenário
Desenvolvimento de Funções do Azure
Normalmente, uma aplicação sem servidor em tempo real criada com Funções do Azure e Azure SignalR Service requer dois Funções do Azure:
- Uma
negotiatefunção que o cliente chama para obter um token de acesso SignalR Service válido e o URL do ponto final de serviço. - Uma ou mais funções que enviam mensagens ou gerem a associação a um grupo.
SignalRFunctionApp
SignalRFunctionApp é uma aplicação de funções que cria uma instância Funções do Azure, com um acionador de barramento de serviço com o SignalR.
Negotiate.cs
Esta função é acionada por um pedido HTTP. É utilizado pelas aplicações cliente para obter um token do serviço SignalR, que os clientes podem utilizar para subscrever um hub. Esta função deve ter o nome negotiate. Para obter mais informações, veja Funções do Azure desenvolvimento e configuração com Azure SignalR Service,
Message.cs
Esta função é acionada por um acionador do service bus. 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:
- Confirme que tem uma fila do service bus aprovisionada no Azure.
- Confirme que tem um serviço SignalR aprovisionado no modo sem servidor no Azure.
- Introduza as cadeias de ligação (Service Bus e SignalR) no ficheiro local.settings.json .
- Introduza o URL da aplicação cliente (cliente SignalR) no CORS (Partilha de Recursos Transversais à Origem). Para obter a sintaxe mais recente, veja Funções do Azure desenvolvimento e configuração com Azure SignalR Service.
- Introduza o nome da fila do service bus no acionador do service bus no ficheiro Message.cs .
Agora, vamos configurar a aplicação cliente para testá-la. Primeiro, veja as origens de exemplo da página gitHub solution-architectures .
Cliente do SignalR
Esta é uma aplicação Web .NET Core simples para subscrever o hub criado pelo SignalRFunctionApp. Apresenta as mensagens recebidas na fila do service bus em tempo real. Embora possa utilizar o SignalRFunctionApp para trabalhar com um cliente móvel, vamos manter o cliente Web para este cenário neste repositório.
Instruções
Certifique-se de que SignalRFunctionApp está em execução.
Copie o URL gerado pela função negotiate. Tem um aspeto semelhante ao seguinte:
http://localhost:7071/api/.Cole o URL no ficheiro dechat.js , dentro
signalR.HubConnectionBuilder().withUrl("YOUR_URL_HERE").build();de .Execute a aplicação.
O estado é ligado quando o cliente Web subscreve com êxito o hub do SignalR.
SendToQueue.js
Este node.js script envia uma mensagem para o Service Bus, para que possa testar a implementação que acabou de concluir.
Instruções
Instale o módulo de Azure Service Bus de nós (@azure/service-bus).
Introduza as cadeias de ligação e o nome da fila no script.
Execute o script.
Passos seguintes
Pode levar este cenário para o seu ambiente de produção. No entanto, certifique-se de que os seus serviços do Azure estão definidos para dimensionamento. 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 o seu código no Funções do Azure a partir do Visual Studio, siga o guia De forma a criar software.
Veja como trabalhar com enlaces de Azure Service Bus no Funções do Azure. Funções do Azure suporta enlaces de acionador e saída para filas e tópicos do service bus.
Veja como autenticar e enviar mensagens em tempo real para clientes ligados a Azure SignalR Service, utilizando enlaces de SignalR Service no Funções do Azure. As Funções do Azure suportam associações de entrada e saída para o SignalR Service.