我正在开发一个服务结构应用程序，想要从此应用程序发布一些事件，并在另一个应用程序中订阅或处理这些发布事件。
我尝试过 EventGrid 概念，并观察到发布和处理事件时存在延迟。所以，现在我正在寻找其他替代方案，例如 EventHub 或队列等。
如果有人已经使用过 EventGrid、EventHud 或 Queues 等，请建议当我们处理更多事件时，哪一个会提供更好的性能。
设计方法
我们已将表从 SQL 服务迁移到 Service Fabric。 SQL Service 中有一个视图，我们计划将其实现为 Service Fabric 中的服务。
实现逻辑如下。
- 表 1 实现了服务，我们将每个 CRUD 操作的事件发布到 EventGrid/EventHud。
- 表 2 实现了服务，我们将每个 CRUD 操作的事件发布到 EventGrid/EventHud。
- 我们创建了一个视图服务，它监听事件，当任何事件发送到 EventGrid/EventHud 时，它将执行所需的计算并存储在 ViewService 中（这是一个后台作业）
我们正在寻找一种能够提供更高性能的消息传递服务。
你见过吗这个比较 https://learn.microsoft.com/en-us/azure/event-grid/compare-messaging-services and this one https://azure.microsoft.com/en-us/blog/events-data-points-and-messages-choosing-the-right-azure-messaging-service-for-your-data/?
不管怎样，您能澄清一下您在吞吐量和性能方面的要求吗？这取决于很多因素，包括但不限于消息大小和消息数量。
使用事件网格和事件中心后，我认为事件中心每秒可以很好地处理许多消息，例如来自物联网设备的数据流，但下游处理的性能可能是一个瓶颈。您必须非常快速地处理它们才能接收新事件。然后是分区和消费者组，它们可以帮助平衡负载，并且对于相同的数据有不同的处理器，但具有不同的数据流视图。 （一种快速处理器用于实时显示传感器数据，另一种较慢处理器用于存储数据以供以后分析）
如果您正在谈论由应用程序生成的一些事件，这些事件会触发其他应用程序开始基于这些事件执行某些工作，那么事件网格非常适合。我在接收这些事件方面并没有经历太多延迟。
但最重要的是，我认为所有服务（事件网格、事件中心、服务总线等）都支持不同的用例，这应该是您的第一个决策点。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
