0

Étant donné un rôle Web hébergé Azure avec une application WebAPI hautement disponible (disons 99,95%, conformément à https://azure.microsoft.com/en-us/documentation/articles/resiliency-disaster-recovery-high-availability-azure-applications/) qui a ~ 1000 clients. Le client est une application ReactJS. L'application WebAPI va envoyer des notifications adaptées à des groupes de clients spécifiques (par exemple, tous les utilisateurs clients ne sont pas intéressés par tous les événements, mais un utilisateur peut être intéressé par le même événement). À la lecture de la documentation de SignalR et en jouant avec certains échantillons, il semble que SignalR Groups nous aidera à transmettre les bons événements aux bonnes instances d'application ReactJS. De plus, nous utiliserions l'un des fournisseurs de mise à l'échelle de SignalR pour nous assurer que nous envoyions les clients à partir de la bonne instance de serveur WebAPI. Question: Comment les applications se rétablissent-elles lorsque l'instance "WebAPI" droite devient indisponible?SignalR et haute disponibilité - Les clients de Hub peuvent-ils se rétablir si le serveur s'en va?

Je peux imaginer un système actif/passif côté serveur avec une certaine complexité pour s'assurer qu'il y a au moins un 'serveur' pour chaque client Hub ... mais un serveur peut se connecter (de manière non sollicitée) à un Hub Client? Aurions-nous chaque client Hub se connecter (lors de l'inscription pour un groupe) à> 1 serveur?

Comment les applications ont-elles résolu ce problème avec SignalR?

Répondre

0

Je pense que j'ai manqué le point évident que les fournisseurs de scale-out et le back-office fournissent la protection dont les clients ont besoin contre les serveurs qui s'en vont. Les clients ne se connectent pas à un serveur spécifique mais à un nom à charge équilibrée.

+0

Ma question initiale est toujours valable; ma réponse ci-dessus n'est pas juste. Ma lecture de la documentation est que le plan arrière scale-out permettra à tous les serveurs Web de connaître tous les clients. Cependant, il n'est pas clair comment les groupes jouent avec cela. Supposons deux machines Web, WebA et WebB, deux clients ClientA et ClientB, avec deux groupes, GroupA et GroupB. Si 'ClientA' se connecte à' WebA' et rejoint 'GroupA',' WebB' peut-il appeler une API sur 'ClientA'? Je pense que seulement WebA peut appeler des API sur ClientA. Est-ce correct? –

+0

J'ai trouvé que les groupes fonctionnent bien avec le plan arrière scale-out; aucun code personnalisé requis. En utilisant ServiceBus avec les groupes, confirmé avec 2 instances d'IISExpress hébergeant une application WebAPI (OWIN) que chaque application était capable d'envoyer du trafic vers les groupes appropriés. En outre, un worker 'ThreadPool.QueueWorkItem' capable d'envoyer du trafic aux clients dans les groupes qui se sont connectés aux deux serveurs Web. Ce qui m'a lancé, ce sont quelques commentaires dans la présentation 2013 de @DamianEdwards (https://channel9.msdn.com/Events/Build/2013/3-502), ce qui m'a amené à penser que j'avais besoin d'une solution personnalisée. Aucun besoin –