3
respostas

[Dúvida] Erro no circuit breaker

Nao estou conseguindo anexar por aqui o erro do postman, mas quando meu eu desligo meu ms de pagamento, na requisicao http://localhost:8082/pagamentos-ms/pagamentos/2/confirmar retorna como:

{
    "timestamp": "2023-11-14T18:59:39.060+00:00",
    "path": "/pagamentos-ms/pagamentos/2/confirmar",
    "status": 500,
    "error": "Internal Server Error",
    "requestId": "39306825-63"
}

E quando ativo o ms novamente... o request http://localhost:8082/pagamentos-ms/pagamentos/2 retorna e nao o status novo CONFIRMADO_SEM_INTEGRACAO,

{
    "id": 2,
    "valor": 500.00,
    "nome": "Jacqueline",
    "numero": "12345678",
    "expiracao": "10/29",
    "codigo": "123",
    "status": "CONFIRMADO",
    "formaDePagamentoId": 1,
    "pedidoId": 1
}
public void confirmarPagamento(Long id){
        Optional<Pagamento> pagamento = repository.findById(id);

        if (!pagamento.isPresent()) {
            throw new EntityNotFoundException();
        }

        pagamento.get().setStatus(Status.CONFIRMADO);
        repository.save(pagamento.get());
        pedido.atualizaPagamento(pagamento.get().getPedidoId());
    }


    public void alteraStatus(Long id) {
        Optional<Pagamento> pagamento = repository.findById(id);

        if (!pagamento.isPresent()) {
            throw new EntityNotFoundException();
        }

        pagamento.get().setStatus(Status.CONFIRMADO_SEM_INTEGRACAO);
        repository.save(pagamento.get());
    }

    @PatchMapping("/{id}/confirmar")
    @CircuitBreaker(name = "atualizaPedido", fallbackMethod = "pagamentoAutorizadoComIntegracaoPendente")
    public void confirmarPagamento(@PathVariable @NotNull Long id){
        service.confirmarPagamento(id);
    }


    public void pagamentoAutorizadoComIntegracaoPendente(Long id, Exception e){
        service.alteraStatus(id);
    }
//circuit breaker
resilience4j.circuitbreaker.instances.atualizaPedido.slidingWindowSize: 3
resilience4j.circuitbreaker.instances.atualizaPedido.minimumNumberOfCalls: 2
resilience4j.circuitbreaker.instances.atualizaPedido.waitDurationInOpenState: 50s
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-openfeign</artifactId>
            <version>3.1.2</version>
        </dependency>

        <dependency>
            <groupId>io.github.resilience4j</groupId>
            <artifactId>resilience4j-spring-boot2</artifactId>
            <version>1.7.0</version>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-aop</artifactId>
        </dependency>
3 respostas

Olá! O código fornecido mostra um controlador Spring MVC que tem um método para confirmar um pagamento usando um circuit breaker (resilience4j).

  1. Logs do Microsserviço:

    • Verifique os logs do microsserviço de pagamento para ver se há alguma mensagem de erro ou stack trace quando você desliga o serviço.
  2. Logs do Postman:

    • Mesmo que você não possa anexar diretamente o erro do Postman, verifique se há informações detalhadas na guia "Body" ou "Console" do Postman que podem fornecer mais detalhes sobre o erro.
  3. Verifique o Status HTTP:

    • Confirme se o status HTTP retornado é sempre 500 quando o microsserviço está desligado. Isso pode indicar que o circuit breaker está entrando em ação.
  4. Circuit Breaker:

    • Verifique se o circuit breaker está abrindo e fechando corretamente. Os parâmetros de configuração (slidingWindowSize, minimumNumberOfCalls, waitDurationInOpenState) parecem estar corretos, mas certifique-se de que estão ajustados conforme necessário para o seu caso de uso.
  5. Feign Client (OpenFeign):

    • Certifique-se de que a comunicação entre microsserviços usando Feign está configurada corretamente. Se houver algum problema de comunicação, pode levar a erros 500.
  6. Resilience4j Fallback:

    • Certifique-se de que o método pagamentoAutorizadoComIntegracaoPendente está sendo chamado corretamente como fallback quando o circuit breaker está aberto.
  7. Testes Unitários e Mocking:

    • Certifique-se de que seus testes unitários cobrem os cenários em que o microsserviço de pagamento está desligado. Use ferramentas de mock para simular o comportamento desejado durante os testes.

A solução exata pode depender de mais detalhes, e estou fornecendo sugestões com base nas informações disponíveis. Se possível, forneça mais informações sobre mensagens de erro específicas ou logs para uma análise mais aprofundada.

Opa, verifiquei e ainda assim nao achei nada.. retorna como 200 mesmo com o servico de pagamentos desligado segundo o video... e o status fica como confirmado_sem_integracao. Segue link do repositorio.

https://github.com/lucasbarroscode/lucasfood

O exemplo é:

  1. Você chama o microsserviço de PAGAMENTOS
  2. O microsserviço de PAGAMENTOS chama o microsserviço de PEDIDOS e atualiza o pedido.

Aí, desligando o microsserviço de pedidos, o passo 2 dá erro. Então, você fez o fallback para:

  1. Você chama o microsserviço de PAGAMENTOS
  2. O microsserviço de PAGAMENTOS tenta chamar o microserviço de PEDIDOS, e dá erro
  3. O microsserviço de PAGAMENTOS chama o método fallback "pagamentoAutorizadoComIntegracaoPendente" (que não usa o outro microsserviço).

Então, o microsserviço que você deveria desligar é o de PEDIDOS, não o de PAGAMENTOS.

Se você desligar o microserviço de pagamentos, você realmente não vai conseguir chamá-lo pela API.

Talvez tenha acontecido uma confusão com a aula anterior, na qual deveríamos subir várias instâncias do mesmo serviço. Se desligarmos uma instância, ou se uma instância travar ou cair, tudo (deveria) continuar funcionando por que outras instâncias continuam rodando.

Quer mergulhar em tecnologia e aprendizagem?

Receba a newsletter que o nosso CEO escreve pessoalmente, com insights do mercado de trabalho, ciência e desenvolvimento de software