Questo scenario descrive come progettare una soluzione che elabora le modifiche ai dati sottostanti all'interno di una visualizzazione Web, senza la necessità di un aggiornamento di pagina, usando servizi in tempo reale. Esempi che usano questo scenario includono il rilevamento in tempo reale di prodotti e beni e soluzioni di social media.
Architettura
Scaricare un file di Visio di questa architettura.
Componenti
- bus di servizio di Azure è un servizio di messaggistica cloud altamente affidabile tra applicazioni e servizi, anche quando uno o più sono offline.
- Servizio Azure SignalR semplifica l'aggiunta di comunicazioni in tempo reale all'applicazione Web.
- Funzioni di Azure è una piattaforma di calcolo serverless basata su eventi che può anche risolvere problemi di orchestrazione complessi.
Alternativi
Le alternative esistono per risolvere questo scenario, tra cui pusher. È il leader della categoria nelle API robuste per gli sviluppatori di app che creano funzionalità di comunicazione in tempo reale scalabili.
C'è anche PubNub. PubNub consente di aggiungere in modo semplice funzionalità in tempo reale alle app, senza doversi preoccupare dell'infrastruttura. È possibile creare app che consentono agli utenti di interagire in tempo reale tra dispositivi mobili, browser, PC desktop e server.
Abilmente è un'altra alternativa. Fornisce la messaggistica pubblica/sottoscrizione serverless (pub/sub), che consente di ridimensionare in modo affidabile le proprie esigenze. La messaggistica viene recapitata al bordo usando WebSockets. La piattaforma Ably offre un'infrastruttura a disponibilità elevata, scalabile in modo elastico e distribuita a livello globale, alla chiamata di un'API.
Anche se pusher, PubNub e Ably sono le piattaforme più ampiamente adottate per la messaggistica in tempo reale, per questo scenario, si eseguiranno tutte le operazioni in Azure. È consigliabile SignalR come piattaforma go-to, perché consente la comunicazione bidirezionale tra server e client. È anche uno strumento open source, con 7,9 migliaia di stelle GitHub e 2,2 migliaia di fork GitHub.
Per altre informazioni, vedere il repository open source SignalR in GitHub.
Dettagli dello scenario
In questo scenario si esaminerà come configurare un servizio di messaggistica in tempo reale per condividere la posizione in tempo reale di una transazione del servizio di consegna del cibo. Questo esempio può essere utile anche per coloro che tentano di creare una piattaforma di condivisione della posizione in tempo reale per le applicazioni Web o per dispositivi mobili.
Si userà un servizio SignalR configurato in modalità serverless per integrare con un'app Funzioni di Azure attivata da un bus di servizio, tutto tramite .NET Core.
Potenziali casi d'uso
Questi altri casi d'uso hanno modelli di progettazione simili:
- Condivisione della posizione in tempo reale con i dispositivi client
- Push di notifiche agli utenti
- Aggiornamento delle sequenze temporali
- Creazione di chat room
Considerazioni
Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di set di set di guide che è possibile usare per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Microsoft Azure Well-Architected Framework.
Ecco alcuni aspetti da tenere presente durante lo sviluppo di questo scenario, tra cui come configurare i parametri nella stringa di connessione bus di servizio di Azure in ServiceBusTrigger:
- Hub: gli hub possono essere confrontati con un servizio di streaming video. È possibile sottoscrivere un hub per inviare e ricevere messaggi da e verso di esso.
- Destinazioni: le destinazioni sono come i canali radio. Includono tutti gli utenti che ascoltano il canale di destinazione e ricevono una notifica quando è presente un nuovo messaggio.
Se si possono ricordare le due funzionalità precedenti della piattaforma SignalR, sarà facile ottenere e eseguire rapidamente.
Disponibilità, scalabilità e sicurezza
È possibile ottenere la disponibilità elevata con questa soluzione seguendo le informazioni descritte nelle due sezioni successive.
Coppie di aree
Ogni area di Azure è abbinata a un'altra area con la stessa collocazione geografica. In generale, è consigliabile scegliere aree della stessa coppia di aree (ad esempio, Stati Uniti orientali 2 e Stati Uniti centrali). I vantaggi di questa operazione includono i seguenti:
- Se è presente un'interruzione ampia, il ripristino di almeno un'area fuori da ogni coppia è prioritaria.
- Gli aggiornamenti di sistema di Azure pianificati vengono implementati in sequenza tra le aree abbinate per ridurre al minimo l'eventuale tempo di inattività.
- Nella maggior parte dei casi le coppie di aree si trovano nella stessa area geografica per soddisfare i requisiti di residenza dei dati.
- Assicurarsi tuttavia che entrambe le aree supportino tutti i servizi di Azure necessari per l'applicazione. Vedere i servizi disponibili in base all'area. Per altre informazioni sulle coppie di aree geografiche, vedere Continuità aziendale e ripristino di emergenza (BCDR): aree geografiche abbinate di Azure.
Frontdoor di Azure
Scaricare un file di Visio di questa architettura.
Azure Frontdoor è un punto di ingresso scalabile e sicuro per la distribuzione rapida di applicazioni globali. Quando si usa il routing con priorità, viene eseguito automaticamente il failover se l'area primaria non è disponibile. Un'architettura di tipo multi-area può fornire una maggiore disponibilità rispetto alla distribuzione in un'unica area. Se un'interruzione a livello di area interessa l'area primaria, è possibile usare Frontdoor per effettuare il failover all'area secondaria.
Questa architettura è utile anche in caso di errore di un singolo sottosistema della soluzione. Con Web Application Firewall e Protezione DDoS, è possibile bloccare gli attacchi al livello di rete e di applicazione al perimetro. Proteggere il servizio usando set di regole gestite da Microsoft e creare regole personalizzate per la protezione personalizzata dell'app.
Frontdoor è un possibile punto di guasto nel sistema. Se il servizio ha esito negativo, i client non possono accedere all'applicazione durante il tempo di inattività. Esaminare il contratto di servizio Frontdoor (CONTRATTO di servizio) e determinare se l'uso solo di Frontdoor soddisfa i requisiti aziendali per la disponibilità elevata. In caso contrario, provare ad aggiungere un'altra soluzione di gestione del traffico come fallback. In caso di errore del servizio Frontdoor, cambiare i record di nome canonico (CNAME) in DNS in modo che puntino all'altro servizio di gestione del traffico. È necessario eseguire questo passaggio manualmente e l'applicazione non sarà disponibile finché non vengono propagate le modifiche DNS.
Ottimizzazione dei costi
L'ottimizzazione dei costi riguarda l'analisi dei modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Panoramica del pilastro di ottimizzazione dei costi.
Si supponga che l'azienda disponga di 1.000 ordini al giorno e che sia necessario condividere i dati di posizione con tutti loro simultaneamente. L'utilizzo stimato di Azure per la distribuzione di questo scenario sarà vicino a USD192 al mese, in base ai prezzi alla data di pubblicazione.
| Tipo di servizio | Costo mensile stimato |
|---|---|
| Funzioni di Azure | USD119.40 |
| Servizio Azure SignalR | USD48,97 |
| Bus di servizio di Azure | USD23.71 |
| Totale | USD192.08 |
Distribuire lo scenario
Sviluppo di Funzioni di Azure
Un'applicazione in tempo reale serverless compilata con Funzioni di Azure e Servizio Azure SignalR richiede normalmente due Funzioni di Azure:
- Funzione
negotiateche il client chiama per ottenere un URL valido Servizio SignalR token di accesso e endpoint di servizio. - Una o più funzioni che inviano messaggi o gestiscono l'appartenenza ai gruppi.
SignalRFunctionApp
SignalRFunctionApp è un'app per le funzioni che crea un'istanza di Funzioni di Azure, con un trigger del bus di servizio con SignalR.
Negotiate.cs
Questa funzione viene attivata da una richiesta HTTP. Viene usato dalle applicazioni client per ottenere un token dal servizio SignalR, che i client possono usare per sottoscrivere un hub. Questa funzione deve essere denominata negotiate. Per altre informazioni, vedere Funzioni di Azure sviluppo e configurazione con Servizio Azure SignalR,
Message.cs
Questa funzione viene attivata da un trigger del bus di servizio. Include un binding con il servizio SignalR. Esegue il pull del messaggio dalla coda e lo passa a un hub SignalR.
Istruzioni
Prima di iniziare:
- Assicurarsi di disporre di una coda del bus di servizio di cui è stato effettuato il provisioning in Azure.
- Assicurarsi di disporre di un servizio SignalR di cui è stato effettuato il provisioning in modalità serverless in Azure.
- Immettere le stringhe di connessione (bus di servizio e SignalR) nel file local.settings.json .
- Immettere l'URL dell'applicazione client (client SignalR) in CORS (Cross-Origin Resource Sharing). Per la sintassi più recente, vedere Funzioni di Azure sviluppo e configurazione con Servizio Azure SignalR.
- Immettere il nome della coda del bus di servizio nel trigger del bus di servizio nel file Message.cs .
A questo punto, configurare l'applicazione client per testarla. Per prima cosa, acquisire le origini di esempio dalla pagina GitHub delle architetture di soluzioni .
Client SignalR
Si tratta di una semplice applicazione Web .NET Core per sottoscrivere l'hub creato da SignalRFunctionApp. Visualizza i messaggi ricevuti nella coda del bus di servizio in tempo reale. Sebbene sia possibile usare SignalRFunctionApp per usare un client mobile, è possibile attenersi al client Web per questo scenario in questo repository.
Istruzioni
Assicurarsi che SignalRFunctionApp sia in esecuzione.
Copiare l'URL generato dalla funzione negotiate. Ha un aspetto simile al seguente:
http://localhost:7071/api/.Incollare l'URL nel file chat.js all'interno
signalR.HubConnectionBuilder().withUrl("YOUR_URL_HERE").build();di .Eseguire l'applicazione.
Lo stato è connesso quando il client Web sottoscrive correttamente l'hub SignalR.
SendToQueue.js
Questo script node.js esegue il push di un messaggio al bus di servizio, in modo da poter testare la distribuzione appena completata.
Istruzioni
Installare il modulo del Bus di servizio di Azure del nodo (@azure/service-bus).
Immettere le stringhe di connessione e il nome della coda nello script.
Eseguire lo script.
Passaggi successivi
È possibile inserire questo scenario nell'ambiente di produzione. Tuttavia, assicurarsi che i servizi di Azure siano impostati per la scalabilità. Ad esempio, il bus di servizio di Azure deve essere impostato su un piano standard o Premium.
È possibile distribuire il codice in Funzioni di Azure direttamente da Visual Studio. Per informazioni su come pubblicare il codice in Funzioni di Azure da Visual Studio, seguire la Guida all'uso del software.
Vedere come usare le associazioni bus di servizio di Azure in Funzioni di Azure. Funzioni di Azure supporta associazioni di trigger e output per code e argomenti del bus di servizio.
Vedere come autenticare e inviare messaggi in tempo reale ai client connessi a Servizio Azure SignalR usando associazioni Servizio SignalR in Funzioni di Azure. Funzioni di Azure supporta le associazioni di input e output per il servizio SignalR.