azure - Azure 事件网格中的订阅验证事件消息架构是什么？

Question

1. 使用门户创建了具有云事件架构的新 azure 事件网格域。
2. 使用 azure 函数创建了新的 Web Hook 端点，该端点可以接收订阅验证事件以及事件通知。
3. 使用门户为上述域创建了新的 Azure 事件网格主题(作为以下订阅的一部分)。
4. 使用上述 Web Hook 端点使用云事件架构创建了新的 Azure 事件网格订阅。
5. 创建订阅后，网格基础设施将通过订阅验证事件调用端点来验证 Web Hook 端点。

令我惊讶的是，验证事件结构(如下所示)似乎符合 native 事件网格架构，而不是云事件架构:

[{
    "id": "6309ef83-117f-47aa-a07c-50f6e71a8ca5",
    "topic": "/subscriptions/13ad1203-e6d5-4076-bf2b-73465865f9f0/resourceGroups/xxxx-sandbox-rg/providers/Microsoft.EventGrid/domains/eg-xxx-test-cloud-domain/topics/eg-xxx-test-cloud-topic",
    "subject": "",
    "data": {
        "validationCode": "391889BB-FCC3-4269-A2BD-0918B5BAB0AE",
        "validationUrl": "https://rp-westus.eventgrid.azure.net/eventsubscriptions/xxxx-subscription-3/validate?id=391889BB-FCC3-4269-A2BD-0918B5BAB0AE&t=2019-01-30T15:45:37.0521594Z&apiVersion=2018-09-15-preview&[Hidden Credential]"
    },
    "eventType": "Microsoft.EventGrid.SubscriptionValidationEvent",
    "eventTime": "2019-01-30T15:45:37.0521594Z",
    "metadataVersion": "1",
    "dataVersion": "2"
}]

我期望以下符合云事件架构的订阅验证事件(基于 https://learn.microsoft.com/en-us/azure/event-grid/cloudevents-schema#cloudevent-schema 处的云事件架构 0.1 版本):

{
    "eventID" : "6309ef83-117f-47aa-a07c-50f6e71a8ca5",
    "source" : "/subscriptions/13ad1203-e6d5-4076-bf2b-73465865f9f0/resourceGroups/xxxx-sandbox-rg/providers/Microsoft.EventGrid/domains/eg-xxx-test-cloud-domain/topics/eg-xxx-test-cloud-topic",
    "data": {
        "validationCode": "391889BB-FCC3-4269-A2BD-0918B5BAB0AE",
        "validationUrl": "https://rp-westus.eventgrid.azure.net/eventsubscriptions/xxxx-subscription-3/validate?id=391889BB-FCC3-4269-A2BD-0918B5BAB0AE&t=2019-01-30T15:45:37.0521594Z&apiVersion=2018-09-15-preview&[Hidden Credential]"
    },
    "eventType" : "Microsoft.EventGrid.SubscriptionValidationEvent",
    "eventTime" : "2019-01-30T15:45:37.0521594Z",
    "cloudEventsVersion" : "0.1",
    "eventTypeVersion" : "2",
}

我错过了什么？

Answer 1

基本上，Webhook 订阅者正在处理以下两组事件。具体的事件类型存储在http header 'aeg-event-type'中。

1. 事件网格模型的内部事件，例如事件类型SubscriptionValidation和SubscriptionDeletion。这些事件类型的架构始终与默认架构(例如 EventGridSchema)相同。换句话说，它不依赖于EventDeliverySchema。 IMO，拥有内部事件的默认架构可以创建强大的事件类型，特别是当我们有 CustomInputSchema 时。

2. 兴趣源事件(主题)是由输入架构定义的事件，目前事件网格模型支持 3 种类型，例如 EventGridSchema(默认)、>CloudEventSchema 和CustomInputSchema。 AEG 支持以下模式输入/输出映射:

   1. EventGridSchema 到交付架构 EventGridSchema 和 CloudEventSchema
   2. CloudEventSchema 仅用于交付架构 CloudSchemaSchema
   3. CustomInputSchema 到交付架构 EventGridSchema 和 CloudEventSchema 以及 CustomInputSchema

   header 中的事件类型为:aeg-event-type=Notification，架构基于订阅的 EventDeliverySchema(请参阅以下映射)。

基于上述内容，对于您的场景，您应该为内部事件(默认架构为 EventGridSchema)和基于订阅的 EventDeliverySchema 的通知事件拥有单独的强类型对象。

以下是 http header 的示例:

aeg-subscription-name=EVENTGRIDSCHEMA
aeg-delivery-count=0
aeg-data-version=
aeg-metadata-version=0
aeg-event-type=SubscriptionValidation

注意，只有订阅名称可以确定已订阅哪个 EventDeliverySchema。最好有一个额外的 aeg header ，例如:aeg-subscription-labels 将一些订阅元数据传递给订阅者处理程序。

作为解决方法，我们可以通过 url 查询参数向订阅者 Webhook 处理程序传递一些值，例如:&eds=CustomInputSchema