Esta arquitectura de ejemplo se basa en la arquitectura de integración empresarial básica. Amplía esa arquitectura para mostrar la forma en que se integran los sistemas de back-end empresariales, mediante el uso de agentes de mensajes y eventos para desacoplar los servicios, con el fin de aumentar la escalabilidad y confiabilidad. Asegúrese de que conoce ese diseño y los componentes usados en la arquitectura de integración básica. Proporciona información fundamental sobre los componentes principales de esta arquitectura, ya que no se reproducirán aquí.
Architecture
Los sistemas de back-end a los que se hace referencia en este diseño pueden incluir sistemas de software como servicio (SaaS), servicios de Azure y servicios web existentes de su empresa.
Descargue un archivo de Visio de esta arquitectura.
Flujo de trabajo
La arquitectura que se muestra aquí se basa en una arquitectura más sencilla que se muestra en el artículo Integración empresarial básica en Azure. Esta arquitectura usa Logic Apps para organizar los flujos de trabajo directamente con los sistemas back-end y API Management para crear catálogos de API.
Esta versión de la arquitectura agrega dos componentes que ayudan a que el sistema sea más confiable y escalable:
Azure Service Bus . Service Bus es un agente de mensajes seguro y confiable.
Azure Event Grid . Event Grid es un servicio de enrutamiento de eventos. Usa un modelo de generación de eventos de publicación/suscripción (pub/sub).
La comunicación asincrónica mediante un agente de mensajes proporciona las siguientes ventajas con respecto a la realización de llamadas directas, sincrónicas a servicios de back-end:
- Proporciona la nivelación de carga para controlar los picos de cargas de trabajo, mediante el patrón de nivelación de carga basado en cola.
- Proporciona la difusión de mensajes a varios consumidores mediante el patrón de publicador y suscriptor.
- Realiza un seguimiento confiable del progreso de los flujos de trabajo de ejecución prolongada que implican varios pasos o varias aplicaciones.
- Ayuda a desacoplar aplicaciones.
- Se integra con los sistemas existentes basados en mensajes.
- Permite poner en cola el trabajo cuando algún sistema de back-end no está disponible.
Event Grid permite a los distintos componentes en el sistema reaccionar ante eventos cuando estos se produzcan, en lugar de confiar en sondeos o tareas programadas. Igual que hace una cola de mensajes y temas, le ayuda a desacoplar aplicaciones y servicios. Una aplicación o un servicio puede publicar eventos y todos los suscriptores interesados recibirán notificaciones. Se pueden agregar suscriptores sin actualizar al remitente.
Muchos servicios de Azure admiten el envío de eventos a Event Grid. Por ejemplo, una aplicación lógica puede escuchar un evento cuando se agregan nuevos archivos a un almacén de blobs. Este patrón permite los flujos de trabajo reactivos, donde cargar un archivo o poner un mensaje en una cola inicia una serie de procesos. Los procesos se pueden ejecutar en paralelo o en una secuencia concreta.
Recomendaciones
Las recomendaciones que se describen en el artículo Integración empresarial básica en Azure se aplican a esta arquitectura.
Azure Service Bus
Service Bus tiene dos modos de entrega, extracción o inserción con proxy. En el modelo de extracción, el receptor realiza sondeos de continuamente para detectar mensajes nuevos. El sondeo puede ser ineficaz, sobre todo si hay varias colas y cada una de ellas recibe unos pocos mensajes, o si pasa mucho tiempo entre los mensajes. En el modelo de inserción con proxy, Service Bus envía un evento a través de Event Grid cuando hay mensajes nuevos. El receptor se suscribe al evento. Cuando se desencadena el evento, el receptor extrae el siguiente lote de mensajes de Service Bus.
Cuando se crea una aplicación lógica para consumir mensajes de Service Bus, se recomienda usar el modelo de inserción con proxy con la integración de Event Grid. A menudo resulta más económico, ya que la aplicación lógica no necesita sondear Service Bus. Para más información, consulte Introducción a la integración de Azure Service Bus en Event Grid. En la actualidad, se requiere el nivel Premium de Service Bus para las notificaciones de Event Grid.
Use PeekLock para acceder a un grupo de mensajes. Cuando usa PeekLock, la aplicación lógica puede realizar los pasos necesarios para validar cada mensaje antes de completar o abandonar el mensaje. Este enfoque protege contra la pérdida accidental de datos.
Event Grid
Cuando se activa un desencadenador de Event Grid, significa que se ha producido al menos un evento. Por ejemplo, cuando una aplicación lógica recibe un desencadenador de Event Grid en un mensaje de Service Bus, debe asumir que varios mensajes puedan estar disponibles para procesarlos.
Consideraciones
Estas consideraciones implementan los pilares del marco de buena arquitectura de Azure, que es un conjunto de principios guía que se pueden usar para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.
Confiabilidad
La confiabilidad garantiza que la aplicación pueda cumplir los compromisos contraídos con los clientes. Para más información, consulte Resumen del pilar de fiabilidad.
- Azure AD: Azure AD es una plataforma SaaS distribuida globalmente y de alta disponibilidad. Consulte el Acuerdo de Nivel de Servicio para obtener los detalles de la disponibilidad garantizada.
- API Management: API Management se puede implementar en varias configuraciones de alta disponibilidad, según los requisitos empresariales y la tolerancia a costos. Consulte la sección Garantía de la disponibilidad y confiabilidad de API Management para obtener una revisión completa de las opciones. Consulte también el Acuerdo de Nivel de Servicio para obtener los detalles de la disponibilidad garantizada.
- Logic Apps: el almacenamiento con redundancia geográfica está disponible para Logic Apps en el nivel del plan de consumo. Para más información sobre cómo diseñar una solución de continuidad empresarial y recuperación ante desastres, consulte las instrucciones. Consulte también el Acuerdo de Nivel de Servicio para obtener los detalles de la disponibilidad garantizada.
- Event Grid: las definiciones de recursos de Event Grid para temas, temas del sistema, dominios y suscripciones de eventos y datos de eventos se replican automáticamente en tres zonas de disponibilidad (si están disponibles) en la región. Cuando se produce un error en una de las zonas de disponibilidad, los recursos de Event Grid conmutan por error automáticamente a otra zona de disponibilidad sin intervención humana. Consulte la recuperación ante desastres geográfica entre regiones para obtener instrucciones para diseñar una solución de recuperación ante desastres para conmutar por error a otra región. Consulte también el Acuerdo de Nivel de Servicio para obtener los detalles de la disponibilidad garantizada.
- Service Bus: Service Bus Premium admite la recuperación ante desastres geográfica y Availability Zones. La replicación está disponible en Service Bus Estándar. Consulte también el Acuerdo de Nivel de Servicio para obtener los detalles de la disponibilidad garantizada.
Seguridad
La seguridad proporciona garantías contra ataques deliberados y el abuso de datos y sistemas valiosos. Para más información, consulte Introducción al pilar de seguridad.
Para proteger Service Bus, use la autenticación de Azure Active Directory (Azure AD) emparejada con identidades administradas. La integración de Azure AD para recursos de Service Bus proporciona control de acceso basado en rol de Azure (RBAC) para el control específico del acceso de los clientes a los recursos. Puede usar Azure RBAC para conceder permisos a una entidad de seguridad, que puede ser un usuario, un grupo o una entidad de servicio de aplicación (una identidad administrada en este caso).
Si Azure AD no está disponible, puede usar la firma de acceso compartido (SAS). Puede usar la autenticación de SAS para conceder acceso a un usuario a los recursos de Service Bus con derechos específicos.
Si necesita exponer un tema o una cola de Service Bus como punto de conexión de HTTP para, por ejemplo, publicar nuevos mensajes, use API Management para proteger la cola por delante del punto de conexión. El punto de conexión se puede proteger con certificados o con autenticación de OAuth, según corresponda. La manera más sencilla de proteger un punto de conexión es mediante una aplicación lógica con un desencadenador HTTP de solicitud o respuesta como intermediario.
El servicio Event Grid protege la entrega de eventos con un código de validación. Si usa Logic Apps para consumir el evento, la validación se realiza automáticamente. Para más información, vea Event Grid security and authentication (Seguridad y autenticación de Event Grid).
Seguridad de las redes
La seguridad de red debe tenerse en cuenta a lo largo del diseño.
- Service Bus Premium se puede enlazar a un punto de conexión de servicio de la subred de una red virtual (VNet), protegiendo el espacio de nombres para que acepte solo el tráfico de las redes virtuales autorizadas. Además, use puntos de conexión privados para bloquear el tráfico de red virtual hacia el tráfico privado a través de Private Link.
- Logic Apps Las versiones Estándar y Premium de Azure Logic Apps se pueden configurar para que acepten el tráfico entrante a través de puntos de conexión privados y para que envíen el tráfico saliente mediante la integración con una red virtual.
- API Management proporciona varias opciones para proteger el acceso a la instancia de API Management y a las API mediante una red virtual de Azure. Consulte el documento Uso de una red virtual con Azure API Management, ya que en él se realiza un análisis exhaustivo de las opciones. También se admiten los puntos de conexión privados.
Optimización de costos
La optimización de costos trata de buscar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para más información, vea Información general del pilar de optimización de costos.
En general, use la calculadora de precios de Azure para calcular los costos. Estas son algunas otras consideraciones.
API Management
Se le cobra por todas las instancias de API Management cuando están en ejecución. Si ha realizado un escalado vertical y no necesita ese nivel de rendimiento todo el tiempo, reduzca verticalmente de forma manual o configure la escalabilidad automática.
En el caso de las cargas de trabajo de uso ligero, considere la posibilidad de usar el nivel de consumo ya que es una opción sin servidor y de bajo costo. El nivel de consumo se factura por llamada API, mientras que los demás niveles se facturan por hora.
Logic Apps
Logic Apps usa un modelo sin servidor. La facturación se calcula en función de la acción y la ejecución del conector. Para obtener más información, consulte Precios de Logic Apps.
Colas, temas y suscripciones de Service Bus
Las colas y suscripciones de Service Bus admiten los modelos de inserción con proxy y extracción para la entrega de mensajes. En el modelo de inserción, cada solicitud de sondeo se mide como una acción. Incluso con un sondeo largo de 30 segundos (valor predeterminado), el costo puede ser alto. A menos que necesite la entrega en tiempo real de mensajes, considere la posibilidad de usar el modelo de inserción con proxy.
Las colas de Service Bus se incluyen en todos los niveles (básico, estándar y premium). Aunque los temas y suscripciones de Service Bus están disponibles en los niveles Estándar y Premium. Para obtener más información, vea Precios de Azure Service Bus.
Event Grid
Event Grid usa un modelo sin servidor. La facturación se calcula en función del número de operaciones (ejecuciones de eventos). Las operaciones incluyen la entrada de eventos a dominios o temas, coincidencias avanzadas, intentos de entrega y llamadas de administración. El uso de hasta 100 000 operaciones es gratuito.
Para más información, consulte Precios de Event Grid.
Para más información, consulte la sección acerca de los costos del artículo sobre elmarco de buena arquitectura de Microsoft Azure.
Excelencia operativa
La arquitectura de referencia básica de integración empresarial proporciona instrucciones sobre los patrones de DevOps que están en línea con el pilar de excelencia operativa del Marco de buena arquitectura.
Automatizar las operaciones de recuperación tanto como sea posible es un componente integral de la excelencia operativa. Pensando en todo momento en la automatización, puede combinar la supervisión de registros de Azure con Azure Automation para automatizar la conmutación por error de los recursos de Service Bus. Consulte el diagrama de la documentación del flujo de conmutación por error para obtener un ejemplo de lógica de automatización para iniciar una conmutación por error.
Eficiencia del rendimiento
La eficiencia del rendimiento es la capacidad de la carga de trabajo para escalar con el fin de satisfacer de manera eficiente las demandas que los usuarios hayan ejercido sobre ella. Para obtener más información, vea Resumen del pilar de eficiencia del rendimiento.
El nivel Premium de Service Bus puede escalar horizontalmente el número de unidades de mensajería para alcanzar una mayor escalabilidad. Para conocer las ventajas del nivel Prémium, consulte el documento Niveles de mensajería Premium y Estándar de Service Bus. Y si lo que desea es aprender a configurar el escalado automático de las unidades de mensajería, consulte el documento sobre la característica de escalado automático.
Puede encontrar más recomendaciones para Service Bus en Procedimientos recomendados para mejorar el rendimiento mediante la mensajería de Service Bus.
Pasos siguientes
Para más información, consulte la documentación de Service Bus:
- Introducción a la integración de Azure Service Bus en Event Grid
- Niveles de mensajería Premium y Estándar de Service Bus
- Característica de escalabilidad automática de Service Bus
- Procedimientos recomendados para mejorar el rendimiento mediante la mensajería de Service Bus