🧚🏼 👩🏻‍🎓 💬 Arquitectura cliente-servidor en imágenes 👩🏻‍🚀 🖐🏿 😝

¿Una foto familiar? Pero se enfrenta constantemente con esta arquitectura: cuando compra un boleto de cine en línea, reserva un boleto para el mar o hace una cita con un médico.

En la arquitectura cliente-servidor se construyen todos los sitios y servicios de Internet. También lo utilizan los programas de escritorio que transmiten datos a través de Internet. Por lo tanto, los profesionales de TI deben comprender qué es y cómo funciona.

Hablaré de esto en el artículo. Explicaré con los dedos, con ejemplos y fotos divertidas =) Si te gusta más el formato de video, puedes ver mi video de YouTube sobre el mismo tema.

Contenido

Qué es y cómo funciona

Aquí tenemos a cierto Vasya que decidió comprar un automóvil. Como en la publicidad: ¡rápido, poderoso, hermoso! Ella solo se para como la cola de un avión, Vasya no tiene ese tipo de dinero.

Por supuesto, Vasya puede desenterrar durante varios años y luego comprar un automóvil. Pero quieres aquí y ahora! Sí, y se necesita un vehículo ...

Y Vasya no sabe cómo ahorrar: recibió un salario, compró el principal, pagó la vivienda, ¡eso es todo! El resto se puede gastar. Para esas personas, hay bancos donde puedes venir y tomar dinero a crédito.

Por supuesto, luego pagarás de más, devolviéndolos. El interés es el caballo. Pero ahora ya puede darse el lujo de comprar algo caro.

Vasya pensó, estimó y dijo:

- Sí, ¡lo quiero así! Puedo pagar 100 rublos de mi salario al banco, pero no puedo ahorrarlo. Lo gastaré

Por lo tanto, Vasya va al banco y dice:

- Soy Vasily Ivanov, quiero un préstamo de auto por 1000 rublos.

El secretario Katya tiene que verificar su historial de crédito. De repente no se le puede dar un préstamo, ¿tiene una mala historia? ¿Quizás ya obtuvo 10 créditos y ninguno paga? ¿O tal vez es un terrorista? Es necesario verificar que los operadores no conozcan las listas negras de memoria.

Katya tiene un programa especial para verificar los datos de los clientes. Este programa puede ser web o de escritorio:

Web : abrir en el navegador como google o facebook
Escritorio : en una computadora, como una palabra o una calculadora

No importa si Katya está mirando el navegador o solo el programa. En cualquier caso, será un cliente. El cliente es tu aplicación. Con la que está trabajando nuestro operador.

Katya conduce el programa "Vasily Ivanov" y recibe información sobre el cliente. ¿Está en las listas negras? ¿Hubo un historial de crédito antes? Etc. ¿Pero qué sucede en los menudillos de la aplicación?

Katya ingresó los datos del cliente. Pero cuando hizo clic en "verificar", el cliente envió una solicitud al servidor:

- ¡Dame información sobre Vasya Ivanov!

El servidor envió una solicitud a la base de datos, base de datos:

- Seleccione * de los clientes donde fio = 'Vasily Ivanov'. (Dame toda la información sobre el nombre 'Vasily Ivanov')

La base respondió:

- Aquí tienes todo lo que encontré.

El servidor devolvió esta información al cliente:

Y el cliente ya lo ha dibujado para Katya:

Katya mira:

- Sí, el historial de crédito es bueno.

Y le propone a Vasya:

- Por favor, si desea obtener un préstamo, estamos listos para asignar 1000 rublos por 12 años al 80% anual. ¿Arreglado?

Vasya está contenta:

- Sí, todo me conviene, ¡dame más dinero y corrí detrás del auto!
Todos están felices, todos están felices.

Katya ni siquiera sabe de qué manera lo hicieron los datos en el programa cuando condujo el nombre completo de su cliente allí. Pero tú y yo debemos descubrir qué tipo de camino es este. ¿Y por qué todas estas dificultades? ¿Por qué tal estructura? ¿Por qué hay un cliente, por qué hay un servidor?

¿Por qué necesito un cliente?

Aquí todo es simple: el usuario está trabajando con el cliente. Es necesario convertir los bytes del código del programa en una imagen hermosa y comprensible. El usuario no es un programador, no entiende el lenguaje de programación o sql. Entiende moldes y botones. Los dibujamos en el cliente.

¿Por qué necesitamos un servidor?

Es más poderoso,

puede haber muchos clientes. En el ejemplo con el banco, podemos tener 10 sucursales en 10 ciudades de Rusia, y cada sucursal tiene 10 agentes de operación. Mil Katek, y cada uno tiene una computadora separada.

Pero queremos que la aplicación funcione rápidamente. Para que no sea estúpido y no se congele, desconcierta al operador y hace que el cliente espere. Entonces, el auto necesita uno poderoso. Pero si la computadora de cada operador se hace poderosa, ¡tendrá que invertir mucho dinero!

Por lo tanto, transferimos toda la lógica básica al servidor. ¡Y ahora lo estamos haciendo poderoso! Y las máquinas cliente pueden ser baratas, porque solo tienen lógica en el estilo de "solicitar información y renderizar bellamente".

Sin duplicación de código

Si solo tuviéramos máquinas cliente, cada una de ellas tendría el mismo código de procesamiento lógico, la base de datos completa, todos los directorios terroristas, etc. Pero como el servidor y la base de datos se colocan en enlaces separados, se libera mucho espacio de la máquina del cliente ... Y el código.

No es necesario duplicar el código, porque toda la lógica principal se lleva a un servidor más potente.

Esto es más seguro:

en el servidor y en la base de datos se almacena información inaccesible para un operador simple. Eso:

Información de los clientes
Información sobre sus finanzas.
Listas negras del banco
...

¿Por qué mostrar esta información a todos y a todos? El operador solo ve su interfaz. Conduje un nombre completo: recibí una respuesta sobre si otorgar un préstamo o no. Todas. Ella no necesita nada más.

Hay empleados que están listos para fusionar la información del cliente para denyushki. Hay personas deshonestas que están listas para mirar accidentalmente sobre sus hombros. O tal vez el cliente mismo es esa persona. Imagínese, Vasya empuja a la frágil Katya, se sienta en su computadora y transfiere millones a su cuenta hasta que los guardias la atan.

¿Por qué necesitamos una base?

¿Qué tiene que ver la base de datos con ella? Aquí tenemos nuestro servidor, incluso si almacena toda la información. Ocurre, a veces la base de datos simplemente no es necesaria y todavía tenemos una arquitectura cliente-servidor de dos niveles.

En este caso, el servidor almacena todos los datos en la memoria. Pero solo si el servidor falla, o simplemente se reinicia, toda la información se perderá. Todo lo que estaba en la memoria se borra cuando se apaga el sistema.

DB (base de datos): un producto de software separado que le permite:

Obtener información rápidamente
guardar información incluso al reiniciar el sistema.

Es decir, si la red desaparece repentinamente, la base se congela, la máquina con la base se reinicia o sucede algo más, nuestros cambios no se perderán. Esto se llama persistencia. Se logra a través de transacciones que retroceden cuando algo sale mal. Pero en este artículo no profundizaremos en este tema))

Sí, puede que no haya una base. Pero cuando lo es, confiamos en la seguridad de los datos y podemos buscarlos fácilmente.

Ventajas de la arquitectura

Resumimos las ventajas de la arquitectura:

Un servidor potente es más barato que más de 100 máquinas cliente potentes : si queremos que la aplicación no se ralentice, necesitamos una buena máquina. Tendrás uno. O algunos, si la carga es grande, pero claramente menor que la cantidad de clientes.
— , « » « , 100 ».
— . , .

Se ha

caído un enlace: todos están descansando. Si el servidor se ha caído o la base se ha caído, es decir, un enlace se ha deteriorado: todo, todos están en estado de estupor, todos están descansando. Cientos, miles e incluso millones de clientes, si los hay, nadie puede trabajar. Todos los oficiales de operaciones están mirando tristemente la ventana "Lo siento, algo salió mal" y encogen sus manos frente al cliente.

Es por eso que en el software empresarial crítico la arquitectura es complicada e incluso duplicada. Un banco con miles de cajeros no puede permitirse un tiempo de inactividad. Por lo tanto, usan un clúster de servidores: uno cayó, el resto funciona.

Entonces, ¿cómo entiende el cliente dónde enviarle la solicitud?

Se coloca un equilibrador delante de los servidores y el cliente envía una solicitud allí. No importa cuántos servidores se coloquen en el clúster, el cliente no está interesado. Tiene una URL: la dirección del equilibrador.

Y ahora el cliente recibe una solicitud:

- Dame toda la información sobre Vasya Ivanov.

El equilibrador dice:

- ¡Chicos, una nueva solicitud! ¿Quién está menos cargado?

Primer servidor:

- Tengo 5 solicitudes en la cola.

Segundo:

- Y tengo 2. El

equilibrador envía una solicitud al segundo servidor.

Tal esquema se usa para una aplicación altamente cargada, cuando hay tantas solicitudes que un servidor simplemente no puede hacer frente a ellas.

Facebook, Amazon, Google: millones de usuarios van allí. Un servidor no puede manejarlos. Por lo tanto, colocan un clúster y el equilibrador comparte la carga entre ellos. Y en este caso, en el clúster puede que no haya 2 servidores, sino 10, 15, siempre que lo necesitemos, configuramos tantos.

Al hacerlo, podemos equilibrar la base de datos de la misma manera. Podemos tener varias copias de las bases de datos en una variedad de máquinas, y el equilibrador envía solicitudes a uno u otro.

Este esquema se llama hot standby , cuando tenemos varios servidores ejecutándose en paralelo y el equilibrador distribuye la carga entre ellos.

También puede haber un esquema de reserva en frío , cuando nuestro segundo servidor es una copia de seguridad "por si acaso". Todas las solicitudes van al primer servidor, el segundo descansa.

Pero si algo le sucede al primer servidor y muere, el equilibrador redirigirá la carga al segundo servidor:

en este momento, los administradores tendrán tiempo para resolver el problema en el servidor 1.

El esquema de reserva en frío se utiliza cuando un servidor puede soportar la carga y proporcionar una buena velocidad. Pero la aplicación es crítica para el negocio y es simplemente inaceptable.

Puede ser simple no solo porque sucedió algo malo. También hay una actualización regular de la aplicación. Ambos esquemas de respaldo le permiten actualizar sin problemas. Si hay dos servidores en el clúster, la actualización se verá así:

Redireccionar toda la carga al servidor 2
Detener el servidor 1
Actualizando el servidor 1
Lo lanzamos y dirigimos toda la carga sobre él.
Detener el servidor 2
Actualizarla
Lanzamos
Divida la carga nuevamente (si es una reserva caliente)

Es decir, la aplicación no deja de funcionar en absoluto.

Por lo tanto, los esquemas de redundancia nos ayudan a eliminar el problema de "1 enlace ha caído: todos descansan". El cliente nunca sabrá que uno o más servidores en el clúster están muertos, todo le ha funcionado y funciona.

Alto costo El equipo del

servidor es costoso. Allí no puede colocar un SSD normal para una computadora en casa. ¿Por qué? Debido a que los requisitos de hardware para los servidores son completamente diferentes para hardware +, hay soporte para funciones específicas:

- HDD tiene un firmware de controlador especial, que está optimizado para la operación del disco en RAID, esto no es necesario en el hogar.

- SSD tiene la presencia de un grupo de condensadores que almacenan energía en caso de falla de energía, por lo que hay tiempo suficiente para arrojar datos del caché DDR a la memoria no volátil y los datos no se rompen.

SSD - un disco de trabajo rápido, HDD - normal. RAID: cuando conectamos N discos juntos, y el caché DDR es RAM

Además, las soluciones de servidor generalmente tienen una garantía mucho más larga: 5 años, no un año.

Por el precio difieren en 2 veces. Por ejemplo, SSD:

para una casa gigabyte cuesta 16.53r
para un servidor la empresa cuesta 32 rublos

Cifras de diciembre de 2019. Esto si no es hierro de marca para tomar, sino del fabricante.

Parece no muy diferente, ¿verdad? Pero el punto es que para una casa 1 TB es suficiente para los ojos, y todo encajará en fotos, películas y un montón de aplicaciones ... Y para una base de datos, a veces 10 TB serán pequeñas. Y si crea un grupo, entonces multiplicamos el costo por 2, si no más. Por lo tanto, la diferencia de precio parece enorme, pero cuando se convierte a gigabytes, sale una pequeña.

No olvides que en casa solo necesitas guardar tus fotos, e incluso esas suelen estar en la nube. Y en el servidor hay una funcionalidad crítica para el negocio que consume gran cantidad de recursos y que debe duplicarse en caso de que "de repente muera el primero".

Necesita contratar un administrador del sistemaツ

Necesitamos contratar un administrador del sistema que supervise todos nuestros servidores de aplicaciones y bases de datos. ¡Agregue su salario al costo del equipo!

Que probar

Para entender qué probar, debe comprender con qué está tratando una persona.

El usuario está trabajando con un cliente. Puede ser una aplicación web o de escritorio, no el punto. El operador Kate recibió un lugar de trabajo, le mostraron qué programa ejecutar y cómo trabajar con él. Ella no sabe acerca de la disponibilidad de servidores y bases de datos, solo trabaja con el cliente.

¡Por lo tanto, el probador primero verifica al cliente! Debido a que el servidor puede funcionar perfectamente, incluso puedes escribir pruebas a nivel API y todas serán verdes, ¡y parece que todos están heridos! Y el usuario descargará el informe y verá el error. Oh.

El servidor se está ejecutando, se ha producido un error en el cliente. Y no te preocupes por cientos de autotests "verdes". El usuario todavía tiene un error. Y nuestra tarea es mirar desde su punto de vista.

Sin embargo, si tiene acceso al servidor de aplicaciones y su base de datos, ¡también vale la pena revisarlos! Entonces podemos ver el "error futuro". Por ejemplo:

Guardamos la tarjeta del producto: el sistema la saca y dice que todo está bien. ¡Todo está bien para el cliente!
Verificamos la base de datos, y allí parte de los campos permanecieron vacíos, el desarrollador indicó incorrectamente el nombre del campo en la base de datos. Y la información se perdió.

Lo que el usuario ahora ve en el cliente es solo un caché, "lo que ingresé es lo que muestro". Si no verifica la base de datos, es posible que este problema ni siquiera se abra de inmediato. El usuario abre la tarjeta del producto; algunos de los campos no se completan:

- Bueno, probablemente no se completaron.

¡Y estaban llenos! Solo ahorrar torcidamente funcionó. Por lo tanto, si solo tenemos un cuadro negro, entonces debemos verificar, "¿Están realmente guardados los datos?" ¿Salvado? Abra la tarjeta en una nueva ventana o llame a la información a través del método API.

Si tiene acceso a la base de datos, simplemente verifique que todo esté bien. Si tiene acceso a los registros del servidor, verifique si hay errores.

Además de los usuarios comunes, hay personas malvadas que intentan adherirse a nuestra aplicación y robar dinero / datos. No utilizan un cliente o servidor, no tienen acceso allí. Intentan interceptar datos del cliente al servidor, o del servidor a la base de datos.

Bueno, si las personas malas pueden hacer esto, ¡entonces el probador también debe poder hacerlo! Porque el probador proporciona información sobre nuestro producto.

El probador examina las vulnerabilidades y luego le dice al equipo:

- Chicos, así que verifiqué, tenemos tales agujeros potenciales. Pensemos si necesitamos cerrarlos de alguna manera o no.

Ese no es el hecho de que solucionarán el problema. Tal vez tenga una aplicación no crítica: los datos no se filtrarán, no almacenará dinero. Entonces, nadie se molestará una vez más, porque las pruebas de seguridad son caras, hay pocos especialistas.

Pero vale la pena explorar y verificar su aplicación en algunas comprobaciones básicas como inyecciones sql o ataques XSS. Al menos para entender su criticidad. Después de todo, si el ataque rompe al cliente, bueno, permítete ser Pinocho. Y si el ataque pone al servidor, no es muy bueno. Y al menos uno debe saber de qué sucede.

Total

El cliente es el programa con el que trabaja el usuario. No sabe si este es el programa completo en su computadora, o en algún lugar un servidor con una base o incluso un RAID completo se esconde detrás de él. Funciona en un navegador o con una aplicación de escritorio. Y todo lo que necesita saber es dónde empujar.

El cliente no necesita mucha memoria, espacio en disco y otros recursos. Por lo tanto, los trabajos son relativamente baratos. Y esto es exactamente lo que necesitamos, especialmente si necesitamos comprar equipos para miles de oficiales de operaciones bancarias.

Servidor : una computadora en la que se almacena la aplicación. Todo el código, toda la lógica, todos los materiales adicionales y libros de referencia. Por ejemplo, el directorio de direcciones FIAS o el directorio de entidades jurídicas del registro de entidades jurídicas, también ocupan un lugar, tanto solos como en la memoria de la aplicación.

A veces dicen "servidor de aplicaciones" y "servidor de bases de datos". Esto es normal, porque de hecho el servidor es solo una máquina, una computadora. Y la base de datos y el servidor de aplicaciones generalmente se almacenan en diferentes máquinas, en aras de la seguridad. En este caso, si dicen "servidor de aplicaciones", estamos hablando del segundo enlace de nuestro esquema.

Las aplicaciones son muy diferentes. Son intensivos en recursos, necesitan mucha memoria y espacio en disco. Hay "pulmones" que pueden desplegarse incluso en una computadora doméstica.

DB (base de datos) : almacén de datos. Aquí puede buscar información fácilmente y está seguro de que permanecerá, incluso si algo se rompe en la aplicación.

La cantidad de espacio necesario para la base de datos depende de la cantidad de datos. Hay grandes bases en los bancos, donde 1tb serán pocas. Y hay algunos muy pequeños que puede instalar en su máquina. Por ejemplo,XAMPP puede ser suministrado. Y es poco probable que ingrese tantos datos que no tenga un lugar para ellos.

Puede que no haya una base separada, entonces la estructura se convertirá en dos niveles: cliente-servidor. ¡Y eso es todo!

El esquema es condicional, en la vida real al menos tendremos más clientes. Y si la aplicación está muy cargada, habrá varios servidores y varias bases de datos:

PD: busque artículos más útiles en mi blog bajo la etiqueta "útil"

Arquitectura cliente-servidor en imágenes