Editar

Sistema de mensajería de publicación y suscripción dinámico de Transit Hub

Azure Cache for Redis
Azure Cosmos DB
Azure Event Hubs
Azure Functions
Azure Service Bus

Ideas de solución

Este artículo es una idea de solución. Si te gustaría que ampliemos este artículo con más información, como posibles casos de uso, servicios alternativos, consideraciones de implementación o una guía de precios, comunícalo a través de los Comentarios de GitHub.

En este artículo se describe un modelo elástico y flexible de publicación y suscripción para que los productores y consumidores de datos creen y consuman contenido o datos seleccionados mantenidos.

Architecture

Diagrama del sistema de mensajería de publicación y suscripción de Transit Hub.

Descargue un archivo Visio de esta arquitectura.

Flujo de datos

  1. La aplicación Data Producer publica datos en Azure Event Hubs, que envía los datos a la función de procesamiento de eventos de Azure Functions.

  2. Data Producer también envía el esquema JSON para el almacenamiento a un contenedor de Azure Storage.

  3. La función de procesamiento de eventos recupera el esquema JSON de Azure Cache for Redis para reducir la latencia y lo usa para validar los datos.

    Si el esquema aún no se ha almacenado en la caché, la función de procesamiento de eventos recupera el esquema del contenedor de Azure Storage. La solicitud del esquema también lo almacena en Azure Cache for Redis, con el fin de que se pueda recuperar en el futuro.

    Nota

    En Event Hubs, Azure Schema Registry puede ser una alternativa viable tanto al almacenamiento en disco como al almacenamiento en caché de esquemas JSON. Para más información, consulte Azure Schema Registry de Azure en Event Hubs (versión preliminar).

  4. Si ya existe un tema y los datos son válidos, la función de procesamiento de eventos combina los datos en el tema de Azure Service Bus Datos válidos y envía el tema a la aplicación Data Consumer.

  5. Si ya existe un tema y los datos no son válidos, la función de procesamiento de eventos combina los datos en el tema de Service Bus Datos no válidos y devuelve el tema al productor de los datos. El productor de datos se suscribe a los temas de Datos no válidos para obtener comentarios sobre los datos no válidos que creó el productor.

  6. Si algún tema aún no existe, la función de procesamiento de eventos publica los datos nuevos en el tema Datos nuevos de Service Bus y envía el tema a la función de administración de temas de Service Bus.

  7. Si los nuevos datos son válidos, la función de procesamiento de eventos también inserta los datos como un nuevo registro de datos de instantáneas en Azure Cosmos DB.

  8. Si los nuevos datos son válidos, la función de administrador de temas de Service Bus crea un tema Datos válidos de Service Bus y envía el tema a Event Hubs.

  9. Si los nuevos datos no son válidos, la función de administrador de temas de Service Bus crea un tema Datos no válidos de Service Bus y lo devuelve a la aplicación Data Producer.

  10. El procesador de archivos planos de datos de instantáneas de Azure Data Factory se ejecuta según una programación para extraer todos los datos de instantáneas de la base de datos Datos de instantáneas de Azure Cosmos DB. El procesador crea un archivo plano y lo publica en un archivo plano de datos de instantáneas en Azure Storage para descargas.

  11. La aplicación Data Consumer recupera una lista de todos los temas Service Bus que el administrador de temas de Service Bus tiene disponible para la suscripción. La aplicación se registra en el administrador de temas de Service Bus para suscribirse a los temas de Service Bus.

Componentes

Detalles del escenario

Transit Hub es un modelo de publicación y suscripción dinámico para que los productores y consumidores de datos creen y consuman contenido o datos seleccionados mantenidos. El modelo es elástico para permitir la escala y el rendimiento. Los productores de datos pueden incorporar y cargar datos rápidamente en un servicio. El servicio valida los datos con un esquema que proporciona el productor de datos. Luego, el servicio hace que los datos validados estén disponibles para que los suscriptores consuman los que les interesen.

La única información que el servicio que valida los datos necesita tener saber sobre la carga es si es válida en el esquema que proporciona el productor. Esta flexibilidad significa que el servicio puede aceptar nuevos tipos de carga sin tener que volver a implementarse. Esta solución también permite a los consumidores de datos obtener datos históricos que se publicaron antes que el consumidor se suscribiera.

Posibles casos de uso

Este modelo es especialmente útil en los siguientes escenarios:

  • Sistemas de mensajería en los que el volumen y estado del usuario son desconocidos o varían de forma impredecible
  • Sistemas de publicación que posiblemente necesiten admitir orígenes de datos nuevos o desconocidos
  • Sistemas de comercio o de emisión de billetes que necesitan actualizar continuamente los datos y almacenarlos en la caché para poder entregarlos de forma rápida

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes