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

Question

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

但是，在分析迁移时，我们发现很难将我们的基础设施置于 Azure 事件中心的限制范围内。我们在 Kafka 中有数百个主题，并且我们知道 future 将扩展到数千个主题，但这并不容易适合事件中心。

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

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

我在互联网上查找了这个问题的答案，但没有运气，每个人似乎都看到了使用事件中心的很多优点，所以我开始认为我可能错过了一些东西。哪一种方法可以有效地将大量主题放入 10 个主题限制内，而无需对我的架构进行大量更改？

Answer 1

Azure 事件中心提供 Kafka/EH，用于两种不同类型的数据流 - 单租户和 Multi-Tenancy 。虽然 Multi-Tenancy 使您可以灵活地保留小容量和使用小容量，但它是通过配额和限制强制执行的。这些都是严格的，不能变通。原因是，类似地，您可以将 Multi-Tenancy 想象为一个巨大的 kafka 集群，其中 %CPU 和 %内存在不同租户之间以严格的边界共享。通过这个支持 Multi-Tenancy 的基础设施，我们定义了边界，这些边界是通过配额和限制来强制执行的。事件中心是唯一向您收取预留带宽和事件入口费用的 PaaS 服务。没有导出费用。我们还允许您输入 xMBps 和输出 2xMBps，并且配额允许我们遵守此边界。我们的单租户集群可以被认为是模仿没有附加配额的确切 KAfka 集群。我们在这里强制执行的限制是实际的物理限制。每个命名空间 1000 个主题和每个容量单位 50 个命名空间的限制是软限制，可以放宽，因为它们只是强制执行最佳实践。比较标准和专用时，成本合理性没有任何不同，事实上，当您的速度 > 50MBps 时，您可以占据优势，因为整个容量专用于专用的一个租户。此外，单个容量单元(其中出售专用集群)可让您根据发送/接收模式、有效负载大小、频率等实现 100MBps - 250MBps 之间的任何速度。出于比较目的，尽管我们没有在标准上进行 0TU，并且专用 CU 和标准之间没有直接关系/映射

TU，下面是定价示例，50TU = 0.03 美元/小时 x 50 = 每小时 1.5 美元 |每秒 50,000 个事件 = 每小时 180,000,000 个事件180,000,000/1,000,000 = 180 个单位 1,000,000 条消息 | 180 X 0.028 美元 = 5.04 美元 |因此，每小时总计 6.54 美元

请注意，上述内容不包括 Capture 定价。每小时总计 6.85 美元，您即可获得包含 Capture 的 Dedicated。