[quote=eduveks]
Isto não é bem assim, separar em vários servidores tem muitas vantagens e maior performance, basicamente vc pode ter balanceamento em cada camada, e a velocidade da rede, congestionar a rede? 1GB/s não chega? E se as camadas tiverem ligadas em redes fechadas?
O cenário para uma aplicação de grande porte é este, alguns servidores para cada camada, a quantidade/qualidade dos servidores depende da carga, com balanceamento em todas as camadas.
Este cenário é muito superior a ter tudo em uma máquina só, mesmo q seja uma super máquina, além da garantia de disponibilidade do serviço, muito flexível para contornar problema nas máquinas, além de poder fazer manutenção num servidor e deixar o outro trabalhando e vice-versa.[/quote]
Se você entendeu isso, acho que me expressei mal.
Certamente escalar horizontalmente é bom… O problema que tentei expressar foi ter seus objetos distribuidos… algo como um modulo do sistema em cada servidor, ou então ter a camada de view em um servidor e a camada de negócio em outro etc… isso não vai ajudar com performance, pelo contrario, isso vai ferrar sua performance, ja que pra qualquer funcionalidade irá realizar chamadas remotas em outras jvms.
Este cenário realmente não é bom pra performace… agora você pode ter todo seu projeto deployado em varios servidores em um cluster para conseguir load-balance e até fail-over se for necessário.
[]s
camadas é um conceito… basicamente são 3 (não conheço nenhum outro conceito de mais de 3 camadas…) diante destas 3 camadas vc pode ter varias chamadas varios patterns pode ter uma view que chama um facade que chama um delegate que chama um AS que chama um DAO que faz acesso ao banco…
isto continua sendo 3 camadas mas com varias delegações… mas compensa muito fazer isto? não… até certo ponto esta divisão é boa… mas tenque achar um ponto que a performace e a manutenção sejam adequadas… as camadas devem ser sempre organizada em um ponto que cada uma tenha uma determinada função especifica… e não se pode fragmentar uma função especifica em mais camadas e em colocar mais funçoes para um unica camada… vide o modelo OSI ele é exatamente isto… isto falando de camadas logicas…
porem em camadas fisicas depende muito… tem o custo da velocidade da rede, ruidos e coisas assim… se o sistema for muito grande receber muitas requisições ter muitos acessos é algo que compensa e que ganhara muita performace… mas agora se o sistema for de um porte pequeno com poucas requisições… um sistema de uma pequena/media empresa que so os funcionarios acessem… não a pq dividir em camadas fisicas pois os outros fatores como velocidade de cominicação, da rede, ruidos, etc… irão piorar a performace…
aqui pro cliente que trabalho uma empresa gigantesca com varias filiais no pais… o sistema aqui tem somente o balanceamento de carga de requisições em 2 servidores… e isto funciona bem poraqui…
E lembrando que isso não quer dizer nada em geral. Por mais disco/memória/processador que um nó tenha existem diversos casos onde particionar o trabalho entre máquinas diversas é estupidamente mais rápido. Cada caso é um caso e como eu sempre digo aqui a princial atribuição de um arquiteto é avaliar estes casos -e por isso que arquitetura de referência é besteira.
Dividir sua aplicação em camadas pode te trazer diversos benefícios entre eles manutenção, reúso de código, escalabilidade e blá blá blá.
Mas para vc usufruir dessas vantagens o produto deve ser bem projetado visando alta coesão e baixo acoplamento. Para evitar camadas algumas “vazias” e outras “inchadas”… Como aconteceu tanto no OSI qto no TCP
Enquanto a performance se vc concordar comigo que até comunicações de rede, que geralmente procuram confiabilidade e velocidade, são construidas em cima de uma pilha de protocolos pq com software não pode ser igual.