Muito bom o conteúdo, parabéns Dias. Vou colocar aqui algo que li sobre isso : (Vamos combinar, todos os serviços falharão em algum momento, é tudo uma questão de tempo. Os Circuit Breakers permitem que o sistema lide com essas falhas normalmente. Ao aplicar este padrão, estamos antecipando possíveis problemas (ou consequências 😃) da aplicação.)
caramba, massa essa interceptação das excessões pra microsserviços... nos meus, sempre uso as funções set_error_handler e set_exception_handler pra definir o comportamento em caso de exceção, mas agora vou dar uma olhada nesses pacotes.
Consigo aplicar esse mesmo pattern para consumo de apis ou crawlers? Tenho utilizado uma estrutura de retry e backoff com jobs no Laravel, mas está um tanto incipiente. Outra coisa que queria entender também é se o que é feito no circuit breaker é criar um long running process. Eu comecei a estudar esse pattern recentemente e tem despertado bastante a minha curiosidade. Seu vídeo veio muito a calhar. Parabéns!
Microsserviços são basicamente APIs. É exatamente o exemplo do vídeo. Já pra crawler eu não vejo muito sentido... Sobre long running process, não necessariamente, não. No exemplo do vídeo, por exemplo, isso não foi necessário.
Mas para serviço em produção, não seria melhor configurar essa proteção do lado do servidor web, em vez da aplicação? Ou na aplicação seria eficaz tanto quanto?
No caso apenas para publico ne? Pelo que entendi parece que isto funciona melhor para requisições internas, algo como a comunicação da lógica. É isso? Só sei que é muito interessante e irei estudar mais isto. :)
Parabéns pelo conteúdo!!! Seria interessante mostrar o que é armazenado no Redis, pelo que entendi ele depende de um client que armazena essas informações. Abraço!
Ele precisa de algum driver pra salvar o número de requisições, timestamp da última requisição, etc. Não precisa ser necessariamente Redis. Pode ser APCu, etc. Eu fui de Redis por ser mais fácil. rsrsrs
Pode ser implementado no cliente da requisição, no service mesh, etc. Há várias possibilidades. Eu nunca vi implementado no API Gateway, mas é uma possibilidade sim.
Mas não ia dar na mesma coisa? Sé o serviço estiver em baixa Client vai receber um erro do Microsserviço, e depois vai continuar a receber um erro (só que do Circuit Breaker). Ou será que o circuit breaker poderia mandar uma mensagem para um serviço de filas para que fosse tentado de novo? Era interessante falar sobre CQRS e sobre o Symfony menseger tbm! :D
Exatamente, William. O objetivo é não ir desnecessariamente ao serviço que está falhando, retornando mais rápido para o serviço atual não ser sobrecarregado também além de dar tempo para o outro serviço se recuperar.
Já tive um problema com a Api dos correios. Derrubou muita gente kkkk resolvi reduzindo o time out para 5 segundos. Obrigado pela dica
heheheh
Oi lindão! Passando aqui pra agradecer por ter feito parte do meu ano com os seus vídeos aqui e na Alura. E que venham muito mais em 2023!
Valeu demais pelo apoio!! 🤩🤩
Muito bom, Vinicius. Parabéns!!! Quero ver mais padrões de resiliência de microservices aqui no canal
Pretendo trazer mais conteúdo sim. Inclusive, aceito dicas. :-D
Muito bacana! Show Vinicius
Valeu, Rodrigo.
😁
Vlw pelo vídeo. Ajudou bastante a entender o conceito.
Fico feliz que tenha gostado
top seus videos, te acompanho desde que vc era magrinho.
Kkkkkkkkk
Que bom que tem curtido, mano!
🤩
Muito interessante ainda mais usando com php que fica mais bonito! Ótimo conteúdo.
Que bom que gostou, Elayne.
😁
Parabens primeiro conteudo super descritivo sobre Circuit Breaker em PHP ainda por cima, top
Valeu demais, Weslley. Que bom que gostou! :-D
Muito bom o conteúdo, parabéns Dias.
Vou colocar aqui algo que li sobre isso :
(Vamos combinar, todos os serviços falharão em algum momento, é tudo uma questão de tempo. Os Circuit Breakers permitem que o sistema lide com essas falhas normalmente. Ao aplicar este padrão, estamos antecipando possíveis problemas (ou consequências 😃) da aplicação.)
Boa. É bem por aí mesmo. :-D
Belo conteudo! Aprendi mais uma😊😊😊
Que bom que gostou, Alex.
😁
caramba, massa essa interceptação das excessões pra microsserviços...
nos meus, sempre uso as funções set_error_handler e set_exception_handler pra definir o comportamento em caso de exceção, mas agora vou dar uma olhada nesses pacotes.
Que bom que o conhecimento vai ser útil. :-D
Consigo aplicar esse mesmo pattern para consumo de apis ou crawlers? Tenho utilizado uma estrutura de retry e backoff com jobs no Laravel, mas está um tanto incipiente. Outra coisa que queria entender também é se o que é feito no circuit breaker é criar um long running process. Eu comecei a estudar esse pattern recentemente e tem despertado bastante a minha curiosidade. Seu vídeo veio muito a calhar. Parabéns!
Microsserviços são basicamente APIs. É exatamente o exemplo do vídeo.
Já pra crawler eu não vejo muito sentido...
Sobre long running process, não necessariamente, não. No exemplo do vídeo, por exemplo, isso não foi necessário.
TI ajudando a entender elétrica ou elétrica ajudando a entender TI kkkkkkkk.
Mundos que eu amo, mas infelizmente apenas um paga minhas contas!
Heheheh
Pois é. Mas confesso que não entendo nada de elétrica. Só essa analogia mesmo.
Kkkkkk
Mas para serviço em produção, não seria melhor configurar essa proteção do lado do servidor web, em vez da aplicação? Ou na aplicação seria eficaz tanto quanto?
No caso apenas para publico ne? Pelo que entendi parece que isto funciona melhor para requisições internas, algo como a comunicação da lógica. É isso?
Só sei que é muito interessante e irei estudar mais isto. :)
Implementar o padrão no servidor web pode ser possível sim, mas nem todo servidor web fornece essa funcionalidade.
Parabéns pelo conteúdo!!! Seria interessante mostrar o que é armazenado no Redis, pelo que entendi ele depende de um client que armazena essas informações. Abraço!
Ele precisa de algum driver pra salvar o número de requisições, timestamp da última requisição, etc. Não precisa ser necessariamente Redis. Pode ser APCu, etc. Eu fui de Redis por ser mais fácil. rsrsrs
Bom dia! Uma curiosidade... O Circuit Breaker na prática é implementado junto ao API GATEWAY? O API GATEWAY é responsável por isso?
Pode ser implementado no cliente da requisição, no service mesh, etc. Há várias possibilidades. Eu nunca vi implementado no API Gateway, mas é uma possibilidade sim.
Que cara bom..
Fico muito feliz que tenha gostado. :-D
oia ai, a camisa do darkmira
Bonita, né!?
rsrsrs
@@DiasDeDev dEmais
Mas não ia dar na mesma coisa? Sé o serviço estiver em baixa Client vai receber um erro do Microsserviço, e depois vai continuar a receber um erro (só que do Circuit Breaker). Ou será que o circuit breaker poderia mandar uma mensagem para um serviço de filas para que fosse tentado de novo? Era interessante falar sobre CQRS e sobre o Symfony menseger tbm! :D
O objetivo não é evitar a falha, mas não sobrecarregar um serviço que já está apresentando defeito.
Exatamente, William. O objetivo é não ir desnecessariamente ao serviço que está falhando, retornando mais rápido para o serviço atual não ser sobrecarregado também além de dar tempo para o outro serviço se recuperar.