O que é Service Discovery em Microservices

O que é Descoberta de Serviços? Por que você precisa disso?

Nos primeiros dias da Internet, as pessoas precisavam digitar uma longa sequência de endereços IP para acessar um serviço online. Os endereços IP não eram longos, mas, como uma sequência sem sentido de números, era um desafio lembrar o endereço específico de um determinado serviço, o que levou à invenção do sistema de nomes de domínio. Cada serviço online registrava um nome de domínio com um provedor de nomes de domínio e, em seguida, estabelecia um link entre o nome de domínio e um IP específico via DNS (Sistema de Nomes de Domínio). Dessa forma, as pessoas podiam simplesmente digitar um nome de domínio memorável e acessar o serviço online em um IP específico, que era a forma mais antiga de descoberta de serviços.

Quando o número de serviços dentro de uma empresa atinge um certo tamanho (por exemplo, dividido em microsserviços), também há o problema de que os IPs são realmente difíceis de lembrar, para o qual é necessário um sistema de descoberta de serviços. Os serviços dentro da empresa se registram no sistema, e outros serviços que desejam acessá-los consultam o endereço IP correspondente no sistema, de modo que não há necessidade de um serviço "lembrar" um endereço IP complexo e variável.

Mudanças de endereço IP podem confundir os visitantes.

Ao introduzir o DNS como um mecanismo de descoberta de serviços, as mudanças de IP agora podem ser tratadas de forma flexível.

Introdução aos Sistemas Comuns de Descoberta de Serviços

Como um sistema de descoberta de serviços, ele precisa satisfazer pelo menos quatro funções:

1. API para registro
2. API para consulta
3. Alta disponibilidade: afinal, o sistema de descoberta de serviços é o nervo de todo o sistema e não pode ser paralisado ou falhar
4. Ecossistema: como todos sabem, os programadores são preguiçosos e prefeririam ter uma biblioteca que possa interagir facilmente com as APIs

Vamos dar uma olhada em alguns sistemas de descoberta de serviços de código aberto no mercado:

Consul

Consul é um sistema de descoberta de serviços desenvolvido pela Hashicorp, uma empresa líder em código aberto. Como um software de longa data que lançou sua primeira versão em 17 de abril de 2014, o Consul tem um dos ecossistemas mais ricos e até tem desenvolvedores terceiros que desenvolvem SDKs em Haskell para ele. A maior parte do SDK do Consul é apenas um wrapper para sua API HTTP, então não há muito trabalho de desenvolvimento.

O Consul suporta o registro e a consulta de serviços via API HTTP. Ele suporta long polling HTTP para envio de dados em tempo real durante as consultas, evitando o polling. Além disso, o Consul suporta a consulta da instância do serviço correspondente via DNS.

A implantação do Consul é interessante, pois cada instância do Consul é chamada de agente, que pode ser um cliente ou um servidor. No lado do cliente, o Consul mantém um estado do lado do cliente; no lado do servidor, o Consul suporta implantação distribuída através do algoritmo de consistência Raft, para alcançar alta disponibilidade.

Eureka

Eureka é um projeto de código aberto da Netflix, que também é bastante antigo (há vestígios de commits datando de 2012). No entanto, o projeto não é mantido há um ano. Muitos usuários migraram para o Nacos, que será mencionado abaixo.

O Eureka suporta interação via API HTTP e SDK Java. Muitos dos usuários do Eureka foram trazidos através de projetos no ecossistema Java, como o Spring Cloud. O design de alta disponibilidade do Eureka, se você quiser descrevê-lo em termos de CAP (O teorema CAP afirma que um sistema distribuído pode fornecer apenas duas de três propriedades simultaneamente: Consistência, Disponibilidade e Tolerância a Partições), é AP, o que permite que os clientes vejam dados expirados quando as partições de rede ocorrem, evitando desastres secundários devido a problemas de rede.

Nacos

Nacos é um sistema de descoberta de serviços desenvolvido pela Alibaba, cujo nome vem da agregação das primeiras letras de Naming e Configuration Service. Desde o lançamento da versão 0.1.0 em 20 de julho de 2018, o Nacos agora evoluiu para a versão 2.1.

Como muitos dos projetos de código aberto da Alibaba, o Nacos é bastante popular entre os desenvolvedores Java na China, e sua popularidade é até maior que a do Eureka.

Ele suporta o registro e a consulta de serviços via API HTTP e SDKs como Java/Go/Python/NodeJS/C#. Atualmente, os desenvolvedores do Nacos também estão trabalhando em novas APIs baseadas em gRPC. Para a API HTTP, o Nacos atualmente suporta apenas polling para uma lista de serviços. Portanto, o Nacos oficialmente prefere a abordagem do SDK, que é uma abordagem de polling + push baseada em UDP com melhor desempenho em tempo real. O Nacos também está trabalhando em novas APIs baseadas em gRPC, que introduzirão capacidades de push do lado do servidor, um grande benefício para aqueles sistemas que não têm acesso ao SDK.

A alta disponibilidade do Nacos se deve em parte às capacidades de persistência fornecidas no SDK do cliente, e em parte à consistência do lado do servidor através dos protocolos Raft e Distro.

Métodos Comuns de Interface e Suas Vantagens e Desvantagens

Deixando de lado protocolos privados, os métodos de interface de descoberta de serviços podem ser divididos em três categorias:

1. Polling HTTP
2. DNS
3. Long polling HTTP ou streaming de servidor gRPC

O polling HTTP é simples de implementar, mas não é em tempo real.

A sobrecarga de desempenho do DNS é mínima. O DNS também não é em tempo real devido ao cache DNS, e tem a vantagem de ser um conjunto de padrões amplamente aceitos e independentes de implementação. No entanto, há dois lados da moeda, o que significa que o sistema de descoberta de serviços não pode adicionar campos adicionais à resposta DNS, a menos que o campo Additional na resposta DNS seja usado, mas isso exigiria um tratamento especial pelo cliente.

O long polling HTTP ou o streaming de servidor gRPC é o mais em tempo real dos três. Como ambos são baseados em HTTP, a resposta pode ser facilmente personalizada. A desvantagem é que eles são relativamente difíceis de implementar no lado do cliente.

Como o APISIX Faz Interface com Sistemas de Descoberta de Serviços

Como um gateway nativo da nuvem, o APISIX suporta a obtenção de nós upstream do sistema de descoberta de serviços e é projetado para suportar a interface com o sistema de descoberta de serviços tanto no plano de dados quanto no plano de controle.

Plano de Dados

O APISIX suporta integração com DNS, Eureka, Consul (modo KV), Nacos e K8s no plano de dados.

Ao fazer interface com serviços DNS, o APISIX usará os registros SRV ou A/AAAA do DNS para obter o nó upstream específico de um serviço. Quando uma solicitação é feita para acessar o upstream, ele tentará primeiro obtê-lo do cache DNS. Caso contrário, ele iniciará uma consulta DNS para obter o endereço IP específico dentro do registro correspondente.

Quanto aos outros tipos de descoberta de serviços, eles são sincronizados em segundo plano. Quando uma solicitação é feita para acessar o upstream, a parte dos dados correspondente ao nome do serviço é obtida dos dados atualmente sincronizados. Para K8s e Consul KV, podemos obter o endereço IP alterado em tempo real dessa forma, pois eles suportam long polling HTTP. Para Eureka e Nacos, atualmente estamos apenas fazendo polling para obter os dados.

Plano de Controle

O APISIX também suporta descoberta de serviços no plano de controle. Estamos trabalhando no apisix-seed, que sincronizará dados do sistema de descoberta de serviços para o etcd, para que o plano de dados possa sincronizar os nós upstream mais recentes do etcd.

Agora implementamos suporte para Nacos e Zookeeper no plano de controle. Como o suporte à descoberta de serviços no plano de controle é implementado via SDK oficial, ele tem vantagens que não estão disponíveis com o método HTTP normal. Por exemplo, na implementação do Nacos no apisix-seed, suportamos push baseado em UDP, então os dados são mais eficientes em termos de tempo do que o polling HTTP.

Vantagens do Suporte do APISIX a Cenários de Descoberta de Serviços

Ao integrar a descoberta de serviços diretamente no gateway, você pode simplificar muito o trabalho de colocar seus serviços online. Configure o APISIX para fazer interface com seu sistema de descoberta de serviços e deixe o APISIX fazer o resto por você. Por exemplo, se sua empresa está usando o Nacos como um sistema de descoberta de serviços, tudo o que você precisa fazer é configurar o APISIX para habilitar a descoberta de serviços do Nacos e, em seguida, simplesmente configurar o nome do serviço upstream do APISIX, e o APISIX buscará automaticamente o nó IP específico que corresponde a esse upstream.

Essa é uma vantagem que pode reduzir significativamente a quantidade de trabalho necessária ao migrar um gateway, por exemplo, do Spring Cloud Gateway para o APISIX. Se o Spring Cloud Gateway for usado para aplicar Eureka ou Nacos para descoberta de serviços, a transição para o novo sistema pode ser feita simplesmente habilitando o suporte para Eureka ou Nacos dentro do APISIX.

Huan Bei Loan tem ampla experiência nessa área, e a substituição do Spring Cloud Gateway visa melhorar ainda mais a estabilidade, supervisão, precisão e eficácia.

Para citar o texto original do Huan Bei Loan:

Como um negócio, o custo ainda é o princípio a ser considerado. Na fase de crescimento acelerado, pode ser necessário impulsionar o crescimento do negócio o mais rápido possível. No entanto, no ambiente atual, a prioridade é definitivamente o custo dentro do orçamento. Nesse caso, eficiência e custo só podem ser preservados de uma forma ou de outra. Portanto, com custos limitados, as empresas falarão menos sobre avanço tecnológico. No processo de seleção, a equipe técnica considerará menos o impacto que a tecnologia escolhida terá na equipe, quanto benefício trará para as operações e arquitetura existentes, etc., mas mais a partir da perspectiva de custo.

Além disso, o APISIX suporta a configuração simultânea de múltiplas descobertas de serviços. Muitas empresas, por razões históricas, podem ter vários sistemas de descoberta de serviços. Por exemplo, pelo que sei, algumas empresas terão tanto o antigo sistema de descoberta de serviços Eureka quanto o novo sistema de descoberta de serviços Nacos. O APISIX simplesmente precisa habilitar tanto o Eureka quanto o Nacos para lidar com essa situação.

Se você está atualmente configurando nós upstream diretamente no APISIX, também pode considerar implantar um sistema de descoberta de serviços separado e fazer com que o sistema de descoberta de serviços armazene a configuração específica do nó. O benefício de mover a configuração do nó upstream, do APISIX, para um sistema de descoberta de serviços dedicado é que o cliente pode fazer o registro do serviço sozinho, e o sistema de descoberta de serviços dedicado geralmente fornece funcionalidades adicionais, como verificações de saúde mais ricas.

No futuro, também apoiaremos a integração de vários componentes de registro e descoberta de serviços no APISIX Ingress Controller para facilitar o uso pelos usuários. Nesse momento, os usuários poderão não apenas especificar os endpoints do serviço K8s como nós upstream no APISIX Ingress Controller, mas também integrar os nós obtidos por descoberta de serviços.