Existem dezenas de soluções para realização de serviço de descoberta em ambiente Mesos.
Podemos dividi-los em 3 grupos pela forma como o cliente encontra os serviços:
- Com base em proxy
- Quando entre clientes e serviço fica o proxy, por exemplo, HAProxy (marathon-lb é baseado nele), fabio, traefik, nixy) que cuida do balanceamento de carga de seus serviços com base no caminho HTTP, cabeçalho, domínio etc. Esta solução é fácil de desenvolver e oferece a oportunidade de ajustar o balanceamento de carga com base na solicitação. Por outro lado, adicionamos saltos adicionais e como proxy temos a situação MitM.
- DNSlike (pergunte a um ponto de extremidade bem conhecido especial para a localização do serviço)
- Rede definida por software - podemos usar IP por contêiner com SDN para que cada contêiner seja exposto com IP exclusivo e apresente seus serviços usando as portas padrão 80 para HTTP, 443 para HTTPS e assim por diante. Esta é a técnica mais avançada e relativamente nova, embora use DNS simples e antigo para encontrar o IP de serviço. Pode ser mais difícil introduzir o proxy, mas funcionará com qualquer tipo de tráfego.
- Registro de serviço - onde cada contêiner é registrado no DNS global e o cliente obtém seu IP e PORT usando consultas DNS SRV. A Consul Mesos DNS disponibiliza este tipo de servidor DNS. Também alguns outros protocolos são baseados nessa ideia (dê uma olhada em Bonjure). Ele tenta obter o melhor de SDN e proxy. É relativamente fácil de configurar e é independente de protocolo.
- Outro
- Qualquer coisa que não se encaixe em outros tipos, por exemplo, solução desenvolvida internamente, etcd ou Eureka. Pode ser profundamente apertado com infraestrutura e aplicativos, fornecendo algumas otimizações. Vale a pena mencionar que existem algumas tentativas de usar o serviço de descoberta baseado em DHT - Meta Service Discovery
Você pode encontrar mais detalhes sobre as ferramentas que podem ser usadas para criar o Serviço de Descoberta aqui
Podemos dividir os Serviços de Descoberta pela maneira como são preenchidos com entradas de serviço:
- Agrupamento
- Mesos/Marathon é periodicamente consultado sobre o estado. É assim que o DNS Mesos está funcionando. Este é o método mais fácil, mas causará um grande atraso entre o início/parada do serviço e as alterações na descoberta do serviço. Isso pode ser minimizado usando a verificação de integridade.
- Com base em eventos
- O Marathon tem a capacidade de enviar eventos com informações sobre mudanças de estado (há uma iniciativa para incluir o barramento de eventos no Mesos também - design doc. Dessa forma, o marathon-lb está funcionando. Um trabalho semelhante é feito pelo marathon-consul, mas os dados são passados para cônsul.
- No aplicativo/contêiner
- As soluções acima são assíncronas, portanto, pode haver um intervalo de tempo em que seu estado de descoberta de serviço esteja obsoleto, por exemplo, o serviço foi iniciado, mas não está pronto para atender às solicitações ou o serviço acabou de morrer. Mesmo com a verificação de saúde, não poderíamos assumir que todas as coisas acontecem com 0 tempo de inatividade. A solução para minimizar o tempo de inatividade é permitir que o aplicativo se registre quando estiver pronto para atender às solicitações e cancele o registro antes que ele pare (também conhecido como desligamento normal).
