Esta guía estructura las pautas de diseño para aplicaciones en la nube escalables, resistentes y altamente accesibles. Está diseñado para ayudarlo a tomar decisiones sobre su arquitectura, sin importar qué plataforma de nube utilice.
El manual está organizado como una secuencia de pasos: elegir una arquitectura → elegir tecnologías para computar y almacenar datos → diseñar una aplicación de Azure → elegir plantillas → verificar la arquitectura. Para cada uno de ellos, hay recomendaciones que lo ayudarán a desarrollar la arquitectura de la aplicación.
Hoy publicamos parte del primer capítulo de este libro. Puede descargar la versión completa de forma gratuita
aquí .
Tabla de contenidos
- La elección de la arquitectura - 1;
- La elección de tecnologías para computar y almacenar datos - 35;
- Diseño de una aplicación de Azure: principios de diseño - 60;
- Diseño de una aplicación de Azure: indicadores de calidad - 95;
- Diseño de una aplicación de Azure: patrones de diseño - 103;
- Directorio de plantillas - 110;
- Listas de verificación de validación de arquitectura - 263;
- Conclusión - 291;
- Azure Reference Architectures - 292;
Elección de arquitectura
La primera decisión que debe tomar al diseñar una aplicación en la nube es elegir una arquitectura. La elección de la arquitectura depende de la complejidad de la aplicación, el alcance, su tipo (IaaS o PaaS) y las tareas para las que está destinada. También es importante tener en cuenta las habilidades del equipo de desarrollo y los gerentes de proyecto, así como la disponibilidad de una arquitectura preparada para la aplicación.
La elección de la arquitectura impone ciertas restricciones en la estructura de la aplicación, lo que limita la elección de tecnologías y otros elementos de la aplicación. Estas limitaciones están asociadas con ventajas y desventajas de la arquitectura seleccionada.
La información en esta sección lo ayudará a encontrar un equilibrio entre ellos cuando implemente una arquitectura particular. Esta sección enumera diez principios de diseño a tener en cuenta. Seguir estos principios lo ayudará a crear una aplicación más escalable, resistente y manejable.
Hemos identificado un conjunto de opciones de arquitectura que se usan comúnmente en aplicaciones en la nube. La sección dedicada a cada uno de ellos contiene:
- descripción y lógica de la arquitectura;
- recomendaciones sobre el alcance de esta arquitectura;
- ventajas, desventajas y recomendaciones de uso;
- Opción de implementación recomendada con los servicios de Azure adecuados.
Descripción de la arquitectura
Esta sección proporciona una breve descripción de las opciones de arquitectura que hemos identificado, así como recomendaciones generales para su uso. Puede encontrar información más detallada en las secciones relevantes disponibles a través de los enlaces.
Nivel N
La arquitectura de N niveles se usa más comúnmente en aplicaciones empresariales. Para administrar las dependencias, la aplicación se divide en capas, cada una de las cuales es responsable de una determinada función lógica, por ejemplo, la presentación de datos, la lógica empresarial o el acceso a los datos. Una capa puede llamar a otras capas a continuación. Sin embargo, tal división en capas horizontales puede causar dificultades adicionales. Por ejemplo, puede ser difícil realizar cambios en una parte de la aplicación sin afectar sus otros elementos. Por lo tanto, actualizar dicha aplicación a menudo no es fácil, y los desarrolladores tendrán que agregar nuevas funciones con menos frecuencia.
La arquitectura N-tier es una opción natural cuando se transfieren aplicaciones ya utilizadas creadas sobre la base de una arquitectura escalonada. Por lo tanto, esta arquitectura se usa con mayor frecuencia en soluciones de IaaS (infraestructura como servicio) o en aplicaciones que combinan IaaS con servicios administrados.
Interfaz web - Cola - Rol del trabajador
Para las soluciones PaaS, la interfaz web - cola - arquitectura de roles de trabajo es adecuada. Con esta arquitectura, la aplicación tiene una interfaz web que procesa las solicitudes HTTP y una función de trabajo del servidor responsable de las operaciones que requieren mucho tiempo o requieren recursos informáticos. Se utiliza una cola de mensajes asíncronos para comunicarse entre la interfaz y el rol de trabajo del servidor.
La arquitectura "interfaz web - cola - rol de trabajo" es adecuada para tareas relativamente simples que requieren recursos informáticos. Al igual que la arquitectura de N niveles, este modelo es fácil de entender. El uso de servicios gestionados simplifica la implementación y la operación. Pero al crear aplicaciones para áreas temáticas complejas, puede ser difícil controlar las dependencias. La interfaz web y el rol de trabajo pueden expandirse fácilmente a componentes monolíticos grandes que son difíciles de mantener y actualizar. Al igual que con la arquitectura de N niveles, este modelo se caracteriza por una tasa de actualización más baja y oportunidades de mejora limitadas.
Microservicios
Si la aplicación está diseñada para resolver problemas más complejos, intente implementarla sobre la base de la arquitectura de microservicios. Dicha aplicación consta de muchos pequeños servicios independientes. Cada servicio es responsable de una función comercial separada. Los servicios están acoplados libremente y utilizan contratos API para interactuar.
Un pequeño equipo de desarrolladores puede trabajar en la creación de un servicio separado. Los servicios se pueden implementar sin una coordinación compleja entre los desarrolladores, lo que facilita su actualización periódica. La arquitectura de microservicios es más difícil de implementar y administrar que los dos enfoques anteriores. Requiere una cultura madura de gestión del desarrollo. Pero si todo está organizado correctamente, este enfoque ayuda a aumentar la frecuencia de lanzamiento de nuevas versiones, acelerar la implementación de innovaciones y hacer que la arquitectura sea más tolerante a fallas.
Cqrs
La arquitectura de CQRS (segregación de responsabilidad de comando y consulta, la distribución de responsabilidad entre equipos y consultas) le permite separar las operaciones de lectura y escritura entre modelos individuales. Como resultado, las partes del sistema que se encargan de cambiar los datos se aíslan de las partes del sistema que se encargan de leer los datos. Además, las operaciones de lectura se pueden realizar en una vista materializada que está físicamente separada de la base de datos en la que se está escribiendo. Esto le permite escalar de forma independiente los procesos de lectura y escritura y optimizar la presentación materializada para la ejecución de consultas.
El modelo CQRS se usa mejor para un subsistema de una arquitectura más grande. En general, no debe aplicarse a toda la aplicación, ya que esto complica innecesariamente su arquitectura. Funciona bien en sistemas de colaboración, donde una gran cantidad de usuarios trabajan simultáneamente con los mismos datos.
Arquitectura basada en eventos
Una arquitectura basada en eventos utiliza un modelo de publicación y suscripción en el que los proveedores publican eventos y los consumidores se suscriben a ellos. Los proveedores son independientes de los consumidores, y los consumidores son independientes entre sí.
Una arquitectura basada en eventos es adecuada para aplicaciones que necesitan recibir y procesar rápidamente grandes cantidades de datos con baja latencia, como Internet de las cosas. Además, dicha arquitectura funciona bien en los casos en que diferentes subsistemas deben procesar los mismos datos de eventos de manera diferente.
Big data, gran informática
Big data y big computing son opciones de arquitectura especiales que se utilizan para resolver problemas especiales. Cuando se utiliza la arquitectura de big data, los grandes conjuntos de datos se dividen en fragmentos, que luego se procesan en paralelo para fines de análisis e informes. La gran informática también se denomina informática de alto rendimiento (HPC). Esta tecnología le permite distribuir la informática entre múltiples (miles) de núcleos de procesador. Estas arquitecturas se pueden usar para simulación, renderizado 3D y otras tareas similares.
Opciones de arquitectura como limitaciones
La arquitectura actúa como una restricción en el diseño de una solución, en particular, determina qué elementos se pueden usar y qué conexiones entre ellos son posibles. Las restricciones definen la "forma" de la arquitectura y le permiten elegir entre un conjunto más limitado de opciones. Si se cumplen las restricciones de la arquitectura seleccionada, la solución tendrá propiedades características de esta arquitectura.
Por ejemplo, los microservicios se caracterizan por las siguientes restricciones:
- cada servicio es responsable de una función separada;
- los servicios son independientes entre sí;
- Los datos solo están disponibles para el servicio responsable de ellos. Los servicios no intercambian datos.
Seguir estas restricciones lleva a la creación de un sistema en el que los servicios pueden implementarse independientemente uno del otro, los fallos están aislados, las actualizaciones frecuentes son posibles y las nuevas tecnologías se agregan fácilmente a la aplicación.
Antes de elegir una arquitectura, asegúrese de comprender bien los principios subyacentes y las limitaciones relacionadas. De lo contrario, puede obtener una solución que coincida externamente con el modelo de arquitectura seleccionado, pero no revela completamente el potencial de este modelo. El sentido común también es importante. A veces es más sabio renunciar a una u otra restricción que luchar por una arquitectura limpia.
La siguiente tabla muestra cómo se implementa la gestión de dependencias en cada una de sus arquitecturas, y para qué tareas esta o aquella arquitectura es más adecuada.
Análisis de las ventajas y desventajas.
Las limitaciones crean dificultades adicionales, por lo que es importante comprender lo que tiene que sacrificar al elegir una u otra opción de arquitectura, y poder responder a la pregunta de si las ventajas de la opción elegida superan sus desventajas para una tarea específica en un contexto específico.
A continuación se enumeran algunas de las desventajas a tener en cuenta al elegir una arquitectura:
- Complejidad ¿Está justificado el uso de una arquitectura compleja para su tarea? Y viceversa, ¿es una arquitectura demasiado simple elegida para una tarea compleja? En este caso, corre el riesgo de obtener un sistema sin una estructura clara, ya que la arquitectura utilizada no le permite administrar correctamente las dependencias.
- Mensajería asincrónica y, en última instancia, coherencia. La mensajería asincrónica ayuda a separar los servicios y mejora la confiabilidad (gracias a la capacidad de reenviar mensajes) y la escalabilidad. Sin embargo, crea ciertas dificultades, como la semántica de una sola transmisión y el problema de coherencia a largo plazo.
- Interacción entre servicios. Si divide la aplicación en servicios separados, existe el riesgo de que el intercambio de datos entre los servicios tome demasiado tiempo o conduzca a la congestión de la red (por ejemplo, al usar microservicios).
- Manejabilidad ¿Qué tan difícil será administrar la aplicación, monitorear su trabajo, implementar actualizaciones y realizar otras tareas?
Arquitectura N-tier
En la arquitectura de N niveles, una aplicación se divide en capas lógicas y capas físicas.
Las capas son un mecanismo para compartir la responsabilidad y gestionar las dependencias. Cada capa tiene su propia área de responsabilidad. Las capas de nivel superior utilizan los servicios de las capas de nivel inferior, pero no al revés.
Los niveles están separados físicamente y funcionan en diferentes computadoras. Un nivel puede acceder al otro directamente o mediante mensajes asincrónicos (colas de mensajes). Aunque cada capa debe colocarse en su propio nivel, esto no es necesario. Puede colocar varias capas en un nivel. La separación física de niveles hace que la solución no solo sea más escalable y tolerante a fallas, sino también más lenta, ya que la red a menudo se usa para la interacción. Una aplicación tradicional de tres niveles consta de un nivel de presentación, un nivel intermedio y un nivel de base de datos. Un nivel intermedio es opcional. Las aplicaciones más complejas pueden consistir en más de tres niveles. El diagrama anterior muestra una aplicación con dos niveles intermedios responsables de varias áreas funcionales.
Una aplicación de N niveles puede tener una arquitectura de capa cerrada o una arquitectura de capa abierta.
- En una arquitectura cerrada, una capa arbitraria solo puede acceder a la capa inferior más cercana.
- En una arquitectura abierta, una capa arbitraria puede referirse a cualquier capa inferior.
La arquitectura de capa cerrada limita las dependencias entre capas. Sin embargo, su uso puede aumentar excesivamente el tráfico de red si una capa en particular simplemente reenvía las solicitudes a la siguiente capa.
Aplicaciones de arquitectura
La arquitectura de N niveles generalmente se usa en aplicaciones IaaS, donde cada nivel se ejecuta en un conjunto separado de máquinas virtuales. Sin embargo, una aplicación de N niveles no tiene que ser una aplicación de IaaS pura. A menudo es conveniente usar servicios administrados para algunos componentes de una solución, especialmente para el almacenamiento en caché, la mensajería y el almacenamiento de datos.
Se recomienda utilizar la arquitectura de N niveles en los siguientes casos:
- aplicaciones web simples;
- Portar una aplicación local a Azure con una refactorización mínima
- implementación consistente de aplicaciones locales y en la nube.
La arquitectura de N niveles es común entre las aplicaciones locales normales, por lo que es muy adecuada para portar aplicaciones existentes a Azure.
Los beneficios
- La capacidad de transferir aplicaciones entre la implementación local y la nube, así como entre plataformas en la nube.
- Menos capacitación para la mayoría de los desarrolladores.
- Una extensión natural del modelo de aplicación tradicional.
- Soporte para entornos heterogéneos (Windows / Linux).
Desventajas
- Es fácil obtener una aplicación en la que el nivel medio solo realiza operaciones CRUD en la base de datos, lo que aumenta el tiempo de procesamiento de las solicitudes y no aporta ningún beneficio.
- La arquitectura monolítica no permitirá el desarrollo de componentes individuales por equipos de desarrollo independientes.
- Administrar una aplicación IaaS lleva más tiempo que una aplicación administrada solo de servicio.
- Puede ser difícil administrar la seguridad de la red en sistemas grandes.
Recomendaciones
- Utilice el escalado automático a carga variable. Consulte las mejores prácticas para el escalado automático.
- Utilice la mensajería asincrónica para separar niveles entre sí.
- Caché de datos semiestáticos. Ver Consideraciones de almacenamiento en caché.
- Garantice una alta disponibilidad a nivel de base de datos con una solución como Grupos de disponibilidad siempre activa en SQL Server.
- Instale un firewall de aplicación web (WAF) entre la interfaz e Internet.
- Coloque cada nivel en su propia subred; use subredes como límites de seguridad.
- Limite el acceso al nivel de datos permitiendo solo consultas de niveles intermedios.
Arquitectura de máquina virtual de nivel N
Esta sección proporciona pautas para construir una arquitectura de N niveles usando máquinas virtuales.
Esta sección proporciona pautas para construir una arquitectura de N niveles usando máquinas virtuales. Cada nivel consta de dos o más máquinas virtuales alojadas en un conjunto de disponibilidad o en un conjunto escalable de máquinas virtuales. El uso de varias máquinas virtuales proporciona tolerancia a fallas en caso de falla de una de ellas. Para distribuir solicitudes entre máquinas virtuales del mismo nivel, se utilizan subsistemas de equilibrio de carga. El nivel se puede escalar horizontalmente, agregando nuevas máquinas virtuales al grupo.
Cada nivel también se coloca dentro de su propia subred. Esto significa que sus direcciones IP internas están en el mismo rango. Esto facilita la aplicación de las reglas del Grupo de seguridad de red (NSG) y las tablas de enrutamiento a las capas individuales.
El estado del nivel web y el nivel empresarial no se supervisa. Cualquier máquina virtual puede manejar cualquier solicitud para estos niveles. La capa de datos debe consistir en una base de datos replicada. Para Windows, recomendamos usar SQL Server con Grupos de disponibilidad Always On para alta disponibilidad. Para Linux, debe elegir una base de datos que admita la replicación, como Apache Cassandra.
El acceso a cada nivel está limitado por los grupos de seguridad de red (NSG). Por ejemplo, el acceso al nivel de la base de datos solo está permitido para el nivel empresarial
Características adicionales
- La arquitectura de N niveles no tiene que constar de tres niveles. Las aplicaciones más complejas tienden a usar más niveles. En este caso, utilice el enrutamiento a través de la capa 7 para redirigir las solicitudes a un nivel específico.
- Los niveles limitan la decisión sobre escalabilidad, confiabilidad y seguridad. Se recomienda que utilice diferentes niveles para servicios con diferentes requisitos para estas características.
- Utilice el escalado automático utilizando conjuntos escalables de máquinas virtuales.
- Encuentre elementos en su arquitectura que pueda implementar con servicios administrados sin una refactorización importante. En particular, preste atención al almacenamiento en caché, la mensajería, el almacenamiento y las bases de datos.
- Para aumentar la seguridad, coloque la aplicación detrás de la red perimetral. La red perimetral incluye componentes de red virtual que brindan seguridad, como firewalls e inspectores de paquetes. Para obtener más información, consulte Arquitectura de red de referencia perimetral.
- Para una alta disponibilidad, coloque dos o más componentes de red virtual en el conjunto de disponibilidad y agregue un equilibrador de carga para distribuir las solicitudes de Internet entre ellos. Para obtener más información, consulte Implementación de componentes de red virtual para alta disponibilidad.
- No permita el acceso directo a máquinas virtuales que ejecutan código de aplicación sobre los protocolos RDP y SSH. En cambio, los operadores deben ingresar al nodo de bastión. Esta es una máquina virtual ubicada en la red utilizada por los administradores para conectarse a otras máquinas virtuales. En el host del bastión, las reglas NSG están configuradas para permitir el acceso a través de RDP y SSH solo desde direcciones IP públicas aprobadas.
- Puede expandir la red virtual de Azure a una red local utilizando una red virtual (VPN) de red a red 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 la administración de identidades, puede extender su entorno de Active Directory a la red virtual de Azure. Para obtener más información, consulte Arquitectura de referencia de gestión de identidad.
- Si se requiere un nivel de disponibilidad superior al requerido por el Acuerdo de nivel de servicio de máquina virtual de Azure, replique la aplicación entre las dos regiones y configure Azure Traffic Manager para la conmutación por error. Para obtener más información, consulte Inicio de máquinas virtuales de Windows en varias regiones e Inicio de máquinas virtuales de Linux en varias regiones.
Puede descargar la versión completa del libro de forma gratuita y estudiarla en el siguiente enlace.
→
Descargar