Évolutivité et haute disponibilité d'une application Java autonome

Question

Nous exécutons actuellement une application d'intégration Java sur une machine Linux. D'abord un aperçu de l'application. L'application Java est une application autonome (non déployée sur un serveur d'application Java EE tel que OracleAS, WebLogic, JBOSS, etc.). Par Stand Alone, je veux dire que ce n'est pas une application de BUREAU. Cependant, il est exécuté à partir de la ligne de commande à partir d'une classe Main. L'utilisateur n'interagit pas directement avec cette application. Les messages sont déversés dans la file d'attente à l'aide d'une API qui est ensuite lue par mon application, qui fonctionne constamment 24h/24 et 7j/7. Je ne qualifierais pas cela comme une application de bureau puisque l'utilisateur n'a pas d'interaction directe avec lui (je ne sais pas si c'est le raisonnement correct pour se qualifier comme un). Il utilise Spring et se connecte à WebSphere MQ et Oracle Database Nous utilisons un écouteur Spring (Spring Message Driven POJO) qui écoute une file d'attente sur WebSphere MQ. Une fois qu'il y a un message dans la file d'attente, l'application lit le message à partir du MQ et le vide (insère/met à jour) dans la base de données.

Maintenant, la question est:

1. Comment l'échelle horizontalement cette application? Je veux dire simplement mettre plus de boîtes et exécuter plusieurs instances de cette même application, est-ce une approche viable?
2. Devrions-nous envisager de passer des MDPs de Spring aux MDB EJB? De ce fait, le déployer sur le serveur d'applications. Y a-t-il un avantage supplémentaire à le faire?
3. Une demande de création de l'application Haute disponibilité (HA) est-elle demandée? Quelles sont les méthodologies ou stratégies suggérées qui peuvent être mises en place pour créer une application autonome?

Answer 1

Est-ce que "standalone" == "desktop"?

Comment les utilisateurs interagissent-ils avec le contrôleur propriétaire des beans pilotés par message?

Mes opinions sur vos questions:

1. Vous pouvez faire évoluer en ajoutant plus d'auditeurs de message à la piscine d'écoute, puisque chacun exécute dans son propre fil. Vous devez faire correspondre la taille du pool de connexions de la base de données aux écouteurs de message, ce qui devrait également augmenter. Faites cela avant d'ajouter plus de serveurs. Assurez-vous d'avoir suffisamment de RAM à portée de main.
2. Je ne vois pas ce que EJB MDB vous achète sur Spring MDB. Vous continuez à faire référence aux "serveurs d'applications". Parlez-vous spécifiquement des serveurs d'applications Java EE tels que WebLogic, WebSphere, JBOSS, Glassfish? Parce que si vous déployez Spring sur Tomcat, je considérerais Tomcat comme le "serveur d'application" dans cette conversation.
3. HA signifie équilibrage de charge et basculement. Vous devez disposer de bases de données synchronisées ou redéployables à chaud. Même avec les files d'attente. F5 est une excellente solution matérielle pour l'équilibrage de charge. Je parlerais à vos employés de l'infrastructure si vous en avez.

Answer 2

La mise à l'échelle horizontale de toute application finira par se heurter à des limites à mesure que la demande pour les données augmente. Ces limites sont déterminées par la charge et les performances du serveur/de la base de données. À un certain point, si la demande et la charge augmentent avec la mise à l'échelle, le nombre de serveurs/bases de données devra également augmenter. En fonction des données stockées, les serveurs/bases de données devront être dupliqués et synchronisés, ou une sorte d'algorithme de hachage devra être utilisé pour répartir les données sur plusieurs serveurs. À mesure que vous augmentez le nombre de sources de données synchronisées, le coût de réplication/synchronisation de ces serveurs augmente également.C'est pourquoi l'approche hachée peut être plus attrayante pour minimiser les coûts.

Les solutions True High Availability sont très coûteuses à mettre en œuvre. J'ai également vu divers degrés de HA, mais par définition, cela signifie un temps d'arrêt absolu minimal ou nul, ou un manque d'accès à la source de données. Pour y parvenir, il faut beaucoup de matériel, de réseau et de logiciel redondants capables d'utiliser du matériel redondant sans perdre la possibilité d'accéder aux données lorsque l'une des sources de données tombe en panne. La panne matérielle est inévitable, cela arrivera, ainsi que les coupures de courant et autres actes aléatoires de la nature. Selon la gravité de ces données, une solution haute disponibilité nécessitera plusieurs centres de données sur plusieurs réseaux électriques indépendants. Ce qui est évidemment très cher, donc tout dépend de la façon dont ces données sont critiques pour l'utilisateur final. Donc, HA est un scénario extrême nécessitant une architecture coûteuse. Je trouve que la plupart du temps, les gens sont intéressés à minimiser les temps d'arrêt, et en fonction de la taille de la source de données, cela peut être réalisé à peu de frais en ajoutant des disques de secours des sources de données.

Answer 3

Une autre option est Terracotta, une structure qui fait exactement ce que vous voulez; exécuter votre application sur plusieurs machines simultanément et équilibrer la charge entre elles.

Answer 4

1. La mise à l'échelle horizontale d'une application axée sur les messages est facile ... la plupart du temps. Vous pouvez certainement ajouter un autre écouteur de message fonctionnant sur la même file d'attente. Méfiez-vous, cependant, parce que vous pourriez avoir des dépendances subtiles sur l'ordre des messages. Ils ne peuvent pas être un problème maintenant, avec un seul processeur, mais avec plus d'un, vous êtes assuré que les messages seront traités "hors service" à un moment donné.
2. Les MDP EJB n'offrent rien d'autre que les MDB Spring. Stick avec ce qui fonctionne.
3. Mise à l'échelle horizontale des processeurs est un début, mais celui-ci nécessite un peu plus de discussion.

Pour HA, vous devez clarifier les exigences. La "haute disponibilité" est une question intéressante pour une application basée sur une file d'attente. Si votre application est désactivée pendant quelques minutes, les messages s'accumulent dans la file d'attente. Tant que vous pouvez restaurer votre application, ces messages seront toujours traités, avec un peu plus de latence. Cela vaut probablement la peine de demander: "Quelle est la latence maximale acceptable pour un message?" Il y a probablement un élément de préoccupation concernant les défaillances matérielles, la perte d'un centre de données, etc. Ces problèmes ne seront pas corrigés par une mise à l'échelle horizontale au même emplacement. Vous devrez répliquer tous les composants à chaque couche: la file d'attente elle-même, les processeurs, la base de données principale et tout le matériel réseau qui les connecte. C'est une proposition coûteuse, et il vaut donc la peine de se demander: «Quel est le delta de l'espérance de perte annualisée de temps d'arrêt entre un scénario HA et un scénario non HA? ALE intègre à la fois les pertes directes et les coûts réglementaires ou juridiques, c'est donc un bon moyen de saisir le coût des temps d'arrêt.

Answer 5

.1. Créer plus d'auditeurs dans la file d'attente peut augmenter le nombre de consommateurs. En tant que consommateur meurt, les consommateurs restants peuvent continuer à fonctionner. Remarque: Votre MQ et votre base de données doivent également disposer de solutions à haute disponibilité.

.2. Vous ne savez pas quelle différence un serveur d'applications ferait dans votre cas. Peut-être pourriez-vous expliquer quelles fonctionnalités vous souhaitez utiliser?

.3. Voir ma réponse à 1. pour HA.

Answer 6

Avez-vous essayé de créer plusieurs boîtes? Je pense que vous pouvez voir le doc de votre MQ? l'exécution de plusieurs boîtes peut avoir besoin d'une certaine configuration dans votre MQ mais elle fonctionnera ISA