Como os Reliable Actors utilizam a plataforma do Service Fabric
Este artigo explica como os Reliable Actors funcionam na plataforma do Azure Service Fabric. Os Reliable Actors são executados numa arquitetura alojada numa implementação de um serviço fiável com estado denominado serviço de ator. O serviço de ator contém todos os componentes necessários para gerir o ciclo de vida e o envio de mensagens para os seus atores:
- O Actor Runtime gere o ciclo de vida, a recolha de lixo e impõe o acesso de thread único.
- Um serviço de ator que remoe o serviço de escuta aceita chamadas de acesso remoto para os atores e envia-os para um despachante para encaminhar para a instância de ator apropriada.
- O Fornecedor de Estado do Ator molda os fornecedores de estado (como o fornecedor de estado Reliable Collections) e fornece um adaptador para a gestão do estado do ator.
Estes componentes em conjunto formam a arquitetura Reliable Actor.
Camadas do serviço
Uma vez que o próprio serviço de ator é um serviço fiável, todos os conceitos de modelo de aplicação, ciclo de vida, empacotamento, implementação, atualização e dimensionamento do Reliable Services aplicam-se da mesma forma aos serviços de ator.
O diagrama anterior mostra a relação entre as arquiteturas de aplicações do Service Fabric e o código de utilizador. Os elementos azuis representam a arquitetura da aplicação Reliable Services, laranja representa a arquitetura Reliable Actor e o verde representa o código do utilizador.
No Reliable Services, o seu serviço herda a StatefulService classe. Esta classe é derivada de StatefulServiceBase (ou StatelessService para serviços sem estado). No Reliable Actors, vai utilizar o serviço de ator. O serviço de ator é uma implementação diferente da StatefulServiceBase classe que implementa o padrão de ator onde os seus atores são executados. Uma vez que o próprio serviço de ator é apenas uma implementação do StatefulServiceBase, pode escrever o seu próprio serviço que deriva e implementar funcionalidades ActorService de nível de serviço da mesma forma que ao herdar StatefulService, como:
- Cópia de segurança e restauro do serviço.
- Funcionalidade partilhada para todos os atores, por exemplo, um disjuntor automático.
- O procedimento remoto chama o próprio serviço de ator e em cada ator individual.
Para obter mais informações, veja Implementar funcionalidades ao nível do serviço de ator.
Modelo de aplicação
Os serviços de ator são Reliable Services, pelo que o modelo de aplicação é o mesmo. No entanto, as ferramentas de compilação de arquitetura de ator geram alguns dos ficheiros do modelo de aplicação automaticamente.
Manifesto de serviço
As ferramentas de compilação de arquitetura de ator geram automaticamente os conteúdos do ficheiro ServiceManifest.xml do serviço de ator. Este ficheiro inclui:
- Tipo de serviço de ator. O nome do tipo é gerado com base no nome do projeto do ator. Com base no atributo de persistência no ator, o sinalizador HasPersistedState também está definido em conformidade.
- Pacote de código.
- Pacote de configuração.
- Recursos e pontos finais.
Manifesto de aplicação
As ferramentas de compilação de arquitetura de ator criam automaticamente uma definição de serviço predefinida para o seu serviço de ator. As ferramentas de compilação povoam as propriedades de serviço predefinidas:
- A contagem de conjuntos de réplicas é determinada pelo atributo de persistência no ator. Sempre que o atributo de persistência no ator for alterado, a contagem de conjuntos de réplicas na definição de serviço predefinida é reposta em conformidade.
- O esquema e o intervalo de partições estão definidos como Uniform Int64 com o intervalo de chaves Int64 completo.
Conceitos de partição do Service Fabric para atores
Os serviços de ator são serviços com estado particionado. Cada partição de um serviço de ator contém um conjunto de atores. As partições de serviço são distribuídas automaticamente por vários nós no Service Fabric. Como resultado, as instâncias de ator são distribuídas.
Os Reliable Services podem ser criados com diferentes esquemas de partição e intervalos de chaves de partição. O serviço de ator utiliza o esquema de criação de partições Int64 com o intervalo de chaves int64 completo para mapear atores a partições.
ID do Ator
Cada ator criado no serviço tem um ID exclusivo associado ao mesmo, representado pela ActorId classe. ActorId é um valor de ID opaco que pode ser utilizado para distribuição uniforme de atores nas partições de serviço ao gerar IDs aleatórios:
ActorProxy.Create<IMyActor>(ActorId.CreateRandom());
ActorProxyBase.create<MyActor>(MyActor.class, ActorId.newId());
Cada ActorId é um hash para um Int64. É por isso que o serviço de ator tem de utilizar um esquema de criação de partições Int64 com o intervalo de chaves Int64 completo. No entanto, os valores de ID personalizados podem ser utilizados para um ActorID, incluindo GUIDs/UUIDs, cadeias e Int64s.
ActorProxy.Create<IMyActor>(new ActorId(Guid.NewGuid()));
ActorProxy.Create<IMyActor>(new ActorId("myActorId"));
ActorProxy.Create<IMyActor>(new ActorId(1234));
ActorProxyBase.create(MyActor.class, new ActorId(UUID.randomUUID()));
ActorProxyBase.create(MyActor.class, new ActorId("myActorId"));
ActorProxyBase.create(MyActor.class, new ActorId(1234));
Quando utiliza GUIDs/UUIDs e cadeias, é criado um hash dos valores num Int64. No entanto, quando indica explicitamente um Int64 a um ActorId, o Int64 mapeará diretamente para uma partição sem hashing adicional. Pode utilizar esta técnica para controlar em que partição os atores são colocados.