Skala SignalR Service med flera instanser
SignalR Service SDK stöder flera slutpunkter för SignalR Service-instanser. Du kan använda den här funktionen för att skala de samtidiga anslutningarna eller använda den för meddelanden mellan regioner.
Viktigt!
Råa anslutningssträng visas endast i den här artikeln i demonstrationssyfte.
En anslutningssträng innehåller den auktoriseringsinformation som krävs för att ditt program ska få åtkomst till Azure SignalR Service. Åtkomstnyckeln i anslutningssträng liknar ett rotlösenord för din tjänst. Skydda alltid dina åtkomstnycklar i produktionsmiljöer. Använd Azure Key Vault för att hantera och rotera dina nycklar på ett säkert sätt och skydda dina anslutningssträng med hjälp av Microsoft Entra-ID och auktorisera åtkomst med Microsoft Entra-ID.
Undvik att distribuera åtkomstnycklar till andra användare, hårdkoda dem eller spara dem var som helst i oformaterad text som är tillgänglig för andra. Rotera dina nycklar om du tror att de har komprometterats.
För ASP.NET Core
Lägga till flera slutpunkter från konfigurationen
Råa anslutningssträng visas endast i den här artikeln i demonstrationssyfte. Skydda alltid dina åtkomstnycklar i produktionsmiljöer. Använd Azure Key Vault för att hantera och rotera dina nycklar på ett säkert sätt och skydda dina anslutningssträng med hjälp av Microsoft Entra-ID och auktorisera åtkomst med Microsoft Entra-ID.
Konfigurera med nyckel Azure:SignalR:ConnectionString eller Azure:SignalR:ConnectionString: för SignalR Service-anslutningssträng.
Om nyckeln börjar med Azure:SignalR:ConnectionString:ska den vara i formatet Azure:SignalR:ConnectionString:{Name}:{EndpointType}, där Name och EndpointType är egenskaperna för ServiceEndpoint objektet och är tillgängliga från kod.
Du kan lägga till flera instanser anslutningssträng med hjälp av följande dotnet kommandon:
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>
Lägga till flera slutpunkter från kod
En ServiceEndpoint klass beskriver egenskaperna för en Azure SignalR Service-slutpunkt.
Du kan konfigurera flera instansslutpunkter när du använder Azure SignalR Service SDK via:
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"),
};
});
Anpassa slutpunktsrouter
Som standard använder SDK DefaultEndpointRouter för att hämta slutpunkter.
Standardbeteende
Routning av klientbegäran:
När klienten
/negotiateär med appservern. Som standard väljer SDK slumpmässigt en slutpunkt från uppsättningen med tillgängliga tjänstslutpunkter.Routning av servermeddelande:
När du skickar ett meddelande till en specifik anslutning och målanslutningen dirigeras till den aktuella servern går meddelandet direkt till den anslutna slutpunkten. Annars skickas meddelandena till varje Azure SignalR-slutpunkt.
Anpassa routningsalgoritm
Du kan skapa en egen router när du har särskilda kunskaper för att identifiera vilka slutpunkter meddelandena ska gå till.
I följande exempel definieras en anpassad router som dirigerar meddelanden med en grupp som börjar med till slutpunkten med east- namnet 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);
}
}
I följande exempel åsidosätts standardbeteendet för förhandlingar och slutpunkten väljs beroende på appserverns plats.
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
}
}
Glöm inte att registrera routern till DI-containern med hjälp av:
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 har också stöd för frekvent omläsning. Exempelkoden nedan visar hur du läser in anslutningssträng från ett konfigurationsavsnitt och en offentlig URL som exponeras av omvända proxyservrar från en annan, och så länge konfigurationen stöder snabbinläsning kan slutpunkterna uppdateras i farten.
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"))
},
];
});
För ASP.NET
Lägga till flera slutpunkter från konfigurationen
Konfiguration med nyckel Azure:SignalR:ConnectionString eller Azure:SignalR:ConnectionString: för SignalR Service-anslutningssträng.
Om nyckeln börjar med Azure:SignalR:ConnectionString:ska den vara i format Azure:SignalR:ConnectionString:{Name}:{EndpointType}, där Name och EndpointType är egenskaperna för ServiceEndpoint objektet och är tillgängliga från kod.
Du kan lägga till flera instanser anslutningssträng i 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>
Lägga till flera slutpunkter från kod
En ServiceEndpoint klass beskriver egenskaperna för en Azure SignalR Service-slutpunkt.
Du kan konfigurera flera instansslutpunkter när du använder Azure SignalR Service SDK via:
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>"),
}
});
Anpassa en router
Den enda skillnaden mellan ASP.NET SignalR och ASP.NET Core SignalR är http-kontexttypen för GetNegotiateEndpoint. För ASP.NET SignalR är den av typen IOwinContext .
Följande kod är ett anpassat förhandlingsexempel för 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
}
}
Glöm inte att registrera routern till DI-containern med hjälp av:
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ått för tjänstslutpunkt
För att aktivera en avancerad router tillhandahåller SignalR Server SDK flera mått som hjälper servern att fatta smarta beslut. Egenskaperna finns under ServiceEndpoint.EndpointMetrics.
| Måttnamn | beskrivning |
|---|---|
ClientConnectionCount |
Totalt antal samtidiga klientanslutningar på alla hubbar för tjänstslutpunkten |
ServerConnectionCount |
Totalt antal samtidiga serveranslutningar på alla hubbar för tjänstslutpunkten |
ConnectionCapacity |
Total anslutningskvot för tjänstslutpunkten, inklusive klient- och serveranslutningar |
Följande kod är ett exempel på hur du anpassar en router enligt 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 för dynamisk skalning
Från SDK version 1.5.0 aktiverar vi ServiceEndpoints i dynamisk skala för ASP.NET Core-versionen först. Så du behöver inte starta om appservern när du behöver lägga till/ta bort en ServiceEndpoint. Eftersom ASP.NET Core stöder en standardkonfiguration som appsettings.json med reloadOnChange: truebehöver du inte ändra kod och den stöds av naturen. Och om du vill lägga till en anpassad konfiguration och arbeta med frekvent omläsning läser du in konfigurationen i ASP.NET Core.
Kommentar
Med tanke på tiden för anslutningen mellan server/tjänst och klient/tjänst kan vara annorlunda, för att säkerställa att inga meddelandeförluster uppstår under skalningsprocessen, har vi en mellanlagringsperiod som väntar på att serveranslutningarna ska vara klara innan den nya ServiceEndpoint öppnas för klienter. Vanligtvis tar det några sekunder att slutföra och du kan se ett loggmeddelande som Succeed in adding endpoint: '{endpoint}' anger att processen är klar.
I vissa förväntade situationer, till exempel problem med nätverk mellan regioner eller inkonsekvenser i konfigurationen på olika appservrar, kanske mellanlagringsperioden inte slutförs korrekt. I dessa fall rekommenderar vi att du startar om appservern när du upptäcker att skalningsprocessen inte fungerar korrekt.
Standardtidsgränsen för skalan är 5 minuter och kan anpassas genom att ändra värdet i ServiceOptions.ServiceScaleTimeout. Om du har många appservrar föreslås det att du utökar värdet lite mer.
Kommentar
För närvarande stöds funktionen för flera slutpunkter endast för Persistent transporttyp.
För SignalR Functions-tillägg
Konfiguration
Om du vill aktivera flera SignalR Service-instanser bör du:
Använd
Persistenttransporttyp.Standardtransporttypen är
Transientläge. Du bör lägga till följande post ilocal.settings.jsonfilen eller programinställningen i Azure.{ "AzureSignalRServiceTransportType":"Persistent" }Kommentar
När du växlar från
Transientläge tillPersistentläge kan JSON-serialiseringsbeteendet ändras, eftersom biblioteket underTransientlägeNewtonsoft.Jsonanvänds för att serialisera argument för hubbmetoder, men underPersistentlägeSystem.Text.Jsonanvänds biblioteket som standard.System.Text.Jsonhar några viktiga skillnader i standardbeteende medNewtonsoft.Json. Om du vill användaNewtonsoft.JsonunderPersistentläge kan du lägga till ett konfigurationsobjekt:"Azure:SignalR:HubProtocol":"NewtonsoftJson"ilocal.settings.jsonfilen ellerAzure__SignalR__HubProtocol=NewtonsoftJsonpå Azure Portal.Konfigurera flera SignalR Service-slutpunkter i konfigurationen.
Vi använder ett
ServiceEndpointobjekt för att representera en SignalR Service-instans. Du kan definiera en tjänstslutpunkt med dess<EndpointName>och<EndpointType>i postnyckeln och anslutningssträng i postvärdet. Nycklarna har följande format:Azure:SignalR:Endpoints:<EndpointName>:<EndpointType><EndpointType>är valfritt och standardvärdetprimaryär . Se exempel nedan:{ "Azure:SignalR:Endpoints:EastUs":"<ConnectionString>", "Azure:SignalR:Endpoints:EastUs2:Secondary":"<ConnectionString>", "Azure:SignalR:Endpoints:WestUs:Primary":"<ConnectionString>" }Kommentar
När du konfigurerar Azure SignalR-slutpunkter i App Service på Azure Portal ska du inte glömma att ersätta
":"med"__", det dubbla understrecket i nycklarna. Av orsaker kan du läsa Miljövariabler.Anslutningssträng som konfigurerats med nyckeln
{ConnectionStringSetting}(standardvärdet "AzureSignalRConnectionString") identifieras också som en primär tjänstslutpunkt med tomt namn. Men det här konfigurationsformatet rekommenderas inte för flera slutpunkter.
Routning
Standardbeteende
Som standard använder funktionsbindningen DefaultEndpointRouter för att hämta slutpunkter.
Klientroutning: Välj slumpmässigt en slutpunkt från primära onlineslutpunkter . Om alla primära slutpunkter är offline väljer du slumpmässigt en sekundär onlineslutpunkt . Om markeringen misslyckas igen utlöses undantaget.
Routning av servermeddelande: Alla tjänstslutpunkter returneras.
Anpassning
C#-processmodell
Här är stegen:
Implementera en anpassad router. Du kan använda information som tillhandahålls från
ServiceEndpointför att fatta routningsbeslut. Se guide här: customize-route-algorithm. Observera att HTTP-utlösare krävs i förhandlingsfunktionen när du behöverHttpContexten anpassad förhandlingsmetod.Registrera routern till DI-containern.
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>();
}
}
}
Isolerad processmodell
För funktioner som körs på en isolerad processmodell stöder vi att ange målslutpunkter i varje begäran. Du kommer att använda nya bindningstyper för att hämta slutpunktsinformation.
Rutt för klient
Bindningen SignalRConnectionInfo väljer en slutpunkt enligt standardroutningsregeln. Om du vill anpassa routningsregeln bör du använda SignalRNegotiation bindning i stället SignalRConnectionInfo för bindning.
SignalRNegotiation bindningskonfigurationsegenskaper är samma som SignalRConnectionInfo. Här är ett function.json filexempel:
{
"type": "signalRNegotiation",
"name": "negotiationContext",
"hubName": "<HubName>",
"direction": "in"
}
Du kan också lägga till andra bindningsdata som userId, idToken och claimTypeList precis som SignalRConnectionInfo.
Objektet som du får från SignalRNegotiation bindningen har följande format:
{
"endpoints": [
{
"endpointType": "Primary",
"name": "<EndpointName>",
"endpoint": "https://****.service.signalr.net",
"online": true,
"connectionInfo": {
"url": "<client-access-url>",
"accessToken": "<client-access-token>"
}
},
{
"...": "..."
}
]
}
Här är ett JavaScript-användningsexempel på SignalRNegotiation bindning:
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;
}
}
Routning av meddelanden
Routning av meddelanden eller åtgärder behöver två bindningstyper för att samarbeta. I allmänhet behöver du först en ny indatabindningstyp SignalREndpoints för att få all tillgänglig slutpunktsinformation. Sedan filtrerar du slutpunkterna och hämtar en matris som innehåller alla slutpunkter som du vill skicka till. Slutligen anger du målslutpunkterna i utdatabindningen SignalR .
Här är bindningskonfigurationsegenskaperna SignalREndpoints i functions.json filen:
{
"type": "signalREndpoints",
"direction": "in",
"name": "endpoints",
"hubName": "<HubName>"
}
Objektet du får från SignalREndpoints är en matris med slutpunkter som var och en representeras som ett JSON-objekt med följande schema:
{
"endpointType": "<EndpointType>",
"name": "<EndpointName>",
"endpoint": "https://****.service.signalr.net",
"online": true
}
När du har hämtat målslutpunktsmatrisen lägger du till en endpoints egenskap i utdatabindningsobjektet. Det här är ett JavaScript-exempel:
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();
}
För hanterings-SDK
Lägga till flera slutpunkter från konfigurationen
Konfigurera med nyckel Azure:SignalR:Endpoints för SignalR Service anslutningssträng. Nyckeln ska vara i formatet Azure:SignalR:Endpoints:{Name}:{EndpointType}, där Name och EndpointType är objektets ServiceEndpoint egenskaper och är tillgängliga från kod.
Du kan lägga till flera instanser anslutningssträng med hjälp av följande dotnet kommandon:
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>
Lägga till flera slutpunkter från kod
En ServiceEndpoint klass beskriver egenskaperna för en Azure SignalR Service-slutpunkt.
Du kan konfigurera flera instansslutpunkter när du använder Azure SignalR Management SDK via:
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();
Anpassa slutpunktsrouter
Som standard använder SDK DefaultEndpointRouter för att hämta slutpunkter.
Standardbeteende
Routning av klientbegäran:
När klienten
/negotiateär med appservern. Som standard väljer SDK slumpmässigt en slutpunkt från uppsättningen med tillgängliga tjänstslutpunkter.Routning av servermeddelande:
När du skickar ett meddelande till en specifik anslutning och målanslutningen dirigeras till den aktuella servern går meddelandet direkt till den anslutna slutpunkten. Annars skickas meddelandena till varje Azure SignalR-slutpunkt.
Anpassa routningsalgoritm
Du kan skapa en egen router när du har särskilda kunskaper för att identifiera vilka slutpunkter meddelandena ska gå till.
I följande exempel definieras en anpassad router som dirigerar meddelanden med en grupp som börjar med till slutpunkten med east- namnet 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);
}
}
I följande exempel åsidosätts standardbeteendet för förhandlingar och slutpunkten väljs beroende på appserverns plats.
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
}
}
Glöm inte att registrera routern till DI-containern med hjälp av:
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();
Konfiguration i scenarier mellan regioner
Objektet ServiceEndpoint har en EndpointType egenskap med värdet primary eller secondary.
Primära slutpunkter är prioriterade slutpunkter för att ta emot klienttrafik eftersom de har mer tillförlitliga nätverksanslutningar. Sekundära slutpunkter har mindre tillförlitliga nätverksanslutningar och används endast för server-till-klienttrafik. Till exempel används sekundära slutpunkter för att sända meddelanden i stället för klient till servertrafik.
I fall mellan regioner kan nätverket vara instabilt. För en appserver i USA, östra är primary SignalR Service-slutpunkten i samma region usa, östra och slutpunkter i andra regioner markerade som secondary. I den här konfigurationen kan tjänstslutpunkter i andra regioner ta emot meddelanden från den här appservern usa, östra , men inga klienter mellan regioner dirigeras till den här appservern. Följande diagram visar arkitekturen:
När en klient försöker /negotiate med appservern med en standardrouter väljer SDK:et slumpmässigt en slutpunkt från uppsättningen tillgängliga primary slutpunkter. När den primära slutpunkten inte är tillgänglig väljer SDK:t slumpmässigt från alla tillgängliga secondary slutpunkter. Slutpunkten markeras som tillgänglig när anslutningen mellan servern och tjänstslutpunkten är aktiv.
I ett scenario mellan regioner, när en klient försöker /negotiate med appservern i USA, östra, returnerar den som standard alltid slutpunkten primary som finns i samma region. När alla slutpunkter i USA , östra inte är tillgängliga omdirigerar routern klienten till slutpunkter i andra regioner. I följande redundansavsnitt beskrivs scenariot i detalj.
Redundans
När ingen primary slutpunkt är tillgänglig väljer klienten /negotiate från de tillgängliga secondary slutpunkterna. Den här redundansmekanismen kräver att varje slutpunkt fungerar som en primary slutpunkt till minst en appserver.
Nästa steg
Du kan använda flera slutpunkter i scenarier med hög tillgänglighet och haveriberedskap.