在Azure Fabric可靠的actor之间共享EventHub

Question

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

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

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

我正在考虑创建一个负责将数据推送到EventHub的新actor（通过保持EventHubClient存活）。由于Reliable Actors基于转向的并发模型，我不确定这是一个好主意。如果我“同时”获得10 000个设备推送数据，他们的每个演员都会阻止将消息推送到将消息推送到EventHub的新演员。

此方案的推荐方法是什么？ 谢谢，

Answer 1

您可以在此处使用pub/sub模式（使用KA 8700.00 300.50 Focus 12000.00 340.00 KUGA 23010.00 550.20 ）。 通过将事件发布与事件处理分离，您不必担心基于回合的并发模型。

<强>出版商：

演员只需将publishing个消息发送给BrokerService。

<强>订户

然后您使用一个或多个Stateless Services或（不同）Actors作为事件的订阅者。 他们会按照自己的节奏将它们发送到EventHub。

Event Hub客户端

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

Answer 2

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

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

设备与您的Actors进行通信，Actors依次与Service进行通信（如果您想对消息进行排队，可能是无状态或有状态的，请参阅下文），每个服务管理{{1}可以将消息推送到EventHubClient。

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

Service Fabric Azure-Samples WordCount显示了如何使用不同的分区来使Actors的消息定位到不同的实例（或真正的分区）。

一般提示是不要尝试将Actors用于所有东西（但是对于正确的东西它们很好并且降低了复杂性），Reliable Services模型支持更多的场景和要求，并且可以真正补充你的演员（而不是试图让Actors做一些他们并不是真正设计的东西。

Answer 3

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

事件中心可以自己接收负载。