Padrão de supervisor de agente do Agendador

Coordene um conjunto de ações distribuídas como uma única operação lógica para que a operação como um todo seja bem-sucedida ou falhe. Trate falhas de forma transparente ou desfaça o trabalho concluído. Essa abordagem confere mais resiliência a sistemas distribuídos ao se recuperar de exceções transitórias, falhas mais persistentes e falhas de processo que interrompem fluxos de trabalho de várias etapas orquestrados entre serviços e recursos remotos.

Contexto e problema

Os aplicativos geralmente executam tarefas que abrangem várias etapas e algumas etapas podem invocar serviços remotos ou acessar recursos remotos sob a orquestração da lógica do aplicativo. A interação com qualquer coisa fora do processo local expõe a tarefa a um intervalo de modos de falha. A lógica de orquestração deve lidar com esses modos de falha sem perder a integridade da operação como um todo.

Você pode lidar com situações simples, como falhas transitórias que resolvem por conta própria, usando abordagens como o padrão de repetição. Quando as falhas são mais permanentes ou quando o próprio orquestrador falha, o sistema deve restaurar um estado consistente de registros duráveis e garantir a integridade da operação geral.

Solução

O padrão Supervisor de Agente Agendador coordena uma tarefa distribuída multietapas por meio de três atores lógicos. Esses atores orquestram as etapas a serem executadas como parte da tarefa geral e tratam tanto execuções bem-sucedidas quanto execuções malsucedidas.

Agendador

O Agendador organiza as etapas que compõem a tarefa e orquestra sua execução. O Agendador é responsável por combinar etapas em um pipeline ou fluxo de trabalho e executá-las na ordem correta. À medida que cada etapa progride, o Agendador registra seu estado, como etapa ainda não iniciada, execução de etapa ou etapa concluída. O estado também inclui um prazo de conclusão que limita o tempo máximo que a etapa pode levar.

Quando uma etapa precisa de um serviço ou recurso remoto, o Agendador invoca um Agente apropriado e passa os detalhes do trabalho para ele. O Agendador normalmente se comunica com agentes por meio de mensagens assíncronas de solicitação/resposta, geralmente implementadas em filas. Em vez disso, você pode usar outras tecnologias de mensagens distribuídas.

Agente

Um Agente encapsula uma chamada para um serviço remoto ou o acesso a um recurso remoto que uma etapa de tarefa referencia. Cada Agente normalmente encapsula chamadas para um único serviço ou recurso e implementa o tratamento de erros apropriado e a lógica de novas tentativas dentro do prazo de conclusão imposto pelo Agendador. Quando a lógica de repetição está envolvida, o Agente passa um identificador estável em todas as tentativas de repetição. Um serviço downstream pode usá-lo para eliminação de duplicação.

Se diferentes etapas no fluxo de trabalho usarem diferentes serviços ou recursos, cada etapa poderá fazer referência a um Agente diferente. Esse mapeamento é um detalhe de implementação do padrão. Para obter diretrizes sobre como criar estratégias de repetição, consulte As práticas recomendadas para tratamento transitório de falhas.

Supervisor

O Supervisor monitora o status das etapas executadas pelo Agendador. O Supervisor é executado periodicamente, na frequência especificada pela carga de trabalho, e examina o estado da etapa registrado pelo Agendador. Se o Supervisor encontrar etapas que perderam o tempo limite ou falharam, ele organiza o Agente apropriado para recuperar a etapa ou dispara outra ação corretiva que pode incluir a modificação do status da etapa. O Supervisor solicita apenas essas ações de recuperação. O Agendador e os Agentes os implementam.

Interações

O Agendador, o Agente e o Supervisor são componentes lógicos e sua implementação física depende da tecnologia usada. Por exemplo, você pode implementar vários Agentes lógicos como parte de um único serviço Web ou como atividades dentro do mesmo trabalho hospedado.

O Agendador mantém o progresso da tarefa e o estado por etapa em um armazenamento de dados durável chamado repositório de estado. O Supervisor usa essas informações para determinar se uma etapa falhou. O diagrama a seguir mostra a relação entre o Agendador, os Agentes, o Supervisor e o repositório de estado.

• O Agendador organiza e executa as etapas que compõem a tarefa como um fluxo de trabalho.
• Uma etapa no fluxo de trabalho pode enviar uma solicitação a um Agente para acessar um recurso remoto ou invocar um serviço remoto. Solicitações e respostas normalmente são enviadas de forma assíncrona.
• Um Agente acessa o recurso ou serviço remoto. O agente deve incluir tratamento de erros e lógica de nova tentativa.
• O Agendador mantém o status de cada etapa no repositório de estado conforme ele é iniciado e concluído.
• O Supervisor monitora o estado das etapas no repositório de estado e pode solicitar a atualização do estado de uma etapa.
• O Supervisor solicita ao Scheduler que tente novamente uma etapa que falhou.

Quando o aplicativo está pronto para executar uma tarefa, ele envia uma solicitação para o Agendador. O Agendador registra o estado inicial da tarefa e suas etapas, como etapa ainda não iniciada, no repositório de estado e, em seguida, começa a executar as operações definidas pelo fluxo de trabalho. À medida que o Agendador inicia cada etapa, ele atualiza o estado dessa etapa, como etapa em execução, no armazenamento de estado.

Se uma etapa faz referência a um serviço ou recurso remoto, o Agendador envia uma mensagem para o Agente apropriado. A mensagem contém as informações necessárias para que o Agente invoque o serviço ou acesse o recurso, bem como o prazo para conclusão e o número de tentativas permitidas para a operação.

Um Agente pode implementar qualquer lógica de novas tentativas apropriada para sua tarefa, mas, se o Agente não concluir seu trabalho até o prazo de conclusão, o Agendador presume que a operação falhou e deixa de aguardar uma resposta. O Agente deve observar o prazo e não deve iniciar novos efeitos colaterais após a expiração do tempo, embora o trabalho já em andamento possa continuar.

Se o Agente concluir com êxito sua operação, ele enviará uma resposta para o Agendador. O Agendador atualiza o estado, para a etapa concluída , por exemplo, e inicia a próxima etapa. Esse processo continua até que toda a tarefa seja concluída.

O Agendador deve ignorar qualquer resposta tardia e o Agente não deve tentar a recuperação do fluxo de trabalho por conta própria. Se o próprio Agente falhar, o Agendador também não receberá uma resposta. O status no armazenamento de estado deliberadamente não faz distinção entre uma etapa que excede o tempo limite e uma etapa que falha.

Quando uma etapa atinge o tempo limite ou falha, o registro do repositório de estado ainda mostra a etapa como em execução, mas com um tempo de conclusão expirado. O Supervisor verifica registros nessa condição e organiza a recuperação.

O Supervisor também precisa impedir que a mesma etapa tente novamente indefinidamente. O Supervisor mantém uma contagem de repetição para cada etapa juntamente com as informações de estado no repositório de estado. Se a contagem exceder um limite predefinido, o Supervisor poderá ser configurado para aguardar um período mais longo antes de solicitar ao Agendador que tente novamente a etapa, caso a falha subjacente seja resolvida durante esse intervalo.

Uma possível estratégia do Supervisor é estender o valor de conclusão e enviar uma mensagem ao Agendador identificando a etapa que expirou, para que o Agendador possa tentar novamente. Esse design requer que a lógica da etapa seja idempotente, pois o mesmo trabalho pode ser feito mais de uma vez.

Como alternativa, o Supervisor pode pedir ao Agendador para desfazer a tarefa inteira acionando uma transação de compensação. Essa abordagem depende do Agendador e dos Agentes fornecerem informações suficientes para implementar operações de compensação para cada etapa que já foi concluída com êxito. O log de compensação precisa de ordenação e durabilidade, pois as operações de compensação normalmente são executadas na ordem inversa das etapas concluídas. Uma operação compensatória que falha deixa a tarefa em um estado que não está concluído nem desfeito corretamente. O armazenamento de estado deve ser capaz de representar essa condição para que os operadores possam localizá-la e investigá-la.

Em uma implementação real desse padrão, várias instâncias do Agendador podem ser executadas simultaneamente, cada uma tratando um subconjunto de tarefas. O sistema também pode executar várias instâncias de cada Agente ou vários Supervisores. Quando mais de um Supervisor estiver ativo, os Supervisores deverão coordenar para que não concorram para recuperar a mesma etapa ou tarefa com falha. O padrão de eleição de líder é uma maneira de coordenar supervisores.

O principal benefício desse padrão é que o sistema permanece resiliente a falhas transitórias e irrecuperáveis, e você pode construí-lo para ser auto-cura. Se um Agente ou o Agendador falhar, você poderá iniciar uma nova instância e o Supervisor poderá organizar a retomada da tarefa afetada. Se o próprio Supervisor falhar, outra instância poderá assumir onde a anterior parou. Quando o Supervisor é executado de acordo com uma programação, uma nova instância é iniciada automaticamente no próximo intervalo. Você também pode replicar o armazenamento de estado para maior resiliência.

Problemas e considerações

Considere os seguintes pontos ao decidir como implementar esse padrão:

• Complexidade de implementação. Esse padrão é difícil de implementar e requer um teste completo de todos os modos de falha que o sistema pode experimentar. Planeje testes de injeção de falhas juntamente com testes funcionais.

• Amplificação de novas tentativas. Os limites de repetição independentes nas camadas Agent, runtime de orquestração, biblioteca de clientes, mensagens e Supervisor multiplicam o número de chamadas para uma dependência com falha. Defina o Scheduler como responsável por um orçamento durável de novas tentativas de ponta a ponta e configure ou desabilite as novas tentativas nas outras camadas para que o máximo combinado delas não exceda esse orçamento.

• Controle de admissão. O padrão não limita quanto trabalho pode estar em andamento ao mesmo tempo. Como o Agendador foi projetado para nunca perder nenhuma tarefa que aceita, um serviço downstream lento ou com falha produz um número crescente de registros de processamento, em vez de pressão de retorno visível para o solicitante. O caminho de submissão precisa de seu próprio controle de admissão, como uma fila com limite, um limite para o número de tarefas simultâneas em andamento ou a rejeição de novas submissões quando o volume de pendências ultrapassar um limite. Essa contrapressão ajuda a garantir que um incidente subsequente não cause silenciosamente um acúmulo ilimitado no armazenamento de estado.

• Durabilidade do estado de recuperação. A lógica de recuperação e repetição do Agendador é complexa e depende do estado mantido no repositório de estado. Talvez você também precise registrar as informações necessárias para conduzir uma transação de compensação em um repositório durável e a transação de compensação em si pode falhar. Trate o armazenamento de estado e qualquer log de transações compensatórias como ativos duráveis ​​de primeira classe. Esses ativos devem sobreviver ao Agendador, aos Agentes e ao Supervisor, e ser recuperáveis independentemente dos trabalhadores que gravam neles.

  Importante

  O log de compensação deve herdar a classificação de dados dos dados que ele precisa rastrear. Se uma etapa aceitar dados de cliente ou de pagamento, o log da transação compensatória herdará esse nível de sensibilidade e as respectivas regras de retenção.

• Problema de gravação dupla. O envio de uma tarefa normalmente envolve mais de uma gravação persistente. Por exemplo, uma tarefa pode precisar gravar um registro de aplicativo em um banco de dados empresarial e um registro inicial no repositório de estado. Essas gravações não compartilham uma transação, portanto, se apenas uma gravação for concluída, um registro de aplicativo poderá não ter nenhum registro de repositório de estado ou um registro de repositório de estado poderá não ter nenhum registro de aplicativo. O padrão atual em si não resolve esse problema de gravação dupla. As soluções comuns incluem realizar a gravação em uma orquestração durável com uma exclusão compensatória em caso de falha, aplicar o padrão de Caixa de Saída Transacional ou usar um identificador estável, como o próprio ID de tarefa do aplicativo, para que cada operação de gravação possa ser repetida com segurança.

• Fluxo de trabalho e versionamento de estado. Tarefas de longa duração podem se estender por várias implantações, portanto mudanças na lógica do fluxo de trabalho ou no estado persistido podem impedir a reexecução, a recuperação ou a compensação de trabalhos em andamento. Versione ambos os contratos e mantenha o código e o gerenciamento de estado compatíveis até que nenhuma tarefa ativa dependa deles.

• Resultados de compensação. Uma transação compensatória pode ser concluída, falhar ou parar no meio do caminho. A máquina de estados mantida pelo Agendador precisa representar todos esses estados. Se Erro for o único estado terminal, uma compensação travada será indistinguível de uma etapa que falhou antes de a compensação ser executada, e os operadores perderão o sinal necessário para intervir. Distinga compensação em andamento, compensação concluída e compensação com falha no esquema de armazenamento de estado, em vez de agrupá-los em um único estado Error.

• Cadência do Supervisor. A frequência de execução do Supervisor é uma compensação deliberada. Ele deve ser executado com frequência suficiente para que as etapas com falha ou tempo limite não bloqueiem o trabalho por um longo período, mas não com tanta frequência que se torne uma fonte de carga e custo em relação ao repositório de estado. Ajuste o intervalo em relação à duração típica da etapa e ao atraso de detecção aceitável para uma etapa paralisada e revisite-o à medida que o volume de fluxo de trabalho aumenta.

• Idempotência de etapas. Um agente pode executar uma etapa mais de uma vez. Por exemplo, o Supervisor pode estender o prazo de conclusão e solicitar ao Agendador que tente novamente uma etapa cuja execução original já produziu um efeito que o Agendador nunca observou. Portanto, a lógica que implementa cada etapa deve ser idempotente.

• Visibilidade operacional. O comportamento em tempo de execução do padrão se manifesta em transições no armazenamento de estado, e não em respostas síncronas. Os operadores só podem ver o que o repositório de estado e os trabalhadores emitem. Decida o que o Agendador, os Agentes e o Supervisor devem emitir e quais limites devem disparar alertas.

• Reinicialização e recuperação do agendador. Se o Agendador for reiniciado após uma falha ou o fluxo de trabalho que o Agendador está executando terminar inesperadamente, o Agendador deverá ser capaz de determinar o status de qualquer tarefa que estava tratando quando falhou e retomar a tarefa a partir desse ponto. Os detalhes de implementação dessa recuperação normalmente são específicos do sistema. Por exemplo, um Agendador baseado em um runtime de orquestração com checkpoints pode confiar no runtime para reproduzir o histórico e retomar a execução, enquanto um Agendador personalizado precisa reconstruir o estado em andamento a partir do próprio armazenamento de estado. Se uma tarefa não puder ser recuperada, o trabalho já feito para essa tarefa pode precisar ser desfeito, o que pode exigir uma transação de compensação.

Quando usar esse padrão

Use esse padrão quando:

• Um processo é executado em uma carga de trabalho distribuída e deve permanecer resiliente a falhas de comunicação e falhas operacionais nos serviços e recursos que coordena.

• Tarefas em segundo plano orquestram fluxos de trabalho de várias etapas, cujas etapas envolvem serviços ou recursos remotos, e esses fluxos de trabalho, como um todo, devem ser concluídos ou revertidos corretamente. Exemplos comuns incluem processamento de pedidos e provisionamento de recursos. Para obter mais informações, consulte As práticas recomendadas para trabalhos em segundo plano.

Esse padrão pode não ser adequado quando:

• A tarefa não invoca serviços remotos nem acessa recursos remotos. Não há superfície de falha distribuída para as funções de Agendador, Agente e Supervisor mitigarem. A sobrecarga de coordenação do padrão adiciona custo sem nenhum benefício de resiliência.

Design de carga de trabalho

Avalie como usar o padrão Supervisor de Agente Agendador no projeto de uma carga de trabalho para atender às metas e aos princípios apresentados nos pilares do Azure Well-Architected Framework. A tabela a seguir fornece diretrizes sobre como esse padrão dá suporte às metas de cada pilar.

Se esse padrão introduzir compensações dentro de um pilar, considere-as em relação aos objetivos dos outros pilares.

Exemplo

Este exemplo implanta um aplicativo Web que implementa um sistema de comércio eletrônico no Microsoft Azure. Os usuários navegam pelos produtos e fazem pedidos por meio de uma interface web, e os processos em segundo plano no fluxo de processamento de pedidos invocam um serviço remoto propenso a falhas transitórias e prolongadas. O processamento de pedidos implementa o padrão supervisor do Agente de Agendador usando Durable Functions, Barramento de Serviço do Azure e Azure Cosmos DB.

Uma atividade de submissão grava no banco de dados de pedidos e em um armazenamento de estado do Cosmos DB, um orquestrador de Funções Duráveis ​​reivindica registros de estado pendentes e despacha o trabalho para um Agente por meio de um par de filas de solicitação e resposta do Barramento de Serviço, e um Supervisor verifica o armazenamento de estado em busca de tempos expirados CompleteBy.

O diagrama a seguir mostra uma exibição de alto nível da solução Azure.

1. O aplicativo envia uma solicitação para uma fila para processar o pedido.
2. O processo de envio recupera solicitações, insere detalhes do pedido no banco de dados de pedidos e gera um registro para o pedido no repositório de estado.
3. O Agendador procura um pedido com LockedBy definido como nulo no repositório de estado e a lógica de fluxo de trabalho no Agendador manipula a ordem.
4. A lógica de fluxo de trabalho envia solicitações e recebe respostas de Agentes por meio de filas de mensagens.
5. As tarefas de fluxo de trabalho usam Agentes para invocar o serviço remoto.
6. O Supervisor procura pedidos com um valor expirado CompleteBy e atualiza esse valor para permitir que o Agendador reattempe o processo.

Envio

Quando um cliente faz um pedido, o front-end da Web posta uma mensagem de pedido em uma fila de Barramento de Serviço. Uma função de envio recebe a mensagem no modo PeekLock, insere os detalhes do pedido no banco de dados de pedidos e cria um registro de repositório de estado para o processo de pedido.

Como o banco de dados de pedidos e o banco de dados criado com o Azure Cosmos DB são recursos diferentes e não compartilham uma transação, a função trata cada gravação como idempotente de forma independente. A função usa o ID do pedido como uma chave estável, cria um ou outro registro quando estiver ausente e aceita um registro existente somente após verificar se seus dados imutáveis do pedido correspondem à mensagem. Dados conflitantes fazem com que a função envie a mensagem para a fila de mensagens mortas e alerte um operador, em vez de sobrescrever um registro.

O registro contém os seguintes campos:

Quando a atividade de envio grava o registro pela primeira vez, ela copia OrderID do novo pedido, define LockedBy e CompleteBy como ProcessState, define null como Pending e define FailureCount como 0.

Scheduling

O Agendador é um orquestrador Durable Functions. Uma função de inicialização consulta o Azure Cosmos DB em busca de registros em que LockedBy é nulo e ProcessState é Pending. A função cria uma ID de instância de orquestração específica da tentativa a partir de OrderID e do número da próxima tentativa. Uma atualização condicional define ProcessState como Processing e LockedBy como esse identificador de instância antes de o inicializador agendar a orquestração. Esta reivindicação impede que dois iniciadores agendem a mesma tentativa.

Cada atualização da orquestração também verifica se LockedBy ainda corresponde à sua ID de instância. Essa verificação impede que uma tentativa expirada altere o estado de uma tentativa de substituição. O paralelismo entre ordem vem da execução de muitas instâncias de orquestração simultaneamente, não do paralelismo dentro de uma ordem. A orquestração define CompleteBy e conduz o fluxo de trabalho.

O orquestrador recupera os detalhes da ordem do banco de dados de pedidos e executa o fluxo de trabalho como uma sequência de funções de atividade. Quando uma etapa precisa do serviço remoto, ela invoca um Agente.

Execution

O Agente pode ser uma função de atividade quando o trabalho é de curta duração e é executado no mesmo aplicativo de funções, ou pode ser um worker separado acessado por meio de um par de filas de solicitação/resposta do Barramento de Serviço quando é executado em um runtime diferente ou através de uma fronteira de confiança. Em ambos os casos, o orquestrador executa um temporizador durável contra a resposta do Agente para detectar o prazo CompleteBy.

Quando o Agente é acessado por meio do Barramento de Serviço, uma função acionada por fila recebe a resposta e usa o cliente do Durable Functions para disparar um evento externo que inclui o ID da instância de orquestração e um ID de evento estável. O orquestrador elimina duplicatas de eventos externos habilitando a detecção de duplicatas e definindo um MessageId estável em cada solicitação, para que o Barramento de Serviço possa descartar duplicatas introduzidas por tentativas repetidas.

Se o Agente receber uma resposta do serviço remoto antes do temporizador durável ser acionado, o Agente retornará o resultado para o orquestrador. O orquestrador conclui a etapa e atualiza ProcessState para Processed somente se LockedBy ainda identificar a orquestração atual. Se o temporizador for acionado primeiro, o orquestrador tratará a etapa como falha, interromperá a espera e será concluída sem alterar o registro de estado.

O Agente deixa de iniciar, de forma cooperativa, novos efeitos colaterais após seu próprio prazo limite, mas o trabalho já em andamento pode continuar. O registro do armazenamento de estado permanece no estado Processing com o valor CompleteBy expirado, permitindo que o Supervisor providencie a recuperação. Use idempotência ou um token de isolamento imposto pelo destino para evitar que uma tentativa sobreposta duplique ou entre em conflito com um efeito colateral.

Se o Agente detectar uma falha irrecuperável e não transitória ao entrar em contato com o serviço remoto, ele retornará uma resposta de erro ao orquestrador. O orquestrador define ProcessStateError e gera um evento que alerta um operador, que pode investigar a falha e reenviar a etapa de processamento com falha.

Supervisão

O Supervisor consulta periodicamente o armazenamento de estado do Azure Cosmos DB em busca de pedidos com status Processing e prazo expirado CompleteBy. Como OrderID é a chave de partição, essa consulta atinge todas as partições físicas mesmo quando ProcessState e CompleteBy são indexadas. O processo limita cada verificação por uma janela de tempo CompleteBy uma contagem máxima de resultados e paginação de token de continuação, e monitora sua cobrança por unidade de solicitação (RU).

Cargas de trabalho maiores mantêm um índice ou uma fila de recuperação separados, particionados de acordo com o padrão de acesso do Supervisor. Quando o Supervisor encontra um registro expirado, ele usa uma atualização condicional que verifica o valor expirado LockedBy antes de incrementar FailureCount. Se FailureCount estiver abaixo de um limite configurado, o Supervisor redefine LockedBy para null, atualiza CompleteBy com um novo horário de expiração e redefine Pending de volta para ProcessState, o que permite que o iniciador agende uma nova tentativa. Se FailureCount exceder o limite, o Supervisor tratará a falha como não transitória, definirá ProcessState como Errore gerará um evento que alertará um operador.

Relatório de status

O orquestrador também pode precisar manter informado o aplicativo que enviou a solicitação sobre o progresso e o status final, algo que o diagrama não mostra. O aplicativo e o orquestrador são deliberadamente dissociados. O aplicativo não sabe qual instância de orquestração está processando o pedido, e a orquestração não sabe qual instância do aplicativo o publicou. Devido a esse desacoplamento, o orquestrador não pode fornecer atualizações de progresso de forma síncrona.

Para informar de volta o status do pedido, cada aplicação remetente fornece sua própria fila de resposta privada do Barramento de Serviço com controle de acesso. A solicitação enviada à atividade de envio inclui o identificador dessa fila, que a atividade de envio registra no registro do armazenamento de estado do pedido para que o orquestrador possa postar na fila correta em vez de transmitir. O orquestrador então posta mensagens de status, como solicitação recebida, ordem concluída ou ordem que falhou nessa fila, incluindo a OrderID de modo que o aplicativo possa correlacionar cada mensagem com a solicitação original.

Tecnologias de suporte

Mapeie as funções lógicas do padrão para serviços que se ajustam ao fluxo de trabalho e aos requisitos operacionais:

• Agendador: Use Durable Functions para orquestração com abordagem code-first ou Aplicativos Lógicos do Azure para fluxos de trabalho visuais e integração baseada em conectores.

• Mensagens do agente: Use as filas do Barramento de Serviço para mensagens assíncronas de solicitação e resposta.

• Repositório de estado: Use Azure Cosmos DB para o estado do documento ou Banco de Dados SQL do Azure para transações de estado relacional e de registro cruzado.

• Supervisor: Use um gatilho de temporizador de Funções para verificações leves ou um trabalho de Aplicativos de Contêiner quando precisar de um tempo de execução de contêiner.

• Registro de compensação: Armazene registros de compensação com o estado da tarefa ou em Armazenamento de Tabelas do Azure ou Armazenamento de Blobs.

Próximas Etapas 

• Escolha entre Azure Functions e Aplicativos Lógicos do Azure para orquestração de fluxo de trabalho.
• Versione as orquestrações do Durable Functions para proteger fluxos de trabalho em andamento durante as implantações.
• Evite a perda de mensagens e o processamento duplicado no Barramento de Serviço do Azure combinando liquidação de mensagens, idempotência e tratamento de mensagens não entregues.

Recursos relacionados

Os seguintes padrões também serão relevantes durante a implementação desse padrão:

• Padrão de repetição. Um Agente pode usar esse padrão para tentar novamente de forma transparente uma operação que acessa um serviço ou recurso remoto e falhou anteriormente. Use-o quando a causa da falha deve ser transitória e pode ser corrigida por uma repetição.

• Padrão Circuit Breaker. Um agente que se conecta a um serviço ou recurso remoto pode usar esse padrão para lidar com falhas que levam um tempo variável para corrigir, de modo que chamadas repetidas não se acumulam em relação a uma dependência que é improvável de responder.

• Padrão de transação compensatória. Se um Agendador não puder concluir seu fluxo de trabalho com êxito, o trabalho já executado talvez precise ser desfeito. O padrão Compensating Transaction descreve como desfazer esse trabalho para operações que seguem o modelo de consistência eventual, comum em processos de negócios de longa duração que um Scheduler coordena.

• Padrão de eleição de líder. Quando várias instâncias do Supervisor são executadas simultaneamente, elas devem ser coordenadas para que não concorram para recuperar a mesma etapa com falha. O padrão de eleição de líder descreve como eleger um único coordenador para esse trabalho.