Você poderia detalhar mais sobre o funcionamento por "debaixo dos panos" de como acontece a requisição client-side? E se não houver ninguém online para responder aquele serviço, o que acontece?
Quando é feita a requisição da loja para o fornecedor é feita uma requisição ao ServiceDiscovery antes ou fica algo em background e montando um cache do eureka-server?
O que acontece se o eureka-server cai? Você pode exemplificar como funcionaria o uso EurekaServer visando alta disponibilidade?
Olá, Marcel! Espero que esteja bem!
Desculpe a demora em dar um retorno
Vamos dar uma passeada sobre Service Discovery
A característica de um microservice, é baseada na decomposição de serviços, onde cada serviço pode ser considerado micro, pois cada pequeno recurso que trabalha em conjunto oferece uma ótima característica.
Tudo isso é muito baseado em domain driven design(DDD), interfaces bem definidas, princípios de single responsibility e SOA.
Toda esta decomposição dá agilidade, flexibilidade, escalabilidade e ajuda o negócio a evoluir de acordo com suas necessidades.
Então, em vez de ter um único serviço, agora temos muitos serviços pequenos e provavelmente vamos replicar esses serviços.
Características de Microservices:
Domain Driven Design
Single Responsibility Principle
Interface Pública e Explícita
Deploy Independente
Light-weight Communication
Algumas vantagens de Microservices:
Mais fácil de desenvolver, compreender e manter
Começa mais rápido do que um monolito
Mudanças locais podem ser facilmente implantadas
Escalar de forma independente
Melhora o isolamento de falhas
Quando temos um ou dois serviços, é fácil identificar, mas se temos 20 ou 30 em muitas máquinas, como saberemos se eles estão disponíveis ou não?
Ao trabalhar com microservices, começamos a ter inúmeros problemas que não tínhamos antes.
Portanto, houve alguns padrões que começamos a ter que prestar atenção, o que é o caso de Service Discovery, Service Register e Circuit Breaker, isso deixa mais fáceis algumas tarefas.
O Service Discovery é um dos principais se tratando da arquitetura baseada em microservices. Tentando configurar a mão para cada cliente ou alguma forma de convenção, pode ser muito difícil de fazer e muito frágil.
O Eureka é o Service Discovery do Netflix que é usado no Server e no Cliente.
O servidor pode ser configurado e implantado para estar altamente disponível, com cada servidor replicando o estado sobre os serviços registrados para os outros.
Vamos imaginar que temos muitos serviços dinamicamente distribuídos na rede, onde as instâncias de serviços mudam dinamicamente devido a escala automática, falhas, atualizações e não temos controle de endereços IP e nem o nome da instância.
O ideal nessa situação seria que o serviço comunicasse ao servidor ou até mesmo a algum serviço que poderia chamá-lo e que estará disponível para ser requisitado.
É assim que o Service Discovery funciona. O serviço se junta à rede e se registra em um servidor para disponibilizar para o uso de algum outro serviço, onde os clientes sabem onde é o servidor e enviam para o servidor que está disponível.
Quando um cliente se registra no Eureka, fornece metadados sobre si próprio, como host e porta,health check , URL indicador, página inicial, etc.
O Eureka recebe mensagens de heartbeat de cada instância que pertencente a um serviço. Se o heartbeat falhar ao longo de um cronograma configurável, a instância normalmente é removida do registro.
A localização da rede de uma instância de serviço é registrada no registry service quando ele é iniciado.
Quando uma instância ou o serviço não está mais disponível o registry service é removido.
Esse mecanismo de saber se um serviço está disponível ou não é chamado de heartbeat.
Por padrão, a Eureka usa os heartbeat do cliente para determinar se um cliente está ausente. A menos que especificado de outra forma, o Discovery Client não irá propagar o status de verificação de estado atual do aplicativo pelo Spring Boot Actuator. O que significa que após o registro bem sucedido, a Eureka sempre anunciará que o aplicativo está no estado 'UP'. A habilitação do health check do Eureka pode alterar esse comportamento, o que resulta na propagação do status do aplicativo para a Eureka. Como conseqüência, qualquer outra aplicação não enviará tráfego para o aplicação em outros estados 'UP'.
Continuação...
Quando se trabalha com microservices, chamadas remotas em diferentes tipos de de sistemas é uma das atividades mais comuns neste cenário.
Provavelmente, esses sistemas vão estar em diferentes máquinas distribuídas por uma rede.
Mas o que acontece quando uma chamada para um desses sistemas falha ou tem uma resposta em um tempo inadequado? O sistema pode falhar como um todo e o problema pode ser conectado em cascata a outros sistemas que dependem dessa solicitação.
Para evitar esse tipo de problema, existe um padrão chamado Circuit Breaker. A idéia é simples, exatamente como um Circuit Breaker (Disjuntor) de uma casa. Você projeta uma chamada remota para um objeto Circuit Breaker, que monitora falhas. Quando essas falhas chegam a um certo limite, o circuit breaker dispara, e quando desarmar uma ação pode ser colocada em caso de falha ou até mesmo um aviso que o circuit breaker desarmou.
Segue alguns conceitos do padrão circuit breaker:
Closed: o Request da aplicação é encaminhado para a operação. O proxy mantém uma contagem do número de falhas recentes, e se a chamada para a operação não tiver êxito, o proxy incrementa essa contagem. Se o número de falhas recentes exceder um limiar especificado dentro de um determinado período de tempo, o proxy é colocado no estado Open. Neste ponto, o proxy inicia um temporizador de tempo limite e, quando esse temporizador expirar, o proxy é colocado no estado Half-Open.
Open: a Request da aplicação falha imediatamente e uma exceção é retornada para a aplicação
Half-Open: um número limitado de pedidos da aplicação pode passar e invocar a operação. Se esses pedidos forem bem-sucedidos, presume-se que a falha que anteriormente causou a falha foi corrigida e o circuit breaker muda para o estado Closed (o contador de falhas é reiniciado). Se algum pedido falhar, o circuit breaker assume que a falha ainda está presente para que ele volte para o estado aberto e reinicia o temporizador de tempo limite para dar ao sistema um período de tempo adicional para se recuperar da falha.
Quando podemos usar esse padrão?
Para evitar que uma aplicação tente invocar um serviço remoto ou acessar um recurso compartilhado se esta operação for altamente provável que falhe e também como substituto para lidar com exceções na lógica de negócio a suas aplicações.
O Netflix criou uma ferramenta que implementa o Circuit Breaker chamada de Hystrix e Spring Cloud facilitou ainda mais a implementação deste padrão.
Para mais informações detalhadas, segue o link da documentação
Espero ter ajudado, Marcel, mas fico a disposição caso ainda tenha dúvidas.
Um abraço e bons estudos!!!