O documento discute vários mecanismos de tolerância a falhas do Resilience4J, incluindo Rate Limiter para limitar solicitações, Bulkhead para limitar solicitações simultâneas, Time Limiter para definir tempo limite de resposta, Retry para tentativas de solicitação repetidas e Circuit Breaker para interromper fluxos de falha.

1. © 2021 DXC Technology Company. All rights reserved.
Resilience4J
Norberto Hideaki Enomoto
norberto.enomoto@dxc.com

2. December 21, 2021 2
© 2021 DXC Technology Company. All rights reserved.
Resilience4J

3. December 21, 2021 3
© 2021 DXC Technology Company. All rights reserved.
Rate Limiter
O Rate Limiter limita o número de solicitações em um determinado período. Vamos
supor que queremos limitar o número de solicitações em uma API Rest por um
determinado período. Existem vários motivos para limitar o número de solicitações
de uma API, como proteger os recursos de um ataque de negação de serviço,
minimizar a sobrecarga, cumprir um acordo de nível de serviço e muitos outros.

4. December 21, 2021 4
© 2021 DXC Technology Company. All rights reserved.
Rate Limiter

5. December 21, 2021 5
© 2021 DXC Technology Company. All rights reserved.
resilience4j.ratelimiter:
instances:
getMessageRateLimit:
limitForPeriod: 2
limitRefreshPeriod: 5s
Somente 2 requests no período de 5 segundos
Rate Limiter

6. December 21, 2021 6
© 2021 DXC Technology Company. All rights reserved.
Bulkhead
No contexto do mecanismo de tolerância a falhas, se quisermos limitar o número
de solicitações simultâneas, podemos usar o Bulkhead. Usando o Bulkhead,
podemos limitar o número de solicitações simultâneas em um determinado período.
Observe a diferença entre Bulkhead e Rate Limiter. O Rate Limiter nunca fala sobre
solicitações simultâneas, mas o Bulkhead sim. Portanto, usando o Bulkhead,
podemos limitar o número de solicitações simultâneas.

7. December 21, 2021 7
© 2021 DXC Technology Company. All rights reserved.
resilience4j.bulkhead:
instances:
getMessageBH:
maxWaitDuration: 0s
maxConcurrentCalls: 5
• indica que se o número de chamadas simultâneas
exceder 5, ative o método de fallback.
• indica que não espera nada, mostre a resposta
imediatamente com base na configuração.
Bulkhead

8. December 21, 2021 8
© 2021 DXC Technology Company. All rights reserved.
Time Limiter
Time Limiter é o processo de definir um limite de tempo para a resposta de um
microsserviço. Suponha que o microsserviço ‘A’ envie uma solicitação ao
microsserviço ‘B’, ele define um limite de tempo para o microsserviço ‘B’ responder.
Se o microsserviço ‘B’ não responder dentro desse limite de tempo, será
considerado que há alguma falha. O Time limiter é utilizado para chamada
assíncronas, utilizando CompletableFuture

9. December 21, 2021 9
© 2021 DXC Technology Company. All rights reserved.
resilience4j.timelimiter:
instances:
getMessageTL:
timeoutDuration: 1ms
cancelRunningFuture: false
• Indica que o tempo máximo que uma solicitação
pode levar para responder é 1 milissegundo
• Indica que não cancela o Running Completable
Future depois do TimeOut.
Time Limiter

10. December 21, 2021 10
© 2021 DXC Technology Company. All rights reserved.
Retry
Suponha que o microsserviço ‘A’ dependa de outro microsserviço ‘B’. Suponhamos
que o microsserviço ‘B’ seja um serviço defeituoso e sua taxa de sucesso seja de
apenas 50-60%. No entanto, a falha pode ser devido a qualquer motivo, como
serviço não disponível, serviço com bugs que às vezes responde e às vezes não,
ou uma falha de rede intermitente etc. No entanto, neste caso, se o microsserviço
'A' tentar enviar novamente a solicitação 2 a 3 vezes, as chances de obter resposta
aumentam

11. December 21, 2021 11
© 2021 DXC Technology Company. All rights reserved.
resilience4j.retry:
instances:
getInvoiceRetry:
maxAttempts: 5
waitDuration: 2s
retryExceptions:
- org.springframework.web.client.HttpServerErrorException
- org.springframework.web.client.HttpClientErrorException
- java.io.IOException
- org.springframework.web.client.ResourceAccessException
ignoreExceptions:
- io.github.robwin.exception.BusinessException
5 tentativas em um intervalo de 2 segundos
Retry

12. December 21, 2021 12
© 2021 DXC Technology Company. All rights reserved.
Circuit Breaker
Por exemplo, se um microsserviço ‘A’ depende do microsserviço ‘B’. Por algum
motivo, o microsserviço ‘B’ está apresentando um erro. Em vez de chamar
repetidamente o Microsserviço ‘B’, o Microsserviço ‘A’ deve fazer uma pausa (não
chamar) até que o Microservice ‘B’ seja completamente ou parcialmente
recuperado. Usando o Circuit Breaker, podemos eliminar o fluxo de falhas.

13. December 21, 2021 13
© 2021 DXC Technology Company. All rights reserved.
Circuit Breaker

14. December 21, 2021 14
© 2021 DXC Technology Company. All rights reserved.
resilience4j.circuitbreaker:
instances:
getInvoiceCB:
failureRateThreshold: 80
slidingWindowSize: 10
slidingWindowType: COUNT_BASED
minimumNumberOfCalls: 5
automaticTransitionFromOpenToHalfOpenEnabled: true
permittedNumberOfCallsInHalfOpenState: 4
waitDurationInOpenState: 1s
• indica que se 80% das solicitações falharem, abra o circuito,
ou seja, defina o estado do disjuntor como aberto.
• indica que se 80% das solicitações em 10 (significa 8)
estiverem falhando, abra o circuito.
• indica que estamos usando a janela deslizante
COUNT_BASED. Outro tipo é TIME_BASED.
• indica que estamos usando a janela deslizante
COUNT_BASED. Outro tipo é TIME_BASED.
• indica que não muda diretamente do estado aberto para o
estado fechado, considere também o estado semiaberto.
• indica que, quando estiver no estado semi-aberto, considere o
envio de 4 solicitações. Se 80% deles estiverem falhando,
mude o disjuntor para o estado aberto.
• indica o intervalo de tempo de espera ao passar do estado
aberto para o estado fechado.
Circuit Breaker

15. December 21, 2021 15
© 2021 DXC Technology Company. All rights reserved. December 21, 2021 15
© 2021 DXC Technology Company. All rights reserved.
Questions and answers

16. © 2021 DXC Technology Company. All rights reserved.