Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
A SignalR Service SDK több végpontot is támogat a SignalR-szolgáltatáspéldányokhoz. Ezzel a funkcióval skálázhatja az egyidejű kapcsolatokat, vagy használhatja régiók közötti üzenetkezeléshez.
Fontos
A cikkben szereplő nyers kapcsolati karakterlánc csak bemutató célokra jelenik meg.
A kapcsolati sztring tartalmazzák azokat az engedélyezési információkat, amelyekre az alkalmazásnak szüksége van az Azure SignalR Szolgáltatás eléréséhez. A kapcsolati sztring belüli hozzáférési kulcs hasonló a szolgáltatás gyökérjelszójához. Gyártási környezetben mindig védje a hozzáférési kulcsait. Az Azure Key Vault használatával biztonságosan kezelheti és forgathatja a kulcsokat, biztonságossá teheti a kapcsolat sztringjét a Microsoft Entra-azonosítóval, és engedélyezheti a hozzáférést ugyanazzal az azonosítóval.
Kerülje a hozzáférési kulcsok más felhasználók számára való terjesztését, a szigorú kódolást, illetve a mások számára hozzáférhető egyszerű szövegek mentését. Ha úgy véli, hogy a kulcsai érintetté válhattak, forgassa meg őket.
ASP.NET Core esetén
Több végpont hozzáadása konfigurációból
A cikkben szereplő nyers kapcsolati karaktersor csak bemutató célokra jelenik meg. Éles környezetben mindig védje a hozzáférési kulcsait. Az Azure Key Vault használatával biztonságosan kezelheti és megújíthatja a kulcsokat, és biztonságossá teheti a kapcsolatkarakterláncot a Microsoft Entra ID segítségével, valamint engedélyezheti a hozzáférést a Microsoft Entra ID segítségével.
A kapcsolati karakterlánc beállítása a(z) Azure:SignalR:ConnectionString vagy Azure:SignalR:ConnectionString: kulccsal a SignalR szolgáltatáshoz.
Ha a kulcs a Azure:SignalR:ConnectionString: jelöléssel kezdődik, akkor a formátuma Azure:SignalR:ConnectionString:{Name}:{EndpointType} legyen, ahol a Name és EndpointType a ServiceEndpoint objektum tulajdonságai, és ezek a kódból hozzáférhetők.
A következő dotnet parancsokkal több példány kapcsolati sztringet is hozzáadhat:
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>
Több végpont hozzáadása kódból
Az ServiceEndpoint osztály egy Azure SignalR-szolgáltatásvégpont tulajdonságait írja le.
Az Azure SignalR Service SDK használatával több példányvégpontot is konfigurálhat a következőkkel:
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"),
};
});
Végpont útválasztó testreszabása
Alapértelmezés szerint az SDK a DefaultEndpointRouter használatával veszi fel a végpontokat.
Alapértelmezett viselkedés
Ügyfélkérések útválasztása:
Amikor az ügyfél
/negotiatekapcsolódik az alkalmazáskiszolgálóval. Alapértelmezés szerint az SDK véletlenszerűen kiválaszt egy végpontot az elérhető szolgáltatásvégpontok készletéből.Kiszolgálói üzenet útválasztása:
Amikor üzenetet küld egy adott kapcsolatnak , és a célkapcsolat az aktuális kiszolgálóra van irányítva, az üzenet közvetlenül a csatlakoztatott végpontra kerül. Ellenkező esetben az üzenetek minden Azure SignalR-végpontra el lesznek küldve.
Útválasztási algoritmus testreszabása
Létrehozhat saját útválasztót, ha speciális ismeretekkel rendelkezik annak azonosításához, hogy az üzenetek mely végpontokra kerüljenek.
Az alábbi példa egy egyéni útválasztót határoz meg, amely a csoporttal east- kezdődő üzeneteket a következő nevű eastvégpontra irányítja:
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);
}
}
Az alábbi példa felülírja az alapértelmezett egyeztetési viselkedést, és az alkalmazáskiszolgáló helyétől függően kiválasztja a végpontot.
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
}
}
Ne felejtse el regisztrálni az útválasztót a DI-tárolóban a következő módon:
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 a forró újratöltést is támogatja. Az alábbi mintakód bemutatja, hogyan tölthetők be a kapcsolati sztringek az egyik konfigurációs szakaszból, és a másikban elhelyezkedő fordított proxyk által közzétett nyilvános URL-címek, és amíg a konfiguráció támogatja a dinamikus újratöltést, a végpontok menet közben frissíthetők.
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"))
},
];
});
ASP.NET-hez
Több végpont hozzáadása konfigurációból
Konfiguráció kulccsal Azure:SignalR:ConnectionString vagy Azure:SignalR:ConnectionString: a SignalR szolgáltatás kapcsolati karakterláncához.
Ha a kulcs Azure:SignalR:ConnectionString:-val kezdődik, formátuma Azure:SignalR:ConnectionString:{Name}:{EndpointType} legyen, ahol Name és EndpointType az ServiceEndpoint objektum tulajdonságai, és kódból elérhetők legyenek.
Több példányos kapcsolati sztringet is hozzáadhat a web.config-hoz:
<?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>
Több végpont hozzáadása kódból
Az ServiceEndpoint osztály egy Azure SignalR-szolgáltatásvégpont tulajdonságait írja le.
Az Azure SignalR Service SDK használatával több példányvégpontot is konfigurálhat a következőkkel:
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>"),
}
});
Útválasztó testreszabása
Az egyetlen különbség a ASP.NET SignalR és a ASP.NET Core SignalR között a http-környezet típusa GetNegotiateEndpoint. Az ASP.NET SignalR esetében ez IOwinContext típusú.
Az alábbi kód egy egyéni egyeztetési példa ASP.NET SignalR-hez:
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
}
}
Ne felejtse el regisztrálni az útválasztót a DI konténerbe a következő használatával:
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>")
};
});
Szolgáltatásvégpont-metrikák
A fejlett útválasztó engedélyezéséhez a SignalR-kiszolgáló SDK több metrikát biztosít, amelyek segítik a kiszolgálót az intelligens döntések meghozatalában. A tulajdonságok a következő alatt ServiceEndpoint.EndpointMetricstalálhatók: .
| Metrika neve | Leírás |
|---|---|
ClientConnectionCount |
Az egyidejű ügyfélkapcsolatok teljes száma a szolgáltatásvégpont összes hubján |
ServerConnectionCount |
Az egyidejű kiszolgálókapcsolatok teljes száma a szolgáltatásvégpont összes hubján |
ConnectionCapacity |
A szolgáltatásvégpont teljes csatlakozási kvótája, beleértve az ügyfél- és kiszolgálókapcsolatokat is |
Az alábbi kód egy példa egy útválasztó testreszabására ClientConnectionCount szerint.
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
}
}
Dinamikus méretezési szolgáltatáspontok
Az SDK 1.5.0-s verziójában először engedélyezzük a dinamikus skálázású ServiceEndpoints használatát ASP.NET Core-verzióhoz. Így nem kell újraindítania az alkalmazáskiszolgálót, ha ServiceEndpointot kell hozzáadnia vagy eltávolítania. Mivel az ASP.NET Core támogatja az alapértelmezett konfigurációt, mint például a appsettings.json és reloadOnChange: true, nem kell módosítania a kódot, és ezt a rendszer természetes módon támogatja. Ha testre szabott konfigurációt szeretne hozzáadni, és hot-reloaddal szeretne dolgozni, tekintse meg az ASP.NET Core Konfigurációt.
Feljegyzés
Figyelembe véve a kiszolgáló/szolgáltatás és az ügyfél/szolgáltatás közötti kapcsolat beállításának idejét, annak érdekében, hogy a skálázási folyamat során ne legyen üzenetvesztés, átmeneti időszak áll rendelkezésére, amíg a kiszolgálókapcsolatok készen állnak az új ServiceEndpoint ügyfeleknek való megnyitása előtt. Általában másodpercek alatt befejeződik, és megjelenik egy olyan naplóüzenet Succeed in adding endpoint: '{endpoint}' , amely a folyamat befejezését jelzi.
Bizonyos várt helyzetekben, például a régiók közötti hálózati problémák vagy a különböző alkalmazáskiszolgálók konfigurációs inkonzisztenciája esetén előfordulhat, hogy az előkészítési időszak nem fejeződik be megfelelően. Ezekben az esetekben javasoljuk, hogy indítsa újra az alkalmazáskiszolgálót, ha a skálázási folyamat nem működik megfelelően.
A skálázás alapértelmezett időtúllépési időtartama 5 perc, és az érték ServiceOptions.ServiceScaleTimeoutmódosításával testre szabható. Ha sok alkalmazáskiszolgálóval rendelkezik, javasoljuk, hogy egy kicsit tovább bővítse az értéket.
Feljegyzés
Jelenleg a több végpontos funkció csak átviteli típus esetén Persistent támogatott.
SignalR Functions-bővítmények esetén
Konfiguráció
Több SignalR-szolgáltatáspéldány engedélyezéséhez a következőt kell tennie:
Használjon
Persistentátviteli típust.Az alapértelmezett átviteli típus a
Transientmód. Adja hozzá a következő bejegyzést alocal.settings.jsonfájlhoz vagy az Azure-beli alkalmazásbeállításhoz.{ "AzureSignalRServiceTransportType":"Persistent" }Feljegyzés
Amikor a
TransientmódbólPersistentmódra vált, előfordulhat, hogy a JSON szerializálási viselkedése megváltozik, mertTransientmódban aNewtonsoft.Jsonkönyvtárat használják a központi metódusok argumentumainak szerializálására, mígPersistentmódban aSystem.Text.Jsonkönyvtár az alapértelmezett.System.Text.Jsonaz alapértelmezett viselkedésben van néhány alapvető különbség a következővelNewtonsoft.Json: . HaPersistentmód alatt szeretné használni aNewtonsoft.Json-t, hozzáadhat egy konfigurációs elemet alocal.settings.jsonfájlban:"Azure:SignalR:HubProtocol":"NewtonsoftJson", vagy az Azure portálonAzure__SignalR__HubProtocol=NewtonsoftJson.Konfiguráljon több SignalR-szolgáltatásvégpont-bejegyzést a konfigurációban.
Objektumot
ServiceEndpointhasználunk a SignalR-szolgáltatáspéldányok megjelenítéséhez. Egy szolgáltatásvégpontot definiálhat a hozzá tartozó<EndpointName>, a belépési kulccsal és a<EndpointType>belépési értékben található kapcsolati sztringgel. A kulcsok formátuma a következő:Azure:SignalR:Endpoints:<EndpointName>:<EndpointType><EndpointType>nem kötelező, és alapértelmezés szerintprimary. Lásd az alábbi példákat:{ "Azure:SignalR:Endpoints:EastUs":"<ConnectionString>", "Azure:SignalR:Endpoints:EastUs2:Secondary":"<ConnectionString>", "Azure:SignalR:Endpoints:WestUs:Primary":"<ConnectionString>" }Feljegyzés
Amikor Azure SignalR-végpontokat konfigurál az App Service-ben az Azure Portalon, ne felejtse el lecserélni a
":"-t a"__"-re, a kulcsokban található dupla aláhúzásjelre. Ennek okait lásd: Környezeti változók.A
{ConnectionStringSetting}kulccsal konfigurált kapcsolati sztring (alapértelmezés szerint az "AzureSignalRConnectionString") is elsődleges szolgáltatásvégpontként ismerhető fel, még akkor is, ha az üres névvel rendelkezik. Ez a konfigurációs stílus azonban nem ajánlott több végpont esetében.
Útválasztás
Alapértelmezett viselkedés
Alapértelmezés szerint a függvénykötés a DefaultEndpointRouter használatával veszi fel a végpontokat.
Ügyfél-útválasztás: Véletlenszerűen válasszon ki egy végpontot az elsődleges online végpontokból. Ha az összes elsődleges végpont offline állapotban van, véletlenszerűen válasszon ki egy másodlagos online végpontot. Ha a kijelölés ismét meghiúsul, a rendszer kivételt vet ki.
Kiszolgálói üzenetek útválasztása: A rendszer minden szolgáltatásvégpontot visszaad.
Testreszabás
C# folyamaton belüli modell
A lépések a következők:
Implementáljon egy testre szabott útválasztót. Az útválasztási döntés meghozatalához használhatja a megadott
ServiceEndpointinformációkat. Tekintse meg az útmutatót itt: customize-route-algorithm. Vegye figyelembe, hogy a HTTP triggerre akkor van szükség az egyeztetési függvényben, amikor szükséges egyéni egyeztetési módszernélHttpContext.Regisztrálja a routert a DI-konténerbe.
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>();
}
}
}
Izolált folyamatmodell
Az izolált folyamatmodellen futó függvények esetében minden kérésben támogatjuk a célvégpontok megadását. A végpontadatok lekéréséhez új kötéstípusokat fog használni.
Ügyfél-útválasztás
A SignalRConnectionInfo kötés az alapértelmezett útválasztási szabálynak megfelelően kiválaszt egy végpontot. Ha testre szeretné szabni az útválasztási szabályt, használja a SignalRNegotiation kötést a SignalRConnectionInfo kötés helyett.
SignalRNegotiation kötéskonfiguráció tulajdonságai megegyeznek SignalRConnectionInfo-el. Íme egy function.json fájlminta:
{
"type": "signalRNegotiation",
"name": "negotiationContext",
"hubName": "<HubName>",
"direction": "in"
}
Más kötési adatokat is hozzáadhat, például userId, idToken és claimTypeList, ugyanúgy, mint a SignalRConnectionInfo.
A kötésből SignalRNegotiation kapott objektum formátuma a következő:
{
"endpoints": [
{
"endpointType": "Primary",
"name": "<EndpointName>",
"endpoint": "https://****.service.signalr.net",
"online": true,
"connectionInfo": {
"url": "<client-access-url>",
"accessToken": "<client-access-token>"
}
},
{
"...": "..."
}
]
}
Íme egy JavaScript-használati minta kötésről 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;
}
}
Üzenetek útválasztása
Az üzenetek vagy műveletek útválasztásához két kötéstípusra van szükség az együttműködéshez. Általában először egy új bemeneti kötéstípusra SignalREndpoints van szükség az összes elérhető végpontinformáció lekéréséhez. Ezután szűrheti a végpontokat, és lekérhet egy tömböt, amely tartalmazza az összes küldendő végpontot. Végül meg kell adnia a célvégpontokat a SignalR kimeneti kötésben.
Íme a kötési konfigurációs tulajdonságok a SignalREndpoints fájlban:
{
"type": "signalREndpoints",
"direction": "in",
"name": "endpoints",
"hubName": "<HubName>"
}
A kapott SignalREndpoints objektum végpontok tömbje, amelyek mindegyike JSON-objektumként jelenik meg az alábbi sémával:
{
"endpointType": "<EndpointType>",
"name": "<EndpointName>",
"endpoint": "https://****.service.signalr.net",
"online": true
}
A célvégpont-tömb lekérése után adjon hozzá egy tulajdonságot endpoints a kimeneti kötési objektumhoz. Ez egy JavaScript-példa:
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();
}
Felügyeleti SDK esetén
Több végpont hozzáadása konfigurációból
Konfigurálja a SignalR Service kapcsolati sztringet a kulccsal Azure:SignalR:Endpoints. A kulcsnak formátumot Azure:SignalR:Endpoints:{Name}:{EndpointType}kell megadnia, ahol Name és EndpointType amelyek az ServiceEndpoint objektum tulajdonságai, és a kódból elérhetőnek kell lennie.
A következő dotnet parancsokkal több példány kapcsolati sztringet adhat hozzá:
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>
Több végpont hozzáadása kódból
Az ServiceEndpoint osztály egy Azure SignalR-szolgáltatásvégpont tulajdonságait írja le.
Az Azure SignalR Management SDK használatával több példányvégpontot is konfigurálhat az alábbiakon keresztül:
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();
Végpont útválasztó testreszabása
Alapértelmezés szerint az SDK a DefaultEndpointRouter használatával veszi fel a végpontokat.
Alapértelmezett viselkedés
Ügyfélkérések útválasztása:
Amikor az ügyfél
/negotiatekapcsolódik az alkalmazáskiszolgálóval. Alapértelmezés szerint az SDK véletlenszerűen kiválaszt egy végpontot az elérhető szolgáltatásvégpontok készletéből.Kiszolgálói üzenet útválasztása:
Amikor üzenetet küld egy adott kapcsolatnak , és a célkapcsolat az aktuális kiszolgálóra van irányítva, az üzenet közvetlenül a csatlakoztatott végpontra kerül. Ellenkező esetben az üzenetek minden Azure SignalR-végpontra el lesznek küldve.
Útválasztási algoritmus testreszabása
Létrehozhat saját útválasztót, ha speciális ismeretekkel rendelkezik annak azonosításához, hogy az üzenetek mely végpontokra kerüljenek.
Az alábbi példa egy egyéni útválasztót határoz meg, amely a csoporttal east- kezdődő üzeneteket a következő nevű eastvégpontra irányítja:
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);
}
}
Az alábbi példa felülírja az alapértelmezett egyeztetési viselkedést, és az alkalmazáskiszolgáló helyétől függően kiválasztja a végpontot.
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
}
}
Ne felejtse el regisztrálni a routert a DI-tárolóban az alábbi módszerrel:
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();
Konfiguráció régiók közötti forgatókönyvekben
Az ServiceEndpoint objektum rendelkezik egy EndpointType értékkel primary vagy secondary.
Az elsődleges végpontok előnyben részesített végpontok az ügyfélforgalom fogadásához, mivel megbízhatóbb hálózati kapcsolatokkal rendelkeznek. A másodlagos végpontok kevésbé megbízható hálózati kapcsolatokkal rendelkeznek, és csak a kiszolgáló és az ügyfél közötti forgalomhoz használhatók. A másodlagos végpontok például az ügyfél és a kiszolgáló közötti forgalom helyett az üzenetek közvetítésére szolgálnak.
Régiók közötti esetekben a hálózat instabil lehet. Az East US-ben található alkalmazáskiszolgáló esetében a SignalR Service végpont ugyanabban az East US régióban van primary, míg más régiókban található végpontok a secondary-vel jelöltek. Ebben a konfigurációban a más régiókban lévő szolgáltatásvégpontok üzeneteket fogadhatnak az USA keleti régiójának alkalmazáskiszolgálójáról, de a régióközi ügyfelek nem lesznek átirányítva ehhez az alkalmazáskiszolgálóhoz. Az alábbi ábrán az architektúra látható:
Amikor egy ügyfél egy alapértelmezett útválasztóval próbálkozik /negotiate az alkalmazáskiszolgálóval, az SDK véletlenszerűen kiválaszt egy végpontot az elérhető primary végpontok készletéből. Ha az elsődleges végpont nem érhető el, az SDK véletlenszerűen kiválasztja az összes elérhető secondary végpontot. A végpont elérhetőként van megjelölve, ha a kiszolgáló és a szolgáltatásvégpont közötti kapcsolat életben van.
Régiók közötti forgatókönyv esetén, amikor egy ügyfél az USA/negotiateüzemeltetett alkalmazáskiszolgálóval próbálkozik, alapértelmezés szerint mindig az ugyanabban a primary régióban található végpontot adja vissza. Ha az összes kelet-amerikai végpont nem érhető el, az útválasztó átirányítja az ügyfelet más régiókban található végpontokra. A következő átállási szakasz részletesen ismerteti a szcenáriót.
Átállás
Ha nincs primary elérhető végpont, az ügyfél kiválasztja /negotiate az elérhető secondary végpontokat. Ez a feladatátvételi mechanizmus megköveteli, hogy minden végpont végpontként primary szolgáljon legalább egy alkalmazáskiszolgáló számára.
Következő lépések
Több végpontot is használhat magas rendelkezésre állású és vészhelyreállítási forgatókönyvekben.