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

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

我想得对吗？是否还有其他细节我需要考虑？我意识到事件中心和主题可能有一些功能重叠，但我只是想弄清楚如何使用事件中心。

正确

EventHubs和Topics之间的根本区别在于，Topics提供每条消息的语义——而EventHubs提供的流语义——意味着，不应该期望EventHubs具有每条消息的

功能/语义。
任何提供每条消息
功能的中间层都会带来
处理开销（税）
！！
例如：每条消息重复检测，每条消息接收确认（主题有一条消息。完成确认消息接收）-都是主题功能。EventHubs缩小了功能集的范围，以提供更好的低延迟/高吞吐量解决方案

要可视化至少一次传递（每个消息的传递在eventHub中不可用）之类的功能，需要将其转换为流语义—读取到给定eventHub分区和检查点中的某个点，并让使用这些事件的应用程序至少处理一次传递

如果您有选择权，那么编写一个基于完整enterprise pubsub消息传递系统的系统几乎总是比较容易的，在该系统中，您可以将单个事件标记为已消费、重试消息以及几乎所有其他精彩功能。如果您已经接受对消息通道进行分区（Azure Service Bus主题似乎支持该分区），那么原则上您可以根据需要扩展功能更全面的消息系统。问题是要付出什么代价

AmazonSQS（有些类似）列表显示，Azure服务总线主题的成本大约为消息的高规模。如果您自己托管它，您可能需要在分区时设置许多RabbitMQ服务器，甚至多个集群

对于Amazon Kinesis，Azure事件中心的成本加上每吞吐量单位的金额。ApacheKafka在3台机器上的速度为每秒200万次

以每秒20000个事件的速度，一些Azure主题和Azure Event Hub之间的差异在全职开发人员的工资范围内。以每秒200万美元的速度持续（这需要联系微软），差额接近每月100万美元

当您不需要完整消息传递系统的所有有用功能时，或者当您不需要足够的功能来支付10倍的额外费用时，基本上使用分区流日志/偏移量跟踪系统。（或者不能使用它们，因为如果没有英勇的努力，就无法充分扩展适当的消息传递系统）。
我不久前在服务总线团队的Dan的支持下写了一篇关于这个主题的帖子。希望这能为你澄清


服务总线（消息传递）
对于消息传递，它是一个应用程序告诉一个或多个应用程序做一些事情或给我一些东西

事件中心（事件处理）
另一种选择是，在事件发生时，应用程序会说发生了什么

根据这一点以及选择什么：

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

理解事件和消息的用途之间的区别很重要，因为通信服务通常被设计为处理各自的对象——事件集线器处理事件，服务总线处理消息

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

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

（还有事件网格，它也处理事件，但与事件中心不同。事件中心是为涉及分析的大数据管道而设计的，而事件网格是为事件驱动的反应式编程而设计的。）
我添加了一个答案，重点说明为什么放弃这么多有意义，而不是放弃什么。我认为大多数开发人员在达到分区服务总线主题限制之前都会遇到资金限制。谢谢Sreeram和cacsar。你们都证实了我的想法。