3

我有一个应用程序，我将设备从物理世界映射到Azure Fabric中的Reliable Actors。每次收到来自设备的消息时，我都想将消息推送到事件中心。

我现在正在做的是为每条消息创建/使用/关闭 EventHubClient 对象。

这是非常低效的（大约需要 1500 毫秒），但它解决了我过去将 EventHubClient 保存在内存中的问题。当我有很多设备时，底层虚拟机会很快耗尽网络连接。

我正在考虑创建一个新的参与者，负责将数据推送到 EventHub（通过保持 EventHubClient 活动）。由于 Reliable Actors 的基于回合的并发模型，我不确定这是一个好主意。如果我有 10 000 个设备“同时”推送数据，它们的每个参与者都会阻止将消息推送到将消息推送到 EventHub 的新参与者。

这种情况下推荐的方法是什么？谢谢，

4

3 回答 3

4

一种方法是创建一个无状态服务，负责将消息推送到 EventHub。每次 Actor 接收到来自设备的消息（顺便问一下，他们如何与 Actor 通信？），Actor 调用无状态服务。反过来，无状态服务将负责为每个服务创建、维护和处置一个 EventHubClient。Reliable Service 在处理传入消息时不会像 Reliable Actor 那样引入相同的“开销”。如果对于您的应用程序而言，消息以与生成消息的顺序完全相同的顺序到达 EventHub 很重要，那么您必须使用有状态服务和可靠队列来执行此操作。(请注意，另一方面，这并不能保证 Actor 能够以与生成消息相同的顺序完成处理传入消息）

instance count然后，您可以通过试验( https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-availability-services ) 来微调解决方案，以确保您有足够的实例处理传入消息的吞吐量。有多少实例大致取决于每个节点的节点数和核心数，尽管其他因素也可能会影响。

简化架构，Actor 与 Services 通信，Service 与 EventHub 设备与您Actors的Actors通信，然后与 通信Service（如果您想将消息排队，可能是无状态或有状态的，见下文），每个服务管理一个EventHubClient可以将消息推送到EventHub.

如果您的集群无法支持此服务的足够高的实例计数（稍微简化：更多实例 = 更高吞吐量），那么您可能需要将其创建为有状态服务并将消息放入可靠队列中服务然后让RunAsync服务按顺序处理队列。这可能会承受性能峰值的压力。

Service Fabric Azure-Samples WordCount展示了如何使用不同的分区来使来自 Actor 的消息针对不同的实例（或真正的分区）。

一般的提示是不要尝试将 Actor 用于所有事情（但对于正确的事情，它们很棒并且可以大大降低复杂性），Reliable Services 模型支持更多的场景和要求，并且可以真正补充您的 Actor（而不是尝试让 Actor 做一些他们并非真正为之设计的事情）。

于 2017-01-06T15:39:15.193 回答
4

您可以在此处使用pub/sub模式（使用BrokerService）。通过将事件发布与事件处理解耦，您无需担心基于回合的并发模型。

出版商：

Actor 通过简单地将消息发布到BrokerService.

订户

然后，您使用一个或多个无状态服务或（不同的）Actor作为事件的订阅者。他们会按照自己的节奏将他们发送到 EventHub。

事件中心客户端

使用这种方法，您可以完全控制EventHubClient实例计数和生命周期。您可以通过简单地添加更多订阅者来提高事件处理能力。

于 2017-01-06T14:46:29.727 回答
0

在我看来，您应该直接从您的演员调用带有内部内存队列的后台线程中的事件中心。您应该聚合消息并使用 SendBatch 来提高性能。

事件中心能够自己接收负载。

于 2017-01-10T14:07:44.917 回答