Como é que o circuit breaker contém uma ferramenta externa com falhas num fluxo de trabalho de um agente local?

Eva Wong é a Redatora Técnica e e entusiasta residente na ZimaSpace. Uma geek de longa data com paixão por homelabs e software de código aberto, ela é especialista em traduzir conceitos técnicos complexos em guias acessíveis e práticos . Eva acredita que o auto-hospedagem deve ser divertida, não intimidante. Através dos seus tutoriais, ela capacita a comunidade adesmistificar configurações de hardware , desde a construção do seu primeiro NAS até dominar os contêineres Docker., from building their first NAS to mastering Docker containers.

A interrupção de circuito contém uma ferramenta externa em falha ao interromper chamadas repetidas, devolver um resultado controlado e verificar a recuperação antes de restaurar o tráfego normal.

Um agente local pode depender de um modelo na nuvem, de uma API de pesquisa, de um serviço de notificações ou de uma ponte remota para uma casa inteligente, enquanto o resto do seu fluxo de trabalho funciona corretamente. Sem um limite de contenção, uma dependência lenta pode consumir o orçamento de tempo do agente e provocar mais tentativas. Um disjuntor transforma essa condição remota incerta num estado local explícito sobre o qual o orquestrador pode raciocinar.

O disjuntor fica entre a seleção da ferramenta e a execução externa

Normalmente, um agente seleciona uma ferramenta, valida os respetivos argumentos e entrega a chamada a um executor, enquanto a interrupção de circuito acrescenta um invólucro com estado nesse último limite. Não altera o que o modelo solicitou; decide se o executor deve contactar a dependência, rejeitar localmente a tentativa ou permitir uma verificação de recuperação limitada.

O invólucro observa as chamadas concluídas e classifica resultados como sucesso, tempo limite, falha de transporte, limitação de taxa ou outro sinal de falha configurado. Um padrão de disjuntor convencional envolve chamadas remotas, monitoriza falhas, abre após atingir um limiar e, mais tarde, permite pedidos de teste, mantendo a saúde da dependência fora do julgamento do modelo ao nível do prompt.

Por conseguinte, o resultado imediato não é simplesmente uma exceção da ferramenta. É um resultado de orquestração estruturado que contém o estado do disjuntor, indica se a execução foi tentada e identifica quais os caminhos de continuação que permanecem autorizados.

As falhas recentes são comprimidas numa transição de estado

Enquanto está fechado, o disjuntor deixa passar as chamadas e regista apenas os resultados relevantes para a sua política, pelo que um único tempo limite isolado não desativa necessariamente uma ferramenta útil. As implementações avaliam normalmente uma contagem recente, uma taxa ou uma janela temporal, abrindo apenas quando esses dados locais ultrapassam o limiar configurado de falhas ou de chamadas lentas.

O limiar converte muitos eventos ruidosos numa decisão de controlo estável. Um limiar da taxa de erros pode limitar a criação contínua de ligações durante uma falha de rede, em vez de permitir que cada operação solicitada estabeleça outra ligação condenada ao fracasso.

O que conta como falha deve corresponder ao contrato da ferramenta. Uma recusa de autenticação, argumentos malformados e um recurso permanentemente inexistente exigem normalmente um tratamento diferente do aplicado à latência, à indisponibilidade temporária ou à limitação de taxa.

Um limiar percentual também precisa de observações suficientes para ser significativo. Abrir após uma única falha torna instável uma ferramenta pouco utilizada, enquanto esperar por uma amostra grande pode deixar uma dependência que falha frequentemente ativa durante demasiado tempo. Por isso, a janela de amostragem e o requisito de chamadas mínimas devem pertencer à política do disjuntor, não ao modelo de linguagem.

Um circuito aberto transforma a espera remota numa falha local

Depois de o disjuntor abrir, o executor deixa de contactar essa dependência durante um intervalo de arrefecimento explícito, pelo que as novas tentativas falham localmente em vez de aguardarem outro tempo limite remoto. As ferramentas locais saudáveis, as etapas de recuperação e os turnos de raciocínio podem continuar sem herdar a latência da dependência em falha.

Este caminho de falha rápida contém tanto a pressão sobre os recursos como o atraso, porque chamadas remotas repetidas podem manter sockets, posições de trabalho, memória ou tarefas em fila ocupados enquanto aguardam. Rejeitar operações antes de estas alocarem mais capacidade para chamadas externas reduz o esgotamento de recursos durante uma interrupção persistente.

A contenção é seletiva, não global. Um disjuntor deve normalmente abranger uma única dependência e, muitas vezes, uma única classe de operações, porque as leituras e as escritas podem ter custos de falha diferentes.

As tentativas e os tempos limite alteram o que o disjuntor observa

Uma nova tentativa trata uma falha considerada transitória, enquanto um disjuntor memoriza que as falhas se tornaram suficientemente persistentes para justificar parar de tentar, pelo que a sua ordem altera os dados observados pelo disjuntor. As tentativas dentro de uma execução protegida podem contar como uma única chamada lógica, enquanto as tentativas fora do disjuntor podem acrescentar cada uma outra amostra de falha.

Os tempos limite também determinam quando uma chamada lenta se torna uma amostra de falha. Os padrões de resiliência separam tempos limite, novas tentativas e disjuntores, porque cada controlo é responsável por um limite de falha diferente.

Esta separação torna-se fundamental quando a ferramenta tem efeitos secundários não idempotentes. Os mesmos ciclos repetidos de chamadas de ferramentas podem ter origem em decisões do modelo ou em camadas de novas tentativas abaixo do modelo, e um disjuntor não consegue provar se uma escrita cujo tempo limite foi excedido já alterou o sistema externo.

Por isso, um caminho de execução seguro regista separadamente o orçamento de novas tentativas e o estado do disjuntor, para que o orquestrador possa explicar se uma ação nunca foi tentada, foi tentada uma vez ou foi bloqueada após falhas repetidas da dependência.

As alternativas preservam o significado do fluxo de trabalho sem fingir que a ferramenta funcionou

A abertura do circuito apenas responde à questão de saber se a ferramenta principal pode ser executada, enquanto o orquestrador continua a precisar de uma política de continuação que preserve a intenção do utilizador. Dependendo da tarefa, pode devolver resultados parciais, utilizar dados de leitura em cache, mudar de fornecedor, colocar a tarefa em fila, solicitar revisão humana ou parar.

Uma alternativa deve incluir metadados de degradação, em vez de se fazer passar pelo resultado original. As etapas seguintes podem restringir ações de alto impacto quando trabalham com conteúdo antigo em cache ou dados substitutos.

Algumas chamadas não têm uma alternativa segura. Uma notificação pode ser colocada em fila, mas um comando de controlo de uma porta não deve ser substituído por um estado presumido, e uma eliminação de cópia de segurança não deve ser inferida a partir de um inventário em cache.

As verificações em estado semiaberto restauram o acesso sem libertar uma onda de novas tentativas

Um circuito aberto não pode permanecer fechado ao tráfego indefinidamente, porque a ferramenta externa pode recuperar. Por isso, após um intervalo de arrefecimento, o disjuntor permite apenas um pequeno número de chamadas de teste. A carga de trabalho normal continua bloqueada até essas verificações fornecerem provas de que a dependência pode voltar a aceitar tráfego em segurança.

As verificações bem-sucedidas fazem o disjuntor avançar para o estado fechado, enquanto as verificações falhadas o reabrem e reiniciam o período de espera. Monitorizar os estados do disjuntor torna visíveis as aberturas repetidas e os longos períodos de recuperação, em vez de os ocultar dentro dos erros das ferramentas.

Uma verificação de saúde bem-sucedida não é automaticamente uma repetição segura de uma escrita anterior. A dependência pode responder a uma verificação de leitura enquanto o efeito secundário anterior permanece ambíguo, pelo que as chaves de idempotência, os pontos de controlo, a reconciliação e os limites de aprovação continuam a determinar se as ações interrompidas podem ser retomadas.

A admissão de verificações é intencionalmente mais restrita do que o tráfego normal, porque as provas de recuperação tornam-se menos úteis se centenas de pedidos pendentes atingirem a dependência em simultâneo. Limitar as verificações concorrentes impede que o próprio disjuntor crie o pico que faria uma ferramenta recém-recuperada parecer novamente insalubre.

Centro de Tecnologia e IA

Mais para Ler

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.