用于管理数百万订阅者（即客户）的 Webhook 架构答案

【问题标题】：Webhook architecture for managing millions of subscribers (who are customers)用于管理数百万订阅者（即客户）的 Webhook 架构
【发布时间】：2018-11-15 07:26:05
【问题描述】：

我基于 Azure 的 SaaS 系统发布事件，并且我有客户希望订阅它们 - 不可否认，webhook 似乎是正确的架构（而且我目前是 webhook 的快乐消费者）。我找到了很多关于最佳实践的优秀文档和案例研究（例如http://resthooks.org），但是我还没有找到实施最佳实践的现有架构、框架、项目、示例或解决方案。

我可以构建自己的解决方案，但我不想重新发明轮子。我期待找到一个由比我聪明得多的人创建的现有框架（例如在 Github 上），但没有取得任何成功。

我目前在内部使用许多 Azure 服务（例如 Service Bus、Cosmos、表存储）并使用 Azure Functions 进行消费，但我没有允许我的客户订阅这些事件的架构。

具体来说，我正在寻找有关如何管理潜在的数百万订阅者（外部客户）以及将 webhook 分发给每个订阅者的方法的最佳实践和代码示例。

我已经了解如何在个人订阅者的情况下发布和使用 webhook，并且已经有一些很棒的示例可用 - https://github.com/aspnet/AspLabs/tree/master/src/WebHooks

谁能指出我正确的方向？（最好是基于 .NET / C# 的解决方案）

【问题讨论】：

您是否考虑过在事件网格中使用自定义事件？
Event Grid 看起来绝对是一个很好的构建基础，它与我基于 Azure 的解决方案很好地结合在一起（哦，我多么喜欢 Azure - 只需要加入它）。从我所见，它需要一些定制才能将订阅连接到我的特定客户，但绝对比从头开始构建更理智。我将做更多的研究，并了解 Event Grid 提供的内容与我的（在此阶段主要是概念性的）需求之间所需的工作量。
@Fanetic - 你有没有找到解决问题的方法？你走自定义路线了吗？
@StephenMcDowell - 不，从来没有最终实现 webhook。我们使用的解决方案允许“请求者”提供一个“回调”端点，我们将事件发布到该端点。它暂时满足了我的需求，但是我最终需要解决此问题。解决它已从我的优先级列表中移出，但如果其他人有兴趣，仍然有兴趣。

标签： azure events architecture webhooks publish-subscribe

【解决方案1】：

不确定这是否是“正确”的方向，但这是我目前对解决方案的想法。

我们目前正在使用 CosmosDb，并正在利用更改源来触发 Azure 函数执行。函数中的代码为我们系统中的所有租户执行特定任务。此代码将更改为简单地将新事件发送到事件网格主题。然后将添加一个“内部”订阅，该订阅将处理功能代码当前正在执行的操作。

然后我们将关注subscription management guidance Zapier 的报价。简而言之，它是向我们的客户公开订阅我们通过几个端点发布的事件的能力。除了当租户添加/删除订阅时的标准 CRUD 内容外，代码将利用事件网格管理 SDK 添加/删除对事件网格中适当主题的订阅 (samples here)。添加的订阅将设置过滤器以确保每个租户只接收自己的事件。

Azure (details here) 中的订阅和主题数量存在限制。这些限制在我们的案例中是可以接受的，但如果您需要覆盖 1 毫米订阅者，您可能需要进一步研究这些限制。

我是这样想象的：

我们不会 100% 构建它，但如果我们这样做了，我会将我们发现的任何问题发回此处。

干杯！

【讨论】：