Partilhar via

Ciclo de vida dos Reliable Services

  • Artigo

Serviços Confiáveis é um dos modelos de programação disponíveis no Azure Service Fabric. Ao aprender sobre o ciclo de vida dos Serviços Confiáveis, é mais importante entender os eventos básicos do ciclo de vida. A ordenação exata dos eventos depende dos detalhes da configuração.

Em geral, o ciclo de vida dos Serviços Confiáveis inclui os seguintes eventos:

  • Durante o arranque:
    • Os serviços são construídos.
    • Os serviços têm a oportunidade de construir e retornar zero ou mais ouvintes.
    • Todos os ouvintes retornados são abertos, para comunicação com o serviço.
    • O método do runAsync serviço é chamado, para que o serviço possa fazer trabalho de longa duração ou em segundo plano.
  • Durante o encerramento:
    • O token de cancelamento para o qual foi passado runAsync é cancelado e os ouvintes são fechados.
    • O próprio objeto de serviço é destruído.

A ordem dos eventos em Serviços Confiáveis pode mudar ligeiramente dependendo se o serviço confiável é stateless ou stateful.

Além disso, para serviços com monitoração de estado, você deve abordar o cenário de permuta principal. Durante essa sequência, a função de primário é transferida para outra réplica (ou retorna) sem que o serviço seja desligado.

Finalmente, você tem que pensar sobre as condições de erro ou falha.

Inicialização de serviço sem estado

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

  1. O serviço é construído.
  2. StatelessService.createServiceInstanceListeners() é invocado e todos os ouvintes retornados são abertos. CommunicationListener.openAsync() é chamado a cada ouvinte.
  3. Depois, em paralelo:
    • O método do runAsync serviço (StatelessService.runAsync()) é chamado.
    • Se presente, o próprio onOpenAsync método do serviço é chamado. Especificamente, StatelessService.onOpenAsync() é chamado. Esta é uma substituição incomum, mas está disponível.

Desligamento do serviço sem estado

Ao encerrar um serviço sem monitoração de estado, o mesmo padrão é seguido, mas no sentido inverso:

  1. Todos os ouvintes abertos são fechados. CommunicationListener.closeAsync() é chamado a cada ouvinte.
  2. O token de cancelamento para runAsync() o qual foi passado é cancelado. Verificar a propriedade do token de isCancelled cancelamento retorna truee, se chamado, o método do throwIfCancellationRequested token lança um CancellationExceptionarquivo .
  3. Quando runAsync() termina, o método do StatelessService.onCloseAsync() serviço é chamado, se estiver presente. Novamente, essa não é uma substituição comum, mas pode ser usada para fechar recursos com segurança, interromper o processamento em segundo plano, terminar de salvar o estado externo ou fechar conexões existentes.
  4. Após StatelessService.onCloseAsync() a conclusão, o objeto de serviço é destruído.

Inicialização de serviço com monitoração de estado

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

  1. O serviço é construído.
  2. StatefulServiceBase.onOpenAsync() é chamado. 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. CommunicationListener.openAsync() é chamado a cada ouvinte.
    • Se o serviço for um serviço secundário, apenas os ouvintes marcados como listenOnSecondary = true serão abertos. Ter ouvintes abertos em secundárias é menos comum.
  4. Depois, em paralelo:
    • Se o serviço for atualmente um primário, o método do StatefulServiceBase.runAsync() serviço será chamado.
    • StatefulServiceBase.onChangeRoleAsync() é chamado. Essa chamada geralmente não é substituída no serviço.

Nota

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 do serviço com estado

Como os serviços sem monitoração de 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 monitoração de estado está sendo encerrado, ocorrem os seguintes eventos:

  1. Todos os ouvintes abertos são fechados. CommunicationListener.closeAsync() é chamado a cada ouvinte.
  2. O token de cancelamento para runAsync() o qual foi passado é cancelado. Uma chamada para o método do token de isCancelled() cancelamento retorna truee, se chamado, o método do throwIfCancellationRequested() token lança um OperationCanceledExceptionarquivo . O Service Fabric aguarda runAsync() a conclusão.

Nota

Esperar pela runAsync conclusão é necessário somente se essa réplica for uma réplica primária.

  1. Após runAsync() a conclusão, o método do StatefulServiceBase.onCloseAsync() serviço é chamado. Esta chamada é uma substituição incomum, mas está disponível.
  2. Após StatefulServiceBase.onCloseAsync() a conclusão, o objeto de serviço é destruído.

Trocas primárias de serviço com estado

Enquanto um serviço com estado está em execução, os ouvintes de comunicação são abertos e o runAsync método é chamado apenas para as réplicas primárias desses serviços com monitoração de estado. Réplicas secundárias são construídas, mas não há mais chamadas. Enquanto um serviço com monitoração de estado está em execução, a réplica que é atualmente a principal pode mudar. Os eventos de ciclo de vida que uma réplica com estado pode ver dependem se é a réplica que está sendo rebaixada ou promovida durante a troca.

Para a primária rebaixada

O Service Fabric precisa da réplica principal rebaixada para interromper o processamento de mensagens e qualquer trabalho em segundo plano. Esta etapa é semelhante a quando o serviço é desligado. Uma diferença é que o serviço não é destruído ou fechado, porque permanece como secundário. Ocorrem os seguintes eventos:

  1. Todos os ouvintes abertos são fechados. CommunicationListener.closeAsync() é chamado a cada ouvinte.
  2. O token de cancelamento para runAsync() o qual foi passado é cancelado. Uma verificação do método do token isCancelled() de cancelamento retorna true. Se chamado, o método do throwIfCancellationRequested() token lança um OperationCanceledExceptionarquivo . O Service Fabric aguarda runAsync() a conclusão.
  3. Os ouvintes marcados como listenOnSecondary = true são abertos.
  4. O serviço StatefulServiceBase.onChangeRoleAsync() é chamado. Essa chamada geralmente não é substituída no serviço.

Para o secundário promovido

Da mesma forma, o Service Fabric precisa da réplica secundária promovida para começar a ouvir mensagens no fio e para iniciar quaisquer tarefas em segundo plano que precise ser concluída. Este processo é semelhante a quando o serviço é criado. A diferença é que a réplica em si já existe. Ocorrem os seguintes eventos:

  1. CommunicationListener.closeAsync() é chamado para todos os ouvintes abertos (marcado com listenOnSecondary = true)
  2. Todos os ouvintes de comunicação estão abertos. CommunicationListener.openAsync() é chamado a cada ouvinte.
  3. Depois, em paralelo:
    • O método do StatefulServiceBase.runAsync() serviço é chamado.
    • StatefulServiceBase.onChangeRoleAsync() é chamado. Essa chamada geralmente não é substituída no serviço.

Nota

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 CommunicationListener 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 com monitoração de estado e o rebaixamento primário

O Service Fabric altera o principal de um serviço com monitoração de estado por vários motivos. Os motivos mais comuns são o rebalanceamento de cluster e a atualização de aplicativos. Durante essas operações, é importante que o serviço respeite o cancellationToken. Isso também se aplica durante o desligamento normal do serviço, como se o serviço fosse excluído.

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 com falha que expiram e revertem. O não cumprimento do token de cancelamento também pode causar clusters desequilibrados. Os clusters ficam desequilibrados porque os nós ficam quentes. No entanto, os serviços não podem ser reequilibrados porque leva muito tempo para movê-los para outro lugar.

Como os serviços são com monitoração de estado, também é provável que os serviços usem Coleções Confiáveis. No Service Fabric, quando um primário é rebaixado, uma das primeiras coisas que acontece é que o acesso de gravação 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. É importante lidar com essas exceções corretamente.

As exceções geradas pelo Service Fabric são permanentes (FabricException) ou transitórias (FabricTransientException). Exceções permanentes devem ser registradas e lançadas. Exceções transitórias podem ser repetidas com base na lógica de repetição.

Uma parte importante do teste e da validação dos Serviços Confiáveis é lidar com as exceções decorrentes do uso do em conjunto com eventos do ciclo de vida do ReliableCollections serviço. Recomendamos que você sempre execute seu serviço sob carga. Você também deve executar 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 que ele lide com eventos do ciclo de vida corretamente.

Notas sobre o ciclo de vida do serviço

  • Tanto o runAsync() método como as createServiceInstanceListeners/createServiceReplicaListeners chamadas são opcionais. Um serviço pode ter um, 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()o . Apenas os ouvintes de comunicação e seu código associado são necessários. Da mesma forma, criar e retornar ouvintes de comunicação é opcional. O serviço pode ter apenas trabalho em segundo plano para fazer, por isso só precisa implementar runAsync().
  • É válido para que um serviço seja concluído runAsync() com sucesso e retorne dele. Esta não é considerada uma condição de falha. Ele representa o trabalho de fundo do acabamento do serviço. Para Serviços Confiáveis com monitoração de estado, runAsync() será chamado novamente se o serviço for rebaixado de primário e, em seguida, promovido de volta para primário.
  • Se um serviço sair lançando runAsync() alguma exceção inesperada, isso é uma falha. O objeto de serviço é desligado e um erro de integridade é relatado.
  • Embora não haja limite de tempo para retornar desses métodos, você perde imediatamente a capacidade de escrever. Portanto, você não pode concluir nenhum trabalho real. Recomendamos que devolva o mais rapidamente 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 acontece apenas 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 onCloseAsync() caminho resultam em onAbort() ser chamado. Esta chamada é uma oportunidade de última chance e melhor esforço para o serviço limpar e liberar quaisquer recursos que eles reivindicaram. 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 monitoração de estado está mudando de função, por exemplo, para primária ou secundária. As réplicas primárias recebem status de gravação (têm permissão para criar e gravar em Coleções Confiá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 monitoração de estado é executada na réplica principal. As réplicas secundárias podem executar validação somente leitura, geração de relatórios, mineração de dados ou outros trabalhos somente leitura.

Próximos passos