Arquitectura de red de aplicaciones web modulares

7

Suponiendo que estoy tratando con servidores físicos dedicados o VPS, ¿es concebible y tiene sentido tener distintos servidores configurados con las siguientes funciones para alojar una aplicación web?

  1. Proxy inverso
  2. servidor web
  3. servidor de aplicaciones
  4. Servidor de base de datos

Puntosespecíficosdeinterés:

  1. Estoyconfundidosobrecómosepararlosservidoreswebydeaplicaciones.Mientendimientofuequetales arquitecturas de 3 niveles eran factibles.

  2. No me queda claro si el servidor de la aplicación residiría directamente entre la web y el servidor de la base de datos, o si el servidor web también podría interactuar directamente con la base de datos. El servidor de la aplicación puede hacer el trabajo pesado computacional en nombre del servidor de la aplicación o puede hacer el trabajo pesado más el control de toda la lógica de negocios (como se indica en el diagrama anterior, negando así la web). servidor de acceso directo a la base de datos).

  3. Tampoco estoy seguro de qué rol puede desempeñar el proxy inverso (ej. nginx ) como servidor web, dada la configuración mencionada anteriormente. Sé que nginx tiene características de servidor web. Pero no sé si tiene sentido que el proxy inverso sea su propio VPS, dado que el servidor web, en teoría, estaría separado del servidor de aplicaciones.

pregunta nairware 11.06.2014 - 04:32

3 respuestas

1

Recuerde una regla clave:

No se preocupe demasiado por hacer que la arquitectura sea escalable y todo en el primer paso. Es posible que deba cambiarlo varias veces a medida que su aplicación evolucione como resultado de más usuarios / traffic / features / etc.

Simplemente empiece a enviar algo para que los usuarios REALES puedan intentarlo y actúe según sus comentarios. No planee demasiado porque no importa qué planear, está obligado a cambiar.

En cuanto a la pregunta, el proxy inverso y el servidor web generalmente pueden ser la misma aplicación, por lo general, para empezar, nginx. Luego, a medida que aumenta la escala, el barniz puede ser un proxy inverso más poderoso.

Los servidores web como nginx nunca hablan directamente con la base de datos. Los servidores de aplicaciones se encuentran entre los dos.

- ACTUALIZACIÓN -

Lo anterior NO significa que no tenemos que pensar en arquitectura en absoluto. Significa no preocuparse por obtener todos los detalles arquitectónicos desde el principio.

Sin embargo, DEBEMOS pensar en la forma del sistema de alto nivel. Las interacciones entre componentes es algo que debe ser bien pensado antes de comenzar la implementación concreta.

    
respondido por el treecoder 11.06.2014 - 04:55
0

puedes pensar en los Servidores de Aplicaciones como una especie de super versión de JDBC o ActiveRecord o lo que sea que uses. Algunas aplicaciones no necesitarán esa separación, y si esta es su primera pasada, como se mencionó, no se preocupe por eso. Sin embargo, si encuentra que la lógica responsable de interactuar con la base de datos se está volviendo muy compleja, puede ser útil dividirla en su propio servicio. Esto casi siempre se hace en los entornos de Big Data, ya que la lógica alrededor de la programación de la base de datos es muy compleja e involucrada.

Si todo lo que tienes es una aplicación web simple que no necesita nada más complejo que MySQL o Postgres, todavía no me preocuparía el Servidor de Aplicaciones. Si está utilizando un marco web decente para el servidor web (como Play, Django, Rails, etc.), el código será lo suficientemente modular como para cambiar la capa DAO por una capa REST / HTTP para comunicarse con un nuevo servidor de aplicaciones No debería ser demasiado difícil.

Ya se ha mencionado que el servidor web también puede funcionar como el proxy inverso. Nuevamente, si se da cuenta de que esto se vuelve lo suficientemente complejo en el futuro como para justificar que esa lógica sea su propia caja, por supuesto. Solo tenga en cuenta el hecho de que esta es una posible dirección en la que podría ir la aplicación en el futuro cuando esté programando cosas para que no tenga que desentrañar un código no modular para romper un servidor proxy dedicado.

    
respondido por el Josiah 08.11.2014 - 09:11
0

Para una arquitectura de 3 niveles, está (en parte) intentando escalar. Esto significa que descargará parte del procesamiento de la base de datos única a unos pocos servidores de aplicaciones y descargará el procesamiento de ellos a muchos servidores web. Esto también le permite escribir código para cada nivel que es especializado, por lo que el servidor DB solo ejecutará la base de datos, los servidores de aplicaciones solo leerán (y almacenarán en caché) los datos y aplicarán la lógica empresarial, y los servidores web solo manejarán la presentación de resultados a los clientes.

Hay otras razones para hacer una arquitectura de 3 niveles como esta, la seguridad es una razón importante: en tales arquitecturas seguras, se considera que el servidor web es el que tiene mayor probabilidad de verse comprometido y, por lo tanto, se ejecuta en un entorno de privilegios bajos acceso directo a la base de datos: si alguien obtiene acceso a su servidor web y puede leer cualquier tabla de base de datos, todas sus contraseñas son suyas. Si todo lo que puede hacer es hacer una llamada a la API al servidor de aplicaciones, también tienen que piratear el servidor. servidor de aplicaciones también).

Puede crear una arquitectura de este tipo sin muchos servidores físicos, ya sea ejecutarlos en máquinas virtuales o simplemente crear cada nivel como un servicio separado, por ejemplo. el servidor web es uno, y su código llama a un servicio que se ubicaría en el servidor de la aplicación si tuviera uno, pero de lo contrario es solo un servicio local con el que se comunica utilizando el mismo canal de comunicaciones.

En muchos sentidos, es fácil de conceptualizar esta arquitectura: si utiliza un servicio de terceros, entonces ya tiene un nivel n, el "servidor de aplicaciones" es el servicio de terceros que consume. Por lo tanto, si utiliza un servicio de mapas de Google para parte de su sitio, obviamente se está ejecutando en un servidor diferente y está realizando llamadas de red para obtener los datos que combina con los suyos para crear una página. ¡Reemplace el servicio de Google con el suyo que habla con su propia base de datos y tiene un servicio de 3 niveles!

Los proxies inversos son generalmente una cuestión de seguridad, ya que protegen el servidor web de los atacantes; tienen que pasar por alto el proxy, lo que debería ser difícil ya que tiene una superficie de ataque muy pequeña. Una arquitectura de 3 niveles a menudo hace que el servidor web realice esta función, ya que no hace mucho más que generar HTML a partir de los datos que le proporcionan los servicios de la aplicación.

    
respondido por el gbjbaanb 07.04.2015 - 14:52

Lea otras preguntas en las etiquetas