Introducción a la arquitectura de tres niveles
La arquitectura de tres niveles es la arquitectura de interacción más común en Internet. Apareció cuando la parte del servidor de dos niveles se dividió en dos partes: una capa lógica y una capa de datos .
Se veía algo como esto:
La capa de cliente es la parte de la "aplicación distribuida" que es responsable de la interacción del usuario. Esta capa no debe contener lógica comercial y no debe almacenar datos críticos. Además, no debe interactuar directamente con la capa de la base de datos, sino solo a través de la capa de lógica empresarial.
Sin embargo, todavía hay algo de lógica aquí. En primer lugar, esta es la interacción con el usuario a través de la interfaz, la validación de los datos ingresados por él, el trabajo con archivos locales. Esto también incluye todo lo relacionado con la autorización de usuarios y el cifrado de datos cuando se trabaja con el servidor.
En segundo lugar, es una lógica de negocio simple. Por ejemplo, si una tienda en línea envió una lista de productos, podemos ordenarlos y filtrarlos del lado del cliente. Y el almacenamiento primitivo de datos también está aquí: almacenamiento en caché, cookies de usuarios registrados y similares.
La capa de lógica de negocios se encuentra en el segundo nivel, la mayor parte de la lógica de negocios se concentra en ella. Fuera de ella, solo quedan fragmentos que se exportan al cliente, así como elementos lógicos que se encuentran inmersos en la base de datos (procedimientos almacenados y disparadores).
Una parte muy importante del servidor de lógica empresarial no solo contiene esta misma lógica, sino que también resuelve problemas de escalado: el código se divide en partes y se distribuye a diferentes servidores. Algunos servicios de alta demanda pueden ejecutarse en docenas de servidores. La carga entre ellos es administrada por el balanceador de carga.
Las aplicaciones del servidor generalmente están diseñadas de tal manera que otra copia del servidor puede iniciarse fácilmente y comenzar a trabajar en cooperación con otras copias del mismo. Es decir, incluso en el proceso de escritura del código del servidor, nunca tendrá garantías de que su clase estática se inicie en una sola instancia.
La capa de datos proporciona almacenamiento de datos y se coloca en un nivel separado, implementado, por regla general, por medio de sistemas de administración de bases de datos (DBMS), la conexión a este componente se proporciona solo desde el nivel del servidor de aplicaciones.
Razones para separar la capa de datos
La separación de la capa de datos en una tercera capa completa se produjo por muchas razones, pero la principal es el aumento de la carga en el servidor.
Primero, las bases de datos comenzaron a requerir mucha memoria y tiempo de procesador para el procesamiento de datos. Por lo tanto, comenzaron a colocarse en todas partes en servidores separados.
Con una mayor carga, el backend se podía duplicar fácilmente y se podían generar diez copias de un servidor, pero era imposible duplicar la base de datos: la base de datos seguía siendo un componente único e indivisible del sistema.
En segundo lugar, las bases de datos se han vuelto inteligentes : tienen su propia lógica comercial. Comenzaron a soportar procedimientos almacenados, disparadores, lenguajes propios como PLSQL. E incluso aparecieron programadores que comenzaron a escribir código que se ejecuta dentro del DBMS.
Toda la lógica que no estaba vinculada a los datos se llevó al backend y se lanzó en paralelo en docenas de servidores. Todo lo relacionado críticamente con los datos permaneció dentro del DBMS, y allí ya los problemas del aumento de la carga debían resolverse utilizando nuestros propios métodos:
- Un clúster de base de datos es un grupo de servidores de bases de datos que almacenan los mismos datos y los sincronizan mediante un protocolo específico.
- Sharding: los datos se dividen en bloques lógicos y se distribuyen en diferentes servidores de bases de datos. Es muy difícil mantener los cambios de la base de datos con este enfoque.
- El enfoque NoSQL consiste en almacenar datos en bases de datos creadas para almacenar grandes cantidades de datos. A menudo, ni siquiera son bases de datos, sino almacenamientos de archivos específicos. Funcionalidad muy pobre en comparación con las bases de datos relacionales.
- Almacenamiento en caché de datos. En lugar de un caché simple a nivel de base de datos, apareció un DBMS de almacenamiento en caché completo, que almacenaba el resultado solo en la memoria.
Está claro que se necesitaban personas separadas y/o equipos completos para administrar este zoológico de tecnologías de servidor, lo que condujo a la eliminación de la capa de datos en una capa separada.
¡Importante! Todas las tecnologías avanzadas nacen en las profundidades de las grandes corporaciones de TI, cuando los viejos enfoques ya no hacen frente a los nuevos desafíos. La creación de bases de datos en una capa separada no fue inventada por ningún programador, sino por un grupo de ingenieros en algún lugar de las profundidades de Oracle o IBM.
¡Interesante! Cuando Zuckerberg comenzó a escribir Facebook, trabajaba simplemente en PHP + MySQL. Cuando había millones de usuarios, escribieron un traductor especial que traducía todo el código PHP a C ++ y lo compilaba en código de máquina nativo.
Además, MySQL no es capaz de almacenar los datos de miles de millones de usuarios, por lo que Facebook desarrolló el concepto de bases de datos NoSQL y escribió un poderoso DBMS NoSQL del lado del servidor: Cassandra. Por cierto, está completamente escrito en Java.
Ambigüedad de la ubicación de la lógica de la aplicación
Y aunque una arquitectura de tres niveles distribuye roles entre sus partes casi sin ambigüedades, no siempre es posible determinar correctamente en qué parte del sistema se debe agregar una nueva parte de la lógica comercial (nuevo código).
Un ejemplo de tal ambigüedad se muestra en la siguiente imagen:
La parte del servidor se rellena con un fondo gris, la parte del cliente se rellena con blanco. Un buen ejemplo de este último enfoque (extremo derecho) son las aplicaciones móviles modernas. El lado del cliente (en el teléfono) contiene la vista (pantalla), la lógica y los datos. Y solo a veces estos datos se sincronizan con el servidor.
Un ejemplo de la opción más a la izquierda es un servidor PHP típico, que tiene toda la lógica en el servidor y le da al cliente HTML ya estático. En algún lugar entre estos dos extremos, se ubicará su proyecto.
Al comienzo del trabajo, después de familiarizarse con el proyecto, deberá consultar con los programadores que trabajan en él, sobre los lugares donde es mejor para usted implementar la lógica de la siguiente tarea.
Siéntete libre de hacerlo. En primer lugar, no suben al monasterio de otra persona con su estatuto. En segundo lugar, será más fácil para todos (y para ti también) encontrar el código que necesitas en el lugar donde esperas encontrarlo.