Introdução à arquitetura de três camadas
A arquitetura de três camadas é a arquitetura de interação mais comum na Internet. Apareceu quando a parte do servidor de duas camadas foi dividida em duas partes: uma camada lógica e uma camada de dados .
Parecia algo assim:
A camada do cliente é a parte do "aplicativo distribuído" responsável pela interação do usuário. Essa camada não deve conter lógica de negócios e não deve armazenar dados críticos. Além disso, ele não deve interagir diretamente com a camada de banco de dados, mas apenas por meio da camada de lógica de negócios.
No entanto, ainda há alguma lógica aqui. Em primeiro lugar, trata-se da interação com o usuário por meio da interface, validação dos dados por ele inseridos, trabalho com arquivos locais. Isso também inclui tudo relacionado à autorização do usuário e criptografia de dados ao trabalhar com o servidor.
Em segundo lugar, é uma lógica de negócios simples. Por exemplo, se uma loja online enviou uma lista de produtos, podemos classificá-los e filtrá-los no lado do cliente. E o armazenamento de dados primitivo também está aqui: cache, cookies de usuários logados e similares.
A camada de lógica de negócios está localizada no segundo nível, a maior parte da lógica de negócios está concentrada nela. Fora dele, permanecem apenas os fragmentos que são exportados para o cliente, bem como os elementos lógicos que estão imersos no banco de dados (stored procedures e triggers).
Uma grande parte do servidor de lógica de negócios contém não apenas essa mesma lógica, mas também resolve problemas de dimensionamento: o código é dividido em partes e distribuído para diferentes servidores. Alguns serviços altamente demandados podem ser executados em dezenas de servidores. A carga entre eles é gerenciada pelo balanceador de carga.
Os aplicativos de servidor geralmente são projetados de forma que outra cópia do servidor possa ser facilmente iniciada e começar a trabalhar em cooperação com outras cópias dele. Ou seja, mesmo no processo de escrever o código do servidor, você nunca terá garantias de que sua classe estática seja lançada em uma única instância.
A camada de dados fornece armazenamento de dados e é colocada em um nível separado, implementada, via de regra, por meio de sistemas de gerenciamento de banco de dados (DBMS), a conexão a esse componente é fornecida apenas a partir do nível do servidor de aplicativos.
Razões para separar a camada de dados
A separação da camada de dados em uma terceira camada completa ocorreu por vários motivos, mas o principal é o aumento da carga no servidor.
Primeiro, os bancos de dados começaram a exigir muita memória e tempo de processador para processamento de dados. Portanto, eles começaram a ser colocados em todos os lugares em servidores separados.
Com carga aumentada, o back-end poderia ser facilmente duplicado e dez cópias de um servidor poderiam ser criadas, mas era impossível duplicar o banco de dados - o banco de dados ainda permanecia um componente único e indivisível do sistema.
Em segundo lugar, os bancos de dados se tornaram inteligentes - eles têm sua própria lógica de negócios. Eles começaram a suportar stored procedures, triggers, suas próprias linguagens como PLSQL. E até apareceram programadores que começaram a escrever códigos que rodam dentro do DBMS.
Toda a lógica que não estava vinculada aos dados foi levada para o back-end e lançada em paralelo em dezenas de servidores. Tudo o que é criticamente vinculado aos dados permaneceu dentro do DBMS, e já lá os problemas do aumento de carga tiveram que ser resolvidos usando nossos próprios métodos:
- Um cluster de banco de dados é um grupo de servidores de banco de dados que armazenam os mesmos dados e os sincronizam usando um protocolo específico.
- Sharding - os dados são divididos em blocos lógicos e distribuídos em diferentes servidores de banco de dados. É muito difícil manter as alterações do banco de dados com essa abordagem.
- A abordagem NoSQL é armazenar dados em bancos de dados criados para armazenar grandes quantidades de dados. Freqüentemente, nem são bancos de dados, mas armazenamentos de arquivos específicos. Funcionalidade muito ruim em comparação com bancos de dados relacionais.
- Cache de dados. Em vez de um simples cache no nível do banco de dados, apareceu todo o cache do DBMS, que armazenava o resultado apenas na memória.
É claro que pessoas separadas e/ou equipes inteiras eram necessárias para gerenciar esse zoológico de tecnologias de servidor, o que levou à remoção da camada de dados para uma camada separada.
Importante! Todas as tecnologias avançadas nascem nas profundezas das grandes corporações de TI, quando as velhas abordagens não lidam mais com os novos desafios. Fazer bancos de dados em uma camada separada não foi inventado por nenhum programador, mas por um grupo de engenheiros em algum lugar nas profundezas da Oracle ou da IBM.
Interessante! Quando Zuckerberg começou a escrever o Facebook, ele trabalhava simplesmente com PHP + MySQL. Quando havia milhões de usuários, eles escreveram um tradutor especial que traduzia todo o código PHP em C ++ e o compilava em código de máquina nativo.
Além disso, o MySQL não é capaz de armazenar os dados de bilhões de usuários, então o Facebook desenvolveu o conceito de bancos de dados NoSQL e escreveu um poderoso DBMS NoSQL do lado do servidor - Cassandra. By the way, é totalmente escrito em Java.
Ambiguidade de localização da lógica do aplicativo
E embora uma arquitetura de três camadas distribua funções quase inequivocamente entre suas partes, nem sempre é possível determinar corretamente exatamente onde no sistema uma nova parte da lógica de negócios (novo código) precisa ser adicionada.
Um exemplo dessa ambigüidade é mostrado na figura abaixo:
A parte do servidor é preenchida com fundo cinza, a parte do cliente é preenchida com branco. Um bom exemplo da última abordagem (extrema direita) são os aplicativos móveis modernos. O lado do cliente (no telefone) contém a visualização (display), a lógica e os dados. E apenas às vezes esses dados são sincronizados com o servidor.
Um exemplo da opção mais à esquerda é um servidor PHP típico, que tem toda a lógica no servidor e fornece ao cliente HTML já estático. Em algum lugar entre esses dois extremos, seu projeto estará localizado.
No início do trabalho, depois de conhecer o projeto, você precisará consultar os programadores que trabalham nele, sobre os locais onde é melhor para você implementar a lógica da próxima tarefa.
Sinta-se a vontade para fazer isso. Em primeiro lugar, eles não sobem no mosteiro de outra pessoa com sua carta. Em segundo lugar, será mais fácil para todos (e para você também) encontrar o código de que precisa no local onde espera encontrá-lo.