Webhook体系结构，用于管理数百万个订户（是客户）

Question

我基于Azure的SaaS系统发布事件，并且我有希望订阅这些事件的客户-毫无疑问，Webhooks似乎是正确的体系结构（而且我现在是Webhooks的快乐用户）。我发现了很多有关最佳做法的出色文档和案例研究（例如http://resthooks.org），但是我还没有找到实现最佳做法的现有架构，框架，项目，示例或解决方案。

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

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

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

我已经了解了如何在个人订户中发布和使用Webhooks，并且已经有了一些不错的示例-https://github.com/aspnet/AspLabs/tree/master/src/WebHooks

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

Answer 1

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

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

然后，我们将遵循subscription management guidance Zapier的报价。简而言之，就是要使我们的客户能够通过几个端点订阅我们发布的事件。当租户添加/删除订阅时，除了标准CRUD内容外，代码还将利用事件网格管理SDK来添加/删除对事件网格（samples here）中相应主题的订阅。添加的订阅将设置过滤器，以确保每个租户仅接收自己的事件。

Azure（details here）中订阅和主题的数量受到限制。这些限制在我们的情况下是可以接受的，但是如果您需要吸引1毫米订户，则可能需要进一步研究。

这是我如何可视化它：

不是100％的我们会构建它，但是如果这样做，我会在这里发布我们发现的所有陷阱。

干杯！