Comment les grands sites Web qui ne peuvent pas être complètement apatrides atteignent-ils une évolutivité extrême au niveau du Web?Sharding (sic!) Le niveau Web afin d'éviter un goulot d'étranglement de l'équilibreur de charge?
Il existe des sites comme eBay et Amazon, qui ne peuvent pas être complètement apatrides, car ils ont un panier ou quelque chose comme ça. Il n'est pas possible d'encoder chaque article du panier dans l'URL, et il n'est pas non plus possible d'encoder chaque article dans un cookie et de l'envoyer à chaque connexion. Amazon stocke donc simplement l'identifiant de session dans le cookie envoyé. Donc, je comprends que l'évolutivité du niveau Web d'eBay et Amazon devrait être beaucoup plus difficile que l'évolutivité du moteur de recherche google, où tout peut être codé reposant dans l'URL. D'autre part, tant eBay que Amazon ont évolué de manière absolument massive. La rumeur veut qu'il y ait environ 15 000 serveurs d'application J2EE sur eBay.
Comment ces sites traitent-ils les deux: évolutivité extrême et état? Comme le site est dynamique, il n'est pas possible de faire un simple équilibrage DNS. Donc, on pourrait supposer que ces entreprises ont un équilibreur de charge basé sur le matériel comme BigIP, Netscaler ou quelque chose comme ça, qui est le seul appareil derrière l'adresse IP unique de ce site. Cet équilibreur de charge déchiffrerait le SSL (s'il est codé), inspecterait le cookie et déciderait, en fonction de l'identifiant de session de ce cookie, quel serveur d'applications détient la session de ce client.
Mais cela ne peut tout simplement pas fonctionner car aucun load-balancer ne peut supporter la charge de milliers de serveurs d'applications? J'imagine que même ces équilibreurs de charge matérielle n'atteignent pas un tel niveau.
En outre, l'équilibrage de charge est effectué de façon transparente pour l'utilisateur, c'est-à-dire que les utilisateurs ne sont pas transférés à des adresses différentes, mais restent tout le temps collectivement sur www.amazon.com. Donc ma question est: Y a-t-il un truc spécial avec lequel on peut réaliser quelque chose comme un sharding transparent du niveau web (pas le niveau de la base de données comme cela est fait habituellement)? Tant que le cookie n'est pas inspecté, il est impossible de savoir quel serveur d'applications héberge cette session.
Editer: Je me suis rendu compte qu'il n'y a qu'un besoin de transparence, s'il y a un besoin pour que le site soit spidered et bookmarké. Par exemple. Si le site est une simple application Web, quelque chose comme un système de réservation de billets d'avion ou de train, il ne devrait pas y avoir de problème à simplement rediriger les utilisateurs vers des groupes de serveurs Web spécifiques derrière des URL différentes, par exemple. a17.ticketreservation.com. Dans ce cas précis, il serait possible de simplement utiliser plusieurs clusters de serveurs d'applications, chacun derrière son propre équilibreur de charge. Fait intéressant, je n'ai pas trouvé de site qui utilise ce genre de concept. Modifier: J'ai trouvé ce concept discussed à highscalability.com, où la discussion se réfère à un article de Lei Zhu nommé "Client Side Load Balancing for Web 2.0 Applications". Lei Zhu utilise le script croisé pour équilibrer la charge côté client de manière transparente.
Même s'il y a des inconvénients, comme bookmarking, xss, etc, je pense que cela semble être une très bonne idée pour certaines situations spéciales, à savoir des applications web presque sans contenu, qui ne doivent pas être spidered ou bookmarked (par exemple, systèmes de réservation de billets ou quelque chose comme ça). Ensuite, il n'est pas nécessaire de faire l'équilibrage de charge de manière transparente.
Il pourrait y avoir une simple redirection du site principal vers le serveur, par ex. une redirection de www.ticketreservation.com vers a17.ticketreservation.com. De là, l'utilisateur reste sur le serveur a17. a17 n'est pas un serveur, mais un cluster lui-même, par lequel la redondance pourrait être atteinte.
Le serveur de redirection initial peut lui-même être un cluster derrière un équilibreur de charge. De cette façon, une très grande évolutivité pourrait être atteinte, car l'équilibreur de charge primaire derrière www n'est touché qu'une fois au début de chaque session. Bien sûr, la redirection vers des URLs différentes est extrêmement désagréable, mais avec de simples applications web (qui n'ont pas besoin d'être spidered, deep-bookmark ou deep-bookmarked), cela ne devrait être qu'un problème optique pour l'utilisateur ? Le cluster de redirection a pu interroger la charge des clusters d'applications et adapter les redirections en conséquence, réalisant ainsi l'équilibrage et non la simple répartition de la charge.
Comment les serveurs Web sans état trouvent-ils le bon serveur d'applications? Chaque serveur Web doit-il connaître chaque session hébergée par un serveur d'applications? Ce ne serait pas cette communication terrifiante? – SAL9000
Les équilibreurs de charge utilisent votre ID de session ou votre adresse IP comme entrée pour choisir le serveur d'applications. Si chaque programme d'équilibrage de charge a le même algorithme pour choisir le serveur d'application, peu importe sur quelle loadbalancer vous allez, vous serez toujours envoyé au même serveur d'applications. Aucune communication entre le serveur d'applications et l'équilibreur de charge impliqués. –