Editar

Compartir a través de

Estilo de arquitectura de n niveles

Azure Storage
Azure Cloud Services
Azure Virtual Machines

Una arquitectura de N niveles divide una aplicación en capas lógicas y niveles físicos.

diagrama lógico de un estilo de arquitectura de N niveles

Las capas son una manera de separar las responsabilidades y administrar las dependencias. Cada capa tiene una responsabilidad específica. Una capa superior puede usar servicios en una capa inferior, pero no de otro modo.

Los niveles están separados físicamente y se ejecutan en máquinas independientes. Contractualmente, el nivel puede hacer que sus modelos de comunicación sean estrictos o relajados. En el modelo estricto, una solicitud debe pasar por niveles adyacentes, uno por uno, y no puede omitir ningún nivel entre sí. Por ejemplo, desde el firewall de aplicaciones web hasta el nivel web, a nivel intermedio 1, etc. En cambio, en el enfoque relajado, la solicitud puede omitir algunos niveles si es necesario. El enfoque estricto tiene más latencia y sobrecarga, y el enfoque relajado tiene más acoplamientos y, posteriormente, es más difícil cambiar. Un sistema puede usar un enfoque híbrido: tener niveles relajados y estrictos cuando sea necesario.

Un nivel puede llamar a otro nivel directamente o usar patrones de mensajería asincrónica a través de una cola de mensajes. Aunque cada capa se puede hospedar en su propio nivel, no es necesario. Es posible que varias capas se hospede en el mismo nivel. La separación física de los niveles mejora la escalabilidad y la resistencia, pero también agrega latencia de la comunicación de red adicional.

Una aplicación tradicional de tres niveles tiene un nivel de presentación, un nivel intermedio y un nivel de base de datos. El nivel intermedio es opcional. Las aplicaciones más complejas pueden tener más de tres niveles. En el diagrama anterior se muestra una aplicación con dos niveles intermedios, encapsulando diferentes áreas de funcionalidad.

Una aplicación de N niveles puede tener una arquitectura de capa cerrada o una arquitectura de capa abierta :

  • En una arquitectura de capa cerrada, una capa solo puede llamar a la siguiente capa inmediatamente abajo.
  • En una arquitectura de capa abierta, una capa puede llamar a cualquiera de las capas debajo de ella.

Una arquitectura de capa cerrada limita las dependencias entre capas. Sin embargo, podría crear tráfico de red innecesario, si una capa simplemente pasa solicitudes a la siguiente capa.

Cuándo usar esta arquitectura

Normalmente, las arquitecturas de N niveles se implementan como aplicaciones de infraestructura como servicio (IaaS), con cada nivel que se ejecuta en un conjunto independiente de máquinas virtuales. Sin embargo, una aplicación de N niveles no necesita ser IaaS pura. A menudo, es ventajoso usar servicios administrados para algunas partes de la arquitectura, especialmente el almacenamiento en caché, la mensajería y el almacenamiento de datos.

Considere la posibilidad de usar una arquitectura de N niveles para:

  • Aplicaciones web sencillas.
  • Un buen punto de partida cuando los requisitos arquitectónicos aún no están claros.
  • Migración de una aplicación local a Azure con una refactorización mínima.
  • Desarrollo unificado de aplicaciones locales y en la nube.

Las arquitecturas de n niveles son muy comunes en las aplicaciones locales tradicionales, por lo que es una opción natural para migrar las cargas de trabajo existentes a Azure.

Beneficios

  • Portabilidad entre la nube y el entorno local, y entre plataformas en la nube.
  • Menor curva de aprendizaje para la mayoría de los desarrolladores.
  • Costo relativamente bajo al no rediseñar la solución
  • Evolución natural del modelo de aplicación tradicional.
  • Abierto a un entorno heterogéneo (Windows/Linux)

Desafíos

  • Es fácil terminar con un nivel intermedio que solo realiza operaciones CRUD en la base de datos, agregando latencia adicional sin realizar ningún trabajo útil.
  • El diseño monolítico impide la implementación independiente de características.
  • La administración de una aplicación IaaS es más trabajo que una aplicación que solo usa servicios administrados.
  • Puede ser difícil administrar la seguridad de red en un sistema grande.
  • Los flujos de datos y de usuario suelen abarcar varios niveles, lo que agrega complejidad a problemas como las pruebas y la observabilidad.

Procedimientos recomendados

Arquitectura de N niveles en máquinas virtuales

En esta sección se describe una arquitectura de N niveles recomendada que se ejecuta en máquinas virtuales.

diagrama físico de una arquitectura de N niveles

Cada nivel consta de dos o más máquinas virtuales, colocadas en un conjunto de disponibilidad o un conjunto de escalado de máquinas virtuales. Varias máquinas virtuales proporcionan resistencia en caso de que se produzca un error en una máquina virtual. Los equilibradores de carga se usan para distribuir las solicitudes entre las máquinas virtuales de un nivel. Un nivel se puede escalar horizontalmente agregando más máquinas virtuales al grupo.

Cada nivel también se coloca dentro de su propia subred, lo que significa que sus direcciones IP internas se encuentran dentro del mismo intervalo de direcciones. Esto facilita la aplicación de reglas de grupo de seguridad de red y tablas de enrutamiento a niveles individuales.

Los niveles web y de negocio no tienen estado. Cualquier máquina virtual puede controlar cualquier solicitud de ese nivel. El nivel de datos debe constar de una base de datos replicada. Para Windows, se recomienda SQL Server, con grupos de disponibilidad AlwaysOn para lograr una alta disponibilidad. En Linux, elija una base de datos que admita la replicación, como Apache Cassandra.

Los grupos de seguridad de red restringen el acceso a cada nivel. Por ejemplo, el nivel de base de datos solo permite el acceso desde el nivel empresarial.

Nota

La capa etiquetada "Nivel de negocio" en nuestro diagrama de referencia es un moniker para el nivel de lógica de negocios. Del mismo modo, también llamamos al nivel de presentación "Nivel web". En nuestro ejemplo, se trata de una aplicación web, aunque también se pueden usar arquitecturas de varios niveles para otras topologías (como las aplicaciones de escritorio). Asigne un nombre a los niveles que mejor funcionen para que el equipo comunique la intención de ese nivel lógico o físico en la aplicación, incluso podría expresar esa nomenclatura en los recursos que elija para representar ese nivel (por ejemplo, vmss-appName-business-layer).

Consideraciones adicionales

  • Las arquitecturas de n niveles no están restringidas a tres niveles. Para aplicaciones más complejas, es habitual tener más niveles. En ese caso, considere la posibilidad de usar el enrutamiento de nivel 7 para enrutar las solicitudes a un nivel determinado.

  • Los niveles son el límite de escalabilidad, confiabilidad y seguridad. Considere la posibilidad de tener niveles independientes para los servicios con requisitos diferentes en esas áreas.

  • Use conjuntos de escalado de máquinas virtuales para escalado automático.

  • Busque lugares en la arquitectura donde puede usar un servicio administrado sin refactorización significativa. En concreto, examine el almacenamiento en caché, la mensajería, el almacenamiento y las bases de datos.

  • Para mayor seguridad, coloque una red perimetral delante de la aplicación. La red perimetral incluye aplicaciones virtuales de red (NVA) que implementan funcionalidades de seguridad como firewalls e inspección de paquetes. Para obtener más información, consulte arquitectura de referencia de red perimetral.

  • Para lograr una alta disponibilidad, coloque dos o más NVA en un conjunto de disponibilidad, con un equilibrador de carga externo para distribuir las solicitudes de Internet entre las instancias. Para obtener más información, consulte Implementación de aplicaciones virtuales de red de alta disponibilidad.

  • No permita el acceso directo a RDP o SSH a las máquinas virtuales que ejecutan código de aplicación. En su lugar, los operadores deben iniciar sesión en un jumpbox, también denominado host bastión. Se trata de una máquina virtual de la red que los administradores usan para conectarse a las otras máquinas virtuales. Jumpbox tiene un grupo de seguridad de red que permite RDP o SSH solo desde direcciones IP públicas aprobadas.

  • Puede ampliar la red virtual de Azure a la red local mediante una red privada virtual (VPN) de sitio a sitio o Azure ExpressRoute. Para obtener más información, consulte arquitectura de referencia de red híbrida.

  • Si su organización usa Active Directory para administrar la identidad, puede que desee ampliar el entorno de Active Directory a la red virtual de Azure. Para obtener más información, consulte arquitectura de referencia de Identity Management.

  • Si necesita una mayor disponibilidad que el Acuerdo de Nivel de Servicio de Azure para VM, replique la aplicación en dos regiones y use Azure Traffic Manager para la conmutación por error. Para obtener más información, consulte Ejecución de máquinas virtuales Linux en varias regiones.