Escalabilidade e alta disponibilidade de um aplicativo independente Java

Question

No momento, estamos executando um aplicativo de integração Java em uma máquina Linux. Primeiro uma visão geral da aplicação.

A aplicação Java é um aplicativo independente (não implantado em qualquer servidor de aplicativos Java EE como OracleAS, WebLogic, o JBoss etc). Por Stand Alone I significa que não é um aplicativo de desktop. No entanto, é executado a partir da linha de comando a partir de uma classe principal. O usuário não interage diretamente com este aplicativo em tudo. As mensagens são despejados no fila usando uma API que é então lido pelo meu aplicativo que está funcionando constantemente 24/7. Eu não qualificar isso como um aplicativo de desktop desde que o usuário não tem nenhuma interação direta com ele. (Não tenho certeza se este é o raciocínio correto para se qualificar como um).

Ele usa Primavera e se conecta ao WebSphere MQ e Oracle Database Nós usamos uma mola Listener (Primavera Mensagem POJOs motrizes) que ouve uma fila no WebSphere MQ. Uma vez que há uma mensagem na fila, a aplicação ler a mensagem do MQ e despeja (inserção / actualização) lo na base de dados.

Agora, a questão é:

1. Como podemos dimensionar horizontalmente esta aplicação? Quero dizer apenas colocar mais caixas e executando várias instâncias desta mesma aplicação, é que uma abordagem viável?
2. devemos considerar que se deslocam a partir da Primavera MDPs para EJB MDBs? Assim implantá-lo no servidor de aplicativos. Existe algum benefício adicional ao fazê-lo?
3. Não é um pedido para tornar a aplicação altas disponíveis (HA)? Quais são as metodologias sugeridas ou estratégias que podem ser colocados no lugar para fazer um aplicativo independente HA?

Answer 1

O "independente" == "desktop"?

Como os usuários interagem com o controlador que possui os beans orientados a mensagens?

As minhas opiniões sobre suas perguntas:

1. Você pode dimensionar, adicionando mais ouvintes de mensagens para a piscina ouvinte, já que cada um é executado em seu próprio segmento. Você deve corresponder ao tamanho do pool de conexão do banco de dados para os ouvintes da mensagem, de modo que teria que aumentar também. Faça isso antes de adicionar mais servidores. Verifique se você tem RAM suficiente na mão.
2. Não vejo o que EJB MDB, você compra ao longo da Primavera MDB. Você manter referindo-se a "servidores de aplicativos". Você quer dizer especificamente servidores de aplicação Java EE como WebLogic, WebSphere, JBOSS, Glassfish? Porque se você estiver implantando Primavera no Tomcat eu consideraria Tomcat para ser o "servidor de app" nesta conversa.
3. HA significa balanceamento de carga e failover. Você precisa ter bancos de dados que são ou sincronizadas ou hot reafectados no âmbito. Mesmo com filas. F5 é uma solução excelente hardware para balanceamento de carga. Eu ia falar com seus pais de infra-estrutura se você tiver algum.

Answer 2

Outra opção é Terracotta , um quadro que faz exatamente o que você quer ; executando o seu aplicativo em várias máquinas simultaneamente e equilibrar a carga entre eles.

Answer 3

escalonamento horizontal para qualquer aplicação acabará por correr em limites como demanda para os dados aumenta. Esses limites são determinados pelo desempenho de carga e servidor / banco de dados. Em algum momento, se a demanda e aumento de carga com escala, o número de servidores / bancos de dados terá que aumentar também. Dependendo dos dados que estão sendo armazenados, os servidores / bancos de dados terá que ser repetido e sincronizado, ou algum tipo de algoritmo de hash terá de ser empregado para dados dividido em vários servidores. À medida que aumenta o número de fontes de dados sincronizados o custo de replicar / sincronizar esses servidores também aumenta. É por isso que a abordagem hash pode ser mais atraente para minimizar os custos.

Verdadeiros soluções de alta disponibilidade são muito caro para implementar. Eu vi vários graus de HA bem, mas, por definição, isso significa absoluta mínimo ou nenhum tempo de inatividade, ou perder o acesso à fonte de dados. Para conseguir isso requer um monte de hardware redundante, rede e software que é capaz de utilizar hardware redundante sem perder a capacidade de obter os dados quando uma das fontes de dados falhar. falha de hardware é inevitável, isso vai acontecer, assim como falta de energia e outros atos de natureza. Dependendo do grau de importância destes dados é uma solução HA também vai exigir vários centros de dados em múltiplas redes de energia independentes. Que é, obviamente, vai ser muito caro, por isso tudo depende de quão crítico este dado é para o usuário final.

Assim, HA é um cenário extremo que exige uma arquitetura caro. Acho que a maioria das vezes as pessoas estão interessados ??em apenas minimizar o tempo de inatividade, e, dependendo do tamanho da fonte de dados isso pode ser conseguido razoavelmente barata com a adição de hot-peças das fontes de dados.

Answer 4

1. Horizontal escalar uma aplicação baseada mensagem é fácil ... a maior parte do tempo. Você certamente pode adicionar uma outra operação mensagem ouvinte na mesma fila. Cuidado, porém, porque você pode ter dependências sutis sobre a ordenação das mensagens. Eles podem não ser um problema agora, com apenas um processador, mas com mais de um que está garantido que as mensagens serão processados ??"fora de ordem" em algum ponto.
2. MDPs EJB não oferecem nada além Primavera MDBs. Vara com o que está funcionando.
3. horizontalmente escalar os processadores é um começo, mas este requer um pouco mais discussão.

Para HA, é necessário clarificar os requisitos. "A alta disponibilidade" é uma pergunta interessante para uma aplicação baseada em fila. Se seu aplicativo vai para baixo por alguns minutos, as mensagens se acumulam na fila. Contanto que você pode obter o seu aplicativo voltar a funcionar, essas mensagens ainda são processadas, apenas com um pouco mais de latência. É provavelmente vale a pena perguntar: "Qual é a latência máxima aceitável para uma mensagem?"

Há provavelmente algum componente de preocupação com falhas de hardware, perda de um datacenter, etc. Estes não serão abordados pela escala horizontal no mesmo local. Você vai precisar para replicar todos os componentes em cada camada:. A própria fila, os processadores, o banco de dados back-end, e todo o hardware de rede conectando-los

É uma proposta cara, por isso é também vale a pena perguntar: "Qual é o delta da expectativa de perda anualizada de tempo de inatividade entre um cenário de HA e um cenário não-HA?" ALE incorpora ambos os prejuízos diretos e custos regulatórios ou legais, por isso é uma boa maneira de capturar o custo de downtime.

Answer 5

.1. Criando mais ouvintes na fila pode dimensionar o número de consumidores. Como consumidor morre, os demais consumidores podem continuar correndo. . Nota: o MQ e necessidade do banco de dados para ter soluções de alta disponibilidade, bem

.2. Não tenho certeza que diferença um servidor de aplicativos faria no seu caso. Talvez você poderia explicar quais recursos você pretende usar?

0,3. Veja a minha resposta a 1. para HA.

Answer 6

Você tentou fazer várias caixas? Eu acho que você pode ver o doc de sua MQ? executando várias caixas podem precisar de alguma configuartion em sua MQ, mas ele será executado ISA