Evolutivité et haute disponibilité d'une application autonome Java

Question

Nous courons actuellement une application d'intégration Java sur un système Linux. Tout d'abord une vue d'ensemble de l'application.

L'application Java est une application autonome (non déployée sur un serveur d'applications Java EE comme OracleAS, WebLogic, JBOSS, etc.). En Stand Alone Je veux dire ne est pas une application DESKTOP. Cependant, il est exécuté à partir de la ligne de commande d'une classe principale. L'utilisateur ne réagit pas directement avec cette application du tout. Les messages sont jetés dans la file d'attente à l'aide d'une API qui est ensuite lu par ma demande qui est constamment en cours d'exécution 24/7. Je ne qualifierais pas cela comme une application de bureau puisque l'utilisateur n'a pas d'interaction directe avec elle. (Je ne sais pas si cela est le raisonnement correct de se qualifier comme l'un).

Il utilise Spring et se connecte à WebSphere MQ et Oracle Database Nous utilisons un Listener Spring (Message Driven printemps de POJO) qui écoute une file d'attente sur WebSphere MQ. Une fois qu'il ya un message dans la file d'attente, la demande de lire le message de la MQ et les décharges (insertion / mise à jour) dans la base de données.

Maintenant, la question est la suivante:

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 qu'une approche viable?
2. Faut-il envisager de passer du printemps à MDPs EJB BDM? De ce fait le déploiement sur le serveur d'applications. Y at-il avantage en le faisant?
3. Il y a une demande de rendre l'application disponible Haute (HA)? Quelles sont les méthodes ou stratégies proposées qui peuvent être mises en place pour une application autonome HA?

Answer 1

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

Comment les utilisateurs interagissent avec le contrôleur qui possède les beans gérés par message?

Mes opinions sur vos questions:

1. Vous pouvez évoluer en ajoutant plus d'auditeurs de message à la piscine d'écoute, puisque chacun exécute dans son propre fil. Vous devez correspondre à la taille du pool de connexion de base de données pour les auditeurs de message, de sorte que devrait augmenter aussi bien. Faites cela avant d'ajouter plusieurs serveurs. Assurez-vous que vous avez suffisamment de RAM sur la main.
2. Je ne vois pas ce que MDB EJB achète sur Spring MDB. Vous gardez référence aux « serveurs d'applications ». Voulez-vous dire spécifiquement les serveurs d'applications Java EE comme WebLogic, WebSphere, JBOSS, Glassfish? Parce que si vous déployez Spring sur Tomcat je considère Tomcat être le dans cette conversation « serveur d'application ».
3. HA des moyens d'équilibrage de charge et le basculement. Vous aurez besoin d'avoir des bases de données qui sont soit synchronisés ou chaud redéployables. Même avec les files d'attente. F5 est une solution matérielle pour l'équilibrage de charge. Je parler à vos gens d'infrastructure si vous en avez.

Answer 2

Une autre option est Terre cuite , un cadre qui fait exactement ce que vous voulez ; l'exécution de votre application sur plusieurs machines simultanément et équilibrer la charge entre eux.

Answer 3

mise à l'échelle horizontale pour toute application finira par atteindre les limites que la demande pour les augmentations de données. Ces limites sont déterminées par la charge et les performances du serveur / base de données. À un moment donné, si l'augmentation de la demande et la charge avec mise à l'échelle, le nombre de serveurs / bases de données devront augmenter. Selon les données qui sont stockées, les serveurs / bases de données soit être dupliqués et synchronisés, ou une sorte d'algorithme de hachage devra être utilisé pour diviser les données sur plusieurs serveurs. Comme vous augmentez le nombre de données synchronisées sources les coûts de réplication / synchronisation de ces serveurs augmente également. Voilà pourquoi l'approche peut être plus hachée attrayante pour minimiser les coûts.

True solutions de haute disponibilité sont très coûteux à mettre en œuvre. Je l'ai vu divers degrés de HA ainsi, mais, par définition, cela signifie peu ou pas de temps d'arrêt absolu, ou perdre l'accès à la source de données. Pour parvenir à cela nécessite beaucoup de matériel redondant, la mise en réseau et un logiciel qui est capable d'utiliser du matériel redondant sans perdre la capacité d'obtenir les données lorsque l'une des sources de données échoue. défaillance matérielle est inévitable, il va se passer, ainsi que des pannes de courant et d'autres actes aléatoires de la nature. Selon la façon dont ces données critiques est une solution HA également besoin de plusieurs centres de données sur plusieurs réseaux électriques indépendants. Ce qui est évidemment va être très cher, donc tout dépend de la façon dont ces données est essentielle pour l'utilisateur final.

Alors, HA est un scénario extrême nécessitant une architecture coûteuse. Je trouve que la plupart des gens de temps sont intéressés tout en minimisant les temps d'arrêt, et en fonction de la taille de la source de données, cela peut être réalisé assez peu de frais avec l'ajout de disques hot-spare des sources de données.

Answer 4

1. mise à l'échelle horizontale un message application est facile ... conduit la plupart du temps. Vous pouvez certainement ajouter un autre écouteur de messages fonctionnant sur la même file d'attente. Attention, cependant, parce que vous pourriez avoir des dépendances subtiles sur l'ordre des messages. Ils pourraient ne 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. EJB n'offrent MDPs rien au-delà du printemps BDM. Tenez-vous avec ce qui fonctionne.
3. mise à l'échelle Horizontalement les processeurs est un début, mais celui-ci a besoin d'un peu plus de discussion.

Pour HA, vous avez besoin de clarifier les exigences. « Haute disponibilité » est une question intéressante pour une application basée sur une file. Si votre application descend pendant quelques minutes, les messages empilent dans la file d'attente. Tant que vous pouvez obtenir votre application de sauvegarde et en cours d'exécution, ces messages seront toujours se traiter, avec juste un peu plus de latence. Il est sans doute utile de se demander: « Quel est le temps d'attente maximal acceptable pour un message? »

Il y a probablement une composante de préoccupation au sujet des défaillances matérielles, la perte d'un centre de données, etc. Ceux-ci ne seront pas traités par mise à l'échelle horizontale dans le même endroit. Vous devrez dupliquer tous les composants à chaque couche:. La file d'attente elle-même, les processeurs, la base de données back-end, et tout le matériel de réseau qui les relie

Il est une proposition coûteuse, il est également intéressant de demander: « Quel est le delta de l'espérance de perte annualisée de temps d'arrêt entre un scénario de haute disponibilité et un scénario non-HA? » ALE intègre les pertes directes et les coûts réglementaires ou juridiques, il est donc une bonne façon de déterminer le coût des temps d'arrêt.

Answer 5

.1. Créer plus d'auditeurs sur la file d'attente peut évoluer le nombre de consommateurs. En tant que consommateur meurt, les autres consommateurs peuvent continuer à fonctionner. Remarque:. Votre MQ et la base de données ont besoin d'avoir des solutions de haute disponibilité et

0,2. Je ne sais pas quelle différence un serveur d'application serait dans votre cas. Peut-être pourriez-vous expliquer les fonctionnalités que vous souhaitez utiliser?

0,3. Voir ma réponse à 1. HA.

Answer 6

Avez-vous essayé de faire plusieurs boîtes? Je pense que vous pouvez voir le doc de votre MQ? en cours d'exécution boîtes multiples peut avoir besoin d'configuartion dans votre MQ, mais il fonctionnera ISA