我一直在学习事件中心，只是想确认或更正我对事件中心的看法？我习惯于利用 Azure 服务总线队列和主题为我提供的正常企业消息传递解决方案的重试、有害消息、至少一次传递等。似乎事件中心旨在为非常高的规模提供不同的工具，在这种情况下，您必须放弃一些更多的“企业”功能才能获得更高的规模。
我是否正确地考虑了这一点？我还需要考虑其他细节吗？我意识到事件中心和主题可能存在一些功能重叠，但我只是想弄清楚如何考虑使用事件中心。
【问题讨论】：
标签： azure azureservicebus azure-eventhub
如果您可以选择，几乎总是更容易围绕完整的企业发布订阅消息系统编写系统，您可以在其中将单个事件标记为已被使用、重试消息以及几乎所有其他精彩功能。如果您已经接受对消息通道进行分区（Azure 服务总线主题似乎支持），那么原则上您可以将功能更全的消息传递系统扩展到您需要的程度。问题是要付出什么代价？
Azure 服务总线主题的大规模成本约为 $0.20 per Million 消息，Amazon SQS（有点相似）列表 $0.50 per Million。如果您自己托管它，您可能需要在分区时设置很多 RabbitMQ 服务器甚至多个集群。
Azure 事件中心的成本为 $0.028 per Million 加上每个吞吐量单位的金额，same 用于 Amazon Kinesis。 Apache Kafka 在 3 台机器上以每秒 200 万的速度运行 benchmarked
假设每秒 20,000 个事件持续，某些 Azure 主题和 Azure 事件中心之间的差异在全职开发人员的工资范围内。以每秒 200 万的速度持续（这需要联系 MS），差额接近 100 万美元/月。
当您不需要完整消息传递系统的所有有用功能，或者当您不需要它们来支付大约 10 倍的溢价时，基本上可以使用分区流|日志/偏移跟踪系统。 （或者不能使用它们，因为如果没有英勇的努力，您就无法充分扩展适当的消息传递系统）。
【讨论】：
不久前，在服务总线团队的 Dan 的支持下，我写了一篇关于此主题的帖子。希望这应该为您澄清
http://microsoftintegration.guru/2015/03/03/azure-event-hubs-vs-azure-messaging/
对于消息传递，它是关于一个应用程序告诉一个或多个应用程序做某事或给我某事。
另一种选择是，在 eventing 中，应用程序说有些事情已经发生了。
【讨论】：
正确！！
EventHubs 和 Topics 之间的根本区别在于 - TOPICS 提供 每条消息语义 - 而 EventHubs - 提供 Stream Semantics - 意味着，不应期待任何 @987654322 @ 带有 EventHubs 的功能/语义。
任何提供per-message 功能的中间层都带有processing overhead (the tax)！！
例如：每条消息重复检测，每条消息接收确认（主题有一个 Message.Complete 以确认收到的消息） - 都是主题功能。 EventHubs 缩小功能集以提供更好的低延迟/高吞吐量解决方案。
要可视化诸如至少一次交付（每个消息在 EventHubs 中不可用）之类的特性，是将其转换为流语义 - 读取到给定 eventHub 分区和检查点中的一个点，并让您的应用程序使用这些事件处理 at-least-once 传递。
【讨论】：
根据这个MS Learn article和"Choose between Azure messaging services"上的选择：
“Azure 事件中心专为高流量分析类型的事件而设计。Azure 服务总线和存储队列用于消息，可用于绑定任何应用程序工作流的核心部分。”
了解事件和消息的用途之间的区别很重要，因为通信服务通常设计为处理它们各自的对象——事件中心处理事件，服务总线处理消息。
一个事件会触发发生某事的通知。它比消息“更轻松”——它包含有关发生的事情的信息，但 没有 有触发事件本身的数据。例如，某个事件可能会通知您文件上传并包含有关文件的信息，但不是文件本身。事件通常用于广播通信/扇出工作流，即当您为每个发布者拥有大量订阅者时。发布者对消费者如何处理事件没有期望。
消息包含触发消息管道的数据。与事件不同，发布者对消费者如何处理消息有期望。例如，发布者发送一条包含服务生成的原始数据的消息，并希望消费者存储该数据并在完成后发回响应。
（还有事件网格，它也处理事件，但与事件中心不同。事件中心是为涉及分析的大数据管道设计的，而事件网格是为事件驱动的反应式编程设计的。）
【讨论】：