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