Eine von Azure gehostete Webrolle mit einer hoch verfügbaren WebAPI-Anwendung (z. B. 99,95%, nach https://azure.microsoft.com/en-us/documentation/articles/resiliency-disaster-recovery-high-availability-azure-applications/) mit ~ 1000 Clients. Client ist eine ReactJS-Anwendung. Die WebAPI-Anwendung sendet Benachrichtigungen, die auf bestimmte Clientgruppen zugeschnitten sind (z. B. sind nicht alle Clientbenutzer an allen Ereignissen interessiert, aber> ein Benutzer kann an demselben Ereignis interessiert sein).SignalR und High Availability - Können Hub-Clients wiederherstellen, wenn Server-Goes-Away?
Aus dem Lesen der SignalR-Dokumentation und dem Abspielen einiger Beispiele ergibt sich, dass SignalR-Gruppen uns helfen, die richtigen Ereignisse an die richtigen ReactJS-Anwendungsinstanzen weiterzuleiten. Zusätzlich würden wir einen der SignalR-Scale-Out-Provider verwenden, um sicherzustellen, dass wir die Clients von der richtigen WebAPI-Serverinstanz an die Clients senden.
Frage: Wie werden Anwendungen wiederhergestellt, wenn die "richtige WebAPI" -Instanz nicht mehr verfügbar ist?
Ich kann mir ein serverseitiges Aktiv/Passiv-Schema mit einiger Komplexität vorstellen, um sicherzustellen, dass es mindestens einen "Server" für jeden Hub-Client gibt ... aber einen Server kann (unaufgefordert) einen Hub verbinden Klient? Würden wir jeden Hub-Client (bei der Registrierung für eine Gruppe) mit> 1 Server verbinden?
Wie haben Anwendungen dieses Problem mit SignalR gelöst?
Meine ursprüngliche Frage steht noch; meine obige Antwort ist nicht richtig. Meine Lektüre der Dokumentation ist, dass die Scale-Out-Back-Ebene alle Webserver von allen Clients wissen lassen wird. Es ist jedoch nicht klar, wie Gruppen damit spielen. Man nehme 2 Web-Maschinen, "WebA" und "WebB", 2 Clients "ClientA" und "ClientB", mit 2 Gruppen, "GroupA" und "GroupB". Wenn 'ClientA' mit' WebA' verbindet und 'GroupA' verbindet, kann' WebB' eine API auf 'ClientA' aufrufen? Mein Denken ist nur WebA kann APIs auf ClientA aufrufen. Ist das richtig? –
Ich habe festgestellt, dass Gruppen gut mit der Scale-Out-Back-Ebene arbeiten; kein benutzerdefinierter Code erforderlich. Die Verwendung von ServiceBus mit Gruppen wurde mit 2 Instanzen von IISExpress bestätigt, die eine WebAPI-Anwendung (OWIN) hosten, mit der jede Anwendung Verkehr an die richtigen Gruppen senden konnte. Außerdem kann ein 'ThreadPool.QueueWorkItem'-Worker Datenverkehr an Clients in Gruppen senden, die mit beiden Webservern verbunden waren. Was mich angestoßen hat, waren einige Kommentare in @DamianEdwards 2013 Präsentation (https://channel9.msdn.com/Events/Build/2013/3-502), die mich zu der Annahme brachten, dass ich eine benutzerdefinierte Lösung benötigte. Keine benötigt. –