用于发布事件的Azure服务总线

Question

我们正在开发一个多租户系统，该系统应突发生成大量事件（尤其是在新客户登机期间），并且正在寻找一种将事件源与事件处理程序分离的方法。最初，具有多个订阅的azure服务总线似乎是最好的情况，但是请阅读似乎在大小上受到限制的限制。 （例如每个主题几GB），即使在队列中，我认为对于我们的要求来说仍然很小。 （约80GB）

不要误会我的意思，我们不打算在正常操作期间（也就是99％的时间）摄取100GB的数据。但是，考虑到这是多租户，租户（因此数据/事件）的数量必然会增长。而且我们更喜欢使用单个服务总线/队列，以便在我们自己的所有服务器之间分配所有租户的负载。事件爆发的性质是，一个租户可以产生大量事件，而其他租户则没有做很多事。因此为每个租户创建一个队列；并让我们的每台服务器都监听几个租户队列并不是对我们硬件的真正使用。并且让所有服务器都监听所有（许多）队列，这也不是负载平衡的好方法。

所以我们最重要的要求是：

• 永远不要错过任何输入。
• 将负载平均分布在可变数量的服务器上。
  （理想情况下，将根据队列的大小动态缩放。）

但是我们可以忍受以下缺点：

• 我们需要花一些时间（几天...）
• 实际使用的每GB费用（与支付预订费用相比）
• 当您输入大量数据时，它会变慢。

这可以通过Azure服务总线/队列来完成吗？
还是任何其他Azure存储系统？
还是我们需要完全着眼于其他事物？

Answer 1

您可以利用Azure事件网格来解决满足您的业务需求的问题。您可以将事件从不同的租户发送到事件网格主题。 事件网格主题可以由多个事件订阅来订阅，每个事件订阅都配置有将处理事件的不同终结点。终结点可以是Azure功能，它将通过负载均匀分布的方式处理来自不同租户的事件。

您可以使用“事件网格订阅”的过滤器来过滤事件并分配负载。

Azure函数使用扇出模式。因此，负载将由功能应用自动处理，并且仅当事件网格中有事件时，您才需要承担费用。

Answer 2

永远不能保证编排媒体可以100％地被信任以保证完整性。与选择哪种编排介质有关的事情很少，而与设计系统部分有关的事情更多的是，如果出现问题，系统可以继续可用，同时进行恢复而不会丢失数据。

您可以考虑采用其他方法来确保不会丢失任何输入。例如，作为接受输入的过程的一部分，将接收到的输入持久保存到近似线性可伸缩的存储（例如blob store中），然后在仅包含消息ID的Azure Service Bus命名空间中放置一条微小的消息（这两个操作位于交易）。然后拥有另一个可伸缩单元（例如，天蓝色逻辑应用程序或功能应用程序），以将完整的有效负载放入另一个天蓝色服务总线名称空间。这样，即使第二名称空间达到最大大小，由于第一名称空间的消息中的数据非常小，因此第一名称空间将继续收集新的输入。如果这还不够可扩展，那么还有很多其他方法可以考虑专业人士和专业人士的所有需求。