Modelo de hospedagem do Azure Service Fabric

Este artigo fornece uma visão geral dos modelos de hospedagem de aplicativos fornecidos pelo Azure Service Fabric e descreve as diferenças entre os modelos Processo Compartilhado e Processo Exclusivo . Ele descreve a aparência de um aplicativo implantado em um nó do Service Fabric e a relação entre réplicas (ou instâncias) do serviço e o processo do host de serviço.

Antes de prosseguir, certifique-se de entender os vários conceitos e relacionamentos explicados em Modelar um aplicativo no Service Fabric.

Nota

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

• Réplica refere-se a uma réplica de um serviço stateful e uma instância de um serviço stateless.
• CodePackage é tratado como equivalente a um processo ServiceHost que registra um ServiceType e hospeda réplicas de serviços desse ServiceType.

Para entender o modelo de hospedagem, vamos dar um exemplo. Digamos que temos um ApplicationType 'MyAppType', que tem um ServiceType 'MyServiceType'. 'MyServiceType' é fornecido pelo ServicePackage 'MyServicePackage', que tem um CodePackage 'MyCodePackage'. 'MyCodePackage' registra ServiceType 'MyServiceType' quando é executado.

Digamos que temos um cluster de três nós e criamos uma malha de aplicativo:/App1 do tipo 'MyAppType'. Dentro desta malha de aplicativo :/App1, criamos uma malha de serviço :/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 a seguir mostra a exibição deste aplicativo à medida que ele termina implantado em um nó.

O Service Fabric ativou 'MyServicePackage', que iniciou 'MyCodePackage', que está hospedando réplicas de ambas as partições. Todos os nós no cluster têm a mesma exibição, 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, na malha do aplicativo :/App1. Este serviço tem uma partição (por exemplo, P3) e três réplicas por partição. O diagrama a seguir mostra a nova exibição 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 outra malha de aplicativo :/App2 do tipo 'MyAppType'. Dentro da malha:/App2, crie uma malha de serviço :/App2/ServiceA. Este serviço tem duas partições (P4 e P5) e três réplicas por partição. O diagrama a seguir mostra a nova exibição 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 da malha de serviço :/App2/ServiceA (P4 e P5) são colocadas nesta nova cópia 'MyCodePackage'.

Modelo de processo compartilhado

A seção anterior descreve o modelo de hospedagem padrão fornecido pelo Service Fabric, conhecido como modelo de Processo Compartilhado. Neste modelo, para um determinado aplicativo, apenas uma cópia de um determinado ServicePackage é ativada em um nó (que inicia todos os CodePackages contidos nele). Todas as réplicas de todos os serviços de um determinado ServiceType são colocadas no CodePackage que registra esse ServiceType. Em outras palavras, todas as réplicas de todos os serviços em um nó de um determinado ServiceType compartilham o mesmo processo.

Modelo de processo exclusivo

O outro modelo de hospedagem fornecido pelo Service Fabric é o modelo de Processo Exclusivo. Neste modelo, em um determinado nó, cada réplica vive em seu próprio processo dedicado. O Service Fabric ativa uma nova cópia do ServicePackage (que inicia todos os CodePackages contidos nele). As réplicas são colocadas no CodePackage que registrou o ServiceType do serviço ao qual a réplica pertence.

Se você estiver usando o Service Fabric versão 5.6 ou posterior, poderá escolher o modelo de Processo Exclusivo no momento da criação de um serviço (usando 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 você tiver um serviço padrão no manifesto do aplicativo, poderá escolher o modelo Processo Exclusivo especificando 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, em application fabric:/App1. Este serviço tem duas partições (por exemplo, P6 e P7) e três réplicas por partição. Você define ServicePackageActivationMode como 'ExclusiveProcess'. O diagrama a seguir mostra uma nova exibição no nó:

Como você 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 em sua cópia dedicada do CodePackage. Quando você usa o modelo de processo exclusivo, para um determinado aplicativo, várias cópias de um determinado ServicePackage podem estar ativas em um nó. No exemplo anterior, três cópias de 'MyServicePackage' estão ativas para fabric:/App1. Cada uma dessas cópias ativas de 'MyServicePackage' tem um ServicePackageActivationId associado a ele. Esse ID identifica essa cópia na malha do aplicativo :/App1.

Quando você usa apenas o modelo de Processo Compartilhado para um aplicativo, há apenas uma cópia ativa do ServicePackage em um nó. O ServicePackageActivationId para esta ativação de ServicePackage é uma cadeia de caracteres vazia. É o caso, por exemplo, do fabric:/App2.

Nota

• O modelo de hospedagem de Processo Compartilhado corresponde a ServicePackageActivationMode igual a SharedProcess. Este é o modelo de hospedagem padrão, e ServicePackageActivationMode não precisa ser especificado no momento da criação do serviço.

• O modelo de hospedagem Exclusive Process corresponde a ServicePackageActivationMode igual a ExclusiveProcess. Para usar essa configuração, você deve especificá-la explicitamente no momento da criação do serviço.

• Para exibir o modelo de hospedagem de um serviço, consulte a descrição do serviço e examine o valor de ServicePackageActivationMode.

Trabalhar com um pacote de serviço implantado

Uma cópia ativa de um ServicePackage em um nó é chamada de pacote de serviço implantado. Quando você usa o modelo Processo Exclusivo para criar serviços, para um determinado aplicativo, pode haver vários pacotes de serviço implantados para o mesmo ServicePackage. Se você estiver executando operações específicas para um pacote de serviço implantado, deverá fornecer ServicePackageActivationId para identificar um pacote de serviço implantado específico. Por exemplo, forneça a ID se você estiver relatando a integridade de um pacote de serviço implantado ou reiniciando o pacote de código de um pacote de serviço implantado.

Você pode descobrir o ServicePackageActivationId de um pacote de serviço implantado consultando a lista de pacotes de serviço implantados em um nó. Quando você está consultando os tipos de serviço implantados, réplicas implantadas e pacotes de código implantados em um nó, o resultado da consulta também contém o ServicePackageActivationId do pacote de serviço implantado pai.

Nota

• No modelo de hospedagem de Processo Compartilhado, em um determinado nó, para um determinado aplicativo, apenas uma cópia de um ServicePackage é ativada. Ele tem um ServicePackageActivationId igual a cadeia de caracteres vazia e não precisa ser especificado durante a execução de operações relacionadas ao pacote de serviço implantado.

• No modelo de hospedagem de Processo Exclusivo, em um determinado nó, para um determinado aplicativo, uma ou mais cópias de um ServicePackage podem estar ativas. Cada ativação tem um ServicePackageActivationId não vazio, especificado durante a execução de operações relacionadas ao pacote de serviço implantado.

• Se ServicePackageActivationId for omitido, o padrão será a cadeia de caracteres vazia. Se um pacote de serviço implantado que foi ativado no modelo de Processo Compartilhado estiver presente, a operação será executada nele. Caso contrário, a operação falha.

• Não consulte uma vez e armazene em cache o ServicePackageActivationId. O ID é gerado dinamicamente e pode ser alterado por vários motivos. Antes de executar uma operação que precisa de ServicePackageActivationId, você deve primeiro consultar a lista de pacotes de serviço implantados em um nó. Em seguida, use o ServicePackageActivationId do resultado da consulta para executar a operação original.

Aplicativos executáveis e contêineres convidados

O Service Fabric trata aplicativos executáveis e contêineres convidados como serviços sem monitoração de estado, que são autônomos. Não há tempo de execução do Service Fabric no ServiceHost (um processo ou contêiner). Como esses serviços são independentes, o número de réplicas por ServiceHost não é aplicável a esses serviços. A configuração mais comum usada com esses serviços é de 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 padrão para esses serviços é SharedProcess, caso em que o Service Fabric ativa apenas uma cópia do ServicePackage em um nó para um determinado aplicativo. Isso significa que apenas uma cópia do código de serviço executará um nó. Se desejar que várias cópias do código de serviço sejam executadas em um nó, especifique ServicePackageActivationMode como ExclusiveProcess no momento da criação do serviço. Por exemplo, você pode fazer isso quando você cria vários serviços (Service1 para ServiceN) de ServiceType (especificado em ServiceManifest), ou quando seu serviço é multiparticionado.

Alterar o modelo de hospedagem de um serviço existente

No momento, você não pode alterar o modelo de hospedagem de um serviço existente de Processo Compartilhado para Processo Exclusivo (ou vice-versa).

Escolha entre os modelos de hospedagem

Você deve avaliar qual modelo de hospedagem melhor se adapta às suas necessidades. O modelo de Processo Compartilhado usa melhor os recursos do sistema operacional, porque menos processos são gerados e várias réplicas no mesmo processo podem compartilhar portas. No entanto, se uma das réplicas tiver um erro em que precise derrubar o host de serviço, isso afetará todas as outras réplicas no mesmo processo.

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

Considerações exclusivas sobre o modelo de processo e o modelo de aplicativo

Para a maioria dos aplicativos, você pode modelar seu aplicativo no Service Fabric mantendo um ServiceType por ServicePackage.

Para certos casos, o Service Fabric também permite mais de um ServiceType por ServicePackage (e um CodePackage pode registrar mais de um ServiceType). A seguir estão alguns dos cenários em que essas configurações podem ser úteis:

• Você deseja otimizar a utilização de recursos gerando menos processos e tendo maior densidade de réplicas por processo.
• Réplicas de diferentes ServiceTypes precisam compartilhar alguns dados comuns que têm um alto custo de inicialização ou memória.
• Você tem uma oferta de serviço gratuita e deseja colocar um limite na utilização de recursos colocando todas as réplicas do serviço no mesmo processo.

O modelo de hospedagem de processo exclusivo não é coerente com um modelo de aplicativo com vários ServiceTypes por ServicePackage. Isso ocorre porque vários ServiceTypes por ServicePackage são projetados para obter maior compartilhamento de recursos entre réplicas e permitem maior densidade de réplicas por processo. O modelo de Processo Exclusivo é projetado para alcançar diferentes resultados.

Considere o caso de vários ServiceTypes por ServicePackage, com um CodePackage diferente registrando cada ServiceType. Digamos que temos um ServicePackage 'MultiTypeServicePackage', que tem dois CodePackages:

• 'MyCodePackageA', que registra ServiceType 'MyServiceTypeA'.
• 'MyCodePackageB', que registra ServiceType 'MyServiceTypeB'.

Agora, digamos que criamos um aplicativo, fabric:/SpecialApp. Dentro da malha:/SpecialApp, criamos dois serviços com o modelo de 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.

Em um determinado nó, ambos os serviços têm duas réplicas cada. Como usamos 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 dos 'MyCodePackageA' ou 'MyCodePackageB' hospeda a réplica para a qual 'MultiTypeServicePackage' foi ativado. O diagrama a seguir mostra a exibição do nó:

Na ativação de 'MultiTypeServicePackage' para a réplica da partição P1 da malha de serviço :/SpecialApp/ServiceA, 'MyCodePackageA' está hospedando 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á hospedando a réplica. 'MyCodePackageA' está em execução. Assim, quanto maior o número de CodePackages (registrando diferentes ServiceTypes) por ServicePackage, maior o uso de recursos redundantes.

No entanto, se criarmos a malha de serviços :/SpecialApp/ServiceA e a malha:/SpecialApp/ServiceB com o modelo de Processo Compartilhado, o Service Fabric ativará apenas uma cópia de 'MultiTypeServicePackage' para a malha do aplicativo :/SpecialApp. 'MyCodePackageA' hospeda todas as réplicas da malha de serviço :/SpecialApp/ServiceA. 'MyCodePackageB' hospeda todas as réplicas da malha de serviço :/SpecialApp/ServiceB. O diagrama a seguir mostra a exibição do nó nessa configuração:

No exemplo anterior, você pode pensar que, se 'MyCodePackageA' registra 'MyServiceTypeA' e 'MyServiceTypeB', e não há 'MyCodePackageB', então não há CodePackage redundante em execução. Embora isso esteja correto, esse modelo de aplicativo não se alinha com o modelo de hospedagem de processo exclusivo. Se o objetivo for colocar cada réplica em seu próprio processo dedicado, você não precisará registrar ambos os ServiceTypes do mesmo CodePackage. Em vez disso, você simplesmente coloca cada ServiceType em seu próprio ServicePackage.

Serviços confiáveis e subprocessos de bifurcação de atores

O Service Fabric não oferece suporte a serviços confiáveis e, subsequentemente, a atores confiáveis que falsificam subprocessos. Um exemplo de por que não é suportado é CodePackageActivationContext não pode ser usado para registrar um subprocesso sem suporte, e os tokens de cancelamento são enviados apenas para processos registrados, resultando em todos os tipos de problemas, como falhas de atualização, quando os subprocessos não fecham depois que o processo pai recebeu um token de cancelamento.

Próximos passos

Empacote um aplicativo e prepare-o para implantar.

Implante e remova aplicativos. Este artigo descreve como usar o PowerShell para gerenciar instâncias de aplicativo.