Padrão do Supervisor de Agente do Scheduler

Coordenar um conjunto de ações distribuídas como uma única operação lógica para que a operação como um todo tenha sucesso ou falhe. Trate as falhas de forma transparente, ou então desfaça o trabalho concluído. Esta abordagem acrescenta resiliência aos sistemas distribuídos ao recuperar de exceções transitórias, falhas de maior duração e falhas de processos que interrompem fluxos de trabalho em várias etapas orquestrados entre serviços e recursos remotos.

Contexto e problema

As aplicações frequentemente realizam tarefas que abrangem vários passos, e alguns passos podem invocar serviços remotos ou aceder a recursos remotos sob a orquestração da lógica da aplicação. A interação com qualquer coisa fora do processo local expõe a tarefa a uma série de modos de falha. A lógica de orquestração deve lidar com estes modos de falha sem perder a integridade da operação como um todo.

Podes lidar com situações simples, como falhas transitórias que se resolvem sozinhas, usando abordagens como o padrão Retry. Quando as falhas são mais permanentes, ou quando o próprio orquestrador falha, o sistema deve restaurar um estado consistente a partir de registos duráveis e garantir a integridade da operação global.

Solução

O padrão Scheduler Agent Supervisor coordena uma tarefa distribuída em vários passos através de três atores lógicos. Estes atores orquestram os passos a executar como parte da tarefa global e tratam tanto de execuções bem-sucedidas como de execuções falhadas.

Agendador

O Agendador organiza os passos que compõem a tarefa e orquestra a sua execução. O Scheduler é responsável por combinar passos num pipeline ou fluxo de trabalho, executando-os na ordem correta. À medida que cada etapa avança, o Scheduler regista o seu estado, como passo ainda não iniciado, passo em execução ou passo concluído. O estado também inclui um prazo de conclusão que limita o tempo que a etapa pode demorar.

Quando uma etapa necessita de um serviço ou recurso remoto, o Scheduler invoca um Agente apropriado e transmite-lhe os detalhes do trabalho. O Scheduler comunica normalmente com os Agentes através de mensagens assíncronas de pedido e resposta, muitas vezes implementadas sobre filas. Pode usar outras tecnologias de mensagens distribuídas em vez disso.

Agente

Um Agente encapsula uma chamada a um serviço remoto ou o acesso a um recurso remoto a que um passo de tarefa faz referência. Cada Agente normalmente encapsula chamadas a um único serviço ou recurso e implementa a lógica adequada de gestão de erros e de repetição dentro do prazo de conclusão que o Agendador impõe. Quando há lógica de repetição, o Agente transmite um identificador estável em todas as tentativas de repetição. Um serviço a jusante pode usar isto para deduplicação.

Se diferentes etapas do fluxo de trabalho usarem serviços ou recursos distintos, cada etapa pode referenciar um Agente diferente. Esse mapeamento é um detalhe de implementação do padrão. Para obter orientações sobre a conceção de estratégias de retentativa, consulte Melhores práticas para o tratamento de falhas transitórias.

Supervisor

O Supervisor monitoriza o estado dos passos que o Agendador realiza. O Supervisor executa periodicamente a uma frequência especificada pela carga de trabalho e examina o estado dos passos que o Scheduler registou. Se o Supervisor encontrar etapas que ultrapassaram o tempo limite ou falharam, providencia que o Agente apropriado recupere a etapa, ou desencadeia outra ação corretiva que pode incluir a modificação do estado da etapa. O Supervisor só solicita estas ações de recuperação. O Scheduler e os Agentes implementam-nos.

Interações

O Scheduler, o Agent e o Supervisor são componentes lógicos, e a sua implementação física depende da tecnologia que utiliza. Por exemplo, pode implementar vários Agentes lógicos como parte de um único serviço web ou como atividades dentro do mesmo trabalhador alojado.

O Scheduler mantém o progresso da tarefa e o estado de cada passo num repositório de dados persistente chamado repositório de estado. O Supervisor utiliza esta informação para determinar se um passo falhou. O diagrama seguinte mostra a relação entre o Agendador, os Agentes, o Supervisor e a loja do estado.

• O Scheduler organiza e executa os passos que compõem a tarefa como um fluxo de trabalho.
• Um passo no fluxo de trabalho pode enviar um pedido a um Agente para aceder a um recurso remoto ou invocar um serviço remoto. Os pedidos e respostas são normalmente enviados de forma assíncrona.
• Um Agente acede ao recurso ou serviço remoto. O agente deve incluir lógica de tratamento de erros e mecanismos de repetição.
• O Agendador mantém o estado de cada etapa no armazenamento de estado à medida que esta inicia e se conclui.
• O Supervisor monitoriza o estado dos passos na loja do estado e pode pedir atualização do estado de um passo.
• O Supervisor pede ao Agendador que tente novamente um passo falhado.

Quando a aplicação está pronta para executar uma tarefa, submete um pedido ao Scheduler. O Scheduler regista o estado inicial da tarefa e os seus passos, como o passo ainda não iniciado, na memória de estados, e depois começa a executar as operações definidas pelo fluxo de trabalho. À medida que o Agendador inicia cada etapa, atualiza o estado dessa etapa, como etapa em execução, no repositório de estados.

Se um passo fizer referência a um serviço ou recurso remoto, o Scheduler enviará uma mensagem ao Agente adequado. A mensagem contém a informação de que o Agente precisa para invocar o serviço ou aceder ao recurso, juntamente com o prazo de conclusão e o número de tentativas permitidas para a operação.

Um Agente pode implementar a lógica de repetição adequada à sua tarefa, mas, se o Agente não concluir o seu trabalho dentro do prazo de conclusão, o Agendador assume que a operação falhou e deixa de aguardar uma resposta. O Agente deve cumprir o prazo e não pode iniciar novos efeitos secundários após o prazo expirar, embora o trabalho já em curso possa continuar.

Se o Agente concluir a operação com sucesso, devolverá uma resposta ao Scheduler. O Scheduler atualiza o estado, para passo concluído , por exemplo, e inicia o passo seguinte. Este processo continua até que toda a tarefa seja concluída.

O Scheduler deve ignorar qualquer resposta tardia, e o Agente não pode tentar a recuperação do fluxo de trabalho por si só. Se o próprio Agente falhar, o Agendador também não recebe resposta. O estado no armazenamento de estado não faz distinção intencionalmente entre uma etapa que atinge o tempo limite e uma etapa que falha.

Quando um passo excede o tempo limite ou falha, o registo do armazenamento de estado continua a mostrar o passo como em execução, mas com a hora limite de conclusão expirada. O Supervisor verifica registos nesta condição e organiza a recuperação.

O Supervisor também precisa de impedir que o mesmo passo volte a tentar indefinidamente. O Supervisor mantém uma contagem de retentativas para cada passo, juntamente com as informações de estado no armazenamento de estado. Se a contagem ultrapassar um limiar pré-definido, o Supervisor pode ser configurado para esperar um período prolongado antes de pedir ao Agendador que tente novamente o passo, caso a falha subjacente seja resolvida durante esse intervalo.

Uma possível estratégia do Supervisor é estender o valor complete-by e enviar uma mensagem ao Scheduler a indicar o passo que excedeu o tempo limite, para que este o possa tentar novamente. Esta conceção exige que a lógica das etapas seja idempotente, porque o mesmo trabalho pode ser realizado mais do que uma vez.

Em alternativa, o Supervisor pode pedir ao Agendador que desfaça toda a tarefa ativando uma transação compensatória. Esta abordagem depende de o Scheduler e os Agentes fornecerem informação suficiente para implementar operações compensatórias para cada etapa que já tenha sido concluída com êxito. O registo de compensação precisa de ordenação e durabilidade, porque as operações de compensação normalmente decorrem na ordem inversa dos passos concluídos. Uma operação compensatória que, por si só, falha deixa a tarefa num estado que não está nem concluído nem completamente desfeito. O armazenamento de estado deve ser capaz de representar esta condição para que os operadores possam localizá-la e investigá-la.

Numa implementação real deste padrão, múltiplas instâncias do Scheduler podem correr em simultâneo, cada uma a lidar com um subconjunto de tarefas. O sistema pode também executar múltiplas instâncias de cada Agente, ou múltiplos Supervisores. Quando há mais do que um Supervisor ativo, os Supervisores têm de coordenar para não competir para recuperar a mesma etapa ou tarefa falhada. O padrão de eleição para líderes é uma forma de coordenar os supervisores.

O principal benefício deste padrão é que o sistema se mantém resiliente tanto a falhas transitórias como irrecuperáveis, e pode construí-lo para ser auto-recuperável. Se um Agente ou o Agendador falhar, pode iniciar uma nova instância, e o Supervisor pode organizar a retomada da tarefa afetada. Se o próprio Supervisor falhar, outra instância pode assumir onde a anterior parou. Quando o Supervisor é executado de acordo com uma programação, é iniciada automaticamente uma nova instância no intervalo seguinte. Também pode replicar a loja estatal para maior resiliência.

Problemas e considerações

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

• Complexidade da implementação. Este padrão é difícil de implementar e requer testes minuciosos de todos os modos de falha que o sistema possa experienciar. Planeie os testes de injeção de falhas juntamente com os testes funcionais.

• Retentar amplificação. Limites independentes de novas tentativas ao nível do Agente, do runtime de orquestração, da biblioteca cliente, da camada de mensagens e do Supervisor multiplicam o número de chamadas para uma dependência com falha. Defina o Scheduler como responsável por um orçamento persistente de novas tentativas de ponta a ponta e configure ou desative as novas tentativas nas restantes camadas, de modo que o máximo combinado destas não possa exceder esse orçamento.

• Controlo de admissão. O padrão não limita a quantidade de trabalho que pode haver em voo ao mesmo tempo. Como o agendador foi concebido para nunca perder o trabalho que aceita, um serviço subsequente lento ou com falhas origina um número crescente de registos de processamento, em vez de retropressão visível para o cliente que submete. O caminho de submissão necessita do seu próprio controlo de admissão, como uma fila limitada, um limite para tarefas em voo concorrentes ou rejeição de novas submissões quando o atraso pendente ultrapassa um limiar. Esta contrapressão ajuda a garantir que um incidente a jusante não cause silenciosamente uma acumulação sem limites no armazenamento de estado.

• Durabilidade do estado de recuperação. A lógica de recuperação e repetição do Scheduler é complexa e depende do estado mantido no repositório de estado. Também pode ser necessário registar a informação necessária para conduzir uma transação compensatória numa loja duradoura, e a própria transação compensatória pode falhar. Trate a loja estatal e qualquer registo de transações compensatórias como ativos duráveis de primeira classe. Estes ativos devem sobreviver ao Scheduler, aos Agentes e ao Supervisor, e devem ser recuperáveis independentemente dos trabalhadores que lhes escrevem.

  Importante

  O registo de compensação deve herdar a classificação de dados dos dados que tem de rastrear. Se uma etapa aceitar dados de clientes ou de pagamentos, o registo da transação de compensação herda esse nível de sensibilidade e as regras de retenção associadas.

• Problema de escrita em duplicado. Submeter uma tarefa envolve normalmente mais do que uma gravação persistente. Por exemplo, uma tarefa pode precisar de escrever tanto um registo da aplicação numa base de dados empresarial como um registo inicial no armazenamento de estado. Estas escritas não partilham uma transação, por isso, se apenas uma escrita for concluída, um registo de aplicação pode não ter registo de armazenamento de estado ou um registo de armazenamento de estado pode não ter registo de aplicação. O padrão atual em si não resolve este problema de escrita dupla. Soluções comuns incluem efetuar uma escrita dentro de uma orquestração persistente com uma eliminação de compensação em caso de falha, aplicar o padrão Transactional Outbox ou usar um identificador estável, como o próprio ID de tarefa da aplicação, para garantir que cada escrita possa ser repetida em segurança.

• Versionamento de fluxo de trabalho e estado. Tarefas de longa duração podem estender-se por várias implementações, pelo que alterações na lógica do fluxo de trabalho ou no estado persistido podem impedir a reexecução, a recuperação ou a compensação do trabalho em curso. Controle a versão de ambos os contratos e mantenha o código e a gestão do 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 bloquear a meio do processo. A máquina de estados que o Scheduler mantém precisa de representar todos esses estados. Se o erro for o único estado terminal, uma compensação bloqueada parece idêntica a um passo que falhou antes da compensação ser executada, e os operadores perdem o sinal de que precisam para intervir. Distinga-se compensação em progresso, compensação concluída e compensação falhada no esquema do estado de armazenamento, em vez de os colapsar num único estado de Erro .

• Cadência do supervisor. A frequência com que o Supervisor deve ser usado é uma troca deliberada. Deve ser executado com frequência suficiente para que etapas que falhem ou excedam o tempo limite não bloqueiem o processamento durante um período prolongado, mas não com tanta frequência que passe a constituir uma fonte de carga e custos para o armazenamento de estado. Ajuste o intervalo em função da duração típica do passo e do atraso aceitável de deteção para um passo bloqueado, e volte a vê-lo à medida que o volume do fluxo de trabalho aumenta.

• Idempotência gradual. Um Agente pode executar um passo mais de uma vez. Por exemplo, o Supervisor pode prolongar o prazo de conclusão e pedir ao Agendador que repita uma etapa cuja execução original já produziu um efeito que o Agendador nunca chegou a ver. Portanto, a lógica que implementa cada passo deve ser idempotente.

• Visibilidade operacional. O comportamento em tempo de execução do padrão está em transições de armazenamento de estados em vez de respostas síncronas. Os operadores só conseguem ver o que a loja estatal e os trabalhadores emitem. Decida o que o Agendador, os Agentes e o Supervisor devem emitir, e quais os limiares que devem desencadear alertas.

• Reinício e recuperação do agendador. Se o Scheduler reiniciar após uma falha, ou se o workflow que o Scheduler está a executar terminar inesperadamente, o Scheduler deve ser capaz de determinar o estado de qualquer tarefa que estava a tratar quando falhou e retomar a tarefa a partir desse ponto. Os detalhes de implementação desta recuperação são tipicamente específicos do sistema. Por exemplo, um Scheduler construído sobre um runtime de orquestração com pontos de verificação pode confiar no runtime para reexecutar o histórico e retomar a execução, enquanto um Scheduler personalizado tem de reconstruir o estado em curso a partir do próprio armazenamento de estado. Se uma tarefa não puder ser recuperada, o trabalho já realizado para essa tarefa pode ter de ser desfeito, o que pode exigir uma transação compensatória.

Quando utilizar este padrão

Utilize este padrão quando:

• Um processo corre numa carga de trabalho distribuída e deve manter-se resiliente tanto a falhas de comunicação como a falhas operacionais entre os serviços e recursos que coordena.

• Os trabalhos em segundo plano orquestram fluxos de trabalho em múltiplos passos cujos passos envolvem serviços ou recursos remotos, e os fluxos de trabalho como um todo devem ser concluídos ou desfeitos de forma limpa. Exemplos comuns incluem o processamento de encomendas e o provisionamento de recursos. Para mais informações, consulte Boas práticas para tarefas em segundo plano.

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

• A tarefa não invoca serviços remotos nem acede a recursos remotos. Não existe uma superfície distribuída de falha associada às funções de Scheduler, Agent e Supervisor que seja necessário mitigar. A sobrecarga de coordenação do padrão acrescenta custos sem qualquer benefício de resiliência.

Design da carga de trabalho

Avalie como utilizar o padrão Scheduler Agent Supervisor no design de uma carga de trabalho para abordar os objetivos e princípios abordados nos pilares do Azure Well-Architected Framework. A tabela a seguir fornece orientação sobre como esse padrão suporta as metas de cada pilar.

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

Exemplo

Este exemplo implementa uma aplicação web que implementa um sistema de comércio eletrónico no Microsoft Azure. Os utilizadores navegam pelos produtos e fazem encomendas através de uma interface web, e os trabalhadores em segundo plano no caminho de processamento de encomendas chamam um serviço remoto que é propenso a falhas transitórias e de longa duração. O processamento de ordens implementa o padrão Scheduler Agent Supervisor utilizando Durable Functions, Azure Service Bus e Azure Cosmos DB.

Uma atividade de submissão escreve para a base de dados de encomendas e para um arquivo de estado do Cosmos DB, um orquestrador do Durable Functions assume registos de estado pendentes e envia trabalho para um Agente através de um par de filas de pedido e de resposta do Service Bus, e um Supervisor analisa o arquivo de estado à procura de instantes expirados CompleteBy.

O diagrama seguinte mostra uma visão geral da solução Azure.

1. A aplicação envia um pedido para uma fila para processar a encomenda.
2. O processo de submissão recupera pedidos, insere detalhes das encomendas na base de dados de encomendas e gera um registo para a encomenda no stock de estado.
3. O Agendador procura, no armazenamento de estado, uma ordem com LockedBy definido como nulo, e a lógica do fluxo de trabalho no Agendador processa a ordem.
4. A lógica do fluxo de trabalho envia pedidos e recebe respostas dos Agentes através de filas de mensagens.
5. As tarefas de fluxo de trabalho usam Agentes para invocar o serviço remoto.
6. O Supervisor procura ordens com um valor expirado CompleteBy e atualiza esse valor para permitir que o Agendador tente novamente o processo.

Submissão

Quando um cliente faz uma encomenda, a interface web publica uma mensagem de encomenda numa fila do Service Bus. Uma função de submissão recebe a mensagem em modo PeekLock, insere os detalhes da encomenda na base de dados de encomendas e cria um registo de armazenamento de estado para o processo de encomenda.

Como a base de dados de encomendas e a base de dados criada no Azure Cosmos DB são recursos diferentes e não partilham uma transação, a função trata cada operação de escrita como sendo independentemente idempotente. A função usa o ID da ordem como chave estável, cria qualquer um dos registos quando este está em falta, e só aceita um registo existente depois de verificar se os seus dados de ordem imutáveis correspondem à mensagem. Dados contraditórios fazem com que a função faça uma letra morta da mensagem e alerte um operador, em vez de sobrescrever um registo.

O registo contém os seguintes campos:

Quando a atividade de submissão escreve o registo pela primeira vez, copia OrderID da nova encomenda, define LockedBy e CompleteBy como null, define ProcessState como Pending e define FailureCount como 0.

Scheduling

O Scheduler é um orquestrador de Durable Functions. Uma função inicial sonda o Azure Cosmos DB para registos onde LockedBy é nulo e ProcessState é Pending. A função cria um ID de instância de orquestração específico para a tentativa a partir OrderID e o número da tentativa seguinte. Uma atualização condicional define ProcessState para Processing e LockedBy para esse ID de instância antes de o starter agendar a orquestração. Esta alegação impede que dois titulares marquem a mesma tentativa.

Cada atualização da orquestração também verifica se LockedBy continua a corresponder ao identificador da instância. Esta verificação impede que uma tentativa expirada altere o estado da tentativa de substituição. O paralelismo entre ordens resulta da execução simultânea de várias instâncias de orquestração, não do paralelismo dentro de uma única ordem. A orquestração define CompleteBy e orienta o fluxo de trabalho.

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

Execution

O Agente pode ser uma função de atividade quando o trabalho é de curta duração e é executado na mesma aplicação de funções, ou pode ser um processo de trabalho separado, acedido através de um par de filas de pedido/resposta do Service Bus, quando é executado num ambiente de execução diferente ou além de um limite de confiança. Em ambos os casos, o orquestrador coloca um temporizador persistente em concorrência com a resposta do Agente para detetar quando é atingido o CompleteBy prazo limite.

Quando o Agente é contactado através do Service Bus, uma função acionada por fila recebe a resposta e utiliza 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 duplicações de eventos externos ao ativar a deteção de duplicados e ao definir um MessageId estável em cada pedido, para que o Service Bus possa descartar duplicados introduzidos por novas tentativas.

Se o Agente receber uma resposta do serviço remoto antes de o temporizador persistente disparar, o Agente devolve o resultado ao orquestrador. O orquestrador conclui a etapa e atualiza ProcessState para Processed apenas se LockedBy continuar a identificar a orquestração atual. Se o temporizador disparar primeiro, o orquestrador considera o passo como falhado, para de esperar e completa sem alterar o registo de estado.

O Agente, de forma cooperativa, deixa de desencadear novos efeitos secundários depois do seu próprio prazo limite, mas o trabalho já em curso poderá continuar. O registo do arquivo de estado permanece então no estado Processing, com um valor CompleteBy expirado, permitindo ao Supervisor organizar a recuperação. Utilize idempotência ou um token de fencing imposto pelo sistema de destino para evitar que uma tentativa concorrente duplique ou entre em conflito com um efeito lateral.

Se o Agente detetar uma falha irrecuperável e não transitória ao contactar o serviço remoto, devolve uma resposta de erro ao orquestrador. O orquestrador define ProcessState como Error e gera um evento que alerta um operador, que pode investigar a falha e reenviar a etapa de processamento que falhou.

Supervisão

O Supervisor consulta periodicamente o armazenamento de estado do Azure Cosmos DB à procura de encomendas no estado Processing com CompleteBy expirado. Como OrderID é a chave de partição, esta consulta alcança todas as partições físicas mesmo quando ProcessState e CompleteBy estão indexados. O processo limita cada varredura por uma CompleteBy janela temporal, um número máximo de resultados e paginação do token de continuação, e monitoriza a sua carga da unidade de pedido (RU).

As cargas de trabalho de maior dimensão 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 registo expirado, utiliza uma atualização condicional que verifica o valor expirado LockedBy antes de incrementar FailureCount. Se FailureCount estiver abaixo de um limiar configurado, o Supervisor reinicia LockedBy para null, atualiza-se CompleteBy com um novo tempo de expiração e volta ProcessState para Pending, o que permite ao iniciador agendar uma nova tentativa. Se FailureCount ultrapassar o limiar, o Supervisor trata a falha como não transitória, define ProcessState para Error, e gera um evento que alerta um operador.

Relatórios de estado

O orquestrador poderá também precisar de manter a aplicação que submeteu o pedido informada do progresso e do estado final, o que o diagrama não mostra. A aplicação e o orquestrador são deliberadamente desacoplados. A aplicação não sabe qual instância de orquestração está a tratar da ordem, e a orquestração não sabe qual instância de aplicação a publicou. Devido a este desacoplamento, o orquestrador não consegue devolver atualizações de progresso de forma síncrona.

Para comunicar o estado da encomenda, cada aplicação que a submete disponibiliza a sua própria fila de respostas privada do Service Bus com controlo de acesso. O pedido enviado para a atividade de submissão inclui o identificador dessa fila, que a atividade de submissão regista no registo de estado da ordem para que o orquestrador possa publicar na fila correta em vez de transmitir. O orquestrador publica então nessa fila mensagens de estado como pedido recebido, ordem concluída ou ordem falhada, incluindo OrderID, para que a aplicação possa correlacionar cada mensagem com o pedido original.

Tecnologias de apoio

Mapeie os papéis lógicos do padrão para serviços que se ajustem ao seu fluxo de trabalho e requisitos operacionais:

• Scheduler: Utilize Durable Functions para orquestração baseada em código ou Azure Logic Apps para fluxos de trabalho visuais e integração baseada em conectores.

• Mensagens do agente: Utilize filas do Service Bus para mensagens assíncronas de pedidos e respostas.

• Armazenamento de estados: Use o Azure Cosmos DB para o estado do documento ou o Base de Dados SQL do Azure para transações relacionais e entre registos.

• Supervisor: Utilize um acionador de temporizador do Functions para análises ligeiras ou uma tarefa do Container Apps quando precisar de um ambiente de execução de contentores.

• Registo de compensação: Armazene os registos de compensação juntamente com o estado da tarefa ou no Armazenamento de Tabelas do Azure ou no Armazenamento de Blobs do Azure.

Passos seguintes

• Escolha entre Funções do Azure e Azure Logic Apps para orquestração de fluxos de trabalho.
• Versione as orquestrações do Durable Functions para proteger os fluxos de trabalho em execução durante as implementações.
• Evite a perda de mensagens e o processamento duplicado no Azure Service Bus combinando a liquidação de mensagens, a idempotência e o tratamento de mensagens mortas.

Recursos relacionados

Os padrões a seguir também podem ser relevantes quando você implementa esse padrão:

• Padrão de Repetição. Um Agente pode usar este padrão para tentar de forma transparente uma operação que acede a um serviço ou recurso remoto e que falhou anteriormente. Use-o quando se espera que a causa da falha seja transitória e possa ser corrigida por uma nova tentativa.

• Padrão Circuit Breaker. Um Agente que se liga a um serviço ou recurso remoto pode usar este padrão para lidar com falhas que demoram um tempo variável a ser corrigidas, para que chamadas repetidas não se acumulem contra uma dependência que dificilmente responderá.

• Padrão de Transação Compensatória. Se um Scheduler não conseguir completar o seu fluxo de trabalho com sucesso, o trabalho já realizado pode ter de ser desfeito. O padrão de Transação Compensatória descreve como desfazer esse trabalho para operações que seguem o modelo de consistência eventual, que é comum nos processos de negócio de longa duração coordenados por um Scheduler.

• Padrão de Eleição de Coordenador. Quando várias instâncias de Supervisor são executadas em simultâneo, têm de se coordenar para não entrarem em competição para recuperar o mesmo passo que falhou. O padrão de Eleição de Líderes descreve como eleger um único coordenador para esse trabalho.