Modelo de alojamento do Azure Service Fabric

Este artigo fornece uma descrição geral dos modelos de alojamento de aplicações fornecidos pelo Azure Service Fabric e descreve as diferenças entre os modelos Processo Partilhado e Processo Exclusivo . Descreve o aspeto de uma aplicação implementada num nó do Service Fabric e a relação entre réplicas (ou instâncias) do serviço e o processo de anfitrião de serviços.

Antes de continuar, certifique-se de que compreende os vários conceitos e relações explicados em Modelar uma aplicação no Service Fabric.

Nota

Neste artigo, a menos que seja explicitamente mencionado como algo diferente:

• A réplica refere-se a uma réplica de um serviço com estado e a uma instância de um serviço sem estado.
• O CodePackage é tratado como equivalente a um processo ServiceHost que regista um ServiceType e aloja réplicas de serviços desse ServiceType.

Para compreender o modelo de alojamento, vejamos um exemplo. Digamos que temos um ApplicationType "MyAppType", que tem um ServiceType "MyServiceType". "MyServiceType" é fornecido pelo ServicePackage "MyServicePackage", que tem um CodePackage "MyCodePackage". "MyCodePackage" regista o ServiceType "MyServiceType" quando é executado.

Digamos que temos um cluster de três nós e criamos um recurso de infraestrutura da aplicação:/App1 do tipo "MyAppType". Neste recurso de infraestrutura da aplicação:/App1, criamos um service fabric:/App1/ServiceA do tipo "MyServiceType". Este serviço tem duas partições (por exemplo, P1 e P2) e três réplicas por partição. O diagrama seguinte mostra a vista desta aplicação à medida que acaba implementada num nó.

O Service Fabric ativou "MyServicePackage", que iniciou "MyCodePackage", que está a alojar réplicas de ambas as partições. Todos os nós no cluster têm a mesma vista, porque escolhemos o número de réplicas por partição para ser igual ao número de nós no cluster. Vamos criar outro serviço, fabric:/App1/ServiceB, nos recursos de infraestrutura da aplicação :/App1. Este serviço tem uma partição (por exemplo, P3) e três réplicas por partição. O diagrama seguinte mostra a nova vista no nó:

O Service Fabric colocou a nova réplica para a partição P3 do service fabric:/App1/ServiceB na ativação existente de "MyServicePackage". Agora. vamos criar outro recurso de infraestrutura da aplicação:/App2 do tipo "MyAppType". Dentro de recursos de infraestrutura:/App2, crie um service fabric:/App2/ServiceA. Este serviço tem duas partições (P4 e P5) e três réplicas por partição. O diagrama seguinte mostra a nova vista de nó:

O Service Fabric ativa uma nova cópia de "MyServicePackage", que inicia uma nova cópia de "MyCodePackage". As réplicas de ambas as partições do service fabric:/App2/ServiceA (P4 e P5) são colocadas nesta nova cópia "MyCodePackage".

Modelo de Processo Partilhado

A secção anterior descreve o modelo de alojamento predefinido fornecido pelo Service Fabric, referido como o modelo de Processo Partilhado. Neste modelo, para uma determinada aplicação, apenas uma cópia de um determinado ServicePackage é ativada num nó (que inicia todas as CodePackages contidas no mesmo). Todas as réplicas de todos os serviços de um determinado ServiceType são colocadas no CodePackage que regista esse ServiceType. Por outras palavras, todas as réplicas de todos os serviços num nó de um determinado ServiceType partilham o mesmo processo.

Modelo de Processo Exclusivo

O outro modelo de alojamento fornecido pelo Service Fabric é o modelo processo exclusivo. Neste modelo, num determinado nó, cada réplica vive no seu próprio processo dedicado. O Service Fabric ativa uma nova cópia do ServicePackage (que inicia todas as CodePackages contidas na mesma). As réplicas são colocadas no CodePackage que registou o ServiceType do serviço ao qual pertence a réplica.

Se estiver a utilizar a versão 5.6 ou posterior do Service Fabric, pode escolher o modelo Processo Exclusivo no momento em que criar um serviço (utilizando o PowerShell, REST ou FabricClient). Especifique ServicePackageActivationMode como "ExclusiveProcess".

PS C:\>New-ServiceFabricService -ApplicationName "fabric:/App1" -ServiceName "fabric:/App1/ServiceA" -ServiceTypeName "MyServiceType" -Stateless -PartitionSchemeSingleton -InstanceCount -1 -ServicePackageActivationMode "ExclusiveProcess"

var serviceDescription = new StatelessServiceDescription
{
    ApplicationName = new Uri("fabric:/App1"),
    ServiceName = new Uri("fabric:/App1/ServiceA"),
    ServiceTypeName = "MyServiceType",
    PartitionSchemeDescription = new SingletonPartitionSchemeDescription(),
    InstanceCount = -1,
    ServicePackageActivationMode = ServicePackageActivationMode.ExclusiveProcess
};

var fabricClient = new FabricClient(clusterEndpoints);
await fabricClient.ServiceManager.CreateServiceAsync(serviceDescription);

Se tiver um serviço predefinido no manifesto da aplicação, pode escolher o modelo Processo Exclusivo ao especificar o atributo ServicePackageActivationMode :

<DefaultServices>
  <Service Name="MyService" ServicePackageActivationMode="ExclusiveProcess">
    <StatelessService ServiceTypeName="MyServiceType" InstanceCount="1">
      <SingletonPartition/>
    </StatelessService>
  </Service>
</DefaultServices>

Agora, vamos criar outro serviço, fabric:/App1/ServiceC, nos recursos de infraestrutura da aplicação:/App1. Este serviço tem duas partições (por exemplo, P6 e P7) e três réplicas por partição. Defina ServicePackageActivationMode como "ExclusiveProcess". O diagrama seguinte mostra uma nova vista no nó:

Como pode ver, o Service Fabric ativou duas novas cópias de "MyServicePackage" (uma para cada réplica da partição P6 e P7). O Service Fabric colocou cada réplica na respetiva cópia dedicada do CodePackage. Quando utiliza o modelo Processo Exclusivo, para uma determinada aplicação, várias cópias de um determinado ServicePackage podem estar ativas num nó. No exemplo anterior, três cópias de "MyServicePackage" estão ativas para recursos de infraestrutura:/App1. Cada uma destas cópias ativas de "MyServicePackage" tem um ServicePackageActivationId associado ao mesmo. Este ID identifica essa cópia nos recursos de infraestrutura da aplicação:/App1.

Quando utiliza apenas o modelo de Processo Partilhado para uma aplicação, existe apenas uma cópia ativa do ServicePackage num nó. O ServicePackageActivationId para esta ativação do ServicePackage é uma cadeia vazia. Este é o caso, por exemplo, com recursos de infraestrutura:/App2.

Nota

• O modelo de alojamento processo partilhado corresponde a ServicePackageActivationMode é igual a SharedProcess. Este é o modelo de alojamento predefinido e o ServicePackageActivationMode não precisa de ser especificado no momento da criação do serviço.

• O modelo de alojamento Processo Exclusivo corresponde a ServicePackageActivationMode é igual a ExclusiveProcess. Para utilizar esta definição, deve especificá-la explicitamente no momento da criação do serviço.

• Para ver o modelo de alojamento de um serviço, consulte a descrição do serviço e veja o valor de ServicePackageActivationMode.

Trabalhar com um pacote de serviço implementado

Uma cópia ativa de um ServicePackage num nó é referida como um pacote de serviço implementado. Quando utiliza o modelo processo exclusivo para criar serviços, para uma determinada aplicação, poderão existir vários pacotes de serviço implementados para o mesmo ServicePackage. Se estiver a executar operações específicas de um pacote de serviço implementado, deve fornecer ServicePackageActivationId para identificar um pacote de serviço implementado específico. Por exemplo, indique o ID se estiver a comunicar o estado de funcionamento de um pacote de serviço implementado ou a reiniciar o pacote de código de um pacote de serviço implementado.

Pode descobrir o ServicePackageActivationId de um pacote de serviço implementado ao consultar a lista de pacotes de serviço implementados num nó. Quando estiver a consultar os tipos de serviço implementados, as réplicas implementadas e os pacotes de código implementados num nó, o resultado da consulta também contém o ServicePackageActivationId do pacote de serviço implementado principal.

Nota

• No modelo de alojamento processo partilhado, num determinado nó, para uma determinada aplicação, apenas é ativada uma cópia de um ServicePackage . Tem um ServicePackageActivationId igual a uma cadeia vazia e não precisa de ser especificado durante a execução de operações relacionadas com o pacote de serviço implementado.

• No modelo de alojamento Processo Exclusivo, num determinado nó, para uma determinada aplicação, uma ou mais cópias de um ServicePackage podem estar ativas. Cada ativação tem um ServicePackageActivationIdnão vazio, especificado durante a execução de operações relacionadas com o pacote de serviço implementado.

• Se ServicePackageActivationId for omitido, a predefinição será a cadeia vazia. Se estiver presente um pacote de serviço implementado que foi ativado no modelo de Processo Partilhado, a operação será efetuada no mesmo. Caso contrário, a operação falha.

• Não consulte uma vez e coloque em cache o ServicePackageActivationId. O ID é gerado dinamicamente e pode ser alterado por vários motivos. Antes de executar uma operação que necessite de ServicePackageActivationId, deve consultar primeiro a lista de pacotes de serviço implementados num nó. Em seguida, utilize o ServicePackageActivationId do resultado da consulta para efetuar a operação original.

Aplicações executáveis e de contentores convidados

O Service Fabric trata as aplicações executáveis e de contentores convidados como serviços sem estado, que são autónomos. Não existe nenhum runtime do Service Fabric no ServiceHost (um processo ou contentor). Uma vez que estes serviços são autónomos, o número de réplicas por ServiceHost não é aplicável a estes serviços. A configuração mais comum utilizada com estes serviços é a partição única, com InstanceCount igual a -1 (uma cópia do código de serviço em execução em cada nó do cluster).

O ServicePackageActivationMode predefinido para estes serviços é SharedProcess, caso em que o Service Fabric ativa apenas uma cópia do ServicePackage num nó para uma determinada aplicação. Isto significa que apenas uma cópia do código de serviço irá executar um nó. Se quiser executar várias cópias do código de serviço num nó, especifique ServicePackageActivationMode como ExclusiveProcess no momento da criação do serviço. Por exemplo, pode fazê-lo quando cria vários serviços (Service1 para ServiceN) de ServiceType (especificado no ServiceManifest) ou quando o seu serviço é multi-particionado.

Alterar o modelo de alojamento de um serviço existente

Neste momento, não pode alterar o modelo de alojamento de um serviço existente de Processo Partilhado para Processo Exclusivo (ou vice-versa).

Escolher entre os modelos de alojamento

Deve avaliar qual o modelo de alojamento que melhor se adequa aos seus requisitos. O modelo processo partilhado utiliza melhor os recursos do sistema operativo, uma vez que são gerados menos processos e várias réplicas no mesmo processo podem partilhar portas. No entanto, se uma das réplicas tiver um erro em que precisa de derrubar o anfitrião do serviço, isso afetará todas as outras réplicas no mesmo processo.

O modelo Processo Exclusivo proporciona um melhor isolamento, com cada réplica no seu próprio processo. Se uma das réplicas tiver um erro, não afetará outras réplicas. Este modelo é útil para casos em que a partilha de portas não é suportada pelo protocolo de comunicação. Facilita a capacidade de aplicar a governação de recursos ao nível da réplica. No entanto, o Processo Exclusivo consome mais recursos do sistema operativo, uma vez que gera um processo para cada réplica no nó.

Considerações sobre o modelo de processo exclusivo e o modelo de aplicação

Para a maioria das aplicações, pode modelar a sua aplicação no Service Fabric ao manter um ServiceType por ServicePackage.

Para determinados casos, o Service Fabric também permite mais do que um ServiceType por ServicePackage (e um CodePackage pode registar mais do que um ServiceType). Seguem-se alguns dos cenários em que estas configurações podem ser úteis:

• Quer otimizar a utilização de recursos ao gerar menos processos e ter uma maior densidade de réplica por processo.
• As réplicas de diferentes ServiceTypes precisam de partilhar alguns dados comuns que têm um elevado custo de inicialização ou memória.
• Tem uma oferta de serviço gratuita e quer limitar a utilização de recursos ao colocar todas as réplicas do serviço no mesmo processo.

O modelo de alojamento processo exclusivo não é coerente com um modelo de aplicação com vários ServiceTypes por ServicePackage. Isto deve-se ao facto de vários ServiceTypes por ServicePackage terem sido concebidos para obter uma maior partilha de recursos entre réplicas e ativar uma maior densidade de réplica por processo. O modelo Processo Exclusivo foi concebido para obter resultados diferentes.

Considere o caso de vários ServiceTypes por ServicePackage, com um CodePackage diferente a registar cada ServiceType. Digamos que temos um ServicePackage "MultiTypeServicePackage", que tem duas CodePackages:

• "MyCodePackageA", que regista o ServiceType "MyServiceTypeA".
• "MyCodePackageB", que regista o ServiceType "MyServiceTypeB".

Agora, digamos que criamos uma aplicação, recursos de infraestrutura:/SpecialApp. Dentro de recursos de infraestrutura:/SpecialApp, criamos dois serviços seguintes com o modelo Processo Exclusivo:

• Service fabric:/SpecialApp/ServiceA do tipo "MyServiceTypeA", com duas partições (por exemplo, P1 e P2) e três réplicas por partição.
• Service fabric:/SpecialApp/ServiceB do tipo "MyServiceTypeB", com duas partições (P3 e P4) e três réplicas por partição.

Num determinado nó, ambos os serviços têm duas réplicas cada. Uma vez que utilizámos o modelo Processo Exclusivo para criar os serviços, o Service Fabric ativa uma nova cópia de "MyServicePackage" para cada réplica. Cada ativação de "MultiTypeServicePackage" inicia uma cópia de "MyCodePackageA" e "MyCodePackageB". No entanto, apenas um de "MyCodePackageA" ou "MyCodePackageB" aloja a réplica para a qual "MultiTypeServicePackage" foi ativada. O diagrama seguinte mostra a vista de nó:

Na ativação de "MultiTypeServicePackage" para a réplica da partição P1 do service fabric:/SpecialApp/ServiceA, "MyCodePackageA" está a alojar a réplica. "MyCodePackageB" está em execução. Da mesma forma, na ativação de "MultiTypeServicePackage" para a réplica da partição P3 do service fabric:/SpecialApp/ServiceB, "MyCodePackageB" está a alojar a réplica. "MyCodePackageA" está em execução. Assim, quanto maior for o número de CodePackages (registando diferentes ServiceTypes) por ServicePackage, maior será a utilização de recursos redundante.

No entanto, se criarmos os recursos de infraestrutura dos serviços:/SpecialApp/ServiceA e recursos de infraestrutura:/SpecialApp/ServiceB com o modelo processo partilhado, o Service Fabric ativa apenas uma cópia de "MultiTypeServicePackage" para os recursos de infraestrutura da aplicação:/SpecialApp. "MyCodePackageA" aloja todas as réplicas do service fabric:/SpecialApp/ServiceA. "MyCodePackageB" aloja todas as réplicas do service fabric:/SpecialApp/ServiceB. O diagrama seguinte mostra a vista de nó nesta definição:

No exemplo anterior, poderá pensar que, se "MyCodePackageA" registar "MyServiceTypeA" e "MyServiceTypeB" e não existir "MyCodePackageB", não existe nenhum CodePackage redundante em execução. Apesar de estar correto, este modelo de aplicação não está alinhado com o modelo de alojamento processo exclusivo. Se o objetivo for colocar cada réplica no seu próprio processo dedicado, não precisa de registar ambos os ServiceTypes a partir do mesmo CodePackage. Em vez disso, basta colocar cada ServiceType no seu próprio ServicePackage.

Reliable Services e Subprocessos de forking de ator

O Service Fabric não suporta serviços fiáveis e, posteriormente, subprocessos de forking de atores fiáveis. Um exemplo do motivo pelo qual não é suportado é o CodePackageActivationContext não pode ser utilizado para registar um subprocesso não suportado e os tokens de cancelamento são enviados apenas para processos registados; resultando em todos os tipos de problemas, como falhas de atualização, quando os subprocessos não fecham depois de o processo principal ter recebido um token de cancelamento.

Passos seguintes

Empacote uma aplicação e prepare-a para implementação.

Implementar e remover aplicações. Este artigo descreve como utilizar o PowerShell para gerir instâncias de aplicações.