Ciclo de vida da aplicação do Service Fabric

Tal como acontece com outras plataformas, uma aplicação no Azure Service Fabric costuma passar pelas seguintes fases: design, desenvolvimento, teste, implementação, atualização, manutenção e remoção. O Service Fabric fornece suporte de primeira classe para o ciclo de vida completo da aplicação das aplicações na cloud, desde o desenvolvimento até à implementação, gestão diária e manutenção até eventual desativação. O modelo de serviço permite que várias funções diferentes participem de forma independente no ciclo de vida da aplicação. Este artigo fornece uma descrição geral das APIs e como são utilizadas pelas diferentes funções ao longo das fases do ciclo de vida da aplicação do Service Fabric.

Veja esta página para obter um vídeo de formação que descreva como gerir o ciclo de vida da aplicação:

Importante

Existem dois utilitários CLI utilizados para interagir com o Service Fabric. A CLI do Azure serve para gerir os recursos do Azure, tal como um cluster do Service Fabric alojado no Azure. A CLI do Service Fabric serve para ligar diretamente ao cluster do Service Fabric (independentemente do local onde está alojado) e gerir o cluster, as aplicações e os serviços.

Funções de modelo de serviço

As funções de modelo de serviço são:

  • Programador de serviços: desenvolve serviços modulares e genéricos que podem ser reutilizados e utilizados em várias aplicações do mesmo tipo ou tipos diferentes. Por exemplo, um serviço de fila pode ser utilizado para criar uma aplicação de bilhética (suporte técnico) ou uma aplicação de comércio eletrónico (carrinho de compras).
  • Programador de aplicações: cria aplicações ao integrar uma coleção de serviços para satisfazer determinados requisitos ou cenários específicos. Por exemplo, um site de comércio eletrónico pode integrar "JSON Stateless Front-End Service", "Auction Stateful Service" e "Queue Stateful Service" para criar uma solução de leilão.
  • Administrador da aplicação: toma decisões sobre a configuração da aplicação (preenchendo os parâmetros do modelo de configuração), a implementação (mapeamento para recursos disponíveis) e a qualidade do serviço. Por exemplo, um administrador de aplicações decide a região de idioma (inglês para o Estados Unidos ou japonês para Japão, por exemplo) da aplicação. Uma aplicação implementada diferente pode ter definições diferentes.
  • Operador: implementa aplicações com base na configuração da aplicação e nos requisitos especificados pelo administrador da aplicação. Por exemplo, um operador aprovisiona e implementa a aplicação e garante que está em execução no Azure. Os operadores monitorizam as informações de estado de funcionamento e desempenho da aplicação e mantêm a infraestrutura física conforme necessário.

Programar

  1. Um programador de serviços desenvolve diferentes tipos de serviços com o modelo de programação Reliable Actors ou Reliable Services .
  2. Um programador de serviços descreve declarativamente os tipos de serviço desenvolvidos num ficheiro de manifesto de serviço que consiste num ou mais pacotes de código, configuração e dados.
  3. Em seguida , um programador de aplicações cria uma aplicação com diferentes tipos de serviço.
  4. Um programador de aplicações descreve declarativamente o tipo de aplicação num manifesto de aplicação ao referenciar os manifestos de serviço dos serviços constituintes e substituir e parametrizar adequadamente diferentes definições de configuração e implementação dos serviços constituintes.

Veja Introdução ao Reliable Actors e Introdução ao Reliable Services para obter exemplos.

Implementar

  1. Um administrador de aplicações adapta o tipo de aplicação a uma aplicação específica para ser implementada num cluster do Service Fabric ao especificar os parâmetros adequados do elemento ApplicationType no manifesto da aplicação.
  2. Um operador carrega o pacote de aplicação para o arquivo de imagens do cluster com o método CopyApplicationPackage ou o cmdlet Copy-ServiceFabricApplicationPackage. O pacote de aplicação contém o manifesto da aplicação e a coleção de pacotes de serviço. O Service Fabric implementa aplicações a partir do pacote de aplicações armazenado no arquivo de imagens, que pode ser um arquivo de blobs do Azure ou o serviço de sistema do Service Fabric.
  3. Em seguida, o operador aprovisiona o tipo de aplicação no cluster de destino do pacote de aplicações carregado com o método ProvisionApplicationAsync, o cmdlet Register-ServiceFabricApplicationType ou a operação Aprovisionar uma Aplicação REST.
  4. Após o aprovisionamento da aplicação, um operador inicia a aplicação com os parâmetros fornecidos pelo administrador da aplicação com o método CreateApplicationAsync, o cmdlet New-ServiceFabricApplication ou a operação Create Application REST.
  5. Após a implementação da aplicação, um operador utiliza o método CreateServiceAsync, o cmdlet New-ServiceFabricService ou a operação Create Service REST para criar novas instâncias de serviço para a aplicação com base nos tipos de serviço disponíveis.
  6. A aplicação está agora em execução no cluster do Service Fabric.

Veja Implementar uma aplicação para obter exemplos.

Teste

  1. Depois de implementar no cluster de desenvolvimento local ou num cluster de teste, um programador de serviços executa o cenário de teste de ativação pós-falha incorporado com o cmdlet FailoverTestScenarioParameters e FailoverTestScenario ou o cmdlet Invoke-ServiceFabricFailoverTestScenario. O cenário de teste de ativação pós-falha executa um serviço especificado através de transições e ativações pós-falha importantes para garantir que ainda está disponível e a funcionar.
  2. Em seguida, o programador de serviços executa o cenário de teste de caos incorporado com as classes ChaosTestScenarioParameters e ChaosTestScenario ou o cmdlet Invoke-ServiceFabricChaosTestScenario. O cenário de teste de caos induz aleatoriamente vários nós, pacotes de código e falhas de réplica no cluster.
  3. O programador do serviçotesta a comunicação serviço a serviço ao criar cenários de teste que movem réplicas primárias em torno do cluster.

Veja Introdução ao Serviço de Análise de Falhas para obter mais informações.

Atualizar

  1. Um programador de serviços atualiza os serviços constituintes da aplicação instanciada e/ou corrige erros e fornece uma nova versão do manifesto do serviço.
  2. Um programador de aplicações substitui e parametriza as definições de configuração e implementação dos serviços consistentes e fornece uma nova versão do manifesto da aplicação. Em seguida, o programador de aplicações incorpora as novas versões dos manifestos de serviço na aplicação e fornece uma nova versão do tipo de aplicação num pacote de aplicação atualizado.
  3. Um administrador de aplicação incorpora a nova versão do tipo de aplicação na aplicação de destino ao atualizar os parâmetros adequados.
  4. Um operador carrega o pacote de aplicação atualizado para o arquivo de imagens do cluster com o método CopyApplicationPackage ou o cmdlet Copy-ServiceFabricApplicationPackage. O pacote de aplicação contém o manifesto da aplicação e a coleção de pacotes de serviço.
  5. Um operador aprovisiona a nova versão da aplicação no cluster de destino com o método ProvisionApplicationAsync, o cmdlet Register-ServiceFabricApplicationType ou a operação Aprovisionar uma Aplicação REST.
  6. Um operador atualiza a aplicação de destino para a nova versão com o método UpgradeApplicationAsync, o cmdlet Start-ServiceFabricApplicationUpgrade ou a operação Atualizar uma Aplicação REST.
  7. Um operador verifica o progresso da atualização com o método GetApplicationUpgradeProgressAsync, o cmdlet Get-ServiceFabricApplicationUpgrade ou a operação REST Obter Progresso da Atualização da Aplicação.
  8. Se necessário, o operador modifica e reaplica os parâmetros da atualização atual da aplicação com o método UpdateApplicationUpgradeAsync, o cmdlet Update-ServiceFabricApplicationUpgrade ou a operação UPDATE Application Upgrade REST.
  9. Se necessário, o operador reverte a atualização atual da aplicação com o método RollbackApplicationUpgradeAsync, o cmdlet Start-ServiceFabricApplicationRollback ou a operação REST de Atualização da Aplicação de Reversão.
  10. O Service Fabric atualiza a aplicação de destino em execução no cluster sem perder a disponibilidade de qualquer um dos seus serviços constituintes.

Veja o tutorial atualização da aplicação para obter exemplos.

Manter

  1. Para atualizações e patches do sistema operativo, o Service Fabric interfaces com a infraestrutura do Azure para garantir a disponibilidade de todas as aplicações em execução no cluster.
  2. Para atualizações e patches para a plataforma do Service Fabric, o Service Fabric atualiza-se sem perder a disponibilidade de qualquer uma das aplicações em execução no cluster.
  3. Um administrador da aplicação aprova a adição ou remoção de nós de um cluster depois de analisar os dados de utilização da capacidade histórica e a procura futura projetada.
  4. Um operador adiciona e remove nós especificados pelo administrador da aplicação.
  5. Quando os novos nós são adicionados ou os nós existentes são removidos do cluster, o Service Fabric balancea automaticamente as aplicações em execução em todos os nós do cluster para obter um desempenho ideal.

Remover

  1. Um operador pode eliminar uma instância específica de um serviço em execução no cluster sem remover toda a aplicação com o método DeleteServiceAsync, o cmdlet Remove-ServiceFabricService ou a operação ELIMINAR REST do Serviço.
  2. Um operador também pode eliminar uma instância de aplicação e todos os respetivos serviços com o método DeleteApplicationAsync, o cmdlet Remove-ServiceFabricApplication ou a operação Eliminar REST da Aplicação.
  3. Assim que a aplicação e os serviços pararem, o operador pode anular a aprovisionamento do tipo de aplicação com o método UnprovisionApplicationAsync, o cmdlet Unregister-ServiceFabricApplicationType ou a operação Rest da Aplicação Não Aprovisionada. Anular a anulação do tipo de aplicação não remove o pacote de aplicação da ImageStore.
  4. Um operador remove o pacote de aplicação da ImageStore com o método RemoveApplicationPackage ou o cmdlet Remove-ServiceFabricApplicationPackage.

Veja Implementar uma aplicação para obter exemplos.

Preservar o espaço em disco no arquivo de imagens do cluster

O ImageStoreService mantém os pacotes copiados e aprovisionados, o que pode levar à acumulação de ficheiros. A acumulação de ficheiros pode fazer com que o ImageStoreService (fabric:/System/ImageStoreService) preencha o disco e possa aumentar o tempo de compilação das réplicas imageStoreService.

Para evitar a acumulação de ficheiros, utilize a seguinte sequência de aprovisionamento:

  1. Copie o pacote para ImageStore e utilize a opção de compressão

  2. Aprovisionar o pacote

  3. Remover o pacote no arquivo de imagens

  4. Atualizar a aplicação/cluster

  5. Anular a anulação da versão antiga

Os passos 3 e 5 no procedimento acima impedem a acumulação de ficheiros no arquivo de imagens.

Configuração para limpeza automática

Pode automatizar o passo 3 acima com o PowerShell ou XML. Isto fará com que o pacote de aplicação seja eliminado automaticamente após o registo bem-sucedido do tipo de aplicação.

PowerShell:

Register-ServiceFabricApplicationTye -ApplicationPackageCleanupPolicy Automatic

XML:

<Section Name="Management">
  <Parameter Name="CleanupApplicationPackageOnProvisionSuccess" Value="True" />
</Section>

Pode automatizar o passo 5 acima com XML. Isto fará com que os tipos de aplicações não utilizados sejam automaticamente anulados.

<Section Name="Management">
  <Parameter Name="CleanupUnusedApplicationTypes" Value="true" />
  <Parameter Name="PeriodicCleanupUnusedApplicationTypes" Value="true" />     
  <Parameter Name="TriggerAppTypeCleanupOnProvisionSuccess" Value="true" />
  <Parameter Name="MaxUnusedAppTypeVersionsToKeep" Value="3" />
</Section>

Limpar ficheiros e dados em nós

A replicação de ficheiros de aplicação irá distribuir eventualmente os ficheiros para todos os nós, dependendo das ações de balanceamento. Isto pode criar pressão no disco consoante o número de aplicações e o respetivo tamanho de ficheiro. Mesmo quando nenhuma instância ativa está em execução num nó, os ficheiros de uma instância anterior serão mantidos. O mesmo acontece com os dados de coleções fiáveis utilizadas por serviços com estado. Isto serve o objetivo de uma maior disponibilidade. No caso de uma nova instância de aplicação no mesmo nó, é necessário copiar ficheiros. Para coleções fiáveis, apenas o delta tem de ser replicado.

Para remover completamente os binários da aplicação, tem de anular o registo do tipo de aplicação.

Recomendações para reduzir a pressão do disco:

  1. Remove-ServiceFabricApplicationPackage isto remove o pacote da localização de carregamento temporário.
  2. Unregister-ServiceFabricApplicationType liberta espaço de armazenamento ao remover os ficheiros do tipo de aplicação do serviço de arquivo de imagens e de todos os nós. O gestor de eliminação é executado a cada hora por predefinição.
  3. CleanupUnusedApplicationTypes limpa automaticamente versões antigas de aplicações não utilizadas.
    {
      "name": "Management",
      "parameters": [
        {
          "name": "CleanupUnusedApplicationTypes",
          "value": true
        },
        {
          "name": "MaxUnusedAppTypeVersionsToKeep",
          "value": "3"
        }
      ]
    }
    
  4. Remove-ServiceFabricClusterPackage remove binários de instalação de runtime antigos não utilizados.

Nota

Está em desenvolvimento uma funcionalidade para permitir que o Service Fabric elimine pastas de aplicações assim que a aplicação for evacuada do nó.

Passos seguintes

Para obter mais informações sobre como desenvolver, testar e gerir aplicações e serviços do Service Fabric, consulte: