azure - 用于发布事件的 Azure 服务总线
问题描述
我们正在制作一个多租户系统，该系统应该会产生大量突发事件（尤其是在新客户上线期间），并且正在寻找一种将事件源与事件处理程序解耦的方法。起初，具有多个订阅的 azure service-bus 似乎是最好的情况，但阅读的限制似乎在大小上受到限制。（例如每个主题几 GB），在我看来，即使是队列对于我们的要求来说仍然很小。（约 80GB）
不要误会我的意思，我们不打算在正常操作期间（也就是 99% 的时间）摄取 100GB 的数据。但是，考虑到这是多租户，租户（以及因此数据/事件）的数量必然会增长。我们更喜欢使用单个服务总线/队列，以便在我们自己的所有服务器之间分散所有租户的负载。事件爆发的本质是单个租户可以产生巨大的事件爆发，而其他租户并没有做太多；因此为每个租户创建一个队列；让我们的每台服务器都听几个租户队列并不是很好地利用我们的硬件。让所有服务器监听所有（许多）队列可能也不是负载平衡的好方法。
所以我们最重要的要求是：
- 不要错过任何输入。
- 将负载均匀地分布在可变数量的服务器上。
（理想情况下将根据队列的大小动态缩放。）
但我们可以忍受以下缺点：
- 在我们处理完所有内容之前需要一些时间（几天......）
- 按实际使用的 GB 付费（与为预订付费相比）
- 当您输入大量数据时，它会变慢。
这可以通过 Azure 服务总线/队列来完成吗？
或者任何其他 Azure 存储系统？
还是我们需要完全寻找其他东西？
解决方案
永远无法保证 100% 的时间可以信任编排介质的完整性。与其说选择哪种编排媒介，不如说设计系统的各个部分，以使如果出现问题，系统可以在恢复的同时继续可用而不会丢失数据。
您可以考虑不同的方法来确保永远不会丢失输入。例如，作为接受输入的过程的一部分，将接收到的输入持久保存到近乎线性可扩展的存储中，例如blob 存储，并将一条小消息放置在仅包含消息 ID 的 Azure 服务总线命名空间中（事务中的这两个操作）。然后使用另一个可扩展单元（例如 azure 逻辑应用或函数应用）将完整的有效负载放入另一个 azure 服务总线命名空间。这样，即使第二个命名空间的大小达到最大值，第一个命名空间也会继续收集新的输入，因为第一个命名空间的消息中的数据非常小。如果这也不够可扩展，那么还有许多其他方法可以考虑所有优点和缺点。