Sdílet prostřednictvím

Škálování služby SignalR s několika instancemi

Sada SIGNALR Service SDK podporuje více koncových bodů pro instance služby SignalR. Pomocí této funkce můžete škálovat souběžná připojení nebo ji použít pro zasílání zpráv mezi oblastmi.

Důležité

Nezpracovaný připojovací řetězec se v tomto článku zobrazuje jenom pro demonstrační účely.

Připojovací řetězec obsahuje autorizační informace potřebné pro vaši aplikaci pro přístup ke službě Azure SignalR. Přístupový klíč uvnitř připojovací řetězec je podobný kořenovému heslu pro vaši službu. V produkčních prostředích vždy chraňte přístupové klíče. Pomocí služby Azure Key Vault můžete bezpečně spravovat a obměňovat klíče a zabezpečit připojovací řetězec pomocí ID Microsoft Entra a autorizovat přístup pomocí Microsoft Entra ID.

Vyhněte se distribuci přístupových klíčů ostatním uživatelům, jejich pevnému kódování nebo jejich uložení kdekoli ve formátu prostého textu, který je přístupný ostatním uživatelům. Otočte klíče, pokud se domníváte, že mohly být ohroženy.

Pro ASP.NET Core

Přidat více koncových bodů z konfigurace

Surové připojovací řetězce se v tomto článku zobrazují jen pro demonstrační účely. V produkčních prostředích vždy chraňte přístupové klíče. Pomocí služby Azure Key Vault můžete bezpečně spravovat a obměňovat klíče a zabezpečit připojovací řetězec pomocí ID Microsoft Entra a autorizovat přístup pomocí Microsoft Entra ID.

Nakonfigurujte klíč Azure:SignalR:ConnectionString nebo Azure:SignalR:ConnectionString: pro připojovací řetězec služby SignalR.

Pokud klíč začíná Azure:SignalR:ConnectionString:, měl by být ve formátu Azure:SignalR:ConnectionString:{Name}:{EndpointType}, kde Name a EndpointType jsou vlastnosti objektu ServiceEndpoint a jsou přístupné z kódu.

Pomocí následujících dotnet příkazů můžete přidat připojovací řetězce instancí:

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>

Přidání několika koncových bodů pomocí kódu

Třída ServiceEndpoint popisuje vlastnosti koncového bodu služby Azure SignalR. Při použití sady SDK služby Azure SignalR můžete nakonfigurovat více koncových bodů instance prostřednictvím:

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"),
            };
        });

Přizpůsobit směrovač koncového bodu

Ve výchozím nastavení sada SDK k vyzvednutí koncových bodů používá DefaultEndpointRouter .

Výchozí chování

  1. Směrování požadavků klienta:

    Když se klient /negotiate spojí se serverem aplikace. Sada SDK ve výchozím nastavení náhodně vybere jeden koncový bod ze sady dostupných koncových bodů služby.

  2. Směrování zpráv serveru:

    Při odesílání zprávy do konkrétního připojení a cílové připojení je směrováno na aktuální server, zpráva přejde přímo do daného připojeného koncového bodu. Jinak se zprávy vysílají do každého koncového bodu Azure SignalR.

Přizpůsobení algoritmu směrování

Vlastní směrovač můžete vytvořit, když máte speciální znalosti, abyste zjistili, na které koncové body mají zprávy přejít.

Následující příklad definuje vlastní směrovač, který směruje zprávy se skupinou začínající east- na koncový bod s názvem 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);
    }
}

Následující příklad přepíše výchozí chování vyjednávání a vybere koncový bod v závislosti na umístění aplikačního serveru.

private class CustomRouter : EndpointRouterDecorator
{    public override ServiceEndpoint GetNegotiateEndpoint(HttpContext context, IEnumerable<ServiceEndpoint> endpoints)
    {
          // Sample code showing how to choose endpoints based on the incoming request endpoint query
          var endpointName = context.Request.Query["endpoint"].FirstOrDefault() ?? "";
          // Select from the available endpoints, don't construct a new ServiceEndpoint object here
          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
    }
}

Nezapomeňte zaregistrovat směrovač do kontejneru DI pomocí:

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>")
                };
            });

ServiceOptions.Endpoints podporuje také opětovné načítání za provozu. Následující ukázkový kód ukazuje, jak načíst připojovací řetězce z jedné konfigurační části a veřejné adresy URL vystavené reverzními proxy servery z jiné konfigurační části, a pokud konfigurace podporuje dynamické načítání, mohou se koncové body aktualizovat za běhu.

services.Configure<ServiceOptions>(o =>
{
        o.Endpoints = [
            new ServiceEndpoint(Configuration["ConnectionStrings:AzureSignalR:East"], name: "east")
            {
                ClientEndpoint = new Uri(Configuration.GetValue<string>("PublicClientEndpoints:East"))
            },
            new ServiceEndpoint(Configuration["ConnectionStrings:AzureSignalR:West"], name: "west")
            {
                ClientEndpoint = new Uri(Configuration.GetValue<string>("PublicClientEndpoints:West"))
            },
        ];
});

Pro ASP.NET

Přidejte několik koncových bodů z konfigurace

Konfigurace s klíčem Azure:SignalR:ConnectionString nebo Azure:SignalR:ConnectionString: pro připojovací řetězec služby SignalR Service.

Pokud klíč začíná Azure:SignalR:ConnectionString:, měl by být ve formátu Azure:SignalR:ConnectionString:{Name}:{EndpointType}, kde Name a EndpointType jsou vlastnosti objektu ServiceEndpoint a jsou přístupné z kódu.

Můžete přidat více připojovacích řetězců instancí kweb.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>

Přidání několika koncových bodů z kódu

Třída ServiceEndpoint popisuje vlastnosti koncového bodu služby Azure SignalR. Při použití sady SDK služby Azure SignalR můžete nakonfigurovat více koncových bodů instance prostřednictvím:

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>"),
            }
        });

Přizpůsobte směrovač

Jediný rozdíl mezi ASP.NET SignalR a ASP.NET Core SignalR je typ kontextu http pro GetNegotiateEndpoint. Pro ASP.NET SignalR se jedná o typ IOwinContext .

Následující kód je vlastní příklad vyjednávání pro ASP.NET SignalR:

private class CustomRouter : EndpointRouterDecorator
{
    public override ServiceEndpoint GetNegotiateEndpoint(IOwinContext context, IEnumerable<ServiceEndpoint> endpoints)
    {
        // Sample code showing how to choose endpoints based on the incoming request endpoint query
        var endpointName = context.Request.Query["endpoint"] ?? "";
        // Select from the available endpoints, don't construct a new ServiceEndpoint object here
        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
    }
}

Nezapomeňte zaregistrovat směrovač do kontejneru DI pomocí:

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>")
                };
});

Metriky koncového bodu služby

Pokud chcete povolit pokročilý směrovač, sada SDK serveru SignalR poskytuje více metrik, které serveru pomáhají při inteligentních rozhodnutích. Vlastnosti jsou pod položkou ServiceEndpoint.EndpointMetrics.

Název metriky Popis
ClientConnectionCount Celkový počet souběžných klientských připojení ve všech centrech pro koncový bod služby
ServerConnectionCount Celkový počet souběžných připojení k serveru ve všech centrech koncového bodu služby
ConnectionCapacity Celková kvóta připojení pro koncový bod služby, včetně připojení klienta a serveru

Následující kód je příkladem přizpůsobení směrovače podle 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
    }
}

Dynamické škálování koncových bodů služby

Ze sady SDK verze 1.5.0 nejprve povolujeme dynamické škálování ServiceEndpoints pro verzi ASP.NET Core. Proto nemusíte restartovat aplikační server, když potřebujete přidat nebo odebrat ServiceEndpoint. Vzhledem k tomu, že ASP.NET Core podporuje výchozí konfiguraci, jako je tomu appsettings.json u reloadOnChange: true, nemusíte měnit kód a podporuje ho příroda. A pokud chcete přidat vlastní konfiguraci a pracovat s opětovným načítáním za provozu, podívejte se na konfiguraci v ASP.NET Core.

Poznámka:

Vzhledem k tomu, že doba nastavení připojení mezi serverem, službou a klientem nebo službou se může lišit, abychom zajistili, že během procesu škálování nedojde ke ztrátě zpráv, čekáme na přípravu připojení k serveru před otevřením nového serviceEndpointu klientům. Dokončení obvykle trvá několik sekund a uvidíte zprávu v protokolu, například Succeed in adding endpoint: '{endpoint}', která naznačuje, že proces byl dokončen.

V některých očekávaných situacích, jako jsou problémy sítě mezi regiony nebo nekonzistence konfigurací na různých aplikačních serverech, nemusí fáze přípravy správně dokončit. V těchto případech se doporučuje restartovat aplikační server, když zjistíte, že proces škálování nefunguje správně.

Výchozí časový limit pro měřítko je 5 minut a dá se přizpůsobit změnou hodnoty v ServiceOptions.ServiceScaleTimeout. Pokud máte hodně aplikačních serverů, doporučuje se hodnotu trochu zvýšit.

Poznámka:

Funkce více koncových bodů je v současné době podporována pouze u Persistent typu přenosu.

Pro rozšíření SignalR Functions

Konfigurace

Pokud chcete povolit více instancí služby SignalR, měli byste:

  1. Použijte Persistent typ přenosu.

    Výchozí typ přenosu je Transient režim. Do souboru nebo nastavení aplikace v local.settings.json Azure byste měli přidat následující položku.

    {
    "AzureSignalRServiceTransportType":"Persistent"
}

    Poznámka:

    Při přechodu z Transient režimu do Persistent režimu může dojít ke změně chování serializace JSON, protože v Transient režimu se Newtonsoft.Json knihovna používá k serializaci argumentů metod hubu, ale v Persistent režimu se System.Text.Json knihovna používá jako výchozí. System.Text.Json má některé klíčové rozdíly ve výchozím chování s Newtonsoft.Json. Pokud chcete použít Newtonsoft.Json v režimu Persistent, můžete přidat položku konfigurace: "Azure:SignalR:HubProtocol":"NewtonsoftJson" v local.settings.json souboru nebo Azure__SignalR__HubProtocol=NewtonsoftJson v Azure portálu.

  2. Nakonfigurujte více položek koncových bodů služby SignalR ve vaší konfiguraci.

    Objekt používáme ServiceEndpoint k reprezentaci instance služby SignalR. Koncový bod služby můžete definovat pomocí jeho <EndpointName> a <EndpointType> ve vstupním klíči a připojovacího řetězce ve vstupní hodnotě. Klíče jsou v následujícím formátu:

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

    <EndpointType> je nepovinný a výchozí hodnota primaryje . Projděte si následující ukázky:

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

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

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

    Poznámka:

    • Při konfiguraci koncových bodů Azure SignalR ve službě App Service na portálu Azure nezapomeňte nahradit klávesu ":" klávesou "__", čili dvojitým podtržítkem v klíčích. Pro důvody viz proměnné prostředí.

    • Připojovací řetězec nakonfigurovaný s klíčem {ConnectionStringSetting} (výchozí hodnota je AzureSignalRConnectionString) se také rozpozná jako primární koncový bod služby s prázdným názvem. Tento styl konfigurace se ale nedoporučuje pro více koncových bodů.

Směrování

Výchozí chování

Ve výchozím nastavení vazba funkcí používá DefaultEndpointRouter pro výběr koncových bodů.

  • Směrování klientů: Náhodně vyberte jeden koncový bod z primárních online koncových bodů. Pokud jsou všechny primární koncové body offline, náhodně vyberte jeden sekundární online koncový bod. Pokud se výběr znovu nezdaří, bude vyvolána výjimka.

  • Směrování zpráv serveru: Vrátí se všechny koncové body služby.

Přizpůsobení

Model v rámci procesu pro C#

Postup je následující:

  1. Implementujte přizpůsobený směrovač. K rozhodování o směrování můžete využít informace, které jsou k dispozici z ServiceEndpoint. Průvodce najdete tady: customize-route-algorithm. Mějte na paměti, že trigger HTTP je vyžadován ve funkci vyjednávání, pokud potřebujete HttpContext ve vlastní metodě vyjednávání.

  2. Zaregistrujte směrovač do kontejneru DI.

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>();
        }
    }
}
Model izolovaného procesu

Pro funkce spuštěné v izolovaném modelu procesu podporujeme zadávání cílových koncových bodů v jednotlivých žádostech. K získání informací o koncovém bodu použijete nové typy vazeb.

Klientské směrování

Vazba SignalRConnectionInfo vybere jeden koncový bod podle výchozího pravidla směrování. Pokud chcete přizpůsobit pravidlo směrování, měli byste místo vazby SignalRNegotiation použít SignalRConnectionInfo vazbu.

SignalRNegotiation vlastnosti konfigurace vazby jsou stejné jako SignalRConnectionInfo vlastnosti. Tady je function.json ukázka souboru:

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

Můžete také přidat další data vazby, například userIdidToken , a claimTypeList stejně jako SignalRConnectionInfo.

Objekt, který získáte z SignalRNegotiation vazby, je v následujícím formátu:

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

Tady je ukázka použití JavaScriptu vazby 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;
    }
}
Směrování zpráv

Směrování zpráv nebo akcí potřebuje ke spolupráci dva typy vazeb. Obecně platí, že nejprve potřebujete nový typ SignalREndpoints vstupní vazby, abyste získali všechny dostupné informace o koncovém bodu. Potom vyfiltrujete koncové body a získáte pole obsahující všechny koncové body, na které chcete odeslat. Nakonec zadáte cílové koncové body ve SignalR výstupní vazbě.

Tady jsou vlastnosti konfigurace vazby SignalREndpoints v functions.json souboru:

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

Objekt, ze SignalREndpoints kterého získáte, je pole koncových bodů, z nichž každý je reprezentován jako objekt JSON s následujícím schématem:

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

Po získání pole cílového koncového bodu přidejte do objektu výstupní vazby endpoints vlastnost. Toto je příklad JavaScriptu:

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();
}

Sada SDK pro správu

Přidejte více koncových bodů z konfigurace

Nakonfigurujte klíč Azure:SignalR:Endpoints pro připojovací řetězec služby SignalR. Klíč by měl být ve formátu Azure:SignalR:Endpoints:{Name}:{EndpointType}, kde Name a EndpointType jsou vlastnosti objektu ServiceEndpoint a jsou přístupné z kódu.

Pomocí následujících dotnet příkazů můžete přidat více připojovacích řetězců instancí:

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>

Přidat více koncových bodů z kódu

Třída ServiceEndpoint popisuje vlastnosti koncového bodu služby Azure SignalR. Při použití sady SDK pro správu Azure SignalR můžete nakonfigurovat více koncových bodů instance prostřednictvím:

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();

Přizpůsobte směrovač koncových bodů

Ve výchozím nastavení sada SDK k vyzvednutí koncových bodů používá DefaultEndpointRouter .

Výchozí chování

  • Směrování požadavků klienta:

    Když klient /negotiate komunikuje se serverem aplikace. Sada SDK ve výchozím nastavení náhodně vybere jeden koncový bod ze sady dostupných koncových bodů služby.

  • Směrování zpráv serveru:

    Při odesílání zprávy do konkrétního připojení a cílové připojení je směrováno na aktuální server, zpráva přejde přímo do daného připojeného koncového bodu. Jinak se zprávy vysílají do každého koncového bodu Azure SignalR.

Přizpůsobení algoritmu směrování

Vlastní směrovač můžete vytvořit, když máte speciální znalosti, abyste zjistili, na které koncové body mají zprávy přejít.

Následující příklad definuje vlastní směrovač, který směruje zprávy se skupinou začínající east- na koncový bod s názvem 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);
    }
}

Následující příklad přepíše výchozí chování vyjednávání a vybere koncový bod v závislosti na umístění aplikačního serveru.

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
    }
}

Nezapomeňte zaregistrovat směrovač do kontejneru DI pomocí:

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();

Konfigurace ve scénářích napříč oblastmi

Objekt ServiceEndpoint má EndpointType vlastnost s hodnotou primary nebo secondary.

Primární koncové body jsou upřednostňované koncové body pro příjem provozu klientů, protože mají spolehlivější síťová připojení. Sekundární koncové body mají méně spolehlivá síťová připojení a používají se jenom pro přenosy mezi servery a klienty. Sekundární koncové body se například používají pro vysílání zpráv místo provozu klienta na server.

V případech mezi oblastmi může být síť nestabilní. Pro aplikační server umístěný v oblasti USA – východ je koncový bod služby SignalR umístěný ve stejné primary – východ a koncové body v jiných oblastech označených jako secondary. V této konfiguraci můžou koncové body služby v jiných oblastech přijímat zprávy z tohoto aplikačního serveru USA – východ, ale na tento aplikační server se nesměrují žádní klienti mezi oblastmi . Následující diagram znázorňuje architekturu:

Mezi-geografická infrastruktura

Když se klient pokusí použít /negotiate aplikační server s výchozím směrovačem, SDK náhodně vybere jeden koncový bod ze souboru dostupných primary koncových bodů. Pokud primární koncový bod není dostupný, sada SDK pak náhodně vybere ze všech dostupných secondary koncových bodů. Koncový bod se označí jako dostupný , když je připojení mezi serverem a koncovým bodem služby aktivní.

Ve scénáři mezi oblastmi se klient pokusí použít /negotiate aplikační server hostovaný v oblasti USA – východ, ve výchozím nastavení vždy vrátí primary koncový bod umístěný ve stejné oblasti. Pokud nejsou dostupné všechny koncové body USA – východ, směrovač přesměruje klienta na koncové body v jiných oblastech. Následující část převzetí služeb při selhání podrobně popisuje scénář.

Normální vyjednávání

Převzetí služeb při selhání

Pokud není k dispozici žádný primary koncový bod, vybere klient /negotiate z dostupných secondary koncových bodů. Tento mechanismus převzetí služeb při selhání vyžaduje, aby každý koncový bod sloužil jako koncový bod alespoň k jednomu aplikačnímu primary serveru.

Diagram znázorňující proces mechanismu převzetí služeb při selhání

Další kroky

Ve scénářích s vysokou dostupností a zotavením po havárii můžete použít několik koncových bodů.

Nastavení služby SignalR pro zotavení po havárii a vysokou dostupnost

  • Last updated on