Como posso escalar o contexto da aplicação de mola?

5

Atualmente, estou trabalhando em um projeto que precisa ser dinamicamente dimensionado sob demanda de acordo com a necessidade.

Minha pergunta é sobre escalar o contexto da primavera. Meu aplicativo da web tem um núcleo multi-módulo clássico (serviço, persistência, domínio), que usa o uso por aplicativo cliente (webapp, api).

O aplicativo final do usuário também pode ser armazenado em cluster, mas eu não sei como prosseguir com o contexto da primavera.

Eu pretendo usar os atores do Scala Akka no serviço Spring, mas não posso ser persuadido pela solução de usar um contexto exposto pelos atores. Todo o restante do aplicativo é construído com técnicas orientadas a eventos (os eventos do Spring são produzidos pela camada de serviço).

Eu já criei diferentes aplicativos da Web por perfil de usuário para escalar de acordo com a função do usuário (por exemplo, admin, enduser), no entanto, a única coisa é o Spring Context para operações comerciais.

Pergunta: Preciso mesclar em um único contexto compartilhado por todos os aplicativos clientes ou devo inicializar um contexto por aplicativo?

http://i.stack.imgur.com/0ysv7.png

    
por Zenithar 11.02.2013 / 14:41
fonte

1 resposta

1

É um pouco difícil entender seus diagramas, como é a seção front-end na parte esquerda é toda a arquitetura de aplicativos cliente? e a seção direita é o lado do servidor? Embora, ainda assim, eu não consiga entender por que você tem o banco de dados e camada de mola no front-end - é um banco de dados exclusivamente local para cada aplicativo cliente?

Mas, para dar a minha ideia, a tendência comum ao usar o contexto de aplicativos Spring é torná-lo como singleton, significando um contexto de primavera no lado do servidor, isso é a essência dele, ou então você já desafiou seu propósito. Os beans (por exemplo, serviços) devem ser sem estado, para não produzir resultados indesejáveis que possam resultar em problemas de simultaneidade de mais de um cliente solicitando a mesma coisa e precisariam usar os mesmos beans / services. Torná-los singleton, é claro, é a maneira ideal de economizar memória e evitar a criação de instâncias sob demanda, e após o uso é apenas para coleta de lixo. Não haverá afunilamento, mas, na verdade, seria mais rápido porque o objeto já está carregado na memória e cada solicitação terá seu próprio heap ao executar esse objeto uma vez chamado. Então, basicamente, singleton é mais rápido e economiza mais memória.

    
por 20.02.2013 / 14:49
fonte