Comment éviter les inondations dans mon application Web très simple et la rendre évolutive?

Question

J'essaie de développer une application Web Java très simple à l'aide de JSP et de servlets.

1) Il y a une zone de texte et un bouton de soumission sur la page,
2) L'utilisateur entre son nom, disons John, à la zone de texte et clique sur le bouton,
3) La chaîne est transmise à mon servlet,
4) Sur la méthode DOSTOST de mon servlet, j'accéderai à la variable de chaîne publiée,
5) Le service Web que j'utiliserai a un sayHello Méthode qui prend un argument et revient "Hello " concaténé avec l'argument,
6) Alors, j'appelle le sayHello Méthode du service Web, obtenez la variable retournée et transmettez-la à un JSP, qui écrit essentiellement Hello John.

J'ai 2 questions:

1) Inondation: Comment éviter les inondations des demandes à mon servlet? Comment puis-je y faire face? J'ai pensé à créer un fil pour contacter le service Web et à dire bonjour. Lorsqu'une demande arrive, je vérifie si le thread est en cours d'exécution / occupé, sinon, je traite la demande. Par conséquent, je répondrais au plus 1 demande par unité de temps. Comment ça sonne?

2) Évolutivité: Supposons que ce soir, 1 000 000 de personnes atteindront mon application Web et feront dire mon application dix fois chacune. Comment puis-je m'assurer que cette application va bien évoluer? Tout ce que je peux faire concernant la partie JSP / servlet, autre que le matériel dont le serveur dépend?

Je sais que les questions sont en quelque sorte génériques, j'ai donc essayé de fournir autant de détails que possible. J'apprécierais vraiment une réponse approfondie et au point =)

Merci d'avance.

Answer 1

Vous pouvez faire beaucoup de choses pour le rendre "évolutif".

D'une part, le servlet est d'une charge aussi mineure que ce n'est probablement pas l'endroit où la charge est un problème; Le service Web est. Vous pouvez fournir deux types d'échelle - horizontal et vertical - ici.

La mise à l'échelle horizontale est lorsque vous servez la demande à la même vitesse, mais pouvez en gérer davantage. Ceci est fourni par l'équilibrage de charge, via F5 ou un autre équilibreur de charge, et avoir les applications Web servies par plusieurs serveurs Web.

La mise à l'échelle verticale est lorsque vous lancez un processeur plus rapide au problème. Horizontal est meilleur.

La gestion du service lui-même est votre point de défaillance d'évolutivité, car c'est là que le travail réel est effectué. Dans ce cas, vous avez un service simple, vous pouvez donc faire la même chose avec la sérice Web que vous faites avec le servlet. Mais si le problème est "plus difficile" - eh bien, c'est là que vous commencez à utiliser JMS pour fournir des services asynchrones, de sorte que vos fournisseurs de services consomment des demandes et fournissent des réponses Dès qu'ils peuvent. Cela vous donne un endroit naturel pour ajouter plus de consommateurs, donc si vous trouvez que votre service JMS n'est pas en mesure de gérer les demandes, vous ajoutez un autre consommateur (un autre serveur écoutant une file d'attente); Si cela n'est pas en mesure de suivre, laver, rincer, répéter.

Bien sûr, il existe également des solutions cloud au problème; Je travaille pour Gigaspaces Technologies, qui fournit un service pour l'évolutivité horizontale pour les services Web, et nous faisons un bien meilleur travail que la solution que je viens de décrire. Pour voir comment cela fonctionne, voir http://www.youtube.com/watch?v=yteqfzrfvsss .

Answer 2

1. Votre solution pourrait épargner la journée des inondations, mais aura un très mauvais impact sur la disponibilité de l'application. La principale cause des inondations est trop de demandes provenant de la même machine avec des intentions malveillantes de bloquer votre application. Je suggère donc d'associer des identifiants de session avec des identifiants de fil. En d'autres termes, vous ne traiterez qu'une seule demande d'un utilisateur à la fois. Le prochain ne sera traité que lorsque le premier sera terminé.

2. Je préfère aller avec la solution de @joseph ottinger