Convido a todos a conhecer a transcrição da apresentação de Alexander Sigachev sobre Discovery de Serviços em sistemas distribuídos, usando o Consul como exemplo.
O Discovery de Serviços foi criado para permitir a conexão de novos aplicativos ao nosso ambiente existente com o mínimo de custo. Ao usar o Discovery de Serviços, podemos separar ao máximo ou um contêiner no formato Docker, ou um serviço virtual do ambiente em que ele está sendo executado.
Saudações a todos! Eu sou Alexander Sigachev, trabalho na empresa Inventos. Hoje, vou apresentá-los a um conceito chamado Discovery de Serviços. Vamos examinar o Discovery de Serviços usando o Consul como exemplo.
Quais problemas o Discovery de Serviços resolve? O Discovery de Serviços foi criado para conectar novos aplicativos ao nosso ambiente existente com o mínimo de custo. Usando o Discovery de Serviços, podemos separar ao máximo um contêiner no formato Docker ou um serviço virtual do ambiente em que ele está sendo executado.
Como isso se parece? Em um exemplo clássico na web – é o frontend que recebe a solicitação do usuário. Depois, ele realiza a roteação dessa solicitação para o backend. Neste exemplo, o load-balancer equilibra duas backends.
Aqui vemos que estamos iniciando a terceira instância do aplicativo. Assim que o aplicativo é lançado, ele se registra no Discovery de Serviços. O Discovery de Serviços notifica o load-balancer. O load-balancer muda sua configuração automaticamente e o novo backend já começa a operar. Dessa forma, novos backends podem ser adicionados ou, ao contrário, excluídos do funcionamento.
O que mais é conveniente fazer com o uso do Discovery de Serviços? No Discovery de Serviços, podem ser armazenadas configurações do nginx, certificados e uma lista de servidores backend ativos.
Além disso, o Discovery de Serviços permite detectar falhas e identificações de problemas. Quais esquemas podem ser utilizados para a detecção de falhas?
- Esse aplicativo que desenvolvemos, notifica o Discovery de Serviços que ainda continua operacional.
- O Discovery de Serviços, por sua vez, interroga o aplicativo sobre sua disponibilidade.
- Ou, alternativamente, pode ser utilizado um script ou aplicativo de terceiros que verifica a disponibilidade do nosso aplicativo e notifica o Discovery de Serviços se tudo está bem e se pode operar, ou, ao contrário, se algo está errado e essa instância do aplicativo deve ser excluída do balanceamento.
Cada um dos esquemas pode ser aplicado dependendo do software que estamos utilizando. Por exemplo, se acabamos de iniciar o desenvolvimento de um novo projeto, podemos facilmente implementar um esquema em que nosso aplicativo notifica o Service Discovery. Alternativamente, podemos conectar o Service Discovery para realizar a verificação.
Por outro lado, se o aplicativo nos foi legado ou desenvolvido por terceiros, o terceiro cenário se aplica, onde escrevemos um manipulador e tudo isso se integra automaticamente ao nosso trabalho.
Este é um dos exemplos. O load balancer na forma do nginx reinicia. É uma ferramenta adicional fornecida junto com o Consul, chamada consul-template. Definimos uma regra. Dizemos que usamos um template (Template Engine Golang). Quando ocorrem eventos, e há notificações de mudanças, ele é regenerado e o Service Discovery recebe o comando ‘reload’. Um exemplo simples é quando o nginx é reconfigurado e reiniciado em resposta a um evento.
O que é o Consul?
Antes de tudo, é um Service Discovery.
Ele possui um mecanismo de verificação de disponibilidade – Health Checking.
Além disso, ele possui um KV Store.
E sua base permite a utilização de Multi Datacenter.
Para que tudo isso pode ser utilizado? No KV Store, podemos armazenar exemplos de configurações. O Health Checking nos permite verificar serviços locais e enviar notificações. O Multi Datacenter é utilizado para construir um mapa de serviços. Por exemplo, a Amazon possui várias zonas e roteia o tráfego da maneira mais otimizada, evitando requisições desnecessárias entre data centers, que são cobradas separadamente do tráfego local e, consequentemente, têm uma latência menor.
Vamos explorar um pouco os termos utilizados no Consul.
- O Consul é um serviço escrito em Go. Uma das vantagens de programas em Go é que você tem apenas um arquivo binário, que você pode simplesmente baixar. Execute de qualquer lugar e não precisa de dependências.
- Além disso, utilizando chaves, podemos iniciar este serviço tanto em modo cliente quanto em modo servidor.
- O atributo ‘datacenter’ também permite marcar a que data center pertence este servidor.
- O consenso é baseado no protocolo raft. Para quem tiver interesse, é possível ler mais sobre isso no site do Consul. Este protocolo permite determinar um líder e identificar quais dados considerar como válidos e disponíveis.
- Gossip é um protocolo que garante a comunicação entre nós. Além disso, esse sistema é descentralizado. Dentro de um único data center, todos os nós se comunicam com os vizinhos. Desta forma, as informações sobre o estado atual são trocadas entre eles. Pode-se dizer que são fofocas entre vizinhos.
- LAN Gossip é a troca local de dados entre vizinhos dentro de um único data center.
- WAN Gossip é utilizado quando precisamos sincronizar informações entre dois data centers. As informações transitam entre os nós que são marcados como servidor.
- RPC permite fazer solicitações através do cliente ao servidor.
Descrição do RPC. Suponha que o Consul está sendo executado em uma máquina virtual ou servidor físico como cliente. Nós fazemos uma solicitação localmente. Em seguida, o cliente local solicita informações ao servidor e se sincroniza. Dependendo das configurações, as informações podem ser fornecidas do cache local ou podem ser sincronizadas com o líder, o mestre do servidor.
Esses dois esquemas têm suas vantagens e desvantagens. Se trabalhamos com cache local, é rápido. Se trabalhamos com dados armazenados no servidor, é mais lento, mas obtemos informações mais atualizadas.
Se representarmos isso graficamente, temos a seguinte imagem do site. Vemos que temos três mestres em funcionamento. Um deles está marcado com uma estrela como líder. Neste exemplo, três clientes estão trocando informações localmente através de UDP/TCP. E as informações entre os data centers são transmitidas entre os servidores. Aqui os clientes interagem entre si localmente.
Que API o Consul oferece? Para obter informações, existem dois tipos de API no Consul.
Esta é a API DNS. Por padrão, o Consul é executado na porta 8600. Podemos configurar o proxy da solicitação e garantir o acesso através da resolução local, por meio do DNS local. Podemos solicitar pelo domínio e obteremos em resposta informações sobre o endereço IP.
API HTTP – ou podemos solicitar localmente na porta 8500 informações sobre um serviço específico e receberemos uma resposta JSON, informando qual IP o servidor tem, qual host, qual porta está registrada. Informações adicionais podem ser transmitidas através de um token.
O que é necessário para iniciar o Consul?
No primeiro modo, indicamos no modo desenvolvedor que estamos em modo desenvolvedor. O Agent é iniciado como servidor. E toda a função é executada de forma independente em uma única máquina. É conveniente, rápido e praticamente não são necessárias configurações adicionais para o primeiro início.
O segundo modo é a execução em produção. Aqui, o início é um pouco mais complicado. Se não temos nenhuma versão do consul, devemos inicializar a primeira máquina no bootstrap, ou seja, essa máquina assumirá as responsabilidades de líder. Levantamos essa máquina, depois levantamos a segunda instância do servidor, passando a ela informações sobre onde está o master. Depois levantamos a terceira. Após termos três máquinas em funcionamento, reiniciamos a primeira máquina da bootstrap em modo normal. Os dados são sincronizados e o cluster inicial já está em funcionamento.
É recomendado executar de três a sete instâncias em modo servidor. Isso se deve ao fato de que, se o número de servidores cresce, aumenta o tempo para sincronização das informações entre eles. O número de nós deve ser ímpar para garantir o quórum.
Como são garantidos os Health Checks? No diretório de configuração do Consul, escrevemos uma regra de verificação em formato Json. A primeira opção é a disponibilidade, neste exemplo, do domínio google.com. E indicamos que a verificação deve ser realizada a cada 30 segundos. Dessa forma, verificamos se nosso nó tem acesso à rede externa.
A segunda opção é a verificação de si mesmo. Nós fazemos um curl normal para localhost na porta especificada com um intervalo de 10 segundos.
Essas verificações são somadas e enviadas para a Descoberta de Serviços. Com base na disponibilidade, esses nós são excluídos ou aparecem na lista de máquinas disponíveis e funcionando corretamente.
O Consul também fornece uma interface UI, que é iniciada com uma flag separada e estará disponível na máquina. Isso permite visualizar informações e também pode-se fazer algumas alterações.
Neste exemplo, a aba ‘Serviço’ está aberta. Mostra que três serviços estão em funcionamento, um dos quais é o Consul. O número de verificações realizadas e há três data centers em que as máquinas estão localizadas.
Este é um exemplo da aba "Nodes". Podemos ver que eles têm nomes compostos relacionados a datacenters. Aqui também é mostrado quais serviços estão em execução, ou seja, vemos que as tags não estão definidas. Nessas tags adicionais, é possível fornecer algumas informações que o desenvolvedor pode usar para especificar parâmetros adicionais.
Também é possível passar informações para o Consul sobre o estado dos discos e a carga média.
Perguntas
Pergunta: Temos um contêiner Docker, como usá-lo com o Consul?
Resposta: Para o contêiner Docker, existem várias abordagens. Uma das mais comuns é usar um contêiner Docker externo responsável pelo registro. Ao iniciar, ele recebe a socket do Docker. Todos os eventos de registro e desregistro do contêiner são registrados no Consul.
Pergunta: Ou seja, o Consul inicia o contêiner Docker?
Resposta: Não. Nós iniciamos o contêiner Docker. E na configuração indicamos - ouça esta socket. É mais ou menos como funciona com o certificado, quando passamos informações sobre onde e o que temos.
Pergunta: Portanto, dentro do contêiner Docker que estamos tentando conectar ao Service Discovery deve haver alguma lógica que consegue fornecer dados ao Consul?
Resposta: Não exatamente. Quando ele inicia, passamos variáveis através do ambiente. Por exemplo, nome do serviço, porta do serviço. O registro ouve essas informações e registra no Consul.
Pergunta: Eu ainda tenho uma pergunta sobre a interface. Nós implantamos a interface, digamos, em um servidor de produção. E quanto à segurança? Onde os dados estão armazenados? É possível acumular dados de alguma forma?
Resposta: Na interface, na verdade, os dados vêm do banco de dados e do Service Discovery. As senhas configuramos nas configurações manualmente.
Pergunta: Isso pode ser publicado na Internet?
Resposta: Por padrão, o Consul inicia em localhost. Para publicar na Internet, será necessário configurar algum proxy. Nós somos responsáveis pelas regras de segurança.
Pergunta: Ele fornece dados históricos por padrão? Estou interessado em ver estatísticas sobre os Health Checks. É possível diagnosticar problemas se o servidor frequentemente falhar.
Resposta: Não tenho certeza se há detalhes sobre as verificações.
Pergunta: Não é tão importante o estado atual, quanto importante é a dinâmica.
Resposta: Para análise – sim.
Pergunta: O Service Discovery para Docker, o Consul é melhor não usar?
Resposta: Eu não recomendaria o uso. O objetivo da apresentação é introduzir o conceito. Historicamente, ele percorreu um caminho, na minha opinião, até a versão 1. Agora já existem soluções mais robustas, como o Kubernetes, que possui tudo isso sob o capô. Dentro do Kubernetes, o Service Discovery fica a cargo do Etcd. Mas não estou tão familiarizado com ele quanto estou com o Consul. Portanto, decidi fazer o Service Discovery com base no Consul.
Pergunta: O esquema com o servidor líder não atrasa o início do aplicativo como um todo? E como o Consul determina um novo líder, se o atual estiver inativo?
Resposta: Eles descreveram um protocolo inteiro. Se tiver interesse, pode ser lido.
Pergunta: O Consul atua como um servidor completo e todas as consultas passam por ele?
Resposta: Ele não atua como um servidor completo, mas cobre uma área específica. Geralmente, ela termina em service.consul. E então seguimos a lógica. Não usamos nomes de domínio em produção, mas sim uma infraestrutura interna, que normalmente fica oculta atrás do cache do servidor, se trabalhamos com DNS.
Pergunta: Ou seja, se quisermos acessar o banco de dados, teremos que consultar o Consul primeiro para encontrar esse banco, correto?
Resposta: Sim. Se estamos trabalhando com DNS, isso funciona como sem o Consul, quando utilizamos nomes DNS. Geralmente, aplicativos modernos não consultam o nome de domínio em cada requisição, porque já estabelecemos a conexão, tudo está funcionando e por um tempo não usamos. Se a conexão falhar, então – sim, vamos perguntar novamente onde está o banco e seguindo para ele.
— Chat de usuários Hashicorp: Consul, Nomad, Terraform
P.S. Sobre health checks. No Consul, assim como no Kubernetes, utiliza-se o mesmo sistema de verificação de estado de disponibilidade do serviço baseado em códigos de status.
200 OK para saudável
503 Serviço Indisponível para não saudávelFontes:
Fonte: habr.com
