Une solution Java EE évolutive et performante?

Question

Supposons que nous voulions concevoir un système d'application Web Java EE qui devrait présenter des performances et une efficacité élevées dans les réponses, car trop d'utilisateurs peuvent envoyer des demandes aux services.

Je pense à déployer les instances d'application sur différents serveurs d'applications (JBoss, Tomcat, etc.). Nous avons donc la notion de "cluster de serveurs d'applications". Et cette application nécessite que certaines données soient traitées sur différents moteurs qui sont à nouveau installés sur des serveurs différents.

Nous avons donc aussi la notion de "cluster of engine servers". Et supposons que nous accédions à l'application à partir d'un seul point, par ex. à partir d'une URL simple. Comment relier cette URL avec le cluster de serveurs d'applications? Quel genre de stratégies devrait-on mettre en place pour concevoir un tel système composé de serveurs d'application et d'autres serveurs qui doivent communiquer aussi efficacement que possible?

Toutes les solutions et suggestions sont les bienvenues. Si vous avez fait face à des problèmes du monde réel similaires, pouvez-vous m'aider? Et toutes les suggestions de tutoriels, livres électroniques, échantillons sont également les bienvenues.

Answer 1

Pour répondre à (certaines) vos questions:

• Comment relier cette URL avec le cluster de serveurs d'applications? Utilisez un équilibreur de charge devant vos serveurs Web - utilisez de préférence un serveur matériel (plus rapide), mais vous pouvez le construire avec un PC/matériel normal (par exemple haproxy)
• Quels types de stratégies devraient être mis en œuvre pour concevoir un tel système composé de serveurs d'applications et d'autres serveurs qui sont nécessaires pour communiquer aussi efficace que possible? Selon le type de données que vous échangez et comment. Si vous n'avez pas besoin d'appels synchrones, vous pouvez probablement consulter la messagerie - JMS, ActiveMQ ou RabbitMQ; alors envoyez un message aux serveurs backend et demandez à un autre thread d'attendre les réponses, quand la réponse arrivera le ramasser et l'envoyer. Si vous avez besoin d'une communication synchrone, il y a beaucoup d'options - de la simple communication basée sur socket, à RMI, SOAP, etc. Il faut tenir compte de la quantité de données échangées entre les 2 couches.