Estilos de arquitectura

Un estilo de arquitectura es una familia de arquitecturas que comparten características específicas. Por ejemplo, N niveles es un estilo de arquitectura común. Más recientemente, las arquitecturas de microservicios empiezan a ganar favor. Los estilos de arquitectura no requieren el uso de tecnologías específicas, pero algunas tecnologías son más adecuadas para determinadas arquitecturas. Por ejemplo, los contenedores son adecuados para microservicios.

Hemos identificado un conjunto de estilos de arquitectura que se encuentran normalmente en aplicaciones en la nube. El artículo para cada estilo incluye los siguientes componentes:

• Descripción y diagrama lógico del estilo
• Recomendaciones para cuándo elegir este estilo
• Ventajas, desafíos y procedimientos recomendados
• Una implementación recomendada que usa los servicios de Azure pertinentes

Un paseo rápido por los estilos

En esta sección se ofrece un paseo rápido por los estilos de arquitectura que hemos identificado, junto con algunas consideraciones de alto nivel para su uso. Esta lista no es exhaustiva. Lea más detalles en los artículos vinculados.

N niveles

En el diagrama se muestra la estructura superpuesta de una arquitectura de N niveles con una separación clara entre los componentes. Las solicitudes de cliente entran a través de un firewall de aplicaciones web (WAF) que proporciona filtrado de seguridad antes de alcanzar el nivel web. El nivel web actúa como capa de presentación. Controla las interacciones del usuario y las solicitudes de enrutamiento a los componentes de lógica de negocios adecuados. Dos rutas de procesamiento distintas surgen del nivel web: una ruta de acceso fluye directamente al nivel intermedio uno para las operaciones sincrónicas, mientras que otra ruta de acceso usa la infraestructura de mensajería para comunicarse con el nivel intermedio dos para el procesamiento asincrónico. Ambos niveles intermedios representan capas de lógica de negocios que procesan solicitudes e interactúan con el nivel de datos a través de mecanismos de almacenamiento en caché para optimizar el rendimiento. El nivel de datos actúa como base. Almacena y administra los datos de la aplicación al tiempo que admite ambos niveles intermedios a través de patrones de acceso a datos almacenados en caché.

N niveles es una arquitectura tradicional para aplicaciones empresariales que divide una aplicación en capas lógicas y niveles físicos. Cada capa tiene una responsabilidad específica y las capas administran las dependencias llamando solo a capas bajo ellas. Entre las capas típicas se incluyen la presentación, la lógica de negocios y el acceso a datos.

Las arquitecturas de n niveles son adecuadas para migrar aplicaciones existentes que ya usan una arquitectura superpuesta. Este enfoque requiere cambios mínimos al pasar a Azure y admite entornos mixtos con componentes locales y en la nube. Pero la capa horizontal puede dificultar la introducción de cambios sin afectar a varias partes de la aplicación, lo que limita la agilidad de las actualizaciones frecuentes.

Web-Cola-Trabajo

En el diagrama se muestra una separación limpia entre los componentes de procesamiento en segundo plano y orientados al usuario. Las interacciones de cliente comienzan con la autenticación a través de un proveedor de identidades antes de llegar al front-end web, que actúa como la interfaz de usuario principal. El front-end web mantiene tres relaciones operativas distintas: puede comunicarse directamente con servicios remotos para integraciones externas, acceder a la base de datos para operaciones de datos inmediatas y poner en cola elementos de trabajo para el procesamiento en segundo plano. La cola actúa como un mecanismo de desacoplamiento. Permite que el componente de trabajo procese tareas que consumen muchos recursos o de larga duración independientemente de las solicitudes de usuario. El trabajador recupera los trabajos de la cola y realiza operaciones en la base de datos, con infraestructura de caché que admite tanto el front-end web como el trabajador para un acceso a los datos optimizado. Además, el contenido estático se distribuye a través de una red de entrega de contenido (CDN) para mejorar el rendimiento de las aplicaciones cliente.

Web-Queue-Worker es una arquitectura que consta de una interfaz web, una cola de mensajes y un trabajador back-end. El front-end web controla las solicitudes HTTP y las interacciones del usuario, mientras que el trabajo realiza tareas que consumen muchos recursos, flujos de trabajo de larga duración o operaciones por lotes. La comunicación entre la interfaz frontal y el trabajador se produce a través de una cola de mensajes asincrónica.

Esta arquitectura es ideal para aplicaciones con dominios relativamente simples que tienen algunos requisitos de procesamiento intensivo de recursos. Es fácil entender e implementar con servicios administrados de Azure, como App Service y Azure Functions. Puede escalar el frontend y el componente de trabajo de forma independiente para proporcionar flexibilidad en la asignación de recursos. Pero sin un diseño cuidadoso, ambos componentes pueden convertirse en grandes y monolíticos.

Microservicios

En el diagrama se muestra una arquitectura de microservicios distribuida organizada en distintas capas funcionales. A la izquierda, las aplicaciones cliente y los sistemas externos inician solicitudes que fluyen a través de una puerta de enlace de API centralizada, que actúa como punto de entrada único y mecanismo de enrutamiento para todo el sistema. La puerta de enlace de API dirige las solicitudes a la capa de microservicios adecuada, que contiene varios tipos de servicio: servicios de dominio que encapsulan funcionalidades empresariales específicas, servicios de composición que organizan interacciones entre servicios de dominio y servicios individuales que controlan funciones discretas. Cada microservicio mantiene la autonomía de los datos a través de su propia base de datos dedicada. El diagrama muestra un enfoque de persistencia políglota mediante bases de datos SQL y NoSQL adaptadas a las necesidades específicas de datos de cada servicio. Los microservicios se comunican de forma asincrónica a través del middleware orientado a mensajes. Este enfoque permite el acoplamiento flexible mediante patrones de publicación y suscripción y interacciones controladas por eventos. Tres niveles fundamentales de infraestructura admiten esta arquitectura distribuida: los sistemas de observabilidad proporcionan una supervisión completa, el registro y el seguimiento distribuido a través de los límites del servicio. Las plataformas de administración y orquestación controlan la implementación automatizada, el escalado y la detección de servicios. Las cadenas de herramientas de DevOps permiten canalizaciones de integración, pruebas y entrega continuas para implementaciones de servicios independientes.

La arquitectura de microservicios descompone las aplicaciones en una colección de servicios pequeños y autónomos. Cada servicio implementa una única funcionalidad empresarial dentro de un contexto limitado y está autocontenida con su propio almacenamiento de datos. Los servicios se comunican a través de API bien definidas y se pueden desarrollar, implementar y escalar de forma independiente.

Los microservicios permiten a los equipos trabajar de forma autónoma y admitir actualizaciones frecuentes con mayor velocidad de versión. Esta arquitectura es adecuada para dominios complejos que requieren cambios e innovación frecuentes. Pero presenta una complejidad significativa en áreas como la detección de servicios, la coherencia de datos y la administración del sistema distribuido. El éxito requiere el desarrollo maduro y las prácticas de DevOps, lo que hace que sea más adecuado para las organizaciones que tienen funcionalidades técnicas avanzadas.

Arquitectura basada en eventos

En el diagrama se muestra un patrón de comunicación asincrónico desacoplado fundamental para las arquitecturas controladas por eventos. Varios productores de eventos operan de forma independiente. Los flujos de eventos generados en función de las actividades empresariales, las interacciones del usuario o los cambios de estado del sistema sin ningún conocimiento de los consumidores de nivel inferior. Los productores alimentan sus eventos en un sistema de ingesta de eventos centralizado que actúa como agente inteligente. El intermediario recibe, valida, conserva y distribuye eventos de forma confiable en toda la arquitectura. El componente de ingestión de eventos actúa como un punto de desacoplamiento crítico. Garantiza que los productores permanezcan aislados de los consumidores, mientras proporciona garantías en torno a la entrega, la ordenación y la durabilidad de los eventos. Desde este centro central, los eventos se distribuyen a través de un patrón de distribución ramificada a varios consumidores de eventos independientes situados en el lado derecho del diagrama. Cada consumidor representa una funcionalidad o servicio empresarial distinto que se suscribe a tipos de eventos específicos relevantes para sus responsabilidades de dominio. Los consumidores procesan eventos de forma asincrónica y en paralelo, lo que permite al sistema escalar horizontalmente mientras se mantiene el acoplamiento flexible. Este patrón arquitectónico elimina las dependencias directas entre productores y consumidores. Permite que cada componente evolucione, se escale e implemente de forma independiente mientras mantiene la resiliencia del sistema a través de las capacidades de almacenamiento en búfer y reintento del intermediario de eventos.

Las arquitecturas controladas por eventos usan un modelo de publicación y suscripción en el que los productores de eventos generan flujos de eventos y los consumidores de eventos responden a esos eventos casi en tiempo real. Los productores y consumidores se desacoplan entre sí, con la comunicación ocurriendo a través de canales de eventos o intermediarios. Esta arquitectura admite el procesamiento de eventos simple y el análisis de patrones de eventos complejos.

Las arquitecturas controladas por eventos se destacan en escenarios que requieren procesamiento en tiempo real con una latencia mínima. Algunos ejemplos son soluciones de IoT, sistemas financieros o aplicaciones que necesitan procesar grandes volúmenes de datos de streaming. Las arquitecturas controladas por eventos proporcionan una excelente escalabilidad y aislamiento de errores, pero presentan desafíos en torno a la entrega garantizada, el orden de eventos y la coherencia final entre los componentes distribuidos.

Macrodatos

En el diagrama se presenta una arquitectura completa de macrodatos con dos canalizaciones de procesamiento complementarias que controlan diferentes velocidades de datos y requisitos analíticos. La canalización de procesamiento por lotes comienza con diversos orígenes de datos que se alimentan de sistemas de almacenamiento de datos escalables, normalmente lagos de datos o sistemas de archivos distribuidos capaces de almacenar grandes volúmenes de datos estructurados, semiestructurados y no estructurados. El componente de procesamiento por lotes realiza transformaciones, agregaciones y cálculos analíticos a gran escala en los datos históricos. Funciona en intervalos programados o cuando se acumulan datos suficientes. Resultados del flujo de procesamiento por lotes a través de dos vías: directamente a los sistemas de análisis e informes para el consumo inmediato y a los almacenes de datos analíticos donde los datos procesados se conservan en formatos optimizados para consultas complejas y análisis históricos. Simultáneamente, la canalización de procesamiento en tiempo real captura los datos de streaming a través de sistemas de ingesta de mensajes en tiempo real que controlan flujos de datos de alta velocidad desde orígenes como dispositivos IoT, aplicaciones web o sistemas transaccionales. Los componentes de procesamiento de flujos analizan estos datos en movimiento, realizando agregaciones en tiempo real, filtrado y detección de patrones para generar información inmediata. Los resultados en tiempo real también siguen dos caminos, lo que se alimenta directamente en análisis e informes para paneles y alertas instantáneos, y en los mismos almacenes de datos analíticos para crear una vista unificada que combine datos históricos y actuales. La capa de orquestación abarca ambas canalizaciones. Coordina flujos de trabajo complejos, administra las dependencias entre trabajos por lotes y de streaming, programa tareas de procesamiento y garantiza la coherencia de los datos en toda la arquitectura. Esta orquestación permite crear arquitecturas lambda en las que tanto el procesamiento por lotes como el procesamiento en tiempo real pueden funcionar en los mismos conjuntos de datos, lo que proporciona un análisis histórico completo e inteligencia operativa inmediata.

Las arquitecturas de macrodatos controlan la ingesta, el procesamiento y el análisis de datos demasiado grandes o complejos para los sistemas de base de datos tradicionales. Estas arquitecturas suelen incluir componentes para el almacenamiento de datos (como lagos de datos), el procesamiento por lotes para el análisis histórico, el procesamiento de flujos para información en tiempo real y los almacenes de datos analíticos para la creación de informes y la visualización.

Las arquitecturas de macrodatos son esenciales para las organizaciones que necesitan extraer información de conjuntos de datos masivos, admitir análisis predictivos mediante el aprendizaje automático o procesar datos de streaming en tiempo real desde dispositivos IoT. Las implementaciones modernas suelen usar servicios administrados como Microsoft Fabric para simplificar la complejidad de crear y mantener soluciones de macrodatos.

Computación a Gran Escala

En el diagrama se muestra un sofisticado sistema de distribución y operación de trabajos diseñado para cargas de trabajo de informática de alto rendimiento. En el punto de entrada, las aplicaciones cliente envían trabajos computacionalmente intensivos a través de una interfaz de cola de tareas que actúa como un mecanismo de amortiguación y admisión para las solicitudes de trabajo entrantes. Los trabajos fluyen a un programador centralizado o un componente de coordinación que actúa como cerebro inteligente del sistema, responsable de analizar las características del trabajo, los requisitos de recursos y las dependencias computacionales. El programador realiza funciones críticas, como la descomposición del trabajo, el planeamiento de la asignación de recursos y la optimización de la carga de trabajo en función de los recursos informáticos disponibles y las interdependencias de tareas. A partir de este punto de coordinación central, el programador enruta inteligentemente las rutas de trabajo a lo largo de dos caminos de operación distintos en función de las características computacionales de cada trabajo. La primera ruta dirige el trabajo a entornos de control de tareas paralelos diseñados para cargas de trabajo embarazosamente paralelas en las que las tareas individuales se pueden ejecutar de forma independiente sin necesidad de comunicación entre unidades de procesamiento. Estas tareas paralelas se distribuyen entre cientos o miles de núcleos simultáneamente, con cada núcleo procesando unidades de trabajo discretas de forma aislada. La segunda ruta controla las tareas estrechamente acopladas que requieren una comunicación entre procesos frecuente, acceso a memoria compartida o patrones de operación sincronizados. Estas cargas de trabajo estrechamente acopladas suelen usar interconexiones de alta velocidad, como InfiniBand o redes de acceso directo a memoria remota (RDMA) para permitir el intercambio rápido de datos entre nodos de procesamiento. El programador supervisa continuamente ambos entornos de operación, administra la asignación de recursos, controla la tolerancia a errores y optimiza el rendimiento ajustando dinámicamente la distribución del trabajo en función de la capacidad del sistema, las prioridades de trabajo y los requisitos de finalización. El enfoque bifurcado permite que la arquitectura controle eficazmente diversas cargas de trabajo computacionales, al tiempo que maximiza el uso de recursos en toda la infraestructura informática.

Las arquitecturas de proceso grande admiten cargas de trabajo a gran escala que requieren cientos o miles de núcleos para las operaciones de proceso intensivo. El trabajo se puede dividir en tareas discretas que se ejecutan en muchos núcleos simultáneamente, con cada tarea que toma entradas, la procesa y genera la salida. Las tareas pueden ser independientes (embarazosamente paralelas) o estrechamente acopladas que requieren comunicación de alta velocidad.

La computación intensiva es esencial para simulaciones, modelado de riesgos financieros, computación científica, análisis de tensiones en la ingeniería y renderizado 3D. Azure proporciona opciones como Azure Batch para cargas de trabajo de proceso grandes administradas o HPC Pack para una administración de clústeres más tradicional. Estas arquitecturas pueden ampliar la capacidad a petición y escalar a miles de núcleos cuando sea necesario.

Estilos de arquitectura como restricciones

Un estilo de arquitectura coloca restricciones en el diseño, incluido el conjunto de elementos que pueden aparecer y las relaciones permitidas entre esos elementos. Las restricciones guían la "forma" de una arquitectura mediante la restricción del universo de opciones. Cuando una arquitectura se ajusta a las restricciones de un estilo determinado, surgen determinadas propiedades deseables.

Por ejemplo, las restricciones de los microservicios incluyen:

• Un servicio representa una única responsabilidad.
• Cada servicio es independiente de los demás.
• Los datos son privados para el servicio que lo posee. Los servicios no comparten datos.

Al cumplir estas restricciones, obtendrá un sistema que le permite realizar las siguientes acciones:

• Implemente servicios de forma independiente.
• Aísle los errores.
• Inserte actualizaciones más frecuentes.
• Introduce nuevas tecnologías en la aplicación con más facilidad.

Cada estilo de arquitectura tiene sus propias ventajas. Antes de elegir un estilo arquitectónico, es esencial comprender los principios y restricciones subyacentes. Sin esa comprensión, corre el riesgo de crear un diseño que se ajuste superficialmente al estilo sin aprovechar sus beneficios completos. Céntrese más en por qué está seleccionando un estilo específico que sobre cómo implementarlo. Sea práctico. A veces es mejor relajar una restricción que perseguir la pureza arquitectónica.

Lo ideal es que la elección del estilo arquitectónico se realice con aportaciones de las partes interesadas informadas sobre la carga de trabajo. El equipo de carga de trabajo debe empezar identificando la naturaleza del problema que están solucionando. Después, deben definir los principales impulsores empresariales y las características de arquitectura correspondientes, también conocidas como requisitos no funcionales, y priorizarlas. Por ejemplo, si el tiempo de comercialización es crítico, el equipo podría priorizar la capacidad de mantenimiento, la capacidad de prueba y la confiabilidad para permitir una implementación rápida. Si el equipo tiene restricciones presupuestarias estrictas, la viabilidad y la simplicidad pueden tener prioridad. Seleccionar y mantener un estilo arquitectónico no es una tarea única. Requiere medición, validación y refinamiento continuos. Dado que cambiar la dirección de la arquitectura más adelante puede ser costoso, a menudo vale la pena invertir más esfuerzo desde el principio para apoyar la eficiencia a largo plazo y reducir los riesgos.

En la tabla siguiente se resume cómo cada estilo administra las dependencias y los tipos de dominio que son más adecuados para cada estilo.

Estilo de arquitectura	Administración de dependencias	Tipo de dominio
N niveles	Niveles horizontales divididos por subred	Dominio empresarial tradicional. La frecuencia de las actualizaciones es baja.
Web-cola-trabajo	Tareas front-end y back-end, desacopladas mediante mensajería asincrónica.	Dominio relativamente sencillo con algunas tareas que consumen muchos recursos.
Microservicios	Servicios descomponidos verticalmente (funcionalmente) que se llaman entre sí a través de las API.	Dominio complicado. Actualizaciones frecuentes.
Arquitectura controlada por eventos	Productor o consumidor. Vista independiente para cada subsistema.	Internet de las cosas (IoT) y sistemas en tiempo real.
Macrodatos	Divida un conjunto de datos enorme en pequeños fragmentos. Procesamiento paralelo en conjuntos de datos locales.	Análisis de datos por lotes y en tiempo real. Análisis predictivo mediante el aprendizaje automático.
Gran capacidad de cálculo	Asignación de datos a miles de núcleos.	Dominios intensivos de proceso, como la simulación.

Tener en cuenta los desafíos y las ventajas

Las restricciones también crean desafíos, por lo que es importante comprender las ventajas y desventajas al adoptar cualquiera de estos estilos. Determine si las ventajas del estilo de arquitectura superan los desafíos, para este subdominio y contexto limitado.

Tenga en cuenta los siguientes tipos de desafíos al seleccionar un estilo de arquitectura:

• Complejidad: La complejidad de la arquitectura debe coincidir con el dominio. Si es demasiado simple, puede dar lugar a una gran bola de barro, donde las dependencias no están bien administradas y la estructura se desglosa.

• Mensajería asincrónica y coherencia final: La mensajería asincrónica se usa para desacoplar servicios y mejorar la confiabilidad porque se pueden reintentar los mensajes. También mejora la escalabilidad. Sin embargo, la mensajería asincrónica también crea desafíos para controlar la coherencia final y la posibilidad de mensajes duplicados.

• Comunicación entre servicios: La descomposición de una aplicación en servicios independientes podría aumentar la sobrecarga de comunicación. En las arquitecturas de microservicios, esta sobrecarga suele dar lugar a problemas de latencia o congestión de red.

• Manejabilidad: La administración de la aplicación incluye tareas como la supervisión, la implementación de actualizaciones y el mantenimiento del estado operativo.

Recursos relacionados

• Diez principios de diseño para las aplicaciones de Azure

Pasos siguientes

• Creación de aplicaciones en la nube de Microsoft
• Procedimientos recomendados en aplicaciones en la nube
• Patrones de diseño en la nube
• Pruebas de rendimiento y antipatrones para aplicaciones en la nube
• Diseño de soluciones multiinquilino en Azure
• Arquitectura de carga de trabajo crítica en Azure
• Arquitectura para startups