我正在服务结构中编写一个可靠的参与者,他的工作是监听 Firebase DB 中的更改并根据这些更改运行逻辑。我有它的功能,但不正确。到目前为止,我所做的是使用名为 MonitorRules() 的方法编写 Actor 代码,该方法使用名为 FireSharp 的 C# Firebase 客户端包装器监听 Firebase。 MonitorRules() 看起来像这样:

public async Task MonitorRules()
{
    FireSharp.FirebaseClient client = new FireSharp.FirebaseClient(new FireSharp.Config.FirebaseConfig
    {
        AuthSecret = "My5up3rS3cr3tAu7h53cr37",
        BasePath = "https://myapp.firebaseio.com/"
    });

    await client.OnAsync("businessRules",
        added: (sender, args) =>
        {
            ActorEventSource.Current.ActorMessage(this, $"{args.Data} added at {args.Path}");
        },
        changed: (sender, args) =>
        {
            ActorEventSource.Current.ActorMessage(this, $"{args.OldData} changed to {args.Data} at {args.Path}");
        }
    );
}

然后在服务的 Main() 方法中注册服务后调用 MonitorRules() :
fabricRuntime.RegisterActor<RuleMonitor>();
var serviceUri = new Uri("fabric:/MyApp.RuleEngine/RuleMonitorActorService");
var actorId = ActorId.NewId();
var ruleMonitor = ActorProxy.Create<IRuleMonitor>(actorId, serviceUri);

ruleMonitor.MonitorRules();

这“有效”,因为该服务打开与 Firebase 的连接并响应数据更改。问题在于,由于该服务在五节点集群的三个节点上运行,因此它实际上监听了 3 次并对每条消息进行了 3 次处理。此外,如果有一段时间没有事件,该服务将被停用并且不再响应 Firebase 中的更改。总而言之,我敢肯定,这不是设置此类内容的正确方法,但我找不到有关如何在服务结构中设置此类轮询客户端的任何文档。有没有一种方法可以设置它以坚持 Azure Service Fabric 的精神?

最佳答案

是的,这里有一些事情需要熟悉。第一个是 Actor lifecycle and garbage collection 。 Tl; dr:如果 Actor 在一段时间内未收到客户端请求(通过 ActorProxy)或提醒,则他们将被停用,这是可配置的。

其次,Actors 有 Timers and Reminders 可以用来做周期性的工作,比如轮询数据库的变化。计时器和提醒之间的区别在于,计时器不计为“正在使用”,这意味着仍然可以停用 Actor 以关闭计时器,但提醒计为“正在使用”并且还可以重新激活停用的 Actor 。考虑计时器和提醒的方式是您正在进行轮询,而不是像 FireSharp 那样等待其他事物的回调。

最后,从 Main() 调用 MonitorRules 并不是最好的主意。原因是 Main() 实际上是您的 actor 服务宿主进程的入口点,它只是一个用于托管您的 actor 实例的 EXE。 Main() 中唯一应该发生的事情是注册您的 Actor 类型,而不是其他任何事情。让我们更详细地看看这里发生了什么:

因此,您将actor 服务部署到集群。发生的第一件事是我们在尽可能多的节点上启动主机进程以运行参与者服务(在您的情况下为 3)。我们进入 Main() ,在那里注册 Actor 服务类型,此时,这就是我们应该做的所有事情,因为一旦 Actor 服务注册到主机进程,我们将创建一个实例(或多个实例或副本,如果它是stateful)的服务,然后服务可以开始做它的工作。对于 actor,这意味着当客户端应用程序使用 ActorProxy 进行调用时,actor 服务已准备好开始激活 actor。但是对于 Main() 中的 ActorProxy 调用,您基本上是在说“在主机启动时在该主机所在的每个节点上激活一个actor”,这就是为什么您要听三遍。

考虑到所有这些,首先要问自己的问题是 Actor 是否适合您。如果您只是想要一个简单的地方来使用 FireSharp 客户端监控 Firebase,那么使用 reliable service 可能会更容易,因为您可以将监控放在 RunAsync 中,它会在服务启动时自动启动,这与需要客户端激活的 actor 不同他们。

关于azure-service-fabric - 您如何在服务结构中注册监听器(天蓝色),我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/34515537/

10-13 07:34