Frais généraux liés à l'exécution d'un serveur non HTTP dans une instance Azure?

Question

J'ai l'intention de créer et de déployer un serveur personnalisé sur Azure. Je comprends que les données entrantes devront d'abord passer par l'équilibreur de charge avant d'arriver aux instances. Donc, afin d'écouter les demandes, j'ai besoin d'écouter sur un port attribué à partir de l'équilibreur de charge. Ma question est la suivante: y a-t-il un temps de latence lorsque les données entrantes doivent d'abord passer par LB? Et ai-je besoin de changer mon code pour être capable de se propager sur plusieurs instances ou l'équilibreur de charge va gérer ces choses pour moi?

Answer 1

Il va y avoir une "certaine" latence due au fait que c'est encore une autre partie du chemin. Cependant, l'équilibreur de charge vers votre instance de machine virtuelle va être très rapide, car les deux sont dans le même centre de données. C'est simplement quelque chose qui fait partie du tissu Windows Azure.

L'équilibreur de charge lui-même n'est pas programmable par vous, et fournit essentiellement une distribution circulaire. Vous devez vous assurer que votre serveur n'a aucune dépendance sur sessions collantes - il n'y a absolument aucune garantie qu'un utilisateur qui visite Server0 visitera ensuite Server0 lors de la prochaine visite. Cela dit: Pour partager des informations d'état entre les instances, jetez un coup d'oeil à la Cache AppFabric, qui est entré en production il y a environ un mois. C'est Cache-as-a-Service, et fournit un moyen très rapide de stocker et de récupérer des paires clé/valeur. Plus d'informations sur AppFabric Cache est here.

Answer 2

Bien sûr, il y aura une certaine latence causée par l'équilibreur de charge. Mais le LB peut être assez simple, donc la latence devrait être minime.

Et le LB fait exactement ce qu'il dit sur la boîte - il équilibre juste la charge. Donc, si votre application est écrite, elle ne fonctionnerait pas correctement si l'utilisateur A accédait au serveur X et l'utilisateur B au serveur Y en même temps, cela ne fonctionnerait pas même si les deux utilisateurs pensent accédez au serveur Z à la place.