无认证Azure Event Hubs监听器作为WebHook的配置方案咨询

Azure Event Hubs在平台层面不支持配置无SAS认证的监听器，所有接入事件中心的请求都必须携带合法的SAS令牌完成鉴权，不存在可关闭鉴权的配置入口。

该方案属于第三方硬约束下的可接受工程实践，具体评估维度如下：

• 技术可行性：方案无落地阻碍。Runbook内置的WebHook能力可接收不带额外请求头、无特殊请求体格式的普通POST请求，仅需在Runbook逻辑中预置Event Hubs的SAS凭据，通过SDK完成认证后将收到的负载转发至目标事件中心即可，全链路无平台限制。
• 实践局限性：
  • 性能与容量限制：Runbook存在冷启动耗时、单作业执行时长上限、单WebHook请求最大载荷64KB的硬约束，不适合高并发、大载荷的请求场景
  • 成本差异：Runbook按作业运行时长、数据流转量计费，长期承载稳定WebHook流量的成本会显著高于云原生托管组件
  • 运维成本：需要自行开发实现请求错误重试、日志审计、异常告警等能力，长期维护成本较高

结合Azure生态的托管能力，可落地的低复杂度替代方案包括：

• 方案1：Azure API Management前置接入转发
  • 实现逻辑：在APIM实例上配置可公开访问的匿名API操作（关闭操作层面的订阅密钥、JWT等内置鉴权策略），接收第三方的普通URL请求，通过内置的策略表达式自动生成Event Hubs要求的SAS授权头，将请求直接转发到目标事件中心
  • 优势：相比Runbook方案，支持更高并发、更大请求载荷，内置日志审计、流量限流、错误重试能力，长期运维成本更低
• 方案2：Azure Functions HTTP触发器前置接收
  • 实现逻辑：创建HTTP触发的Azure Function，将触发器的访问级别设置为Anonymous以接收无认证的公网请求，通过Function内置的Event Hubs输出绑定，直接将收到的请求负载写入目标事件中心，无需手动实现SAS认证逻辑
  • 优势：Serverless架构下按实际调用量计费，冷启动时长远低于Runbook，支持更高的请求载荷上限，配置逻辑简单
• 方案3：简化架构跳过Event Hubs
  • 实现逻辑：由于当前业务场景中Event Hubs的唯一用途是接收请求后将负载写入Azure Blob Storage，可直接为Blob Storage的专用存储容器配置匿名写入权限，作为第三方WebHook的直接接收端，省略Event Hubs、转发层的冗余组件，降低整体架构复杂度

所有无鉴权的公网WebHook端点，可在条件允许时配置来源IP白名单，减少端点被恶意扫描、刷请求带来的额外成本或垃圾数据侵入风险。

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