Conceptos del espacio de nombres de Azure Event Grid

  • Artículo

En este artículo se presentan los conceptos y funcionalidades principales asociados a los temas de espacio de nombres.

Eventos

Un evento es la cantidad mínima de información que describe completamente algo que se ha producido en un sistema. A menudo hacemos referencia a un evento como un evento discreto porque representa un hecho distintivo e independiente sobre un sistema que proporciona una conclusión que puede ser procesable. Todos los eventos tienen información común, como: source del evento, time en que el evento ha tenido lugar y un identificador único. Cada evento también tiene un type, que normalmente es un identificador único que describe el tipo de anuncio para el que se usa el evento.

Por ejemplo, un evento sobre un nuevo archivo que se crea en Azure Storage contiene detalles sobre el archivo, como el valor lastTimeModified. O bien, un evento de Event Hubs tiene la dirección URL del archivo de captura. Un evento sobre un nuevo pedido en el microservicio Orders puede tener un atributo orderId y un atributo URL en la representación de estado del pedido. Algunos ejemplos más de tipos de eventos son: com.yourcompany.Orders.OrderCreated, org.yourorg.GeneralLedger.AccountChanged, io.solutionname.Auth.MaximumNumberOfUserLoginAttemptsReached.

Este es un evento de muestra:

{
    "specversion" : "1.0",
    "type" : "com.yourcompany.order.created",
    "source" : "/orders/account/123",
    "subject" : "O-28964",
    "id" : "A234-1234-1234",
    "time" : "2018-04-05T17:31:00Z",
    "comexampleextension1" : "value",
    "comexampleothervalue" : 5,
    "datacontenttype" : "application/json",
    "data" : {
       "orderId" : "O-28964",
       "URL" : "https://com.yourcompany/orders/O-28964"
    }
}

Otro tipo de evento

La comunidad de usuarios también se refiere como "eventos" a los mensajes que llevan un punto de datos, como una sola lectura de dispositivos o un clic en una página de aplicación web. Ese tipo de evento normalmente se analiza observando un período de tiempo para derivar información y realizar una acción. En la documentación de Event Grid, nos referimos a ese tipo de evento como un punto de datos, datos de streaming o simplemente telemetría. Entre otros tipos de mensajes, este tipo de eventos se usa con la característica de agente Transporte de telemetría de cola de mensajes (MQTT) de Event Grid.

CloudEvents

Los temas del espacio de nombres de Event Grid aceptan eventos que cumplen con la especificación de estándar abierto de Cloud Native Computing Foundation (CNCF) CloudEvents 1.0 mediante la especificación enlace de protocolo HTTP con formato JSON. CloudEvent es un tipo de mensaje que contiene tanto lo que se comunica, a lo que se denomina datos de eventos, como sus metadatos. Los datos de eventos en arquitecturas controladas por eventos normalmente llevan la información que anuncia un cambio de estado del sistema. Los metadatos de CloudEvents se componen de un conjunto de atributos que proporcionan información contextual sobre el mensaje como dónde se originó (el sistema de origen), su tipo, etc. Todos los mensajes válidos que se adhieren a las especificaciones de CloudEvents deben incluir los siguientes atributos de contexto necesarios:

La especificación CloudEvents también define atributos de contexto de extensión y opcionales que puede incluir al usar Event Grid.

Al usar Event Grid, CloudEvents es el formato de evento preferido debido a sus casos de uso bien documentados (modos para transferir eventos, formatos de eventos, etc.), extensibilidad y mejor interoperabilidad. CloudEvents mejora la interoperabilidad al proporcionar un formato de eventos común para la publicación y el consumo de eventos. Permite usar herramientas uniformes y formas estándar de enrutamiento y administración de eventos.

Modos de contenido de CloudEvents

La especificación CloudEvents define tres modos de contenido: binarios, estructurados y por lotes.

Importante

Con todos los modos de contenido se puede intercambiar texto (JSON, text/*, etc.) o datos de eventos con codificación binaria. El modo de contenido binario no se usa exclusivamente para enviar datos binarios.

Los modos de contenido no tienen que ver la codificación que se usa, binario o texto, sino con cómo se describen e intercambian los datos del evento y sus metadatos. El modo de contenido estructurado usa una sola estructura, por ejemplo, un objeto JSON, donde los atributos de contexto y los datos de eventos se unen en la carga HTTP. El modo de contenido binario separa los atributos de contexto, que se asignan a encabezados HTTP, y los datos de eventos, que son la carga HTTP codificada según el tipo de medio establecido en Content-Type.

Compatibilidad con CloudEvents

En esta tabla se muestra la compatibilidad actual con la especificación CloudEvents:

Modo de contenido de CloudEvents ¿Compatible?
JSON estructurado Sí
JSON estructurado por lotes Sí, para publicar eventos
Binario Sí, para publicar eventos

El tamaño máximo permitido para un evento es de 1 MB. Los eventos de más de 64 KB se cobran en incrementos de 64 KB.

Modo de contenido estructurado

Un mensaje en el modo de contenido estructurado de CloudEvents tiene los atributos de contexto y los datos del evento juntos en una carga HTTP.

Importante

Actualmente, Event Grid admite el formato JSON de CloudEvents con HTTP.

Este es un ejemplo de CloudEvents en modo estructurado mediante el formato JSON. Ambos metadatos (todos los atributos que no son "datos") y los datos de mensaje o evento (el objeto de "datos") se describen mediante JSON. En nuestro ejemplo se incluyen todos los atributos de contexto necesarios junto con algunos atributos opcionales (subject, time y datacontenttype) y atributos de extensión (comexampleextension1, comexampleothervalue).

{
    "specversion" : "1.0",
    "type" : "com.yourcompany.order.created",
    "source" : "/orders/account/123",
    "subject" : "O-28964",
    "id" : "A234-1234-1234",
    "time" : "2018-04-05T17:31:00Z",
    "comexampleextension1" : "value",
    "comexampleothervalue" : 5,
    "datacontenttype" : "application/json",
    "data" : {
       "orderId" : "O-28964",
       "URL" : "https://com.yourcompany/orders/O-28964"
    }
}

Puede usar el formato JSON con contenido estructurado para enviar datos de eventos que no son un valor JSON. Para ello, siga los pasos siguientes:

  1. Incluya un atributo datacontenttype con el tipo de medio en el que se codifican los datos.
  2. Si el tipo de medio se codifica en un formato de texto como text/plain, text/csv o application/xml, debe usar un atributo data con una cadena JSON que contenga lo que se comunica como valor.
  3. Si el tipo de medio representa una codificación binaria, debe usar un atributo data_base64 cuyo valor es una cadena JSON que contiene el valor binario codificado en BASE64.

Por ejemplo, este CloudEvent incluye datos de eventos codificados en application/protobuf para intercambiar mensajes Protobuf.

{
    "specversion" : "1.0",
    "type" : "com.yourcompany.order.created",
    "source" : "/orders/account/123",
    "id" : "A234-1234-1234",
    "time" : "2018-04-05T17:31:00Z",
    "datacontenttype" : "application/protobuf",
    "data_base64" : "VGhpcyBpcyBub3QgZW5jb2RlZCBpbiBwcm90b2J1ZmYgYnV0IGZvciBpbGx1c3RyYXRpb24gcHVycG9zZXMsIGltYWdpbmUgdGhhdCBpdCBpcyA6KQ=="
}

Para obtener más información sobre el uso de los atributos data o data_base64, vea Control de datos.

Para obtener más información sobre este modo de contenido, consulte las especificaciones del modo de contenido estructurado HTTP de CloudEvents.

Modo de contenido por lotes

Event Grid admite actualmente el modo de contenido por lotes JSON al publicar CloudEvents en Event Grid. Este modo de contenido usa una matriz JSON rellenada con CloudEvents en modo de contenido estructurado. Por ejemplo, la aplicación puede publicar dos eventos mediante una matriz como la siguiente. Del mismo modo, si usa el SDK del plano de datos de Event Grid, esta carga también es lo que se envía:

[
    {
        "specversion": "1.0",
        "id": "E921-1234-1235",
        "source": "/mycontext",
        "type": "com.example.someeventtype",
        "time": "2018-04-05T17:31:00Z",
        "data": "some data"
    },
    {
        "specversion": "1.0",
        "id": "F555-1234-1235",
        "source": "/mycontext",
        "type": "com.example.someeventtype",
        "time": "2018-04-05T17:31:00Z",
        "data": {
            "somekey" : "value",
            "someOtherKey" : 9
        }
    }
]

Para obtener más información, consulte las especificaciones del modo de contenido por lotes de CloudEvents.

Procesamiento por lotes

La aplicación debe procesar por lotes varios eventos juntos en una matriz para lograr una mayor eficacia y un mayor rendimiento con una única solicitud de publicación. Los lotes pueden tener hasta 1 MB y el tamaño máximo de un evento es también de 1 MB.

Modo de contenido binario

CloudEvent en modo de contenido binario tiene sus atributos de contexto descritos como encabezados HTTP. Los nombres de los encabezados HTTP son el nombre del atributo de contexto prefijo con ce-. El encabezado Content-Type refleja el tipo de medio en el que se codifican los datos del evento.

Importante

Cuando se usa el modo de contenido binario, el encabezado HTTP ce-datacontenttype NO DEBE estar presente también.

Importante

Si planea incluir sus propios atributos (es decir, atributos de extensión) cuando use el modo de contenido binario, asegúrese de que sus nombres contienen letras minúsculas ( de la "a" a la "z") o dígitos (del "0" al "9") del carácter ASCII y que no superan los 20 caracteres de longitud. Es decir, la convención de nomenclatura de para nombrar los atributos de contexto de CloudEvents es más restrictiva que la de los nombres de encabezado HTTP válidos. No todos los nombres de encabezado HTTP válidos son un nombre de atributo de extensión válido.

La carga HTTP son los datos del evento codificados según el tipo de medio de Content-Type.

Una solicitud HTTP que se usa para publicar un CloudEvent en modo binario de contenido puede tener un aspecto similar al de este ejemplo:

POST / HTTP/1.1
HOST mynamespace.eastus-1.eventgrid.azure.net/topics/mytopic
ce-specversion: 1.0
ce-type: com.example.someevent
ce-source: /mycontext
ce-id: A234-1234-1234
ce-time: 2018-04-05T17:31:00Z
ce-comexampleextension1: value
ce-comexampleothervalue: 5
content-type: application/protobuf

Binary data according to protobuf encoding format. No context attributes are included.

Cuándo usar el modo de contenido binario o estructurado de CloudEvents

Puede usar el modo de contenido estructurado si desea un enfoque sencillo para reenviar CloudEvents entre saltos y protocolos. Dado que CloudEvent en modo de contenido estructurado contiene el mensaje, junto con sus metadatos, es fácil que los clientes lo consuman en su totalidad y lo reenvíen a otros sistemas.

Puede usar el modo de contenido binario si sabe que las aplicaciones de bajada solo requieren el mensaje sin información adicional (es decir, los atributos de contexto). Aunque con el modo de contenido estructurado todavía puede obtener los datos del evento (mensaje) de CloudEvent, es más fácil si una aplicación de consumidor solo la tiene en la carga HTTP. Por ejemplo, otras aplicaciones pueden usar otros protocolos y podrían estar interesadas solo en el mensaje principal, no en sus metadatos. De hecho, los metadatos podrían ser relevantes solo para el primer salto inmediato. En este caso, tener los datos que se desean intercambiar aparte de sus metadatos facilita tanto el manejo como el reenvío.

Publicadores

Un publicador es la aplicación que envía eventos a Event Grid. Puede ser la misma aplicación donde se originaron los eventos, el origen del evento. Puede publicar eventos desde su propia aplicación cuando use temas de espacio de nombres.

Orígenes de eventos

Un origen de evento es donde se produce el evento. Cada origen de eventos admite uno o varios tipos de eventos. Por ejemplo, la aplicación es el origen de evento de los eventos personalizados que define el sistema. Al usar temas de espacio de nombres, los orígenes de eventos admitidos son sus propias aplicaciones.

Espacios de nombres

Un espacio de nombres de Event Grid es un contenedor de administración para los siguientes recursos:

Resource Protocolo admitido
Temas de espacio de nombres HTTP
Espacios de temas MQTT
Clientes MQTT
Grupos de clientes MQTT
Certificados de CA MQTT
Enlaces de permisos MQTT

Con un espacio de nombres de Azure Event Grid, puede agrupar recursos relacionados y administrarlos como una sola unidad en la suscripción de Azure. Proporciona un nombre de dominio completo (FQDN) único.

Un espacio de nombres expone dos puntos de conexión:

  • Un punto de conexión HTTP para admitir requisitos generales de mensajería mediante temas de espacio de nombres.
  • Un punto de conexión MQTT para la mensajería o soluciones de IoT que usan MQTT.

Un espacio de nombres también proporciona puntos de conexión de red integrados en DNS. También proporciona una variedad de características de control de acceso y administración de integración de red, como el filtrado de entrada de IP pública y vínculos privados. También es el contenedor de identidades administradas que se usan para los recursos contenidos en el espacio de nombres.

Estos son algunos aspectos más de los espacios de nombres:

  • El espacio de nombres es un recurso de seguimiento con propiedades tags y location y, una vez creado, se puede encontrar en resources.azure.com.
  • El nombre del espacio de nombres puede tener entre 3 y 50 caracteres. Puede incluir caracteres alfanuméricos y guiones (-) y no debe tener espacios.
  • El nombre debe ser único en cada región.
  • Regiones admitidas actuales: Centro de EE. UU., Este de Asia, Este de EE. UU., Este de EE. UU. 2, Norte de Europa, Centro-sur de EE. UU., Sudeste de Asia, Norte de Emiratos Árabes Unidos, Oeste de Europa, Oeste de EE. UU. 2, Oeste de EE. UU. 3.

Unidades de procesamiento

Las unidades de procesamiento (UP) definen la capacidad de velocidad de eventos de entrada y salida en espacios de nombres. Para más información, consulte Cuotas y límites de Azure Event Grid.

Temas

Un tema contiene eventos que se han publicado en Event Grid. Normalmente, se usa un recurso de tema para una colección de eventos relacionados. A menudo se hace referencia a temas dentro de un espacio de nombres como temas de espacio de nombres.

Temas de espacio de nombres

Los temas de espacio de nombres son temas que se crean dentro de un espacio de nombres de Event Grid. La aplicación publica eventos en un punto de conexión de espacio de nombres HTTP que especifica un tema de espacio de nombres donde los eventos publicados están contenidos lógicamente. Cuando diseñe la aplicación, tiene que decidir cuántos temas se van a crear. Para soluciones relativamente grandes, cree un tema de espacio de nombres para cada categoría de eventos relacionados. Por ejemplo, considere una aplicación que administra cuentas de usuario y otra aplicación sobre pedidos de clientes. Es poco probable que todos los suscriptores de eventos quieran eventos de ambas aplicaciones. Para separar los problemas, cree dos temas de espacio de nombres: uno para cada aplicación. Permita que los consumidores de eventos se suscriban al tema según sus requisitos. Para soluciones pequeñas, puede que prefiera enviar todos los eventos a un solo tema.

Los temas de espacio de nombres admiten la entrega de extracción y la entrega de inserción. Consulte cuándo usar la entrega de extracción o inserción para ayudarle a decidir si la entrega de extracción es el enfoque adecuado según sus requisitos.

Suscripciones a eventos

Una suscripción a eventos es un recurso de configuración asociado a un único tema. Entre otras cosas, la suscripción a eventos se usa para establecer los criterios de selección de eventos que definen la colección de eventos disponible para un suscriptor del conjunto total de eventos disponibles en un tema. Se pueden filtrar eventos en función de los requisitos del suscriptor. Por ejemplo, se pueden filtrar eventos por su tipo de evento. También se pueden definir criterios de filtro en las propiedades de datos de eventos, siempre que se use un objeto JSON como valor de la propiedad data. Para obtener más información sobre las propiedades de los recursos, busque operaciones del plano de control en la API REST de Event Grid.

Diagrama que muestra un tema y las suscripciones a eventos asociadas.

Para obtener un ejemplo de creación de suscripciones para temas de espacio de nombres, consulte Publicación y consumo de mensajes mediante temas de espacio de nombres mediante la CLI.

Nota:

La característica de suscripciones a eventos de un tema de espacio de nombres presenta un modelo de recursos simplificado en comparación con el que se usa para los temas personalizados, de dominio, de asociado y del sistema (Event Grid Básico). Para más información, consulte Creación, visualización y administración de suscripciones a eventos.

Entrega de extracción

Con la entrega de extracción, la aplicación se conecta a Event Grid para leer mensajes mediante la semántica similar a la cola. A medida que las aplicaciones se conectan a Event Grid para consumir eventos, están en control de la tasa de consumo de eventos y su tiempo. Las aplicaciones de consumidor también pueden usar puntos de conexión privados al conectarse a Event Grid para leer eventos mediante el espacio IP privado.

La entrega de extracción admite las siguientes operaciones para leer mensajes y controlar el estado del mensaje: recepción, confirmación, liberación, rechazo y bloqueo de renovación. Para obtener más información, consulte Introducción a la entrega de extracción.

Forma de datos al recibir eventos mediante la entrega de extracción

Al entregar eventos mediante la entrega de extracción, Event Grid incluye una matriz de objetos que, a su vez, incluyen los objetos event y brokerProperties. El valor de la propiedad de evento es el CloudEvent entregado en modo de contenido estructurado. El objeto brokerProperties contiene el token de bloqueo asociado al CloudEvent entregado. El siguiente objeto json es una respuesta de ejemplo de una operación de recepción que devuelve dos eventos:

{
    "value": [
        {
            "brokerProperties": {
                "lockToken": "CiYKJDUwNjE4QTFFLUNDODQtNDZBQy1BN0Y4LUE5QkE3NjEwNzQxMxISChDXYS23Z+5Hq754VqQjxywE",
                "deliveryCount": 2
            },
            "event": {
                "specversion": "1.0",
                "id": "A234-1234-1235",
                "source": "/mycontext",
                "time": "2018-04-05T17:31:00Z",
                "type": "com.example.someeventtype",
                "data": "some data"
            }
        },
        {
            "brokerProperties": {
                "lockToken": "CiYKJDUwNjE4QTFFLUNDODQtNDZBQy1BN0Y4LUE5QkE3NjEwNzQxMxISChDLeaL+nRJLNq3/5NXd/T0b",
                "deliveryCount": 1
            },
            "event": {
                "specversion": "1.0",
                "id": "B688-1234-1235",
                "source": "/mycontext",
                "type": "com.example.someeventtype",
                "time": "2018-04-05T17:31:00Z",
                "data": {
                    "somekey" : "value",
                    "someOtherKey" : 9
                }
            }
        }
    ]
}

Entrega de inserción

Con la entrega de inserción, Event Grid envía eventos a un destino configurado en una suscripción de eventos de (modo de entrega en)inserción. Proporciona una lógica de reintento sólida en caso de que el destino no pueda recibir eventos.

Importante

La entrega de inserción de espacios de nombres de Event Grid admite actualmente Azure Event Hubs como destino. En el futuro, los espacios de nombres de Event Grid admitirán más destinos, incluidos todos los que admite la versión básica de Event Grid.

Entrega de eventos de Event Hubs

Event Grid usa el SDK de Event Hubs para enviar eventos a Event Hubs mediante AMQP. Los eventos se envían como una matriz de bytes con cada elemento de la matriz que contiene un CloudEvent.

Entrega de inserción y extracción

Con HTTP, Event Grid admite la entrega de eventos de inserción y extracción. Con la entrega de inserción, se define un destino en una suscripción de eventos, un webhook o un servicio de Azure a los que Event Grid envía eventos. Con la entrega de extracción, las aplicaciones del suscriptor se conectan a Event Grid para consumir eventos. La entrega de extracción es compatible con los temas de un espacio de nombres de Event Grid.

Importante

Event Hubs es compatible como destino para las suscripciones a temas de espacio de nombres. En las próximas versiones, los espacios de nombres de Event Grid admitirán todos los destinos disponibles actualmente en Event Grid Basic junto con destinos adicionales.

Diagrama de alto nivel que muestra la entrega de inserción y la entrega de extracción con el tipo de recursos implicados.

Casos en los que se debe usar la entrega de inserción frente a la entrega de extracción

A continuación, se muestran directrices generales que le ayudarán a decidir cuándo usar la entrega de extracción o inserción.

Entrega de extracción

  • Necesita un control absoluto sobre cuándo recibir eventos. Por ejemplo, es posible que la aplicación no esté en funcionamiento todo el tiempo, no sea lo suficientemente estable, o que no procese los datos en determinados momentos.
  • Necesita un control absoluto sobre el consumo de eventos. Por ejemplo, un servicio o una capa de nivel inferior de la aplicación de consumidor tiene un problema que impide que procese eventos. En ese caso, la API de entrega de extracción permite que la aplicación de consumidor libere un evento de lectura ya leído al agente para que se pueda entregar más adelante.
  • Quiere usar vínculos privados al recibir eventos, lo que solo es posible con la entrega de extracción, no con la entrega de inserción.
  • No tiene la capacidad de exponer un punto de conexión y usar la entrega de inserción, pero puede conectarse a Event Grid para consumir eventos.

Entrega de inserción

  • Quiere evitar sondeos constantes para determinar que se ha producido un cambio de estado del sistema. Prefiere usar Event Grid para enviar eventos en el momento en que se producen cambios de estado.
  • Tiene una aplicación que no puede realizar llamadas salientes. Por ejemplo, puede que a su organización le preocupe la filtración de datos. Sin embargo, la aplicación puede recibir eventos a través de un punto de conexión público.

Pasos siguientes