最近，Azure发布了一项名为Azure Event Hubs for Kafka的功能，该功能允许使用事件集线器，就像它是一个Kafka群集一样，并使用相同的Kafka库。这将使我们能够从当前的IaaS Kafka解决方案迁移到PaaS解决方案，它具有完全托管的解决方案的所有优点，并且只需对基本代码进行最小的更改（至少是有希望的）。
但是，在分析迁移时，我们发现很难将我们的基础结构置于Azure Event Hub限制之内。卡夫卡（Kafka）有数百个主题，而且我们知道将来会扩展到数千个主题，但这在Event Hubs中并不容易。
在Azure中，主题概念的匹配项是事件中心，然后您还拥有与Kafka群集匹配的名称空间。实际上，每个名称空间都有一个不同的DNS名称，从而使其成为一个完整的不同系统。限制如下：每个名称空间最多可以有10个事件中心，每个预订最多100个名称空间。译成卡夫卡行话的主题多达1000个。让我们假设这足以满足我们的目的，但是我需要每10个主题将应用程序的不同部分连接到不同的Kafka群集（命名空间），这给整个故事增加了不必要的复杂性。< / p>
最后，似乎我正在通过重新架构应用程序的难度来改变管理自己集群的基础结构的难度，以使其适合每个集群限制的10个主题。使用Kafka，我可以在一个集群中拥有100个主题。 使用事件中心，我需要10个集群，每个集群有10个主题，这增加了了解消费者和生产者需要连接到哪个集群的复杂性。这完全改变了您的应用程序的体系结构（使它的功能大大增加了）复杂）。
我一直在互联网上寻找这个问题的答案，但是运气并不好，每个人似乎都发现使用Event Hubs有很多优势，所以我开始认为也许我缺少了一些东西。在不改变我的体系结构的情况下，哪种方法可以在10个主题限制之内适应很多主题？
答案 0 :(得分：1)
Azure Event Hubs提供Kafka / EH，用于在两个不同的框架中进行数据流传输-单租户和多租户。虽然多租户为您提供了保留小容量和使用小容量的灵活性，但它是通过配额和限制来强制执行的。这些都是严格的，不能屈服。原因，类似地，您可以想象多租户是一个巨大的kafka集群，其中％CPU和％memory在不同租户之间具有严格的边界共享。借助此基础设施来满足多租户的需要，我们定义了边界，并且这些边界受配额和限制的约束。事件中心是唯一向您收费的PaaS服务，用于保留带宽和事件进入。没有出口费用。我们还允许您进入xMBps并出口2xMBps，配额使我们具有此边界。我们的单个租户集群可以被视为模仿没有配额的确切KAfka集群。我们在此处强制执行的限制是实际的物理限制。每个名称空间1000个主题的限制和每个容量单位50个名称空间的限制是软限制，可以放宽限制，因为它们只是在实施最佳实践。比较“标准”和“专用”时的成本合理性没有什么不同，实际上，当您执行“> 50MBps”时，您可以受益，因为整个容量专用于一个“专用”租户。同样，一个容量单元（出售专用集群）可以根据您的发送/接收模式，有效负载大小，频率等来实现100MBps-250MBps之间的任何带宽。出于比较目的，尽管我们不对Standard进行0TU，并且专用CU与Standard之间没有直接关系/映射
TU的价格示例如下， 50TU's = $ 0.03 / hr x 50 =每小时$ 1.5 |每秒50,000个事件=每小时180,000,000个事件 180,000,000 / 1,000,000 = 1,000,000条消息的180个单位| 180 X $ 0.028 = $ 5.04 |因此，每小时总计$ 6.54
请注意，以上内容不包含“捕获”定价。每小时总计$ 6.85，您将获得包括Capture的全部奉献。
答案 1 :(得分：-1)
在研究限制时，似乎专用层每个名称空间具有1000个事件中心。尽管由于使用专用层会产生一些额外费用。