How can I host multiple Service Fabric Actor Types inside a single service?

Question

I've read here that is should be possible to host tightly coupled ActorTypes within the same service but I can't seem to find any documentation on exactly how to do it.

I thought it might I need to create my own instance of the ActorService and pass the context into it but I don't seen to be able to find the right API's from the document.

Does anyone have an example they could share ?

Answer 1

Sort of but not really. You can have multiple actor types in the same application. It looks like they're in the same service in Visual Studio, but they're actually deployed as separate services. Bear with me for a minute if you will..

So you can register multiple actors like this:

internal static class Program
{
    private static void Main()
    {
        ActorRuntime.RegisterActorAsync<Actor1>().GetAwaiter().GetResult();
        ActorRuntime.RegisterActorAsync<Actor2>().GetAwaiter().GetResult();

        Thread.Sleep(Timeout.Infinite);
    }
}

Great, I have multiple actor types. This works and you can just do that.

But you want know how it works! Well, that's just a simplified version of this:

internal static class Program
{
    private static void Main()
    {
        ActorRuntime.RegisterActorAsync<Actor1>(
            (context, actorType) => new ActorService(context, actorType, () => new Actor1())).GetAwaiter().GetResult();

        ActorRuntime.RegisterActorAsync<Actor2>(
            (context, actorType) => new ActorService(context, actorType, () => new Actor2())).GetAwaiter().GetResult();

        Thread.Sleep(Timeout.Infinite);
    }
}

This is more telling of what's actually happening, because you see here I now have two services. So what's going on?

The secret is in the ActorRuntime. It does a little more work than ServiceRuntime (where you register Reliable Services normally). The Actor framework build process does some magic on your behalf to configure a service type and a default service instance inside your application for each actor type. You can see this in your ApplicationManifest.xml, where the build tools sets up default services for you:

<DefaultServices>
  <Service Name="Actor1ActorService" GeneratedIdRef="3262c188-3eee-44c5-9d1e-d2c2a2685f89|Persisted">
     <StatefulService ServiceTypeName="Actor1ActorServiceType" TargetReplicaSetSize="[Actor1ActorService_TargetReplicaSetSize]" MinReplicaSetSize="[Actor1ActorService_MinReplicaSetSize]">
        <UniformInt64Partition PartitionCount="[Actor1ActorService_PartitionCount]" LowKey="-9223372036854775808" HighKey="9223372036854775807" />
     </StatefulService>
  </Service>
  <Service Name="Actor2ActorService" GeneratedIdRef="1bc66d2c-0479-4bb2-a9aa-3254030506f1|Persisted">
     <StatefulService ServiceTypeName="Actor2ActorServiceType" TargetReplicaSetSize="[Actor2ActorService_TargetReplicaSetSize]" MinReplicaSetSize="[Actor2ActorService_MinReplicaSetSize]">
        <UniformInt64Partition PartitionCount="[Actor2ActorService_PartitionCount]" LowKey="-9223372036854775808" HighKey="9223372036854775807" />
     </StatefulService>
  </Service>

As an example, if I take the two actor types I have defined above and deploy that application, here is the result:

These are actually separate service instances in the application, and each is of a different service type, all of which is automatically generated for you:

And of course, because they're different service instances, they'll be distribute across the cluster as you would normally expect:

I'll go update that doc.