Modalità servizio in Servizio Azure SignalR

La modalità di servizio è un concetto importante in Servizio Azure SignalR. Servizio SignalR supporta attualmente tre modalità di servizio: Impostazione predefinita, serverless e classica. La risorsa Servizio SignalR si comporterà in modo diverso in ogni modalità. In questo articolo si apprenderà come scegliere la modalità di servizio appropriata in base allo scenario in uso.

Impostazione della modalità servizio

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

Azure portal – Choose service mode when creating a SignalR Service

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

Update service mode

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

Modalità predefinita

Come suggerisce il nome, la modalità predefinita è la modalità di servizio predefinita per Servizio SignalR. In modalità predefinita, l'applicazione funziona come un'applicazione tipica 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 duplex completa con il server hub. La differenza tra ASP.NET Core SignalR e Servizio Azure SignalR consiste nel connettere direttamente client e server hub, client e server sia connettersi a Servizio SignalR che usare il servizio come proxy. Il diagramma seguente mostra la struttura tipica dell'applicazione in modalità predefinita.

Application structure in Default mode

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

routing Connessione ion in modalità predefinita

In modalità predefinita sono presenti connessioni WebSocket tra il server hub e Servizio SignalR chiamate 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 verrà mantenuta allo stesso server hub durante la sua durata. Questa proprietà viene definita stickiness della connessione. Quando il client invia messaggi, passano sempre allo stesso server hub. Con il comportamento di stickiness, è 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 connesso per primo 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 sia sempre presente almeno un server hub connesso al servizio SignalR. Ad esempio, è possibile progettare l'applicazione con più server hub e quindi assicurarsi che non vengano tutti offline contemporaneamente.

Il modello di routing predefinito indica anche quando un server hub passa offline, le connessioni indirizzate a tale server verranno eliminate. È consigliabile che le connessioni vengano ridotte quando il server hub è offline per la manutenzione e gestire 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 l'associazione 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 permanentità della connessione e le richieste HTTP possono essere meno efficienti rispetto alle connessioni WebSocket.

La modalità serverless funziona con Funzioni di Azure per offrire funzionalità di messaggistica in tempo reale. I client funzionano con associazioni Servizio SignalR per Funzioni di Azure, denominata associazione di funzioni, per inviare messaggi come associazione di output.

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

La modalità serverless non ha la persistenza della connessione, ma è comunque possibile disporre di messaggi push dell'applicazione sul 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 monouso 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 in SignalR Service Management SDK. Se si usa un linguaggio diverso da .NET, è anche possibile richiamare manualmente le API REST seguendo questa specifica.

È anche possibile che l'applicazione server riceva messaggi ed eventi di connessione dai client. Servizio SignalR recapita i messaggi e gli eventi di connessione agli endpoint preconfigurati (denominati endpoint upstream) usando web hook. 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.

Application structure in Serverless mode

Modalità classica

Nota

La modalità classica è principalmente per la compatibilità con le versioni precedenti alle applicazioni create prima dell'introduzione delle modalità Predefinite e Serverless. Non usare la modalità classica tranne come ultima risorsa. Usare Default 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 è presente un server hub connesso quando viene stabilita la connessione client. Se è presente un server hub, la connessione client verrà instradata a un server hub. Se un server hub non è disponibile, la connessione client verrà 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 verranno effettuate in modalità serverless. È responsabilità dell'utente assicurarsi che almeno un server hub sia sempre disponibile.

Scegliere la modalità di servizio corretta

Ora è necessario comprendere le differenze tra le modalità di servizio e sapere come scegliere tra di esse. Come illustrato in precedenza, la modalità classica non è consigliata per le applicazioni nuove o esistenti. Ecco alcuni altri suggerimenti che consentono di scegliere la modalità di servizio più adatta e di ritirare la modalità classica per le applicazioni esistenti.

  • Scegliere 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 Modalità serverless se si sta creando una nuova applicazione e non si desidera mantenere le connessioni server hub e server. La modalità serverless funziona insieme a Funzioni di Azure in modo che non sia necessario mantenere alcun server. È comunque possibile avere comunicazioni duplex complete con l'API REST, l'SDK di gestione o l'associazione di funzioni + endpoint upstream, ma il modello di programmazione sarà diverso dalla libreria SignalR.

  • Scegliere Modalità predefinita se sono presenti entrambi i server hub per gestire 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 è se sono presenti server hub e come vengono instradate le connessioni client. L'ASSOCIAZIONE API REST/MANAGEMENT SDK/funzione può essere usata in entrambe le modalità.

  • Se in realtà si ha uno scenario misto, è consigliabile separare i casi d'uso in più istanze di Servizio SignalR con la modalità di servizio impostata in base all'uso. Un esempio di scenario misto che richiede la modalità classica è quello in cui sono presenti 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

Vedere gli articoli seguenti per altre informazioni su come usare le modalità predefinite e serverless.