Compartir a través de

Escalado de SignalR Service con varias instancias

  • Artículo

El SDK de SignalR Service admite varios puntos de conexión para las instancias de SignalR Service. Puede usar esta característica para escalar las conexiones simultáneas, o usarla para la mensajería entre regiones.

Para ASP.NET Core

Adición de varios puntos de conexión desde la configuración

Configure con la clave Azure:SignalR:ConnectionString o Azure:SignalR:ConnectionString: para la cadena de conexión de SignalR Service.

Si la clave comienza con Azure:SignalR:ConnectionString:, debe tener el formato Azure:SignalR:ConnectionString:{Name}:{EndpointType}, donde Name y EndpointType son propiedades del objeto ServiceEndpoint y son accesibles desde el código.

Puede agregar varias cadenas de conexión de instancias con los siguientes comandos dotnet:

dotnet user-secrets set Azure:SignalR:ConnectionString:east-region-a <ConnectionString1>
dotnet user-secrets set Azure:SignalR:ConnectionString:east-region-b:primary <ConnectionString2>
dotnet user-secrets set Azure:SignalR:ConnectionString:backup:secondary <ConnectionString3>

Adición de varios puntos de conexión desde el código

Una clase ServiceEndpoint describe las propiedades de un punto de conexión de Azure SignalR Service. Puede configurar varios puntos de conexión de instancia al usar el SDK de Azure SignalR Service mediante:

services.AddSignalR()
        .AddAzureSignalR(options =>
        {
            options.Endpoints = new ServiceEndpoint[]
            {
                // Note: this is just a demonstration of how to set options.Endpoints
                // Having ConnectionStrings explicitly set inside the code is not encouraged
                // You can fetch it from a safe place such as Azure KeyVault
                new ServiceEndpoint("<ConnectionString0>"),
                new ServiceEndpoint("<ConnectionString1>", type: EndpointType.Primary, name: "east-region-a"),
                new ServiceEndpoint("<ConnectionString2>", type: EndpointType.Primary, name: "east-region-b"),
                new ServiceEndpoint("<ConnectionString3>", type: EndpointType.Secondary, name: "backup"),
            };
        });

Personalización del enrutador de punto de conexión

De forma predeterminada, el SDK usa DefaultEndpointRouter para seleccionar los puntos de conexión.

Comportamiento predeterminado

  1. Enrutamiento de solicitudes de cliente:

    Cuando el cliente negocia (acción /negotiate) con el servidor de aplicaciones. De forma predeterminada, el SDK selecciona aleatoriamente un punto de conexión del conjunto de puntos de conexión de servicio disponibles.

  2. Enrutamiento de mensajes del servidor:

    Cuando se envía un mensaje a una conexión específica y la conexión de destino está enrutada al servidor actual, el mensaje va directamente a ese punto de conexión conectado. En caso contrario, los mensajes se difunden a cada punto de conexión de Azure SignalR.

Personalización del algoritmo de enrutamiento

Puede crear su propio enrutador cuando tenga conocimientos especiales para identificar los puntos de conexión a los que deberían ir los mensajes.

En el ejemplo siguiente se define un enrutador personalizado que enruta los mensajes con un grupo a partir de east- al punto de conexión denominado east:

private class CustomRouter : EndpointRouterDecorator
{
    public override IEnumerable<ServiceEndpoint> GetEndpointsForGroup(string groupName, IEnumerable<ServiceEndpoint> endpoints)
    {
        // Override the group broadcast behavior, if the group name starts with "east-", only send messages to endpoints inside east
        if (groupName.StartsWith("east-"))
        {
            return endpoints.Where(e => e.Name.StartsWith("east-"));
        }

        return base.GetEndpointsForGroup(groupName, endpoints);
    }
}

En el ejemplo siguiente se invalida el comportamiento de negociación predeterminado y se selecciona el punto de conexión en función de la ubicación del servidor de aplicaciones.

private class CustomRouter : EndpointRouterDecorator
{    public override ServiceEndpoint GetNegotiateEndpoint(HttpContext context, IEnumerable<ServiceEndpoint> endpoints)
    {
        // Override the negotiate behavior to get the endpoint from query string
        var endpointName = context.Request.Query["endpoint"];
        if (endpointName.Count == 0)
        {
            context.Response.StatusCode = 400;
            var response = Encoding.UTF8.GetBytes("Invalid request");
            context.Response.Body.Write(response, 0, response.Length);
            return null;
        }

        return endpoints.FirstOrDefault(s => s.Name == endpointName && s.Online) // Get the endpoint with name matching the incoming request
               ?? base.GetNegotiateEndpoint(context, endpoints); // Or fallback to the default behavior to randomly select one from primary endpoints, or fallback to secondary when no primary ones are online
    }
}

No olvide registrar el enrutador en el contenedor de DI mediante:

services.AddSingleton(typeof(IEndpointRouter), typeof(CustomRouter));
services.AddSignalR()
        .AddAzureSignalR(
            options =>
            {
                options.Endpoints = new ServiceEndpoint[]
                {
                    new ServiceEndpoint(name: "east", connectionString: "<connectionString1>"),
                    new ServiceEndpoint(name: "west", connectionString: "<connectionString2>"),
                    new ServiceEndpoint("<connectionString3>")
                };
            });

Para ASP.NET

Adición de varios puntos de conexión desde la configuración

Configuración con clave Azure:SignalR:ConnectionString o Azure:SignalR:ConnectionString: para la cadena de conexión de SignalR Service.

Si la clave empieza por Azure:SignalR:ConnectionString:, debe estar en formato Azure:SignalR:ConnectionString:{Name}:{EndpointType}, donde Name y EndpointType son propiedades del objeto ServiceEndpoint y son accesibles desde el código.

Puede agregar varias cadenas de conexión de instancia a web.config:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <connectionStrings>
    <add name="Azure:SignalR:ConnectionString" connectionString="<ConnectionString1>"/>
    <add name="Azure:SignalR:ConnectionString:en-us" connectionString="<ConnectionString2>"/>
    <add name="Azure:SignalR:ConnectionString:zh-cn:secondary" connectionString="<ConnectionString3>"/>
    <add name="Azure:SignalR:ConnectionString:Backup:secondary" connectionString="<ConnectionString4>"/>
  </connectionStrings>
  ...
</configuration>

Adición de varios puntos de conexión desde el código

Una clase ServiceEndpoint describe las propiedades de un punto de conexión de Azure SignalR Service. Puede configurar varios puntos de conexión de instancia al usar el SDK de Azure SignalR Service mediante:

app.MapAzureSignalR(
    this.GetType().FullName,
    options => {
            options.Endpoints = new ServiceEndpoint[]
            {
                // Note: this is just a demonstration of how to set options. Endpoints
                // Having ConnectionStrings explicitly set inside the code is not encouraged.
                // You can fetch it from a safe place such as Azure KeyVault
                new ServiceEndpoint("<ConnectionString1>"),
                new ServiceEndpoint("<ConnectionString2>"),
                new ServiceEndpoint("<ConnectionString3>"),
            }
        });

Personalización de un enrutador

La única diferencia entre ASP.NET SignalR y ASP.NET Core SignalR es el tipo de contexto http para GetNegotiateEndpoint. En ASP.NET SignalR, es de tipo IOwinContext.

El código siguiente es un ejemplo de negociación personalizado para ASP.NET SignalR:

private class CustomRouter : EndpointRouterDecorator
{
    public override ServiceEndpoint GetNegotiateEndpoint(IOwinContext context, IEnumerable<ServiceEndpoint> endpoints)
    {
        // Override the negotiate behavior to get the endpoint from query string
        var endpointName = context.Request.Query["endpoint"];
        if (string.IsNullOrEmpty(endpointName))
        {
            context.Response.StatusCode = 400;
            context.Response.Write("Invalid request.");
            return null;
        }

        return endpoints.FirstOrDefault(s => s.Name == endpointName && s.Online) // Get the endpoint with name matching the incoming request
               ?? base.GetNegotiateEndpoint(context, endpoints); // Or fallback to the default behavior to randomly select one from primary endpoints, or fallback to secondary when no primary ones are online
    }
}

No olvide registrar el enrutador en el contenedor de DI mediante:

var hub = new HubConfiguration();
var router = new CustomRouter();
hub.Resolver.Register(typeof(IEndpointRouter), () => router);
app.MapAzureSignalR(GetType().FullName, hub, options => {
    options.Endpoints = new ServiceEndpoint[]
                {
                    new ServiceEndpoint(name: "east", connectionString: "<connectionString1>"),
                    new ServiceEndpoint(name: "west", connectionString: "<connectionString2>"),
                    new ServiceEndpoint("<connectionString3>")
                };
});

Métricas de punto de conexión de servicio

Para habilitar un enrutador avanzado, el SDK del servidor SignalR proporciona varias métricas para ayudar al servidor a tomar decisiones inteligentes. Las propiedades están en ServiceEndpoint.EndpointMetrics.

Nombre de la métrica Descripción
ClientConnectionCount Recuento total de conexiones de cliente simultáneas en todos los centros para el punto de conexión de servicio
ServerConnectionCount Recuento total de conexiones de servidor simultáneas en todos los centros para el punto de conexión de servicio
ConnectionCapacity Cuota de conexión total para el punto de conexión de servicio, incluidas las conexiones de cliente y servidor

El código siguiente es un ejemplo de personalización de un enrutador según ClientConnectionCount.

private class CustomRouter : EndpointRouterDecorator
{
    public override ServiceEndpoint GetNegotiateEndpoint(HttpContext context, IEnumerable<ServiceEndpoint> endpoints)
    {
        return endpoints.OrderBy(x => x.EndpointMetrics.ClientConnectionCount).FirstOrDefault(x => x.Online) // Get the available endpoint with minimal clients load
               ?? base.GetNegotiateEndpoint(context, endpoints); // Or fallback to the default behavior to randomly select one from primary endpoints, or fallback to secondary when no primary ones are online
    }
}

ServiceEndpoints de escalado dinámico

Desde la versión 1.5.0 del SDK, habilitamos ServiceEndpoints de escalado dinámico para la primera versión de ASP.NET Core. Por lo tanto, no tiene que reiniciar el servidor de aplicaciones cuando necesite agregar o quitar un ServiceEndpoint. Puesto que ASP.NET Core admite una configuración predeterminada, como appsettings.json con reloadOnChange: true, no es necesario cambiar ningún código y es compatible por naturaleza. Y si desea agregar alguna configuración personalizada y trabajar con recarga activa, consulte Configuración en ASP.NET Core.

Nota:

Teniendo en cuenta el tiempo de configuración de la conexión entre el servidor, el servicio y el cliente o el servicio pueden ser diferentes, para garantizar que no se pierda ningún mensaje durante el proceso de escalado, tenemos un período de almacenamiento provisional en espera de que las conexiones del servidor estén listas antes de abrir el nuevo ServiceEndpoint a los clientes. Normalmente, tarda segundos en completarse y podrá ver un mensaje de registro como Succeed in adding endpoint: '{endpoint}' que indica que el proceso se ha completado.

En algunas situaciones esperadas, como problemas de red entre regiones o incoherencias de configuración en distintos servidores de aplicaciones, es posible que el período de proceso de almacenamiento provisional no finalice correctamente. En estos casos, se recomienda reiniciar el servidor de aplicaciones cuando encuentre que el proceso de escalado no funciona correctamente.

El período de tiempo de espera predeterminado para la escala es de 5 minutos y se puede personalizar cambiando el valor de ServiceOptions.ServiceScaleTimeout. Si tiene muchos servidores de aplicaciones, se recomienda ampliar el valor un poco más.

Nota:

Actualmente, la característica de varios puntos de conexión solo se admite en el tipo de transporte Persistent.

Para extensiones de SignalR Functions

Configuración

Para habilitar varias instancias de SignalR Service, debe:

  1. Usar el tipo de transporte Persistent.

    El tipo de transporte predeterminado es el modo Transient. Debe agregar la siguiente entrada al archivo local.settings.json o la configuración de la aplicación en Azure.

    {
    "AzureSignalRServiceTransportType":"Persistent"
}

    Nota:

    Al cambiar del modo Transient al modo Persistent, puede haber un cambio de comportamiento de serialización JSON, ya que en el modo Transient, la biblioteca Newtonsoft.Json se usa para serializar argumentos de métodos concentradores, sin embargo, en el modo Persistent, se usa la biblioteca System.Text.Json como valor predeterminado. System.Text.Json tiene algunas diferencias clave en el comportamiento predeterminado con Newtonsoft.Json. Si quiere usar Newtonsoft.Json en el modo Persistent, puede agregar un elemento de configuración: "Azure:SignalR:HubProtocol":"NewtonsoftJson" en el archivo local.settings.json o Azure__SignalR__HubProtocol=NewtonsoftJson en Azure Portal.

  2. Configure varias entradas de puntos de conexión de SignalR Service en la configuración.

    Usamos un objeto ServiceEndpoint para representar una instancia de SignalR Service. Puede definir un punto de conexión de servicio con su <EndpointName> y <EndpointType> en la clave de entrada y la cadena de conexión en el valor de entrada. Las claves tienen el siguiente formato:

    Azure:SignalR:Endpoints:<EndpointName>:<EndpointType>

    <EndpointType> es opcional y el valor predeterminado es primary. Consulte los siguientes ejemplos:

    {
    "Azure:SignalR:Endpoints:EastUs":"<ConnectionString>",

    "Azure:SignalR:Endpoints:EastUs2:Secondary":"<ConnectionString>",

    "Azure:SignalR:Endpoints:WestUs:Primary":"<ConnectionString>"
}

    Nota:

    • Al configurar puntos de conexión de Azure SignalR en App Service en Azure Portal, no olvide reemplazar ":" por "__", el doble guion bajo en las claves. Para obtener más información, consulte Variables de entorno.

    • La cadena de conexión configurada con la clave {ConnectionStringSetting} (el valor predeterminado es "AzureSignalRConnectionString") también se reconoce como punto de conexión de servicio principal con el nombre vacío. Pero este estilo de configuración no se recomienda para varios puntos de conexión.

Enrutamiento

Comportamiento predeterminado

De forma predeterminada, el enlace de funciones usa DefaultEndpointRouter para seleccionar puntos de conexión.

  • Enrutamiento de cliente: seleccione aleatoriamente un punto de conexión de los puntos de conexión en línea principales. Si todos los puntos de conexión principales están sin conexión, seleccione aleatoriamente un punto de conexión en línea secundario. Si se produce un error en la selección de nuevo, se produce una excepción.

  • Enrutamiento de mensajes del servidor: se devuelven todos los puntos de conexión de servicio.

Personalización

Modelo en proceso de C#

Estos son los pasos que debe realizar:

  1. Implemente un enrutador personalizado. Puede aprovechar la información proporcionada desde ServiceEndpoint para tomar la decisión de enrutamiento. Consulte la guía aquí: customize-route-algorithm. Tenga en cuenta que el desencadenador Http es necesario en la función de negociación cuando necesite HttpContext en el método de negociación personalizado.

  2. Registre el enrutador en el contenedor de inserción de dependencias.

using Microsoft.Azure.Functions.Extensions.DependencyInjection;
using Microsoft.Azure.SignalR;
using Microsoft.Extensions.DependencyInjection;

[assembly: FunctionsStartup(typeof(SimpleChatV3.Startup))]
namespace SimpleChatV3
{
    public class Startup : FunctionsStartup
    {
        public override void Configure(IFunctionsHostBuilder builder)
        {
            builder.Services.AddSingleton<IEndpointRouter, CustomizedRouter>();
        }
    }
}
Modelo de proceso aislado

En el caso de las funciones que se ejecutan en el modelo de proceso aislado, se admite la especificación de puntos de conexión de destino en cada solicitud. Usará nuevos tipos de enlace para obtener información del punto de conexión.

Enrutamiento del cliente

El enlace SignalRConnectionInfo selecciona un punto de conexión según la regla de enrutamiento predeterminada. Si desea personalizar la regla de enrutamiento, debe usar el enlace SignalRNegotiation en lugar del enlace SignalRConnectionInfo.

Las propiedades de configuración de enlace SignalRNegotiation son las mismas que SignalRConnectionInfo. Este es un ejemplo de archivo function.json:

{
    "type": "signalRNegotiation",
    "name": "negotiationContext",
    "hubName": "<HubName>",
    "direction": "in"
}

También puede agregar otros datos de enlace, como userId, idToken y claimTypeList al igual que SignalRConnectionInfo.

El objeto que obtiene del enlace SignalRNegotiation tiene el siguiente formato:

{
    "endpoints": [
        {
            "endpointType": "Primary",
            "name": "<EndpointName>",
            "endpoint": "https://****.service.signalr.net",
            "online": true,
            "connectionInfo": {
                "url": "<client-access-url>",
                "accessToken": "<client-access-token>"
            }
        },
        {
            "...": "..."
        }
    ]
}

Este es un ejemplo de uso de JavaScript de enlace SignalRNegotiation:

module.exports = function (context, req, negotiationContext) {
    var userId = req.query.userId;
    if (userId.startsWith("east-")) {
        //return the first endpoint whose name starts with "east-" and status is online.
        context.res.body = negotiationContext.endpoints.find(endpoint => endpoint.name.startsWith("east-") && endpoint.online).connectionInfo;
    }
    else {
        //return the first online endpoint
        context.res.body = negotiationContext.endpoints.filter(endpoint => endpoint.online)[0].connectionInfo;
    }
}
Enrutamiento de mensajes

El enrutamiento de mensajes o acciones necesita que cooperen dos tipos de enlace. En general, primero necesita un nuevo tipo de enlace de entrada SignalREndpoints para obtener toda la información del punto de conexión disponible. A continuación, filtre los puntos de conexión y obtenga una matriz que contenga todos los puntos de conexión a los que desea enviar. Por último, especifique los puntos de conexión de destino en el enlace de salida SignalR.

Estas son las propiedades de configuración de enlace SignalREndpoints del archivo functions.json:

{
      "type": "signalREndpoints",
      "direction": "in",
      "name": "endpoints",
      "hubName": "<HubName>"
}

El objeto que obtiene de SignalREndpoints es una matriz de puntos de conexión, cada uno de los cuales se representa como un objeto JSON con el esquema siguiente:

{
    "endpointType": "<EndpointType>",
    "name": "<EndpointName>",
    "endpoint": "https://****.service.signalr.net",
    "online": true
}

Después de obtener la matriz de puntos de conexión de destino, agregue una propiedad endpoints al objeto de enlace de salida. Este es un ejemplo de JavaScript:

module.exports = function (context, req, endpoints) {
    var targetEndpoints = endpoints.filter(endpoint => endpoint.name.startsWith("east-"));
    context.bindings.signalRMessages = [{
        "target": "chat",
        "arguments": ["hello-world"],
        "endpoints": targetEndpoints,
    }];
    context.done();
}

Para Administración del SDK

Adición de varios puntos de conexión desde la configuración

Configure con la clave Azure:SignalR:Endpoints para la cadena de conexión de SignalR Service. La clave debe tener el formato Azure:SignalR:Endpoints:{Name}:{EndpointType}, donde Name y EndpointType son propiedades del objeto ServiceEndpoint y son accesibles desde el código.

Puede agregar varias cadenas de conexión de instancias con los siguientes comandos dotnet:

dotnet user-secrets set Azure:SignalR:Endpoints:east-region-a <ConnectionString1>
dotnet user-secrets set Azure:SignalR:Endpoints:east-region-b:primary <ConnectionString2>
dotnet user-secrets set Azure:SignalR:Endpoints:backup:secondary <ConnectionString3>

Adición de varios puntos de conexión desde el código

Una clase ServiceEndpoint describe las propiedades de un punto de conexión de Azure SignalR Service. Puede configurar varios puntos de conexión de instancia al usar el SDK de administración de Azure SignalR mediante:

var serviceManager = new ServiceManagerBuilder()
                    .WithOptions(option =>
                    {
                        options.Endpoints = new ServiceEndpoint[]
                        {
                            // Note: this is just a demonstration of how to set options.Endpoints
                            // Having ConnectionStrings explicitly set inside the code is not encouraged
                            // You can fetch it from a safe place such as Azure KeyVault
                            new ServiceEndpoint("<ConnectionString0>"),
                            new ServiceEndpoint("<ConnectionString1>", type: EndpointType.Primary, name: "east-region-a"),
                            new ServiceEndpoint("<ConnectionString2>", type: EndpointType.Primary, name: "east-region-b"),
                            new ServiceEndpoint("<ConnectionString3>", type: EndpointType.Secondary, name: "backup"),
                        };
                    })
                    .BuildServiceManager();

Personalización del enrutador de punto de conexión

De forma predeterminada, el SDK usa DefaultEndpointRouter para seleccionar los puntos de conexión.

Comportamiento predeterminado

  • Enrutamiento de solicitudes de cliente:

    Cuando el cliente negocia (acción /negotiate) con el servidor de aplicaciones. De forma predeterminada, el SDK selecciona aleatoriamente un punto de conexión del conjunto de puntos de conexión de servicio disponibles.

  • Enrutamiento de mensajes del servidor:

    Cuando se envía un mensaje a una conexión específica y la conexión de destino está enrutada al servidor actual, el mensaje va directamente a ese punto de conexión conectado. En caso contrario, los mensajes se difunden a cada punto de conexión de Azure SignalR.

Personalización del algoritmo de enrutamiento

Puede crear su propio enrutador cuando tenga conocimientos especiales para identificar los puntos de conexión a los que deberían ir los mensajes.

En el ejemplo siguiente se define un enrutador personalizado que enruta los mensajes con un grupo a partir de east- al punto de conexión denominado east:

private class CustomRouter : EndpointRouterDecorator
{
    public override IEnumerable<ServiceEndpoint> GetEndpointsForGroup(string groupName, IEnumerable<ServiceEndpoint> endpoints)
    {
        // Override the group broadcast behavior, if the group name starts with "east-", only send messages to endpoints inside east
        if (groupName.StartsWith("east-"))
        {
            return endpoints.Where(e => e.Name.StartsWith("east-"));
        }

        return base.GetEndpointsForGroup(groupName, endpoints);
    }
}

En el ejemplo siguiente se invalida el comportamiento de negociación predeterminado y se selecciona el punto de conexión en función de la ubicación del servidor de aplicaciones.

private class CustomRouter : EndpointRouterDecorator
{    public override ServiceEndpoint GetNegotiateEndpoint(HttpContext context, IEnumerable<ServiceEndpoint> endpoints)
    {
        // Override the negotiate behavior to get the endpoint from query string
        var endpointName = context.Request.Query["endpoint"];
        if (endpointName.Count == 0)
        {
            context.Response.StatusCode = 400;
            var response = Encoding.UTF8.GetBytes("Invalid request");
            context.Response.Body.Write(response, 0, response.Length);
            return null;
        }

        return endpoints.FirstOrDefault(s => s.Name == endpointName && s.Online) // Get the endpoint with name matching the incoming request
               ?? base.GetNegotiateEndpoint(context, endpoints); // Or fallback to the default behavior to randomly select one from primary endpoints, or fallback to secondary when no primary ones are online
    }
}

No olvide registrar el enrutador en el contenedor de DI mediante:

var serviceManager = new ServiceManagerBuilder()
                    .WithOptions(option =>
                    {
                        options.Endpoints = new ServiceEndpoint[]
                        {
                            // Note: this is just a demonstration of how to set options.Endpoints
                            // Having ConnectionStrings explicitly set inside the code is not encouraged
                            // You can fetch it from a safe place such as Azure KeyVault
                            new ServiceEndpoint("<ConnectionString0>"),
                            new ServiceEndpoint("<ConnectionString1>", type: EndpointType.Primary, name: "east-region-a"),
                            new ServiceEndpoint("<ConnectionString2>", type: EndpointType.Primary, name: "east-region-b"),
                            new ServiceEndpoint("<ConnectionString3>", type: EndpointType.Secondary, name: "backup"),
                        };
                    })
                    .WithRouter(new CustomRouter())
                    .BuildServiceManager();

Configuración en escenarios entre regiones

El objeto ServiceEndpoint tiene una propiedad EndpointType con valor primary o secondary.

Los puntos de conexión principales son puntos de conexión preferidos para recibir tráfico de cliente porque tienen conexiones de red más confiables. Los puntos de conexión secundarios tienen conexiones de red menos confiables y solo se usan para el tráfico del servidor al cliente. Por ejemplo, los puntos de conexión secundarios se usan para difundir mensajes en lugar de para el tráfico de cliente al servidor.

En casos entre regiones, la red puede ser inestable. Para un servidor de aplicaciones ubicado en Este de EE. UU., el punto de conexión de SignalR Service ubicado en la misma región Este de EE. UU. es primary y los puntos de conexión de otras regiones marcadas como secondary. En esta configuración, los puntos de conexión de servicio de otras regiones pueden recibir mensajes de este servidor de aplicaciones de Este de EE. UU., pero no habrá ningún cliente entre regiones enrutado a este servidor de aplicaciones. En el siguiente diagrama se muestra la arquitectura:

Infraestructura entre regiones geográficas

Cuando un cliente intenta /negotiate con el servidor de aplicaciones con un enrutador predeterminado, el SDK selecciona aleatoriamente un punto de conexión del conjunto de puntos de conexión de primary disponibles. Cuando el punto de conexión principal no está disponible, el SDK selecciona aleatoriamente de todos los puntos de conexión de secondary disponibles. El punto de conexión se marca como disponible cuando la conexión entre el servidor y el punto de conexión de servicio está activa.

En un escenario entre regiones, cuando un cliente intenta /negotiate con el servidor de aplicaciones hospedado en Este de EE. UU., de manera predeterminada siempre devuelve el punto de conexión de primary ubicado en la misma región. Cuando todos los puntos de conexión de Este de EE. UU. no están disponibles, el enrutador redirige el cliente a los puntos de conexión de otras regiones. En la siguiente sección de conmutación por error se describe el escenario en detalle.

Negociación normal

Conmutación por error

Cuando no hay ningún punto de conexión primary disponible, el cliente /negotiate elige entre los puntos de conexión de secondary disponibles. Este mecanismo de conmutación por error requiere que cada punto de conexión actúe como un punto de conexión primary para al menos un servidor de aplicaciones.

Diagrama que muestra el proceso del mecanismo de conmutación por error.

Pasos siguientes

Puede usar varios puntos de conexión en escenarios de alta disponibilidad y recuperación ante desastres.

Configuración de SignalR Service para la recuperación ante desastres y la alta disponibilidad