🤳🏼 🤸🏾 😕 Arquitetura cliente-servidor em imagens ⛓️ 🧘🏾 ⁉️

Uma imagem familiar? Mas você é constantemente confrontado com essa arquitetura - ao comprar um ingresso de cinema on-line, reservar um ingresso para o mar ou marcar uma consulta com um médico.

Na arquitetura cliente-servidor, todos os sites e serviços da Internet são criados. Também é usado por programas de desktop que transmitem dados pela Internet. Portanto, os profissionais de TI precisam entender o que é e como funciona.

Vou falar sobre isso no artigo. Vou explicar com os dedos, com exemplos e fotos engraçadas =) Se você gosta mais do formato de vídeo, pode assistir ao meu vídeo do youtube sobre o mesmo tópico.

Conteúdo

O que é e como funciona

Aqui temos um certo Vasya que decidiu comprar um carro. Como na publicidade - rápida, poderosa, bonita! Ela fica como a cauda de um avião, Vasya não tem esse tipo de dinheiro.

Obviamente, Vasya pode desenterrar por vários anos e depois comprar um carro. Mas você quer aqui e agora! Sim, e é necessário um veículo ...

E Vasya não sabe economizar - recebeu um salário, comprou o principal, pagou pela moradia, só isso! O resto pode ser gasto. Para essas pessoas, existem bancos onde você pode receber dinheiro a crédito.

Claro, então você pagará em excesso, devolvendo-os de volta. Interesse é cavalo. Mas agora você já pode comprar algo caro.

Vasya pensou, estimou e disse:

- Sim, eu quero assim! Posso pagar 100 rublos do meu salário ao banco, mas não posso salvá-lo. Eu vou gastar.

Portanto, Vasya vai ao banco e diz:

- Sou Vasily Ivanov, quero um empréstimo de carro por 1000 rublos.

A atendente Katya precisa verificar seu histórico de crédito. De repente, ele não pode receber um empréstimo, ele tem uma história ruim? Talvez ele já tenha marcado 10 créditos e nenhum paga? Ou talvez ele seja um terrorista ?! É necessário verificar se os operadores não conhecem as listas negras de cor.

Katya tem um programa especial para verificar dados de clientes. Este programa pode ser web ou desktop:

Web - abra no navegador como google ou facebook
Desktop - em um computador, como uma palavra ou calculadora

Não importa se Katya está olhando para o navegador ou apenas para o programa. De qualquer forma, será um cliente. O cliente é sua aplicação. Aquele com o qual nosso operador está trabalhando.

Katya dirige o programa "Vasily Ivanov" e recebe informações sobre o cliente - ele está nas listas negras? Havia um histórico de crédito antes? Etc. Mas o que acontece nas crianças do aplicativo?

Katya inseriu os dados no cliente. Mas quando ela clicou em "verificar", o cliente enviou uma solicitação ao servidor:

- Dê-me informações sobre Vasya Ivanov!

O servidor enviou uma solicitação ao banco de dados, banco de dados:

- Selecione * dos clientes em que fio = 'Vasily Ivanov'. (Dê-me todas as informações sobre o nome 'Vasily Ivanov').

A base respondeu:

- Aqui você tem tudo o que encontrei.

O servidor retornou essas informações para o cliente:

E o cliente já desenhou para Katya:

Katya parece:

- Sim, o histórico de crédito é bom.

E ele propõe a Vasya:

- Por favor, se você quiser tomar um empréstimo, estamos prontos para alocar 1000 rublos por 12 anos a 80% ao ano. Arranjados?

Vasya está satisfeito:

- Sim, tudo combina comigo, me dê mais dinheiro e eu corri atrás do carro!
Todo mundo está feliz, todo mundo está feliz.

Katya nem sabe como os dados do programa sabiam quando levou o nome completo do cliente para lá. Mas você e eu devemos descobrir que tipo de caminho é esse. E por que todas essas dificuldades? Por que essa estrutura? Por que existe um cliente, por que existe um servidor?

Por que preciso de um cliente

Tudo é simples aqui - o usuário está trabalhando com o cliente. É necessário transformar os bytes do código do programa em uma imagem bonita e compreensível. O usuário não é um programador, ele não entende a linguagem de programação ou o sql. Ele entende moldes e botões. Nós os desenhamos no cliente.

Por que precisamos de um servidor

Ele é mais poderoso,

pode haver muitos clientes. No exemplo com o banco, podemos ter 10 agências em 10 cidades da Rússia e cada agência possui 10 agentes de operação. Mil Katek, e cada um tem um computador separado.

Mas queremos que o aplicativo funcione rapidamente. Para que não seja estúpido e não congele, enervando o operador e fazendo o cliente esperar. Então, o carro precisa de um poderoso. Mas se o computador de cada operador for potenciado, você terá que investir muito dinheiro!

Portanto, transferimos toda a lógica básica para o servidor. E agora estamos fazendo isso poderoso! E as máquinas clientes podem ser baratas, porque elas têm apenas lógica no estilo de "solicitar informações e renderizar lindamente".

Sem duplicação de código

Se tivéssemos apenas máquinas clientes, cada uma delas teria o mesmo código de processamento lógico, o banco de dados inteiro, todos os diretórios terroristas e assim por diante. Mas como o servidor e o banco de dados são colocados em links separados, muito espaço é liberado da máquina cliente ... E o código.

Não há necessidade de duplicar o código, porque toda a lógica principal é retirada para um servidor mais poderoso.

Isso é mais seguro:

no servidor e no banco de dados são armazenadas informações inacessíveis a um operador simples. Isto:

Dados do cliente
Informações sobre suas finanças
Listas negras de bancos
...

Por que mostrar essas informações para todos e para todos? O operador vê apenas sua interface. Eu dirigi um nome completo - recebi uma resposta sobre dar ou não um empréstimo. Todos. Ela não precisa de mais nada.

Existem funcionários que estão prontos para mesclar informações do cliente para denyushki. Existem pessoas desonestas que estão prontas para olhar acidentalmente por cima dos ombros. Ou talvez o próprio cliente seja uma pessoa assim. Imagine, Vasya empurra a frágil Katya, senta-se em seu computador e transfere milhões para sua conta até que ela seja amarrada por guardas.

Por que precisamos de uma base

O que o banco de dados tem a ver com isso? Aqui temos nosso servidor, mesmo que ele armazene todas as informações. Às vezes, o banco de dados simplesmente não é necessário e ainda temos uma arquitetura cliente-servidor de duas camadas.

Nesse caso, o servidor armazena todos os dados na memória. Mas somente se o servidor travar ou apenas reiniciar, todas as informações serão perdidas. Tudo o que estava na memória é apagado quando o sistema é desligado.

DB (banco de dados) - um produto de software separado que permite:

Busque informações rapidamente
salve as informações mesmo quando reiniciar o sistema.

Ou seja, se a rede desaparecer repentinamente, a base congela, a máquina com a base é reinicializada ou outra coisa acontece, nossas alterações não serão perdidas. Isso é chamado persistência. Isso é alcançado por meio de transações que retrocedem quando algo dá errado. Mas neste artigo não vamos nos aprofundar neste tópico))

Sim, pode não haver uma base. Mas quando é, estamos confiantes na segurança dos dados e podemos procurá-los facilmente.

Vantagens da arquitetura

Resumimos as vantagens da arquitetura:

Um servidor poderoso é mais barato que mais de 100 máquinas clientes poderosas - se queremos que o aplicativo não diminua a velocidade, precisamos de uma boa máquina. Você terá um. Ou alguns, se a carga for grande, mas claramente menor que o número de clientes.
— , « » « , 100 ».
— . , .

Um link

caiu - todo mundo está descansando.Se o servidor caiu ou a base caiu, ou seja, um link se deteriorou - tudo, todo mundo está estupor, todo mundo está descansando. Centenas, milhares e até milhões de clientes, se houver, ninguém pode trabalhar. Todos os funcionários da operação estão olhando tristemente para a janela "Desculpe, algo deu errado" e encolhem os ombros na frente do cliente.

É por isso que, em softwares críticos para os negócios, a arquitetura é complicada e até duplicada. Um banco com milhares de caixas não pode pagar um tempo de inatividade. Portanto, eles usam um cluster de servidores - um caiu, o resto funciona.

Como, então, o cliente entende para onde enviar a solicitação para ele?

Um balanceador é colocado na frente dos servidores e o cliente envia uma solicitação para lá. Não importa quantos servidores são colocados no cluster, o cliente não está interessado. Ele tem um URL - o endereço do balanceador.

E agora o cliente recebe uma solicitação:

- Dê-me todas as informações sobre Vasya Ivanov.

O balanceador diz:

- Pessoal, um novo pedido! Quem é menos carregado?

Primeiro servidor:

- Eu tenho 5 solicitações na fila.

Segundo:

- E eu tenho 2. O

balanceador envia uma solicitação para o segundo servidor.

Esse esquema é usado para um aplicativo altamente carregado - quando há tantas solicitações que um servidor simplesmente não consegue lidar com elas.

Facebook, amazon, google - milhões de usuários acessam o site. Um servidor não pode lidar com eles. Portanto, eles colocam um cluster e o balanceador compartilha a carga entre eles. E, nesse caso, no cluster, pode não haver 2 servidores, mas 10, 15, enquanto precisarmos, configuramos quantos.

Ao fazer isso, podemos equilibrar o banco de dados da mesma maneira. Podemos ter várias cópias dos bancos de dados em uma variedade de máquinas, e o balanceador envia solicitações para um ou outro.

Esse esquema é chamado de hot standby - quando temos vários servidores em execução em paralelo, e o balanceador distribui a carga entre eles.

Também pode haver um esquema de reserva a frio - quando nosso segundo servidor é um backup "apenas por precaução". Todos os pedidos vão para o primeiro servidor, o segundo repousa.

Mas se algo acontecer com o primeiro servidor e ele morrer, o balanceador redirecionará a carga para o segundo servidor:

nesse momento, os administradores terão tempo para lidar com o problema no servidor 1.

O esquema de reserva a frio é usado quando um servidor é capaz de suportar a carga e fornecer uma boa velocidade. Mas o aplicativo é essencial para os negócios e é inaceitável.

Pode ser simples, não apenas porque algo ruim aconteceu. Há também uma atualização regular do aplicativo. Ambos os esquemas de backup permitem que você atualize sem problemas. Se houver dois servidores no cluster, a atualização terá a seguinte aparência:

Redirecionar toda a carga para o servidor 2
Pare o servidor 1
Atualizando servidor 1
Nós o lançamos e direcionamos toda a carga nele
Pare o servidor 2
Atualizar isso
Lançamos
Divida a carga novamente (se for uma reserva quente)

Ou seja, o aplicativo não para de funcionar!

Assim, os esquemas de redundância nos ajudam a eliminar o problema de "1 link caiu - todo mundo está descansando". O cliente nunca saberá que um ou mais servidores no cluster estão mortos, tudo funcionou para ele e funciona.

Equipamento de

servidor de alto custo é caro. Lá você não pode colocar um SSD comum para um computador doméstico. Por quê? Como os requisitos de hardware para servidores são completamente diferentes para o hardware + há suporte para funções específicas:

- O HDD possui um firmware de controlador especial, otimizado para operação em disco em RAID, o que não é necessário em casa.

- O SSD tem a presença de um grupo de capacitores que armazenam energia em caso de falta de energia, para que haja tempo suficiente para lançar dados do cache DDR na memória não volátil e os dados não quebrem.

SSD - um disco de trabalho rápido, HDD - normal. RAID - quando conectamos N discos juntos, e o cache DDR é RAM

Além disso, as soluções de servidor geralmente têm uma garantia muito mais longa: 5 anos, não um ano.

Pelo preço, diferem 2 vezes. Por exemplo, SSD:

para um gigabyte doméstico custa 16,53r
para um show corporativo de servidor custa 32 rublos

Dados de dezembro de 2019. Isto é, se não for ferro de marca, mas do fabricante.

Não parece muito diferente, certo? Mas o ponto é que, para uma casa, 1 TB é suficiente para os olhos - e tudo caberá em fotos, filmes e várias aplicações ... E para um banco de dados, às vezes 10 TB serão pequenos. E se você criar um cluster, multiplicamos o custo por 2, se não mais. Portanto, a diferença de preço parece enorme, mas quando convertida em gigabytes, surge uma pequena.

Não esqueça que, em casa, você só precisa manter suas fotos, e mesmo essas geralmente estão na nuvem. E no servidor há uma funcionalidade essencial para os negócios que consome dofig de recursos e que deve ser duplicada caso "repentinamente o primeiro morra".

Precisa contratar um administrador de sistemaツ

Precisamos contratar um administrador de sistema que monitore todos os nossos servidores de aplicativos e bancos de dados. Adicione o salário dele ao custo do equipamento!

O que testar

Para entender o que testar, você precisa entender com o que uma pessoa está lidando.

O usuário está trabalhando com um cliente. Pode ser um aplicativo da Web ou de desktop, não o ponto. O operador Kate recebeu um local de trabalho, eles mostraram qual programa executar e como trabalhar com ele. Ela não sabe sobre a disponibilidade de servidores e bancos de dados, ela trabalha apenas com o cliente.

Portanto, o testador primeiro verifica o cliente! Como o servidor pode funcionar perfeitamente, você pode até escrever testes no nível da API e todos ficarão verdes, e parece que todos estão feridos! E o usuário fará o download do relatório e verá o erro. Oh.

O servidor está em execução, ocorreu um erro no cliente. E não se preocupe com centenas de autotestes "verdes". O usuário ainda tem um erro. E nossa tarefa é olhar do ponto de vista dele.

No entanto, se você tiver acesso ao servidor de aplicativos e seu banco de dados - vale a pena verificar também! Para que possamos ver o "bug do futuro". Por exemplo:

Salvamos o cartão do produto - o sistema o desenha e diz que está tudo bem. Está tudo bem no cliente!
Verificamos o banco de dados - e parte dos campos permaneceu em branco, o desenvolvedor indicou incorretamente o nome do campo no banco de dados. E a informação foi perdida.

O que o usuário vê agora no cliente é apenas um cache ", o que eu inseri é o que eu mostro". Se você não verificar o banco de dados, esse problema pode nem ser aberto imediatamente. O usuário abre o cartão do produto - alguns dos campos não estão preenchidos:

- Bem, provavelmente eles não foram preenchidos.

E eles foram preenchidos! Apenas salvando torto trabalhou. Portanto, se tivermos apenas uma caixa preta, precisamos verificar: "Os dados estão realmente salvos?" Salvou? Abra o cartão em uma nova janela ou chame as informações pelo método API.

Se você tiver acesso ao banco de dados - verifique se está tudo bem. Se você tiver acesso aos logs do servidor, verifique se há erros.

Além dos usuários comuns, existem pessoas más que tentam aderir ao nosso aplicativo e roubam dinheiro / dados. Eles não usam um cliente ou servidor - eles não têm acesso lá. Eles tentam interceptar dados do cliente para o servidor ou do servidor para o banco de dados.

Bem, se pessoas más podem fazer isso, então o testador deve ser capaz de fazê-lo também! Porque o testador fornece informações sobre nosso produto.

O testador examina as vulnerabilidades e, em seguida, diz à equipe:

- Pessoal, então eu verifiquei, temos esse e aquele potencial buraco. Vamos pensar se precisamos fechá-los de alguma forma ou não.

Não é esse o fato de que eles resolverão o problema. Talvez você tenha um aplicativo não crítico - os dados não vazam, você não armazena dinheiro. Então ninguém se preocupará mais uma vez, porque o teste de segurança é caro, existem poucos especialistas.

Mas algumas verificações básicas, como injeções sql ou ataques XSS, valem a pena explorar e verificar seu aplicativo. Pelo menos para entender sua criticidade. Afinal, se o ataque quebra o cliente - bem, deixe-se ser Pinóquio. E se o ataque coloca o servidor, não é muito bom. E é preciso pelo menos saber do que isso acontece.

Total

O cliente é o programa com o qual o usuário trabalha. Ele não sabe se esse é o programa inteiro no computador ou em algum lugar em que um servidor com base ou mesmo um RAID inteiro está escondido atrás dele. Funciona em um navegador ou em um aplicativo de desktop. E tudo o que ele precisa saber é onde cutucar.

O cliente não precisa de muita memória, espaço em disco e outros recursos. Portanto, os empregos são relativamente baratos. E é exatamente disso que precisamos, especialmente se precisarmos comprar equipamentos para milhares de funcionários de operações bancárias.

Servidor - um computador em que o próprio aplicativo está armazenado. Todo o código, toda lógica, todos os materiais adicionais e livros de referência. Por exemplo, o diretório de endereços FIAS ou o diretório de entidades legais do registro de entidades legais - eles também ocupam um local, por conta própria e na memória do aplicativo.

Às vezes, eles dizem "servidor de aplicativos" e "servidor de banco de dados". Isso é normal, porque na verdade o servidor é apenas uma máquina, um computador. E o banco de dados e o servidor de aplicativos geralmente são armazenados em máquinas diferentes, por questões de segurança. Nesse caso, se eles disserem "servidor de aplicativos" - estamos falando do segundo link do nosso esquema.

As aplicações são muito diferentes. Há muitos recursos, eles precisam de muita memória e espaço em disco. Existem "pulmões" que podem ser implantados mesmo em um computador doméstico.

DB (banco de dados) - data warehouse. Aqui você pode procurar informações com facilidade + e ter certeza de que elas permanecerão, mesmo que algo ocorra no aplicativo.

Quanto espaço é necessário para o banco de dados depende da quantidade de dados. Existem enormes bases nos bancos, onde 1 TB será reduzido. E há muito pequenos que você pode instalar em sua máquina. Por exemplo,XAMPP pode ser fornecido. E é improvável que você coloque tantos dados nele que não terá lugar para eles.

Pode não haver uma base separada, a estrutura se tornará em duas camadas: cliente-servidor. E isso é tudo!

O esquema é condicional, na vida real teremos pelo menos mais clientes. E se o aplicativo estiver muito carregado, haverá vários servidores e vários bancos de dados:

PS - procure artigos mais úteis no meu blog com a tag "útil"

Arquitetura cliente-servidor em imagens