Introdução
O próprio Eureka é um produto de código aberto da Netflix que fornece registro e descoberta de serviço e fornece o pacote Java correspondente. Em sua implementação, os nós são iguais entre si, e a falha de parte do nó de registro não afetará o cluster.Mesmo se apenas um nó do cluster sobreviver, o serviço de descoberta pode ser fornecido normalmente. Mesmo se todos os nós de registro de serviço estiverem inativos, os clientes Eureka armazenarão em cache as informações de chamada de serviço. Isso garante que as chamadas mútuas entre nossos microsserviços sejam robustas o suficiente.
O Zookeeper fornece principalmente serviços de configuração distribuída de código aberto, serviços de sincronização e registro nomeado para computação distribuída em grande escala. Costumava ser um subprojeto do projeto Hadoop para controlar os dados no cluster. Ele foi atualizado para um projeto de nível superior independente. Ele também é usado como uma solução de serviço de descoberta de serviço em muitos cenários.
Comparado
Há um teorema do CAP bem conhecido em sistemas distribuídos (consistência de dados C; disponibilidade de serviço A; tolerância a falhas de serviço P a falhas de partição de rede. Essas três características não podem ser atendidas ao mesmo tempo em qualquer sistema distribuído, no máximo ao mesmo tempo Conheça dois);
Funcionário do zoológico
O Zookeeper é desenhado com base no CP, ou seja, os pedidos de acesso ao Zookeeper a qualquer momento podem obter resultados de dados consistentes, ao mesmo tempo que o sistema é tolerante a falhas na segmentação da rede, mas não pode garantir a disponibilidade de cada pedido de serviço. Analisando a partir da situação real, ao usar o Zookeeper para obter a lista de serviço, se o Zookeeper estiver escolhendo o mestre, ou mais da metade das máquinas no cluster Zookeeper não estiverem disponíveis, os dados não estarão disponíveis. Portanto, o Zookeeper não pode garantir a disponibilidade do serviço.
É verdade que na maioria dos ambientes distribuídos, especialmente em cenários que envolvem armazenamento de dados, a consistência dos dados deve ser garantida primeiro, e é por isso que o zookeeper é projetado como um CP. Mas para o cenário de descoberta de serviço, a situação é diferente: para o mesmo serviço, mesmo que as informações do provedor de serviços armazenadas em nós diferentes do registro não sejam as mesmas, isso não causará consequências catastróficas. Porque para consumidores de serviço, poder consumir é a coisa mais importante - tentar consumir depois de obter as informações da instância de serviço que podem estar incorretas é melhor do que não consumi-las porque as informações da instância não podem ser obtidas. (Tente falhar rapidamente, então você pode atualizar a configuração e tentar novamente) Portanto, para a descoberta de serviço, a disponibilidade é mais importante do que a consistência de dados - o AP é melhor do que o CP.
Eureka
E o Spring Cloud Netflix segue o princípio AP ao projetar o Eureka. O Eureka Server também pode executar várias instâncias para construir clusters e resolver problemas de ponto único, mas ao contrário do processo de eleição de líder do ZooKeeper, o Eureka Server usa comunicação ponto a ponto ponto a ponto. Esta é uma arquitetura descentralizada, não há distinção de mestre / escravo e cada par é igual. Nessa arquitetura, os nós se registram entre si para melhorar a disponibilidade e cada nó precisa adicionar um ou mais serviceUrls válidos para apontar para outros nós. Cada nó pode ser considerado uma cópia de outros nós.
Se um servidor Eureka ficar inativo, as solicitações do cliente Eureka serão automaticamente transferidas para o novo nó do servidor Eureka. Quando o servidor inativo for restaurado, o Eureka o incluirá novamente no gerenciamento do cluster de servidor. Quando um nó começa a aceitar solicitações do cliente, todas as operações realizarão uma operação replicateToPeer (replicação entre nós) e a solicitação será replicada para todos os nós atualmente conhecidos por outro servidor Eureka.
Depois que um novo nó do servidor Eureka for iniciado, ele tentará primeiro obter todas as informações de registro da instância de nós vizinhos para concluir a inicialização. O Eureka Server obtém todos os nós por meio do método getEurekaServiceUrls () e será atualizado regularmente por meio da renovação de pulsação. Na configuração padrão, se o Eureka Server não receber a pulsação de uma determinada instância de serviço dentro de um determinado período de tempo, o Eureka Server fará logout da instância (o padrão é 90 segundos, por meio de eureka.instance.lease-expiration-duration configuração -em segundos). Quando o nó do Eureka Server perde muitos batimentos cardíacos em um curto período de tempo (por exemplo, ocorre uma falha de partição de rede), esse nó entrará no modo de autoproteção.
Qual é o modo de autoproteção? Na configuração padrão, se o número de renovações de pulsação recebidas pelo Eureka Server por minuto for inferior a um limite (o número de instâncias (60 / o número de segundos entre as pulsações para cada instância), coeficiente de autoproteção) e dura por 15 minutos, ele irá disparar a própria proteção. No modo de autoproteção, o Eureka Server protegerá as informações no registro do serviço e não fará mais logoff de nenhuma instância do serviço. Quando o número de batimentos cardíacos que ele recebe retorna para acima do limite, o nó do servidor Eureka sairá automaticamente do modo de autoproteção. Sua filosofia de design foi mencionada anteriormente, ou seja, ele prefere manter as informações de registro de serviço incorretas do que cancelar cegamente quaisquer instâncias de serviço que possam estar íntegras. Este modo pode ser desabilitado por eureka.server.enable-self-preserve = false, e eureka.instance.lease-renewal-interval-in-seconds pode ser usado para alterar o intervalo de pulsação, eureka.server.renewal-percent-threshold pode ser usado para modificar o coeficiente de autoproteção (padrão 0,85).
Resumindo
O ZooKeeper é baseado em CP e não garante alta disponibilidade. Se o ZooKeeper estiver elegendo o mestre, ou mais da metade das máquinas no cluster ZooKeeper estiverem indisponíveis, os dados não estarão disponíveis. Eureka é baseado em AP e pode garantir alta disponibilidade, mesmo que todas as máquinas estejam desligadas, você pode obter dados em cache local. Como centro de registro, a configuração não muda com frequência, apenas quando a versão é lançada e a máquina falha. Para configurações que não mudam com frequência, o CP não é apropriado e o AP pode sacrificar a consistência para garantir a disponibilidade ao encontrar problemas, tanto retornando dados antigos quanto dados em cache.
Portanto, em teoria, Eureka é mais adequado como um centro de registro. No ambiente real, a maioria dos projetos pode usar o ZooKeeper, porque o cluster não é grande o suficiente e, basicamente, não encontrará a situação de mais da metade das máquinas usadas como registro estarem inativas. Portanto, não há realmente nenhum grande problema.