Modo de servicio en Azure SignalR Service
El modo de servicio es un concepto importante en Azure SignalR Service. SignalR Service admite actualmente tres modos de servicio: predeterminado, sin servidor y clásico. El recurso de SignalR Service se comporta de forma diferente en cada modo. En este artículo, aprenderá a elegir el modo de servicio adecuado en función de su escenario.
Establecimiento del modo de servicio
Se le pedirá que especifique un modo de servicio al crear un nuevo recurso de SignalR en Azure Portal.
También puede cambiar el modo de servicio más adelante en el menú de configuración.
Use az signalr create y az signalr update para establecer o cambiar el modo de servicio mediante la CLI de Azure SignalR.
Modo predeterminado
Como su nombre indica, el modo predeterminado es el modo de servicio predeterminado para SignalR Service. En el modo predeterminado, la aplicación funciona como una aplicación típica ASP.NET Core SignalR o ASP.NET SignalR (en desuso). Tiene una aplicación de servidor web que hospeda un centro, denominado servidor concentrador, y los clientes tienen comunicación dúplex completa con el servidor concentrador. La diferencia entre ASP.NET Core SignalR y Azure SignalR Service es: con ASP.NET Core SignalR, el cliente se conecta directamente al servidor central. Con Azure SignalR Service, tanto el cliente como el servidor concentrador se conectan a SignalR Service y usan el servicio como proxy. En el diagrama siguiente se muestra la estructura típica de la aplicación en modo predeterminado.
El modo predeterminado suele ser la opción adecuada cuando tiene una aplicación signalR que desea usar con SignalR Service.
Enrutamiento de conexión en modo predeterminado
En el modo predeterminado, hay conexiones de WebSocket entre el servidor concentrador y SignalR Service llamadas conexiones de servidor. Estas conexiones se utilizan para transferir mensajes entre un servidor y el cliente. Cuando se conecta un nuevo cliente, SignalR Service enruta el cliente a un servidor concentrador (suponga que tiene más de un servidor) a través de las conexiones de servidor existentes. La conexión de cliente se adhiere al mismo servidor concentrador durante su vigencia. Esta propiedad se conoce como permanencia de conexión. Cuando el cliente envía mensajes, siempre se dirigen al mismo servidor concentrador. Con este comportamiento, puede mantener de forma segura algunos estados para las conexiones individuales en el servidor concentrador. Por ejemplo, si quiere transmitir algo entre el servidor y el cliente, no es necesario considerar el caso en que los paquetes de datos vayan a servidores diferentes.
Importante
En el modo predeterminado, un cliente no puede conectarse sin que un servidor concentrador se conecte primero al servicio. Si todos los servidores concentradores se desconectan debido a una interrupción de la red o al reinicio del servidor, la conexión de cliente recibirá un error que indica que no hay ningún servidor conectado. Es su responsabilidad asegurarse de que siempre haya al menos un servidor concentrador conectado al SignalR service. Por ejemplo, puede diseñar la aplicación con varios servidores concentradores y, a continuación, asegurarse de que no se desconectarán al mismo tiempo.
El modelo de enrutamiento predeterminado también significa cuando un servidor concentrador se queda sin conexión, se quitan las conexiones enrutadas a ese servidor. Debe esperar que las conexiones se anulen cuando el servidor concentrador esté sin conexión para el mantenimiento y controlar la reconexión para minimizar los efectos de la aplicación.
Nota:
En el modo predeterminado, también puede usar el enlace de función, el SDK de administración o la API de REST para enviar mensajes directamente al cliente si no quiere pasar por el servidor concentrador. En el modo predeterminado, las conexiones de cliente siguen siendo administradas por servidores concentradores y el punto de conexión ascendente no funcionará en ese modo.
Modo sin servidor
A diferencia del modo predeterminado, el modo sin servidor no requiere que se ejecute un servidor concentrador, por lo que este modo se denomina "sin servidor". El SignalR Service es responsable de mantener las conexiones de cliente. No hay ninguna garantía de permanencia de conexión y las solicitudes HTTP pueden ser menos eficaces que las conexiones de WebSockets.
El modo sin servidor funciona con Azure Functions para proporcionar funcionalidad de mensajería en tiempo real. Los clientes trabajan con enlaces de SignalR Service para Azure Functions, denominados enlaces de función, para enviar mensajes como enlace de salida.
Dado que no hay conexión de servidor, si intenta usar un SDK de servidor para establecer una conexión de servidor, se produce un error. SignalR Service rechaza los intentos de conexión del servidor en modo sin servidor.
El modo sin servidor no tiene permanencia en la conexión, pero todavía puede tener mensajes de inserción de aplicaciones del lado servidor a los clientes. Hay dos maneras de insertar mensajes a los clientes en modo sin servidor:
- Uso de la API de REST para un evento de envío único o
- Use una conexión WebSocket para poder enviar varios mensajes de forma más eficaz. Esta conexión de WebSocket es diferente de una conexión de servidor.
Nota:
Tanto la opción API REST como WebSocket se admiten en el SDK de administración del SignalR service. Si utiliza un lenguaje distinto de .NET, también puede invocar manualmente las API REST que siguen a esta especificación.
También es posible que la aplicación de servidor reciba mensajes y eventos de conexión de los clientes. SignalR Service entrega mensajes y eventos de conexión a puntos de conexión preconfigurados (denominados puntos de conexión ascendentes) mediante enlaces web. Los puntos de conexión ascendentes solo se pueden configurar en el modo sin servidor. Para obtener más información, vea Puntos de conexión ascendentes.
El diagrama siguiente muestra cómo funciona la aplicación de sin servidor.
Modo clásico
Nota:
El modo clásico es principalmente para la compatibilidad con versiones anteriores para las aplicaciones creadas antes de que se introdujeran los modos Predeterminado y Sin servidor. No use el modo clásico excepto como último recurso. Use Predeterminado o Sin servidor para las nuevas aplicaciones, en función de su escenario. Debe considerar la posibilidad de rediseñar las aplicaciones existentes para eliminar la necesidad del modo clásico.
El clásico es una combinación del modo predeterminado y el modo sin servidor. En este modo, el tipo de conexión se decide según si hay un servidor concentrador conectado cuando se establece la conexión de cliente. Si hay un servidor concentrador, la conexión de cliente se enruta a un servidor concentrador. Si un servidor concentrador no está disponible, la conexión de cliente se realiza en un modo limitado sin servidor en el que los mensajes de cliente a servidor no se pueden entregar a un servidor concentrador. Las conexiones sin servidor en modo clásico no admiten algunas características, como los puntos de conexión ascendentes.
Si todos los servidores centrales están sin conexión por cualquier motivo, las conexiones se realizan en modo sin servidor. Es su responsabilidad asegurarse de que, al menos, un servidor concentrador esté siempre disponible.
Selección del modo de servicio correcto
Ahora, debería comprender las diferencias entre los modos de servicio y saber cómo elegir entre ellos. Como se ha explicado anteriormente, no se recomienda el modo clásico para las aplicaciones nuevas o existentes. A continuación, se muestran algunas sugerencias que pueden ayudarle a tomar la decisión adecuada para el modo servidor y retirar el modo clásico para las aplicaciones existentes.
Elija el modo predeterminado si ya está familiarizado con el funcionamiento de la biblioteca de SignalR y quiere pasar de un servicio SignalR autohospedado a Azure SignalR Service. El modo predeterminado funciona exactamente igual que el servicio SignalR autohospedado, y puede usar el mismo modelo de programación en la biblioteca de SignalR. SignalR Service actúa como proxy entre clientes y servidores concentradores.
Elija el modo sin servidor si va a crear una aplicación y no quiere mantener las conexiones de servidor y de servidor concentrador. El modo sin servidor suele funcionar junto con Azure Functions, por lo que no es necesario mantener ningún servidor. Todavía puede tener comunicaciones dúplex completas con la API de REST, el SDK de administración o el enlace de funciones + punto de conexión ascendente, pero el modelo de programación es diferente de la biblioteca de SignalR.
Elija Modo predeterminado si tiene ambos servidores concentradores para atender las conexiones de cliente y una aplicación back-end para insertar mensajes directamente en los clientes. La diferencia principal entre el modo predeterminado y sin servidor radica en si tiene servidores concentradores y en cómo se enrutan las conexiones de cliente. La API REST, el SDK de administración y el enlace de función se pueden usar en ambos modos.
Considere la posibilidad de separar los casos de uso en varias instancias de SignalR Service con el modo de servicio establecido según el uso, si realmente tiene un escenario mixto. Un ejemplo de un escenario mixto que requiere el modo clásico es donde tiene dos concentradores diferentes en el mismo recurso de SignalR. Un concentrador se usa como concentrador de SignalR tradicional y el otro concentrador se usa con Azure Functions. Este ejemplo debe dividirse en dos recursos con una instancia en modo predeterminado y otra en modo sin servidor.
Pasos siguientes
Consulte los artículos siguientes para obtener más información sobre cómo usar los modos Predeterminado y Sin servidor.