Escalabilidad y alta disponibilidad de una aplicación Java independiente

Question

Actualmente estamos ejecutando una aplicación de integración Java en una máquina Linux.Primero una descripción general de la aplicación.

La aplicación Java es una aplicación independiente (no implementada en ningún servidor de aplicaciones Java EE como OracleAS, WebLogic, JBOSS, etc.).Por Stand Alone me refiero a que NO es una aplicación de ESCRITORIO.Sin embargo, se ejecuta desde la línea de comando desde una clase principal.El usuario no interactúa directamente con esta aplicación en absoluto.Los mensajes se colocan en la cola mediante una API que luego mi aplicación lee, que se ejecuta constantemente las 24 horas del día, los 7 días de la semana.No calificaría esto como una aplicación de escritorio ya que el usuario no tiene interacción directa con ella (no estoy seguro de si este es el razonamiento correcto para calificar como tal).

Utiliza Spring y se conecta a WebSphere MQ y Oracle Database Utilizamos un Spring Listener (Spring Message Driven POJOs) que escucha una cola en WebSphere MQ.Una vez que hay un mensaje en la cola, la aplicación lee el mensaje del MQ y lo vuelca (inserta/actualiza) en la base de datos.

Ahora la pregunta es:

1. ¿Cómo podemos escalar horizontalmente esta aplicación?Me refiero a simplemente poner más cuadros y ejecutar múltiples instancias de esta misma aplicación, ¿es ese un enfoque viable?
2. ¿Deberíamos considerar pasar de los MDP de Spring a los BMD de EJB?Implementándolo así en el servidor de aplicaciones.¿Hay algún beneficio adicional al hacerlo?
3. ¿Existe una solicitud para que la aplicación tenga alta disponibilidad (HA)?¿Cuáles son las metodologías o estrategias sugeridas que se pueden implementar para crear una aplicación HA independiente?

Answer 1

¿El "independiente" == "escritorio"?

¿Cómo los usuarios interactúan con el controlador que posee los beans controlados por mensajes?

Mis opiniones sobre sus preguntas:

1. Usted puede escalar añadiendo más escuchas de mensajes a la piscina oyente, ya que cada uno se ejecuta en su propio hilo. Que debe coincidir con el tamaño de la agrupación de conexiones de base de datos a escuchas de mensajes, de manera que tendría que aumentar también. Hacerlo antes de añadir más servidores. Asegúrese de que tiene suficiente memoria RAM en la mano.
2. No veo lo EJB MDB le compra más de Primavera MDB. A mantener en referencia a "servidores de aplicaciones". Qué quiere decir específicamente servidores de aplicaciones Java EE como WebLogic, WebSphere, JBoss, Glassfish? Porque si va a implementar la primavera en Tomcat Tomcat que yo consideraría que es el "servidor de aplicaciones" en esta conversación.
3. HA significa equilibrio de carga y conmutación por error. Tendrá que tener bases de datos que se sincronizan uno o reasignables caliente. Lo mismo pasa con las colas. F5 es una solución de gran hardware para equilibrar la carga. Me hablar con su gente de infraestructura si tiene alguna.

Answer 2

Otra opción es terracota , un marco que hace precisamente lo que quiere ; el funcionamiento de su aplicación en varias máquinas simultáneamente y equilibrar la carga entre ellos.

Answer 3

El escalado horizontal para cualquier aplicación eventualmente llegará a sus límites a medida que aumente la demanda de datos.Esos límites están determinados por la carga y el rendimiento del servidor/base de datos.En algún momento, si la demanda y la carga aumentan con el escalado, la cantidad de servidores/bases de datos también tendrá que aumentar.Dependiendo de los datos que se almacenen, los servidores/bases de datos deberán duplicarse y sincronizarse, o será necesario emplear algún tipo de algoritmo hash para dividir los datos en varios servidores.A medida que aumenta la cantidad de fuentes de datos sincronizadas, el costo de replicar/sincronizar esos servidores también aumenta.Es por eso que el enfoque hash puede resultar más atractivo para minimizar costos.

Las verdaderas soluciones de alta disponibilidad son muy costosas de implementar.También he visto varios grados de HA, pero por definición significa un tiempo de inactividad mínimo o nulo, o pérdida de acceso a la fuente de datos.Para lograr esto se requiere una gran cantidad de hardware, redes y software redundantes que puedan utilizar hardware redundante sin perder la capacidad de acceder a los datos cuando falla una de las fuentes de datos.Las fallas de hardware son inevitables, sucederán, así como también los cortes de energía y otros fenómenos naturales aleatorios.Dependiendo de cuán críticos sean estos datos, una solución HA también requerirá múltiples centros de datos en múltiples redes eléctricas independientes.Lo que obviamente va a ser muy caro, por lo que todo depende de qué tan críticos sean estos datos para el usuario final.

Por lo tanto, HA es un escenario extremo que requiere una arquitectura costosa.Encuentro que la mayoría de las veces la gente está interesada simplemente en minimizar el tiempo de inactividad y, dependiendo del tamaño de la fuente de datos, esto se puede lograr de manera bastante económica agregando repuestos dinámicos de las fuentes de datos.

Answer 4

1. Escalar horizontalmente una aplicación basada en mensajes es fácil...la mayor parte del tiempo.Ciertamente puedes agregar otro detector de mensajes que opere en la misma cola.Sin embargo, tenga cuidado porque puede tener dependencias sutiles en el orden de los mensajes.Puede que ahora no sean un problema, con un solo procesador, pero con más de uno se garantiza que los mensajes se procesarán "desordenados" en algún momento.
2. Los MDP de EJB no ofrecen nada más que los MDB de Spring.Cíñete a lo que funciona.
3. Escalar horizontalmente los procesadores es un comienzo, pero éste requiere un poco más de discusión.

Para HA, es necesario aclarar los requisitos."Alta disponibilidad" es una pregunta interesante para una aplicación basada en colas.Si su aplicación deja de funcionar durante unos minutos, los mensajes se acumulan en la cola.Mientras puedas hacer que tu aplicación vuelva a funcionar, esos mensajes aún se procesarán, solo que con un poco más de latencia.Probablemente valga la pena preguntarse: "¿Cuál es la latencia máxima aceptable para un mensaje?"

Probablemente exista algún componente de preocupación sobre fallas de hardware, pérdida de un centro de datos, etc.Estos no se solucionarán mediante el escalado horizontal en la misma ubicación.Necesitará replicar todos los componentes en cada capa:la cola en sí, los procesadores, la base de datos backend y todo el hardware de red que los conecta.

Es una propuesta costosa, por lo que también vale la pena preguntarse: "¿Cuál es el delta en la expectativa de pérdida anualizada del tiempo de inactividad entre un escenario de alta disponibilidad y un escenario que no es de alta disponibilidad?" El ALE incorpora tanto las pérdidas directas como los costes normativos o legales, por lo que es una buena forma de capturar el coste del tiempo de inactividad.

Answer 5

0.1. La creación de más oyentes en la cola se puede ampliar el número de consumidores. Como muere un consumidor, los consumidores restantes pueden seguir funcionando. Nota:. Su MQ y la base de datos necesita tener soluciones de alta disponibilidad, así

0.2. No está seguro de lo que diferencia un servidor de aplicaciones haría en su caso. Tal vez podría explicar las características que va a utilizar?

0.3. Véase mi respuesta a 1. para HA.

Answer 6

¿Ha intentado hacer varias cajas? Creo que es posible que vea el documento de la MQ? la ejecución de varias cajas puede necesitar algún configuartion en su MQ pero se ejecutará ISA