Partilhar via

Descrição geral do ciclo de vida dos Reliable Services

Quando se está a pensar no ciclo de vida dos Serviços Confiáveis do Azure Service Fabric, os conceitos básicos do ciclo de vida são os mais importantes. Em geral, o ciclo de vida inclui o seguinte:

  • Durante o arranque:
    • Os serviços são construídos.
    • Os serviços têm a oportunidade de construir e devolver zero ou mais ouvintes.
    • Todos os ouvintes retornados são abertos, permitindo a comunicação com o serviço.
    • O método RunAsync do serviço é chamado, permitindo que o serviço execute tarefas de longa duração ou trabalho em segundo plano.
  • Durante o encerramento:
    • O token de cancelamento passado para RunAsync é cancelado e os ouvintes são encerrados.
    • Depois que os ouvintes fecham, o próprio objeto de serviço é destruído.

Há detalhes sobre a ordenação exata desses eventos. A ordem dos eventos pode mudar ligeiramente, dependendo de o Serviço Confiável ser sem estado ou com estado. Além disso, para serviços com estado, devemos lidar com o cenário de swap primário. Durante essa sequência, a função de Primary é transferida para outra réplica (ou retorna) sem que o serviço seja desligado. Finalmente, devemos pensar em condições de erro ou falha.

Inicialização de serviço sem estado

O ciclo de vida de um serviço sem estado é simples. Eis a ordem dos eventos:

  1. O serviço é construído.
  2. StatelessService.CreateServiceInstanceListeners() é invocado e todos os ouvintes retornados são abertos. ICommunicationListener.OpenAsync() é invocado em cada ouvinte.
  3. Então, em paralelo, duas coisas acontecem -
    • O método StatelessService.RunAsync() do serviço é chamado.
    • Se estiver presente, o método StatelessService.OnOpenAsync() do serviço é chamado. Esta chamada é uma substituição incomum, mas está disponível. As tarefas de inicialização de serviço estendidas podem ser iniciadas neste momento.

Desligamento do serviço sem estado

Para encerrar um serviço sem estado, o mesmo padrão é seguido, mas na ordem inversa:

  1. Todos os ouvintes abertos são fechados. ICommunicationListener.CloseAsync() é invocado em cada ouvinte.
  2. O token de cancelamento passado para RunAsync() é cancelado. Uma verificação da propriedade IsCancellationRequested do token de cancelamento retorna true e, se for chamado, o método do token ThrowIfCancellationRequested lança um OperationCanceledException. O Service Fabric aguarda RunAsync() a conclusão.
  3. Após a conclusão de RunAsync(), o método do serviço StatelessService.OnCloseAsync() é chamado, se presente. OnCloseAsync é chamado quando a instância de serviço sem estado será encerrada normalmente. Isso pode ocorrer quando o código do serviço está sendo atualizado, a instância de serviço está sendo movida devido ao balanceamento de carga ou uma falha transitória é detetada. É incomum substituir StatelessService.OnCloseAsync(), mas pode ser usado para fechar recursos com segurança, interromper o processamento em segundo plano, concluir a gravação do estado externo ou fechar conexões existentes.
  4. Após a conclusão de StatelessService.OnCloseAsync(), o objeto de serviço é destruído.

Inicialização de serviço com estado

Os serviços com estado têm um padrão semelhante aos serviços sem estado, com algumas alterações. Para iniciar um serviço com estado, a ordem dos eventos é a seguinte:

  1. O serviço é construído.

  2. StatefulServiceBase.OnOpenAsync() é invocado. Essa chamada geralmente não é substituída no serviço.

  3. StatefulServiceBase.CreateServiceReplicaListeners() é invocado.

    • Se o serviço for um serviço Principal, todos os ouvintes retornados serão abertos. ICommunicationListener.OpenAsync() é invocado em cada ouvinte.
    • Se o serviço for secundário, apenas os ouvintes marcados como ListenOnSecondary = true serão ativados. Ter ouvintes disponíveis em secundárias é menos comum.

  4. Depois, em paralelo:

    • Se o serviço for um Primário atualmente, o método do serviço StatefulServiceBase.RunAsync() será chamado.
    • StatefulServiceBase.OnChangeRoleAsync() é invocado. Essa chamada geralmente não é substituída no serviço.

    Observação

    Para uma nova réplica secundária, StatefulServiceBase.OnChangeRoleAsync() é chamado duas vezes. Uma vez após o passo 2, quando se torna um secundário ocioso e novamente durante o passo 4, quando se torna um secundário ativo. Para obter mais informações sobre o ciclo de vida da réplica e da instância, leia Ciclo de vida da réplica e da instância.

Desligamento de serviço com estado

Como os serviços sem estado, os eventos do ciclo de vida durante o desligamento são os mesmos que durante a inicialização, mas invertidos. Quando um serviço com estado está a ser desligado, ocorrem os seguintes eventos:

  1. Todos os ouvintes abertos são fechados. ICommunicationListener.CloseAsync() é invocado em cada ouvinte.

  2. StatefulServiceBase.OnCloseAsync() o método é chamado. Esta chamada é uma exceção incomum, mas está disponível.

  3. O token de cancelamento passado para RunAsync() é cancelado. Uma verificação da propriedade IsCancellationRequested do token de cancelamento retorna true e, se for chamado, o método do token ThrowIfCancellationRequested lança um OperationCanceledException. O Service Fabric aguarda RunAsync() a conclusão.

    Observação

    A necessidade de aguardar a conclusão do RunAsync só é necessária se essa réplica for uma réplica primária.

  4. Após a conclusão de StatefulServiceBase.RunAsync(), o objeto de serviço é destruído.

Serviço com estado Trocas primárias

Enquanto um serviço com estado está em execução, somente as réplicas primárias desses serviços com estado têm seus ouvintes de comunicação abertos e seu método RunAsync chamado. São criadas réplicas secundárias, mas não recebem mais chamadas. Enquanto um serviço com estado está em execução, a réplica que é atualmente a Primária pode mudar devido a uma falha ou uma otimização de balanceamento de cluster. O que isso significa em termos dos eventos do ciclo de vida que uma réplica pode ver? O comportamento que a réplica stateful observa depende se é a réplica que está a ser rebaixada ou promovida durante a substituição.

Para a Primária que está rebaixada

Para a réplica principal que foi rebaixada, o Service Fabric precisa que esta réplica interrompa o processamento de mensagens e encerre qualquer trabalho em segundo plano que esteja a realizar. Como resultado, esta etapa é semelhante à situação quando o serviço é encerrado. Uma diferença é que o serviço não é destruído ou fechado porque permanece como Secundário. As seguintes APIs são chamadas:

  1. Todos os ouvintes abertos são fechados. ICommunicationListener.CloseAsync() é invocado em cada ouvinte.
  2. O token de cancelamento passado para RunAsync() é cancelado. Uma verificação da propriedade IsCancellationRequested do token de cancelamento retorna true e, se for chamado, o método do token ThrowIfCancellationRequested lança um OperationCanceledException. O Service Fabric aguarda RunAsync() a conclusão.
  3. Os ouvintes marcados como ListenOnSecondary = true são abertos.
  4. Chama-se o serviço StatefulServiceBase.OnChangeRoleAsync(). Essa chamada geralmente não é substituída no serviço.

Para o Ensino Secundário que é promovido

Da mesma forma, o Service Fabric precisa que a réplica secundária promovida comece a ouvir mensagens na rede e inicie quaisquer tarefas em segundo plano que precise de concluir. Como resultado, esse processo se parece com quando o serviço é criado, exceto que a réplica em si já existe. As seguintes APIs são chamadas:

  1. ICommunicationListener.CloseAsync() é chamado para todas as escutas abertas (marcadas com ListenOnSecondary = true).
  2. Todos os ouvintes de comunicação estão ativos. ICommunicationListener.OpenAsync() é invocado em cada ouvinte.
  3. Depois, em paralelo:
    • O método StatefulServiceBase.RunAsync() do serviço é chamado.
    • StatefulServiceBase.OnChangeRoleAsync() é invocado. Essa chamada geralmente não é substituída no serviço.

Observação

CreateServiceReplicaListeners é chamado apenas uma vez e não é chamado novamente durante o processo de promoção ou rebaixamento da réplica; As mesmas ServiceReplicaListener instâncias são usadas, mas novas ICommunicationListener instâncias são criadas (chamando o ServiceReplicaListener.CreateCommunicationListener método) depois que as instâncias anteriores são fechadas.

Problemas comuns durante o desligamento do serviço estado e o rebaixamento do primário

O Service Fabric altera o Primário de um serviço com estado por vários motivos. Os mais comuns são o reequilíbrio de cluster e a atualização de aplicativos. Durante essas operações (bem como durante o desligamento normal do serviço, como você veria se o serviço foi excluído), é importante que o serviço respeite o CancellationToken.

Os serviços que não lidam com o cancelamento de forma limpa podem ter vários problemas. Essas operações são lentas porque o Service Fabric aguarda que os serviços parem normalmente. Isso pode, em última análise, levar a atualizações falhadas que excedem o tempo limite e precisam ser revertidas. O não honrar o token de cancelamento também pode causar clusters desequilibrados. Os clusters ficam desequilibrados porque os nós ficam quentes, mas os serviços não podem ser rebalanceados porque leva muito tempo para movê-los para outro lugar.

Como os serviços são stateful, também é provável que eles usem as Coleções Confiáveis. No Service Fabric, quando um primário é despromovido, uma das primeiras ações é que o acesso de escrita ao estado subjacente é revogado. Isso leva a um segundo conjunto de problemas que podem afetar o ciclo de vida do serviço. As coleções retornam exceções com base no tempo e se a réplica está sendo movida ou encerrada. Essas exceções devem ser tratadas corretamente. As exceções lançadas pelo Service Fabric se enquadram nas categorias permanente (FabricException) e transitória (FabricTransientException). As exceções permanentes devem ser registradas e lançadas, enquanto as exceções transitórias podem ser repetidas com base em alguma lógica de repetição.

Lidar com as exceções decorrentes do uso do ReliableCollections em conjunto com eventos do ciclo de vida do serviço é uma parte importante do teste e da validação de um Serviço Confiável. Recomendamos que você sempre execute seu serviço sob carga enquanto executa atualizações e testes de caos antes de implantar na produção. Estas etapas básicas ajudam a garantir que seu serviço seja implementado corretamente e manipule eventos do ciclo de vida corretamente.

Notas sobre o ciclo de vida do serviço

  • Tanto o RunAsync() método como as CreateServiceReplicaListeners/CreateServiceInstanceListeners chamadas são opcionais. Um serviço pode ter um deles, ambos ou nenhum. Por exemplo, se o serviço faz todo o seu trabalho em resposta a chamadas de usuários, não há necessidade de implementar RunAsync(). Apenas os ouvintes de comunicação e os respetivos códigos associados são necessários. Da mesma forma, criar e retornar ouvintes de comunicação é opcional, pois o serviço pode ter apenas trabalho em segundo plano para fazer e, portanto, só precisa implementar RunAsync().
  • É válido que um serviço seja concluído RunAsync() com sucesso e retorne. Completar não é uma consequência de erro. A conclusão RunAsync() indica que o trabalho em segundo plano do serviço foi concluído. Para serviços confiáveis com estado, RunAsync() é chamado novamente se a réplica for rebaixada de Primária para Secundária e depois promovida de volta a Primária.
  • Se um serviço sair de RunAsync() devido a uma exceção inesperada, isso constituirá uma falha. O objeto de serviço é desligado e um erro de estado é relatado.
  • Embora não haja limite de tempo para retornar desses métodos, você perde imediatamente a capacidade de escrever em Coleções Confiáveis e, portanto, não pode concluir nenhum trabalho real. Recomendamos que você retorne o mais rápido possível após receber o pedido de cancelamento. Se o seu serviço não responder a essas chamadas de API em um período de tempo razoável, o Service Fabric poderá encerrar o serviço à força. Normalmente, isso só acontece durante atualizações de aplicativos ou quando um serviço está sendo excluído. Esse tempo limite é de 15 minutos por padrão.
  • Falhas no caminho OnCloseAsync() levam a OnAbort() ser chamado, o que representa uma última oportunidade para o serviço tentar limpar e liberar quaisquer recursos que tenham reivindicado. Isso geralmente é chamado quando uma falha permanente é detetada no nó ou quando o Service Fabric não pode gerenciar de forma confiável o ciclo de vida da instância de serviço devido a falhas internas.
  • OnChangeRoleAsync() é chamado quando a réplica de serviço com estado está alterando de função, por exemplo, para primário ou secundário. As réplicas primárias recebem estado de escrita (têm permissão para criar e escrever em Coleções Fiáveis). As réplicas secundárias recebem status de leitura (só podem ser lidas a partir de Coleções Confiáveis existentes). A maior parte do trabalho em um serviço com estado é executada na réplica primária. As réplicas secundárias podem executar validação de leitura, geração de relatórios, mineração de dados ou outros trabalhos de leitura.

Próximos passos