将完整实体存入Azure Event Grid替代事件的合理性使用咨询

事件消息仅包含响应服务与应用变更所需的信息，Event Grid并非数据管道，不会传递被更新的实际对象。

你当前的使用链路 Entity changes -> [Azure Event Grid -> Azure function] -> update search index 本身符合Event Grid的适用场景，问题出在「将完整实体存入Event Grid」的操作不符合其设计定位，核心原因如下：

• 消息大小硬限制：Event Grid单事件的大小上限为64KB，批量事件总上限为256KB，绝大多数业务实体的完整数据都会超出该阈值，一旦超出会被服务直接拒绝投递，流程无法正常运行。
• 投递特性不匹配：Event Grid的核心设计目标是低延迟的事件通知，采用「至少一次快速投递」策略，不对消息做高等级持久化兜底，也不支持保序投递、长周期重试、死信队列持久存储等面向数据传递的特性，若传递完整实体，一旦出现投递失败会直接丢失实体数据，也无法保证实体变更的处理顺序。
• 成本与效率问题：Event Grid按事件投递次数计费，塞入大体积实体数据会拉高传输延迟，还可能因超出大小阈值触发事件拆分，直接提升使用成本。
• 数据一致性风险：若事件中携带完整实体，若实体在事件投递过程中又发生了新的变更，会导致Function拿到的事件数据是旧版本，直接更新索引会出现数据不一致的问题。

官方推荐的标准适配方案是：Event Grid事件中仅携带实体ID、变更类型、变更时间戳这类最小通知信息，Azure Function接收到事件后，主动到实体的存储源（如数据库、对象存储等）拉取最新的完整实体数据，再完成搜索索引更新。如果你需要直接在消息中携带完整实体，Azure Service Bus的设计更适配该需求，其单消息最高支持100MB大小，也具备消息持久化、保序、重复检测等特性，可保障数据传递的可靠性。

内容的提问来源于stack exchange，提问作者Markus