Azure 事件中心限制及其与纯 Kafka 集群的比较

Question

最近，Azure 发布了一项名为Azure Event Hubs for Kafka 的功能，它允许使用 Event Hubs，就像它是 Kafka 集群一样，使用相同的 Kafka 库。这将使我们能够从我们当前的 IaaS Kafka 解决方案迁移到 PaaS 解决方案，具有完全托管解决方案的所有优点，并且对我们的基本代码只进行最小的更改（至少这是承诺）。

但是，在分析迁移时，我们发现很难让我们的基础架构在 Azure 事件中心限制内。我们在 Kafka 中有数百个主题，我们知道我们将来会扩展到数千个主题，但这并不能轻松地放入事件中心。

在 Azure 中，主题概念的匹配项是事件中心，然后还有与 Kafka 集群匹配的命名空间。事实上，每个命名空间都有不同的 DNS 名称，使其成为一个完全不同的系统。限制如下：每个命名空间最多可以有 10 个事件中心，每个订阅最多可以有 100 个命名空间。翻译成 Kafka 行话，最多可达 1000 个主题。让我们假设这对于我们的目的来说已经足够了，但是我需要我的应用程序的不同部分连接到每 10 个主题的不同 Kafka 集群（命名空间），这给整个故事增加了不必要的复杂性。

似乎最终我正在通过重新构建我的应用程序的难度来改变管理我自己的集群基础设施的难度，以便它适合每个集群 10 个奇怪的主题限制。使用 Kafka，我可以在一个集群中拥有 100 个主题。对于事件中心，我需要 10 个集群，每个集群 10 个主题，这增加了了解消费者和生产者需要连接到哪个集群的复杂性。这完全改变了应用程序的架构（使其变得更加复杂）。

我已经在互联网上寻找答案但没有运气，每个人似乎都看到了使用事件中心的很多优势，所以我开始认为我可能遗漏了一些东西。在不大量改变我的架构的情况下，在 10 个主题限制内拟合大量主题的有效方法是什么？

Answer 1

在研究限制时，似乎专用层每个命名空间有 1000 个事件中心。尽管由于专用层会产生一些额外费用。