Uso de un agente de mensajes y eventos para integrar sistemas empresariales

Azure Event Grid
Azure Service Bus

Esta arquitectura se basa en la arquitectura básica de integración empresarial , pero incluye cómo integrar sistemas back-end empresariales. Esta arquitectura usa agentes de mensajes y eventos para desacoplar servicios para mayor escalabilidad y confiabilidad. Asegúrese de que está familiarizado con el diseño y los componentes de la arquitectura de integración básica. Estos elementos proporcionan información fundamental sobre los componentes principales de esta arquitectura.

Arquitectura

Los sistemas back-end a los que hace referencia este diseño incluyen sistemas de software como servicio (SaaS), servicios Azure, servicios basados en mensajes y servicios web existentes en su empresa.

Diagrama que muestra una arquitectura de referencia para la integración empresarial que usa colas y eventos.

Descargar un archivo Visio de esta arquitectura.

Detalles del escenario

La arquitectura anterior se basa en la arquitectura básica de integración empresarial. Usa Azure Logic Apps para organizar flujos de trabajo directamente con sistemas back-end y usa Azure 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:

Esta arquitectura usa la comunicación asincrónica a través de un agente de mensajes en lugar de realizar llamadas directas y sincrónicas a los servicios back-end. La comunicación asincrónica proporciona las siguientes ventajas:

  • Utiliza el patrón de nivelación de carga basada en colas para administrar picos en las cargas de trabajo mediante la nivelación de carga.

  • Usa el patrónPublisher-Subscriber para que pueda difundir mensajes a varios consumidores.

  • Realiza un seguimiento del progreso de los flujos de trabajo de ejecución prolongada de forma confiable, incluso cuando implican varios pasos o varias aplicaciones

  • Ayuda a desacoplar aplicaciones

  • Se integra con sistemas basados en mensajes existentes

  • Proporciona la capacidad de poner en cola los mensajes cuando un sistema back-end no está disponible.

Use Azure Event Grid para que varios componentes del sistema puedan reaccionar a los eventos cuando se producen, en lugar de confiar en tareas programadas o sondeos. De forma similar a una cola de mensajes y temas, Event Grid ayuda a desacoplar aplicaciones y servicios. Si una aplicación o servicio publica eventos, se notifica a los suscriptores interesados. Puede agregar nuevos suscriptores sin actualizar el remitente.

Muchos servicios Azure admiten el envío de eventos a Event Grid. Por ejemplo, Azure Logic Apps puede detectar un evento cuando se añaden archivos nuevos a un almacenamiento de blobs. Este patrón crea flujos de trabajo reactivos en los que la carga de un archivo o la colocación de un mensaje en una cola inicia una serie de procesos. Los procesos se pueden ejecutar en paralelo o en una secuencia específica.

Recomendaciones

Tenga en cuenta las siguientes recomendaciones. Para obtener más recomendaciones, consulte Arquitectura básica de integración empresarial.

Bus de Servicio

Service Bus ofrece dos modelos de entrega: el modelo pull y el modelo proxied push.

  • Modelo de extracción: El receptor sondea continuamente para recibir nuevos mensajes. Si necesita administrar varias colas y tiempos de sondeo, el sondeo podría ser ineficaz. Pero este modelo puede simplificar la arquitectura porque quita componentes adicionales y saltos de datos.

  • Modelo de envío a través de proxy: El receptor se suscribe inicialmente a un tipo de evento específico en un tema de Event Grid. Cuando hay un nuevo mensaje disponible, Service Bus genera y envía un evento a través de Event Grid. A continuación, este evento desencadena el receptor para extraer el siguiente lote de mensajes de Service Bus. Este modelo permite a los sistemas recibir mensajes casi en tiempo real, pero sin usar recursos para sondear continuamente los nuevos mensajes. Esta arquitectura usa componentes adicionales que debe implementar, administrar y proteger.

Al crear un flujo de trabajo de Logic Apps Estándar que consume mensajes de Service Bus, utilice los desencadenadores del conector integrado de Service Bus. Los desencadenadores del conector integrado abstraen la mayor parte de la configuración del modelo pull sin añadir costes adicionales. Esta capacidad proporciona el equilibrio adecuado entre coste, administración de la superficie de exposición y seguridad, ya que el conector se ejecuta en bucle de forma continua dentro del motor de tiempo de ejecución de Logic Apps. Para obtener más información, consulte desencadenadores integrados del conector de Service Bus.

Use el modo 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 evita la pérdida accidental de mensajes.

Cuadrícula de Eventos

Cuando se activa un desencadenador de Event Grid, significa que se produjo al menos un evento. Por ejemplo, cuando una aplicación lógica obtiene un desencadenador de Event Grid para un mensaje de Service Bus, puede haber varios mensajes disponibles para procesar.

Consideraciones

Estas consideraciones implementan los pilares del marco de Azure Well-Architected, que es un conjunto de principios rectores que puede usar para mejorar la calidad de una carga de trabajo. Para obtener más información, consulte Well-Architected Framework.

Confiabilidad

La confiabilidad ayuda a garantizar que la aplicación pueda cumplir los compromisos que realice para sus clientes. Para obtener más información, consulte Lista de comprobación de revisión de diseño para confiabilidad.

Para obtener información sobre los detalles de disponibilidad garantizada de cada servicio, consulte SLA para servicios en línea.

Seguridad

La seguridad proporciona protecciones contra ataques deliberados y el uso indebido de sus valiosos datos y sistemas. Para obtener más información, vea Lista de comprobación para la revisión de diseño de seguridad.

Para ayudar a proteger Service Bus, combina la autenticación de Microsoft Entra con identidades administradas. La integración de Entra ID para los recursos de Service Bus proporciona control de acceso basado en roles de Azure (Azure RBAC) para un control granular sobre el acceso de un cliente a los recursos. Puede usar Azure RBAC para conceder permisos a una entidad de seguridad, como un usuario, un grupo o una entidad de servicio de aplicación. La entidad de servicio de la aplicación en este escenario es una identidad administrada.

Si no puede usar Entra ID, use la autenticación de firma de acceso compartido (SAS) para conceder a los usuarios acceso y permisos específicos a los recursos de Service Bus.

Si necesita exponer una cola o un tema de Service Bus como un punto de conexión HTTP, por ejemplo, para publicar nuevos mensajes, utilice API Management para ayudar a proteger la cola colocando este servicio como puerta de enlace del punto de conexión. A continuación, puede usar certificados o autenticación de OAuth para ayudar a proteger el punto de conexión. La manera más fácil de ayudar a proteger un punto de conexión es usar una aplicación lógica que tenga un desencadenador de solicitud o respuesta HTTP como intermediario.

El servicio Event Grid ayuda a proteger la entrega de eventos a través de un código de validación. Si usa Logic Apps para consumir el evento, la validación es automática. Para más información, vea Event Grid security and authentication (Seguridad y autenticación de Event Grid).

Seguridad de las redes

Considere la posibilidad de tener en cuenta la seguridad de red en todo el diseño.

Optimización de costos

La optimización de costos se centra en formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para obtener más información, consulte Lista de comprobación de revisión de diseño para la optimización de costes.

Use la calculadora de precios Azure para calcular los costos. Estas son algunas otras consideraciones.

API Management

Se le cobra por todas las instancias de API Management mientras están en funcionamiento. Si amplías la escala y luego ya no necesitas ese nivel de rendimiento, reduce la escala manualmente o configura el escalado automático.

Para cargas de trabajo de uso ligero, considere el nivel Consumo, que es una opción sin servidor de bajo costo. El nivel Consumo se factura por llamada API. Otros niveles se facturan por hora.

Logic Apps Standard

Logic Apps Standard usa un modelo de proceso elástico. La facturación se calcula en función del número de CPU y memoria usadas por hora. 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 tanto el modelo push con proxy como el modelo pull para entregar mensajes. En el modelo de inserción, cada solicitud de sondeo se mide como una acción. Aunque configures el sondeo prolongado con el valor predeterminado de 30 segundos, el coste puede ser elevado. A menos que necesites la entrega de mensajes en tiempo real, plantéate utilizar el modelo de envío por proxy.

Las colas de Service Bus se incluyen en todos los niveles: Básico, Estándar y Premium. Los temas y las suscripciones de Service Bus están disponibles en los niveles Estándar y Premium. Para obtener más información, consulte precios Service Bus.

Cuadrícula de Eventos

Event Grid usa un modelo sin servidor. La facturación se calcula en función del número de operaciones. Las operaciones incluyen eventos que se envían 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.

Excelencia operativa

La excelencia operativa abarca los procesos de las operaciones que implementan una aplicación y la mantienen en ejecución en producción. Para obtener más información, consulte la Lista de comprobación de revisión de diseño para la excelencia operativa.

La arquitectura de referencia de integración empresarial básica proporciona instrucciones sobre los patrones de DevOps, que se alinean con el pilar de excelencia operativa del marco de Well-Architected.

Automatice las operaciones de recuperación tanto como sea posible para ayudar a mejorar la excelencia operativa. Con la automatización en mente, puedes combinar la supervisión de registros de Azure con Azure Automation para automatizar la conmutación por error de tus recursos de Service Bus. Para obtener un ejemplo de lógica de automatización para iniciar una conmutación por error, consulte Flujo de conmutación por error.

Eficiencia del rendimiento

La eficiencia del rendimiento hace referencia a la capacidad de escalado de la carga de trabajo para satisfacer las demandas de los usuarios de forma eficaz. Para obtener más información, consulte Lista de comprobación de revisión de diseño para la eficiencia del rendimiento.

Para lograr una mayor escalabilidad, el nivel Service Bus Premium puede aumentar el número de unidades de mensajería. Para obtener más información, consulte los niveles de mensajería Premium y Standard de Service Bus y la función de escalamiento automático.

Para obtener más recomendaciones de Service Bus, consulte Mejores prácticas para mejorar el rendimiento mediante mensajería de Service Bus.

Pasos siguientes