管理数百万订阅者(即客户)的Web钩子体系结构

Question

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

我可以建立自己的解决方案，但我不想重新发明车轮。我本来希望找到一个现有的框架(例如，在Github上)，由比我聪明得多的人创建，但没有取得任何成功。

我目前在内部使用许多Azure服务(如服务总线、宇宙、表存储)，并使用Azure函数进行消费，但我没有允许客户订阅这些事件的体系结构。

具体来说，我正在寻找关于如何管理潜在的数百万订阅者(他们是外部客户)的最佳实践和代码示例，以及如何将webhooks分发给他们中的每一个.。

我已经了解了如何发布和使用webhooks，我是一个单独的订阅者，并且已经有一些很好的示例- https://github.com/aspnet/AspLabs/tree/master/src/WebHooks。

谁能给我指明正确的方向？(最好是基于.NET / C#的解决方案)

Answer 1

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

我们目前正在使用CosmosDb，并利用变更提要触发Azure函数的执行。函数中的代码为系统中的所有租户执行特定任务。此代码将被更改为简单地将一个新事件发送到event主题。然后将添加一个“内部”订阅，它将处理函数代码当前正在做的事情。

然后，我们将遵循订阅管理指南 Zapier的报价。简而言之，它是向我们的客户公开通过几个端点发布的事件订阅功能。除了标准CRUD之外，当租户添加/删除订阅时，代码将利用向事件网格(这里的样品)中的适当主题添加/删除订阅。添加的订阅将设置筛选器，以确保每个租户只接收自己的事件。

在Azure (这里的细节)中订阅和主题的数量有限制。在我们的情况下，这些限制是可以接受的，但是如果您需要达到1mm订户，您可能需要了解更多。

下面是我对它的想象：

​

不是100%，我们会建立这个，但如果我们这样做，我会张贴在这里，因为我们发现的任何问题。

干杯!