Compartir a través de

Uso de Azure SignalR Service

  • Artículo

En este artículo se muestra cómo usar el SDK en el lado servidor de aplicaciones para conectarse a SignalR Service cuando se usa SignalR en el servidor de aplicaciones.

Creación de una instancia del servicio Azure SignalR

Siga el Inicio rápido: Uso de una plantilla de ARM para implementar Azure SignalR para crear una instancia de servicio de SignalR.

Para ASP.NET Core SignalR

Instalación del SDK

Ejecute el comando para instalar el SDK de SignalR Service en el proyecto de ASP.NET Core.

dotnet add package Microsoft.Azure.SignalR

En la clase Startup, use el SDK de SignalR Service como el siguiente fragmento de código.

public void ConfigureServices(IServiceCollection services)
{
    services.AddSignalR()
            .AddAzureSignalR();
}

public void Configure(IApplicationBuilder app)
{
    app.UseEndpoints(routes =>
    {
        routes.MapHub<YourHubClass>("/path_for_your_hub");
    });
}

Configurar cadena de conexión

Hay dos enfoques para configurar la cadena de conexión de SignalR Service en la aplicación.

  • Establezca una variable de entorno con el nombre Azure:SignalR:ConnectionString o Azure__SignalR__ConnectionString.

    • En Azure App Service, colóquela en la configuración de la aplicación.

  • Pase la cadena de conexión como parámetro de AddAzureSignalR().

    services.AddSignalR()
        .AddAzureSignalR("<replace with your connection string>");

    o

    services.AddSignalR()
        .AddAzureSignalR(options => options.ConnectionString = "<replace with your connection string>");

Configurar opciones

Hay algunas opciones que puede personalizar al usar el SDK de Azure SignalR Service.

ConnectionString

  • El valor predeterminado es Azure:SignalR:ConnectionStringconnectionString o appSetting en el archivo web.config.
  • Puede volver a configurarse, pero asegúrese de que el valor NO está codificado de forma rígida.

InitialHubServerConnectionCount

  • El valor predeterminado es 5.
  • Esta opción controla el recuento inicial de conexiones por centro entre el servidor de aplicaciones y Azure SignalR Service. Normalmente con mantenerlo como valor predeterminado es suficiente. Durante el tiempo de ejecución, el SDK podría iniciar nuevas conexiones de servidor para el ajuste del rendimiento o el equilibrio de carga. Cuando tiene un gran número de clientes, puede darle un número mayor para mejorar el rendimiento. Por ejemplo, si tiene 100 000 clientes en total, el recuento de conexiones se puede aumentar a 10 o 15.

MaxHubServerConnectionCount

  • El valor predeterminado es null.
  • Esta opción controla el recuento máximo de conexiones permitidas por centro entre el servidor de aplicaciones y Azure SignalR Service. Durante el tiempo de ejecución, el SDK podría iniciar nuevas conexiones de servidor para el ajuste del rendimiento o el equilibrio de carga. De forma predeterminada, se inicia una nueva conexión de servidor siempre que sea necesario. Cuando se configura el número máximo permitido de conexiones de servidor, el SDK no inicia nuevas conexiones cuando el número de conexiones de servidor alcanza el límite.

ApplicationName

  • El valor predeterminado es null.
  • Esta opción puede ser útil cuando desea compartir la misma instancia de Azure SignalR para distintos servidores de aplicaciones que contengan los mismos nombres de concentrador. Si no se establece, todos los servidores de aplicaciones conectados se consideran instancias de la misma aplicación.

ClaimsProvider

  • El valor predeterminado es null.
  • Esta opción controla las notificaciones que desea asociar a la conexión de cliente. Se usa cuando el SDK de servicio genera el token de acceso para el cliente en la solicitud de negociación del cliente. De manera predeterminada, se reservan todas las notificaciones a de HttpContext.User de la solicitud negociada. Se puede acceder a ellas en Hub.Context.User.
  • Normalmente, debe dejar esta opción tal como está. Asegúrese de comprender lo que sucede antes de personalizarla.

AccessTokenLifetime

  • El valor predeterminado es 1 hour.
  • Esta opción controla la vigencia válida del token de acceso, que el SDK de Service genera para cada cliente. El token de acceso se devuelve en la respuesta a la solicitud de negociación del cliente.
  • Cuando ServerSentEvent o LongPolling se usa como transporte, la conexión de cliente se cerrará debido a un error de autenticación después del tiempo expirado. Puede aumentar este valor para evitar la desconexión del cliente.

AccessTokenAlgorithm

  • El valor predeterminado es HS256.
  • Esta opción proporciona la opción de SecurityAlgorithms al generar el token de acceso. Ahora los valores opcionales admitidos son HS256 y HS512. Observe que HS512 es más seguro pero el token generado es relativamente más largo que usando HS256.

ServerStickyMode

  • El valor predeterminado es Disabled.
  • Esta opción especifica el modo para persistente del servidor. Cuando el cliente se enruta al servidor con el que negocia primero, lo llamamos persistente del servidor.
  • En escenarios distribuidos, puede haber varios servidores de aplicaciones conectados a una instancia de Azure SignalR. Como explica el apartado sobre los aspectos internos de las conexiones de cliente, el cliente negocia primero con el servidor de la aplicación y después redirige a Azure SignalR para establecer la conexión persistente. Azure SignalR encuentra después un servidor de aplicaciones para servir al cliente, como explica Transporte de datos entre el cliente y el servidor.
    • Cuando es Disabled, el cliente se enruta a un servidor de aplicaciones aleatorio. En general, los servidores de aplicaciones tienen conexiones de cliente equilibradas con este modo. Si sus escenarios son difusión o envío de grupo, con usar esta opción predeterminada es suficiente.
    • Cuando es Preferred, Azure SignalR intenta encontrar el servidor de aplicaciones con el que el cliente negocia por primera vez de forma que no se necesite ningún otro costo o enrutamiento global. Este puede ser útil cuando su escenario se envía a conexión*. Enviar a la conexión puede tener un mejor rendimiento y una menor latencia cuando el remitente y el receptor se enrutan al mismo servidor de aplicaciones.
    • Cuando es Required, Azure SignalR siempre intenta encontrar el servidor de aplicaciones con el que el cliente negocia primero. Esta opción puede ser útil cuando se obtiene algún contexto de cliente del paso negotiate y se almacena en memoria, para después usarlo dentro de Hubs. Sin embargo, esta opción puede tener inconvenientes de rendimiento, ya que requiere que Azure SignalR realice otros esfuerzos para encontrar globalmente este servidor de aplicación en particular, y para seguir enrutando globalmente el tráfico entre el cliente y el servidor.

GracefulShutdown

GracefulShutdown.Mode
  • El valor predeterminado es Off.
  • Esta opción especifica el comportamiento después de que el servidor de aplicaciones reciba un SIGINT (CTRL + C).
  • Cuando se establece en WaitForClientsClose, en lugar de detener el servidor inmediatamente, lo quitamos de Azure SignalR Service para evitar que se asignen nuevas conexiones de cliente a este servidor.
  • Cuando se establece en MigrateClients, además, intentamos migrar conexiones de cliente a otro servidor válido. La migración se desencadenará solo después de que se entregue un mensaje.
    • OnConnected y OnDisconnected se desencadenan cuando se migran las conexiones dentro y fuera.
    • IConnectionMigrationFeature puede ayudarle a identificar si la conexión está migrada hacia dentro o hacia fuera.
    • Consulte nuestros códigos de ejemplo para una utilización más detallada.
GracefulShutdown.Timeout
  • El valor predeterminado es 30 seconds.
  • Esta opción especifica el tiempo más largo en espera de que los clientes se cierren o migren.

ServiceScaleTimeout

  • El valor predeterminado es 5 minutes.
  • Esta opción especifica el mayor tiempo en espera de los puntos de conexión del servicio de escalado dinámico, para afectar lo menos posible a los clientes en línea. Normalmente, la escala dinámica entre un único servidor de aplicaciones y un punto de conexión de servicio puede terminarse en segundos, pero si tiene varios servidores de aplicaciones y varios puntos de conexión de servicio con inestabilidad de la red y quiere asegurar la estabilidad del cliente, puede configurar este valor en consecuencia.

MaxPollIntervalInSeconds

  • El valor predeterminado es 5.
  • Esta opción define el intervalo de sondeo máximo permitido para conexiones de LongPolling en el servicio Azure SignalR. Si la siguiente solicitud de sondeo no entra en MaxPollIntervalInSeconds, Azure SignalR Service limpia la conexión de cliente.
  • El valor está limitado a [1, 300].

TransportTypeDetector

  • Valor predeterminado: todos los transportes están habilitados.
  • Esta opción define una función para personalizar los transportes que los clientes pueden usar para enviar solicitudes HTTP.
  • Use estas opciones en lugar de HttpConnectionDispatcherOptions.Transports para configurar los transportes.

Ejemplo

Puede configurar las opciones anteriores, como el código de ejemplo siguiente.

services.AddSignalR()
        .AddAzureSignalR(options =>
            {
                options.InitialHubServerConnectionCount = 10;
                options.AccessTokenLifetime = TimeSpan.FromDays(1);
                options.ClaimsProvider = context => context.User.Claims;

                options.GracefulShutdown.Mode = GracefulShutdownMode.WaitForClientsClose;
                options.GracefulShutdown.Timeout = TimeSpan.FromSeconds(10);
                options.TransportTypeDetector = httpContext => AspNetCore.Http.Connections.HttpTransportType.WebSockets | AspNetCore.Http.Connections.HttpTransportType.LongPolling;
            });

Para ASP.NET SignalR heredado

Nota:

Si es la primera vez que prueba SignalR, le recomendamos que use ASP.NET Core SignalR, es más sencillo, fiable y fácil de usar.

Instalación del SDK

Instale el SDK de SignalR Service en su proyecto de ASP.NET con la consola del administrador de paquetes:

Install-Package Microsoft.Azure.SignalR.AspNet

En la clase Startup, use el SDK de SignalR Service como fragmento de código siguiente, reemplace MapSignalR() por MapAzureSignalR({your_applicationName}). Reemplace {YourApplicationName} por el nombre de la aplicación, este es el nombre único para distinguir esta aplicación con las demás aplicaciones. Puede usar this.GetType().FullName como valor.

public void Configuration(IAppBuilder app)
{
    app.MapAzureSignalR(this.GetType().FullName);
}

Configurar cadena de conexión

Establezca la cadena de conexión en el archivo web.config en la sección connectionStrings:

<configuration>
    <connectionStrings>
        <add name="Azure:SignalR:ConnectionString" connectionString="Endpoint=...;AccessKey=..."/>
    </connectionStrings>
    ...
</configuration>

Configurar opciones

Hay algunas opciones que puede personalizar al usar el SDK de Azure SignalR Service.

ConnectionString

  • El valor predeterminado es Azure:SignalR:ConnectionStringconnectionString o appSetting en el archivo web.config.
  • Puede volver a configurarse, pero asegúrese de que el valor NO está codificado de forma rígida.

InitialHubServerConnectionCount

  • El valor predeterminado es 5.
  • Esta opción controla el recuento inicial de conexiones por centro entre el servidor de aplicaciones y Azure SignalR Service. Normalmente con mantenerlo como valor predeterminado es suficiente. Durante el tiempo de ejecución, el SDK podría iniciar nuevas conexiones de servidor para el ajuste del rendimiento o el equilibrio de carga. Cuando tiene un gran número de clientes, puede darle un número mayor para mejorar el rendimiento. Por ejemplo, si tiene 100 000 clientes en total, el recuento de conexiones se puede aumentar a 10 o 15.

MaxHubServerConnectionCount

  • El valor predeterminado es null.
  • Esta opción controla el recuento máximo de conexiones permitidas por centro entre el servidor de aplicaciones y Azure SignalR Service. Durante el tiempo de ejecución, el SDK podría iniciar nuevas conexiones de servidor para el ajuste del rendimiento o el equilibrio de carga. De forma predeterminada, se inicia una nueva conexión de servidor siempre que sea necesario. Cuando se configura el número máximo permitido de conexiones de servidor, el SDK no inicia nuevas conexiones cuando el número de conexiones de servidor alcanza el límite.

ApplicationName

  • El valor predeterminado es null.
  • Esta opción puede ser útil cuando desea compartir la misma instancia de Azure SignalR para distintos servidores de aplicaciones que contengan los mismos nombres de concentrador. Si no se establece, todos los servidores de aplicaciones conectados se consideran instancias de la misma aplicación.

ClaimProvider

  • El valor predeterminado es null.
  • Esta opción controla las notificaciones que desea asociar a la conexión de cliente. Se usa cuando el SDK de servicio genera el token de acceso para el cliente en la solicitud de negociación del cliente. De manera predeterminada, se reservan todas las notificaciones a de IOwinContext.Authentication.User de la solicitud negociada.
  • Normalmente, debe dejar esta opción tal como está. Asegúrese de comprender lo que sucede antes de personalizarla.

AccessTokenLifetime

  • El valor predeterminado es 1 hour.
  • Esta opción controla la vigencia válida del token de acceso, que el SDK de Service genera para cada cliente. El token de acceso se devuelve en la respuesta a la solicitud de negociación del cliente.
  • Cuando ServerSentEvent o LongPolling se usa como transporte, la conexión de cliente se cerrará debido a un error de autenticación después del tiempo expirado. Puede aumentar este valor para evitar la desconexión del cliente.

AccessTokenAlgorithm

  • El valor predeterminado es HS256.
  • Esta opción proporciona la opción de SecurityAlgorithms al generar el token de acceso. Ahora los valores opcionales admitidos son HS256 y HS512. Observe que HS512 es más seguro pero el token generado es relativamente más largo que usando HS256.

ServerStickyMode

  • El valor predeterminado es Disabled.
  • Esta opción especifica el modo para persistente del servidor. Cuando el cliente se enruta al servidor con el que negocia primero, lo llamamos persistente del servidor.
  • En escenarios distribuidos, puede haber varios servidores de aplicaciones conectados a una instancia de Azure SignalR. Como explica el apartado sobre los aspectos internos de las conexiones de cliente, el cliente negocia primero con el servidor de la aplicación y después redirige a Azure SignalR para establecer la conexión persistente. Azure SignalR encuentra después un servidor de aplicaciones para servir al cliente, como explica Transporte de datos entre el cliente y el servidor.
    • Cuando es Disabled, el cliente se enruta a un servidor de aplicaciones aleatorio. En general, los servidores de aplicaciones tienen conexiones de cliente equilibradas con este modo. Si sus escenarios son difusión o envío de grupo, con usar esta opción predeterminada es suficiente.
    • Cuando es Preferred, Azure SignalR intenta encontrar el servidor de aplicaciones con el que el cliente negocia por primera vez de forma que no se necesite ningún otro costo o enrutamiento global. Este puede ser útil cuando su escenario se envía a conexión*. Enviar a la conexión puede tener un mejor rendimiento y una menor latencia cuando el remitente y el receptor se enrutan al mismo servidor de aplicaciones.
    • Cuando es Required, Azure SignalR siempre intenta encontrar el servidor de aplicaciones con el que el cliente negocia primero. Esta opción puede ser útil cuando se obtiene algún contexto de cliente del paso negotiate y se almacena en memoria, para después usarlo dentro de Hubs. Sin embargo, esta opción puede tener inconvenientes de rendimiento, ya que requiere que Azure SignalR realice otros esfuerzos para encontrar globalmente este servidor de aplicación en particular, y para seguir enrutando globalmente el tráfico entre el cliente y el servidor.

MaxPollIntervalInSeconds

  • El valor predeterminado es 5.
  • Esta opción define el tiempo máximo de inactividad permitido para las conexiones inactivas en Azure SignalR Service. En ASP.NET SignalR, se aplica al tipo de transporte de sondeo largo o reconexión. Si la siguiente solicitud /reconnect o /poll no llega en MaxPollIntervalInSeconds, Azure SignalR Service limpia la conexión del cliente.
  • El valor está limitado a [1, 300].

Ejemplo

Puede configurar las opciones anteriores, como el código de ejemplo siguiente.

app.Map("/signalr",subApp => subApp.RunAzureSignalR(this.GetType().FullName, new HubConfiguration(), options =>
{
    options.InitialHubServerConnectionCount = 1;
    options.AccessTokenLifetime = TimeSpan.FromDays(1);
    options.ClaimProvider = context => context.Authentication?.User.Claims;
}));

Escalado horizontal del servidor de aplicaciones

Con Azure SignalR Service, las conexiones persistentes se descargan del servidor de aplicaciones para que pueda centrarse en implementar su lógica de negocios en las clases del centro. Pero todavía necesita escalar horizontalmente los servidores de aplicaciones para mejorar el rendimiento al controlar las conexiones de cliente masivas. A continuación se muestran algunas sugerencias para escalar horizontalmente los servidores de aplicaciones.

  • Varios servidores de aplicaciones pueden conectarse a la misma instancia de Azure SignalR Service.
  • Si quiere compartir la misma instancia de Azure SignalR para distintas aplicaciones que contengan los mismos nombres de centro, establézcalos con la opción ApplicationName diferente. Si no se establece, todos los servidores de aplicaciones conectados se consideran instancias de la misma aplicación.
  • Siempre que la opción ApplicationName y el nombre de la clase del centro sean iguales, las conexiones de diferentes servidores de aplicaciones se agruparán en el mismo centro.
  • Cada conexión de cliente solo se crea en uno de los servidores de aplicaciones y los mensajes de ese cliente solo se envían a ese mismo servidor de aplicaciones. Si quiere acceder a la información de los clientes de forma global (desde todos los servidores de aplicaciones), tendrá que usar algún almacenamiento centralizado para guardar la información de los clientes de todos los servidores de aplicaciones.

Pasos siguientes

En este artículo, se obtiene información sobre cómo usar SignalR Service en las aplicaciones. Consulte los artículos siguientes para obtener más información sobre SignalR Service.

Aspectos internos de Azure SignalR Service

Inicio rápido: creación de una sala de chat con SignalR Service