Integración empresarial mediante el agente de mensajes y eventos

Event Grid
Service Bus

Esta arquitectura de referencia integra sistemas de back-end empresariales y usa el agente de mensajes y los eventos para desacoplar los servicios, con el fin de aumentar la escalabilidad y la confiabilidad. Los sistemas de back-end pueden incluir sistemas de software como servicio (SaaS), servicios de Azure y servicios web existentes de su empresa.

Arquitectura de referencia para la integración empresarial con colas y eventos

Descargue un archivo de Visio de esta arquitectura.

Architecture

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. Dicha arquitectura usa Logic Apps para organizar los flujos de trabajo 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:

La comunicación asincrónica mediante un agente de mensajes proporciona una serie de 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. También se aplican las siguientes recomendaciones:

Azure Service Bus

Service Bus tiene dos modos de entrega, extracción o inserción. 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, 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 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 sobre escalabilidad

El nivel Premium de Service Bus puede escalar horizontalmente el número de unidades de mensajería para alcanzar una mayor escalabilidad. Las configuraciones de nivel Premium pueden tener una, dos o cuatro unidades de mensajería. Para más información sobre el escalado de Service Bus, consulte Procedimientos recomendados para mejorar el rendimiento mediante la mensajería de Service Bus.

Consideraciones sobre disponibilidad

Revise el SLA de cada servicio:

Considere la posibilidad de implementar la recuperación ante desastres geográfica en el nivel Premium de Service Bus para habilitar la conmutación por error si se produce una interrupción grave. Para más información, consulte Recuperación ante desastres geográfica de Azure Service Bus.

Consideraciones sobre DevOps

Vea las consideraciones de DevOps en Arquitectura de referencia de Integración empresarial básica.

Consideraciones sobre la seguridad

Proteja Service Bus con una 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. Para más información, consulte Autenticación y autorización de Service Bus.

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).

Consideraciones sobre el costo

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 escalado verticalmente y no necesita ese nivel de rendimiento todo el tiempo, reduzca verticalmente de forma manual o configure la escalabilidad automática.

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 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 envío.

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.

Pasos siguientes