我的基于 Azure 的 SaaS 系统发布事件，并且我有希望订阅这些事件的客户 - Webhooks 似乎无疑是正确的架构(而且我目前是 Webhooks 的快乐消费者)。我发现了很多关于最佳实践的优秀文档和案例研究(例如 http://resthooks.org )，但是我还没有找到实现最佳实践的现有架构、框架、项目、示例或解决方案。
我可以构建自己的解决方案，但我不想重新发明轮子。我希望找到一个由比我聪明得多的人创建的现有框架(例如在 Github 上)，但没有取得任何成功。
我目前在内部使用许多 Azure 服务(例如服务总线、Cosmos、表存储)并使用 Azure Functions 进行消费，但我没有允许我的客户订阅这些事件的体系结构。
具体来说，我正在寻找有关如何管理潜在的数百万订阅者(外部客户)以及将网络钩子(Hook)分发给每个订阅者的方法的最佳实践和代码示例。
我已经了解如何发布和使用 webhook，我是个人订阅者，并且已经有一些很棒的示例可用 - https://github.com/aspnet/AspLabs/tree/master/src/WebHooks
有人能指出我正确的方向吗？ (最好是基于 .NET/C# 的解决方案)
最佳答案
不确定这是否是“正确”的方向，但这是我目前对解决方案的想法。
我们目前正在使用 CosmosDb 并利用更改源来触发 Azure 函数执行。该函数中的代码为我们系统中的所有租户执行特定任务。此代码将更改为仅将新事件发送到事件网格主题。然后将添加“内部”订阅，该订阅将处理函数代码当前正在执行的操作。
然后我们将遵循subscription management guidance扎 PIL 优惠。简而言之，它是向我们的客户公开订阅我们通过几个端点发布的事件的功能。除了标准 CRUD 内容之外，当租户添加/删除订阅时，代码还将利用事件网格管理 SDK 添加/删除对事件网格 ( samples here ) 内相应主题的订阅。添加的订阅将设置过滤器，以确保每个租户仅接收自己的事件。
Azure 中的订阅和主题数量存在限制 ( details here )。这些限制在我们的案例中是可以接受的，但如果您需要吸引 1mm 订阅者，您可能需要更多地考虑这些限制。
这是我如何想象它的:
我们并不是 100% 会构建这个，但如果我们这样做了，我会在这里发布我们发现的任何问题。
干杯!
关于azure - 用于管理数百万订阅者(即客户)的 Webhook 架构，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/53314336/