最近azure发布了一个名为azure event hubs for kafka的特性，它允许使用事件中心，就像kafka集群一样，使用相同的kafka库。这将允许我们从当前的iaas-kafka解决方案迁移到paas解决方案，具有完全托管解决方案的所有优点，并且只需对基本代码进行最小的更改（至少这是承诺）。
然而，在分析迁移时，我们发现很难让我们的基础设施超出azure事件中心的限制。我们在Kafka有数百个主题，我们知道我们将在未来扩展到数千个，但这不容易适合在活动中心。
在azure中，与topic概念匹配的是事件中心，然后还有与kafka集群匹配的名称空间。实际上，每个名称空间都有一个不同的dns名称，这使它成为一个完全不同的系统。限制如下：每个命名空间最多可以有10个事件中心，每个订阅最多可以有100个命名空间。这，翻译成Kafka行话，是多达1000个主题。让我们假设对于我们的目的来说，这已经足够了，但是我需要我的应用程序的不同部分来连接到每10个主题的不同kafka集群（名称空间），为整个故事增加了不必要的复杂性。
似乎最终我改变了管理自己集群的基础设施的困难，改变了重新构建应用程序的困难，使其符合每个集群10个主题的奇怪限制。与Kafka我可以有100个主题在一个集群。对于事件中心，我需要10个集群，每个集群包含10个主题，这增加了了解消费者和生产者需要连接到哪个集群的复杂性。这完全改变了应用程序的体系结构（使其更加复杂）。
我在网上找了一个答案，但运气不好，每个人似乎都看到了使用活动中心的很多优势，所以我开始想，也许我遗漏了什么。哪种方法可以有效地将大量的主题放在10个主题的范围内，而不会对我的架构造成太大的改变？
2条答案
按热度按时间3bygqnnd1#
在研究限制时，似乎专用层每个命名空间有1000个事件中心。尽管由于专用层的存在，会有一些额外的成本。
ef1yzkbh2#
azure event hubs提供kafka/eh，用于两种不同的保护伞中的数据流—单租赁和多租赁。虽然多租户为您提供了保留小容量和使用小容量的灵活性，但它是通过配额和限制来执行的。这些都是严格的，不能弯曲出来。原因类似地，您可以想象多租户是一个巨大的kafka集群，其中%cpu和%memory在不同租户之间以严格的边界共享。通过这个基础设施，我们定义了多租户的边界，这些边界由配额和限制来强制执行。事件集线器是唯一的paas服务，它为您保留带宽和事件入口而收费。不收出口费。我们还允许您进入xmbps和出口2xmbps，配额允许我们使用此边界。我们的单租户集群可以被认为是模仿没有附加配额的kafka集群。这里我们执行的限制是实际的物理限制。每个名称空间1000个主题和每个容量单元50个名称空间的限制是软限制，可以放宽，因为它们只是在实施最佳实践。当您比较标准和专用时，成本理由没有任何不同，事实上，当您的速度大于50mbps时，您可以获得一个优势，因为整个容量专用于一个拥有专用服务的租户。此外，单个容量单元（其中销售专用集群）允许您根据发送/接收模式、有效负载大小、频率等实现100mbps-250mbps之间的任何速度。出于比较的目的，虽然我们没有对标准进行0tu，而且专用cus和标准之间没有直接的关系/Map
tu's，下面是一个定价示例，50tu's=$0.03/hr x 50=$1.5/小时| 50000事件/秒=180000000事件/小时180000000/1000000=180个1000000消息单元| 180 x$0.028=$5.04 |因此，总计$6.54/小时
请注意，以上不包括捕获定价。每小时总共6.85美元，你就可以得到包括捕获在内的专享。