在 Azure 服务总线中寻找事件中心与主题的清晰度

Question

我一直在了解事件中心，只是想确认或纠正我对事件中心的看法？ 我习惯于利用 Azure 服务总线队列和主题为我提供的正常企业消息传递解决方案中的重试、有害消息、至少一次传递等。 似乎事件中心旨在为非常高的规模提供一种不同的工具，在这种情况下，您必须放弃一些更“企业”的功能以获得更高的规模。

我是否正确地考虑了这一点？ 我还需要考虑其他细节吗？ 我意识到事件中心和主题可能存在一些功能重叠，但我只是想弄清楚如何考虑使用事件中心。

Answer 1

如果您有选择，那么基于完整的企业 pubsub 消息传递系统编写一个系统几乎总是更容易，您可以在其中将单个事件标记为已被使用、重试消息以及几乎所有其他精彩功能。 如果您已经接受对消息通道进行分区（Azure 服务总线主题似乎支持），那么原则上您可以将功能更全面的消息系统扩展到您需要的程度。 问题是什么代价？

Azure 服务总线主题的大规模成本约为 每百万条消息0.20 美元，Amazon SQS（有些类似）列出了 每百万条消息0.50 美元。 如果您自己托管它，您可能需要在分区时设置许多 RabbitMQ 服务器甚至多个集群。

Azure 事件中心的成本为每百万 0.028 美元加上每个吞吐量单位的金额，与Amazon Kinesis相同。 Apache Kafka 在 3 台机器上的基准测试为每秒 200 万

以每秒 20,000 个事件为例，某些 Azure 主题和 Azure 事件中心之间的差异在全职开发人员的薪水范围内。 每秒持续 200 万（需要联系 MS），差异接近 100 万美元/月。

当您不需要完整消息传递系统的所有有用功能时，或者当您不需要它们来支付大约 10 倍的溢价时，基本上使用分区流|日志/偏移量跟踪系统。 （或者不能使用它们，因为如果没有英勇的努力，您就无法充分扩展适当的消息传递系统）。

Answer 2

不久前，我在服务总线团队的 Dan 的支持下写了一篇关于这个主题的帖子。 希望这应该为您澄清

http://microsoftintegration.guru/2015/03/03/azure-event-hubs-vs-azure-messaging/

服务总线（消息）

对于消息传递，它是关于一个应用程序告诉一个或多个应用程序做某事或给我某事。

事件中心（事件）

另一种方法是在事件中应用程序说发生了一些事情。

Answer 3

正确的！！

EventHubs 和 Topics 之间的根本区别是 - TOPICS 提供每消息语义- 而 EventHubs - 提供流语义- 意味着，不应期望 EventHubs 有任何per-message功能/语义。

任何提供per-message功能的中间层都会带来processing overhead (the tax) ！！

例如：每条消息重复检测，每条消息接收确认（主题有一个 Message.Complete 来确认收到的消息） - 都是主题功能。 EventHub 缩小了功能集的范围，以提供更好的低延迟/高吞吐量解决方案。

将至少一次交付（每个 msg 在 EventHub 中不可用）等功能可视化是将其转换为流语义 - 读取直到给定 eventHub 分区和检查点中的某个点，并让使用这些事件的应用程序处理at-least-once交付。

更多关于事件中心...

Answer 4

根据这篇MS Learn 文章和“在 Azure 消息服务之间进行选择”关于选择什么：

“Azure 事件中心专为高流量分析类型的事件而设计。Azure 服务总线和存储队列用于消息，可用于绑定任何应用程序工作流的核心部分。”

了解事件和消息的用途之间的区别很重要，因为通信服务通常设计为处理它们各自的对象——事件中心处理事件，服务总线处理消息。

事件触发通知，表明某事已发生。 它比消息“更轻”——它有关于发生了什么的信息，但没有触发事件本身的数据。 例如，事件可能会通知您文件上传并包含有关文件的信息，但不包含文件本身。 事件通常用于广播通信/扇出工作流，即当每个发布者都有大量订阅者时。 发布者对消费者如何处理事件没有期望。

消息包含触发消息管道的数据。 与事件不同，发布者对消费者如何处理消息有期望。 例如，发布者发送一条包含由服务产生的原始数据的消息，并期望消费者存储该数据并在完成后发回响应。

（还有事件网格，它也处理事件，但与事件中心不同。事件中心是为涉及分析的大数据管道而设计的，而事件网格是为事件驱动的反应式编程而设计的。）