我有一个应用程序，可以将设备从物理世界映射到 Reliable Actors在 Azure Fabric 。每次我从设备收到消息时，我都想将消息推送到事件中心。
我现在正在做的是为每条消息创建/使用/关闭 EventHubClient 对象。
这效率非常低(大约需要 1500 毫秒)，但它解决了我过去将 EventHubClient 保留在内存中的问题。当我有很多设备时，底层虚拟机可能很快就会耗尽网络连接。
我正在考虑创建一个新的参与者，负责将数据推送到 EventHub(通过保持 EventHubClient 处于事件状态)。由于 Reliable Actors 的基于转向的并发模型，我不确定这是一个好主意。如果我让 10000 个设备“同时”推送数据，那么它们的每个 actor 都会阻止将消息推送到将消息推送到 EventHub 的新 actor。
对于这种情况，推荐的方法是什么？ 谢谢，
最佳答案
一种方法是创建一个无状态服务，负责将消息推送到 EventHub。每次 Actor 从设备接收到消息时(顺便问一下，它们如何与 Actor 通信？)，Actor 就会调用无状态服务。无状态服务反过来将负责为每个服务创建、维护和处置一个 EventHubClient。在处理传入消息时，Reliable Service 不会像 Reliable Actor 那样引入相同的“开销”。如果消息以与生成消息的顺序严格相同的顺序到达 EventHub 对您的应用程序很重要，那么您必须使用有状态服务和可靠队列来完成此操作。 (注意，另一方面，不能保证 Actor 能够按照传入消息的生成顺序完成处理)
然后，您可以通过试验实例计数 ( https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-availability-services ) 来微调解决方案，以确保您有足够的实例来处理传入消息的吞吐量。多少个实例大致由节点数和每个节点的核心数决定，尽管其他因素也可能会产生影响。
设备与您的 Actors 通信，Actors 又与 Service 通信(如果您想要对消息进行排队，则可以是无状态或有状态，请参见下文)，每个 Service 管理一个 EventHubClient，它可以将消息推送到 EventHub。
如果您的集群无法支持该服务足够高的实例数(稍微简化一下:更多实例 = 更高的吞吐量)，那么您可能需要将其创建为有状态服务，并将消息放入可靠服务中在服务中排队，然后让服务按顺序处理队列的 RunAsync 。这可以承受性能峰值的压力。
Service Fabric Azure-Samples WordCount显示如何使用不同的分区来使来自 Actor 的消息针对不同的实例(或真正的分区)。
一般建议是不要尝试在所有事情上都使用 Actor(但对于正确的事情，它们非常有用，并且会大大降低复杂性)，Reliable Services 模型支持更多场景和要求，并且可以真正补充您的 Actor(而不是试图让 Actor 做一些他们并非真正设计的目的的事情)。
关于azure - 在 Azure Fabric 可靠参与者之间共享 EventHub，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/41505494/