Nous développons le noyau ASP.NET qui est hébergé comme application Web Azure.
Nous utilisons également un service Azure Signalr
Tout fonctionne très bien tant que nous avons une instance unique de l'application Web, mais une fois que nous avons échoué, nous avons le problème suivant:
Le problème ici est que la réponse pourrait être envoyée à une autre instance d'application Web. Nous envoyons donc une demande d'instance n ° 1 mais la réponse est envoyée à l'instance n ° 2 avec 50% de chances et d'instance n ° 1 ne reçoit jamais une réponse
Des idées de la manière dont nous pourrions faire fonctionner une instance que la demande émise ait réellement reçu une réponse?
3 Réponses :
Malheureusement, je n'ai pas trouvé de solution fiable qui ne nécessiterait pas de solution de contournement peu maladroite
Mais il y a 2 solutions que je pourrais offrir pour ce scénario
@lexli a suggéré une bonne approche pour résoudre ce problème. Donc, vous pouvez également créer votre application Web un client SignalR et en faire un membre d'un groupe. De cette manière, chaque instance d'application Web est également un client, puis une instance qui reçoit la réponse du client de Hub peut transmettre cette réponse au groupe d'instances d'applications Web
Vous pouvez tirer parti des sujets de bus Azure Service. Donc, une fois que l'instance démarrée commencera à vous abonner pour écouter un sujet. Et une fois que toute instance reçoit une réponse du client de Hub, il placerait une réponse dans la rubrique Bus de service, puis chaque instance recevra cette réponse du sujet
J'espérais qu'il pourrait y avoir une meilleure solution pour un tel problème
SignalR est prise en charge pour les scénarios d'échelle hors de la boîte, il s'appelle des arrière-plan. L'idée est qu'avec l'aide de l'un des composants de fond de panier, il diffusera des événements Signalr Accross à toutes les instances. Pour ASP.NET Framework, utilisez l'un de ces packages
microsoft.aspnet.signalr.servicebus3
-
microsoft.aspnet.signalr.servicebus
-
microsoft.aspnet.signalr.stackexchageredis
-
microsoft.aspnet.signalr.sqlserver
pour ASP.NET CORE uniquement ReDIS est porté avec Microsoft.aspnetcore.signalr.stackexchageredis , mais il y en a fournis par la communauté, voir https://github.com/thomaslevesque/aspnetcore.signalr.AzuresServicebus
public void ConfigureServices(IServiceCollection services)
{
services.AddSignalR()
.AddAzureSignalR(options =>
{
options.ApplicationName = "app1";
}
);
}
You could specify an ApplicationName in the server SDK for different server groups.It will help your server generate access tokens like ......?hub=app1_<your_hub> during negotiation which can help our ASRS instances differentiate connections coming from different server groups
Comme l'application Web elle-même, Signalr devait aussi être apatride. Le meilleur pari est de configurer votre fournisseur de session comme Radis Store ce dont il a besoin et ne vous inquiétez pas de quel serveur Web votre client Signalr se connecte.
Votre application Web elle-même peut être un client SignalR qui parle au hub, de sorte que votre hub a 1) clients de navigateur et 2) des clients de l'application Web et de travailler simplement comme proxy. Ensuite, lorsque votre application Web se développe à plusieurs hôtes, votre hub sait toujours quel client Web d'application Web doit transférer le message.