Condividi tramite


Modalità servizio in Servizio Azure SignalR

La modalità servizio è un concetto importante in Servizio Azure SignalR. Servizio SignalR attualmente supporta tre modalità servizio: Predefinita, Serverless e Classica. La risorsa di Servizio SignalR si comporta in modo diverso in ogni modalità. Questo articolo illustra come scegliere la modalità servizio appropriata in base allo scenario in uso.

Impostazione della modalità servizio

Viene chiesto di specificare una modalità servizio quando si crea una nuova risorsa SignalR nel portale di Azure.

Portale di Azure: scegliere la modalità servizio durante la creazione di un Servizio SignalR

È anche possibile modificare la modalità servizio in un secondo momento nel menu delle impostazioni.

Aggiornare la modalità servizio

Usare az signalr create e az signalr update per impostare o modificare la modalità servizio usando l'interfaccia della riga di comando di Azure SignalR.

Modalità predefinita

Come suggerisce il nome, la modalità Predefinita è la modalità servizio predefinita per Servizio SignalR. In modalità Predefinita, l'applicazione funziona come una tipica applicazione ASP.NET Core SignalR o ASP.NET SignalR (deprecata). Si dispone di un'applicazione server Web che ospita un hub denominato server hub e i client hanno una comunicazione full duplex con il server hub. La differenza tra ASP.NET Core SignalR e Servizio Azure SignalR consiste nel fatto che con ASP.NET Core SignalR il client si connette direttamente al server hub. Con Servizio Azure SignalR, sia il client che il server hub si connettono a Servizio SignalR e usano il servizio come proxy. Il diagramma seguente mostra la tipica struttura dell'applicazione in modalità Predefinita.

Struttura dell'applicazione in modalità Predefinita

La modalità Predefinita generalmente è la scelta giusta quando si dispone di un'applicazione SignalR che si vuole usare con Servizio SignalR.

Routing della connessione in modalità Predefinita

In modalità Predefinita sono presenti connessioni WebSocket tra il server hub e Servizio SignalR denominate connessioni server. Queste connessioni vengono usate per trasferire messaggi tra un server e un client. Quando un nuovo client è connesso, Servizio SignalR instrada il client a un server hub (si supponga di avere più di un server) tramite connessioni server esistenti. La connessione client persiste allo stesso server hub durante la sua durata. Questa proprietà viene definita persistenza della connessione. Quando il client invia messaggi, tali messaggi passano sempre allo stesso server hub. Con il comportamento di persistenza, è possibile mantenere in modo sicuro alcuni stati per le singole connessioni nel server hub. Ad esempio, se si vuole trasmettere qualcosa tra server e client, non è necessario considerare il caso in cui i pacchetti di dati passano a server diversi.

Importante

In modalità Predefinita un client non può connettersi senza che un server hub sia prima connesso al servizio. Se tutti i server hub sono disconnessi a causa dell'interruzione della rete o del riavvio del server, le connessioni client riceveranno un errore che informa che non è connesso alcun server. È responsabilità dell'utente assicurarsi che almeno un server hub sia sempre connesso a Servizio SignalR. Ad esempio, è possibile progettare un'applicazione con più server hub e quindi assicurarsi che non si scolleghino tutti contemporaneamente.

Con il modello di routing predefinito, inoltre, quando un server hub si disconnette, le connessioni instradate a tale server vengono rimosse. Ci si dovrebbe aspettare che le connessioni vengano rimosse quando il server hub è offline e che venga gestita la riconnessione per ridurre al minimo gli effetti sull'applicazione.

Nota

In modalità Predefinita è anche possibile usare l'API REST, l'SDK di gestione e il binding di funzioni per inviare direttamente messaggi a un client se non si vuole passare attraverso un server hub. In modalità Predefinita, le connessioni client vengono ancora gestite dai server hub e gli endpoint upstream non funzioneranno in tale modalità.

Modalità Serverless

A differenza della modalità Predefinita, la modalità Serverless non richiede l'esecuzione di un server hub, motivo per cui questa modalità è denominata "Serverless". Servizio SignalR è responsabile della gestione delle connessioni client. Non esiste alcuna garanzia di persistenza e le richieste HTTP potrebbero essere meno efficienti rispetto alle connessioni WebSocket.

La modalità Serverless può essere utilizzata con Funzioni di Azure per ottenere funzionalità di messaggistica in tempo reale. I client funzionano con binding di Servizio SignalR per Funzioni di Azure denominate binding di funzioni, per inviare messaggi come binding di output.

Poiché non è presente alcuna connessione al server, se si tenta di usare un SDK del server per stabilire una connessione server si riceve un errore. Servizio SignalR rifiuta i tentativi di connessione del server in modalità Serverless.

La modalità Serverless non ha la persistenza della connessione, ma è comunque possibile avere messaggi push dell'applicazione lato server ai client. Esistono due modi per eseguire il push dei messaggi ai client in modalità Serverless:

  • Usare le API REST per un evento di invio una tantum o
  • Usare una connessione WebSocket per poter inviare più messaggi in modo più efficiente. Questa connessione WebSocket è diversa da una connessione server.

Nota

Sia l'API REST che i WebSocket sono supportati nell'SDK di gestione di Servizio SignalR. Se si usa un linguaggio diverso da .NET, è possibile richiamare manualmente le API REST anche seguendo questa specifica.

È anche possibile che l'applicazione server riceva messaggi ed eventi di connessione dai client. Servizio SignalR recapita messaggi ed eventi di connessione agli endpoint preconfigurati (denominati endpoint upstream) usando webhook. Gli endpoint upstream possono essere configurati solo in modalità Serverless. Per altre informazioni, vedere Endpoint upstream.

Il diagramma seguente illustra il funzionamento della modalità Serverless.

Struttura dell'applicazione in modalità Serverless

Modalità Classica

Nota

La modalità Classica esiste principalmente per la compatibilità con le versioni precedenti per le applicazioni create prima dell'introduzione delle modalità Predefinita e Serverless. Non usare la modalità Classica se non come ultima risorsa. Usare la modalità Predefinita o Serverless per le nuove applicazioni, in base al proprio scenario. È consigliabile riprogettare le applicazioni esistenti per eliminare la necessità della modalità Classica.

La modalità Classica è una modalità mista di modalità Predefinita e Serverless. In modalità Classica, il tipo di connessione viene deciso se esiste un server hub connesso quando viene stabilita la connessione client. Se esiste un server hub, la connessione client viene instradata a un server hub. Se non è disponibile un server hub, la connessione client viene effettuata in modalità Serverless limitata in cui i messaggi da client a server non possono essere recapitati a un server hub. Le connessioni serverless in modalità Classica non supportano alcune funzionalità, ad esempio gli endpoint upstream.

Se tutti i server hub sono offline per qualsiasi motivo, le connessioni vengono effettuate in modalità Serverless. È responsabilità dell'utente assicurarsi che almeno un server hub sia sempre disponibile.

Scegliere la modalità servizio appropriata

A questo punto è necessario comprendere le differenze tra le modalità servizio e capire come scegliere tra queste modalità. Come illustrato in precedenza, la modalità Classica non è consigliata per applicazioni nuove o esistenti. Di seguito sono indicati altri suggerimenti che consentono di scegliere la modalità servizio più adatta e ritirare la modalità Classica per le applicazioni esistenti.

  • Scegliere la modalità Predefinita se si ha già familiarità con il funzionamento della libreria SignalR e si vuole passare da un SignalR self-hosted per usare Servizio Azure SignalR. La modalità Predefinita funziona esattamente come SignalR self-hosted ed è possibile usare lo stesso modello di programmazione nella libreria SignalR. Servizio SignalR funge da proxy tra client e server hub.

  • Scegliere la modalità Serverless se si sta creando una nuova applicazione e non si vuole mantenere le connessioni server e server hub. La modalità Serverless funziona insieme a Funzioni di Azure in modo che non sia necessario gestire alcun server. È comunque possibile avere comunicazioni full duplex con l'API REST, l'SDK di gestione o il binding di funzioni + endpoint upstream, ma il modello di programmazione è diverso dalla libreria SignalR.

  • Scegliere la modalità Predefinita se entrambi i server hub gestiscono le connessioni client e un'applicazione back-end per eseguire direttamente il push dei messaggi ai client. La differenza principale tra la modalità Predefinita e Serverless riguarda la presenza di server hub e la modalità di instradamento delle connessioni client. L'API REST, l'SDK di gestione e il binding di funzioni possono può essere usati in entrambe le modalità.

  • Valutare la possibilità di separare i casi d'uso in più istanze di Servizio SignalR con la modalità servizio impostata in base all'uso, se lo scenario è realmente misto. Un esempio di scenario misto che richiede la modalità Classica è quello in cui sono esistono due hub diversi nella stessa risorsa SignalR. Un hub viene usato come hub SignalR tradizionale e l'altro hub viene usato con Funzioni di Azure. Questo esempio deve essere suddiviso in due risorse, con un'istanza in modalità Predefinita e una in modalità Serverless.

Passaggi successivi

Per altre informazioni su come usare le modalità Predefinita e Serverless, vedere gli articoli seguenti.