Integração do Traffic Director com o Diretório de serviços

Neste documento, você encontra uma visão geral de como usar o registro de serviços do Diretório de serviços com o Traffic Director. Isso permite que o Traffic Director direcione o tráfego e aplique políticas de tráfego aos serviços registrados no Diretório de serviços. Este documento é destinado aos desenvolvedores do Traffic Director que querem integrar os aplicativos deles a outros serviços no Google Cloud.

O Diretório de serviços é um registro de serviço que armazena informações sobre serviços de rede que estão registrados nele, incluindo nomes, locais e atributos. É possível registrar seus serviços automaticamente, capturando todos os detalhes. Além disso, todos os serviços podem ser registrados, independentemente da infraestrutura.

O registro pode conter não apenas os serviços do Google Cloud, mas também serviços híbridos executados no local ou em outras nuvens públicas. Para entender melhor as informações neste documento, recomendamos que você se familiarize com os princípios básicos das operações do Diretório de serviços.

Quando você usa o registro de serviços do Diretório de serviços com o Traffic Director, a integração disponibiliza os serviços no registro de serviço para os aplicativos na sua malha e para gateways configurados pelo Traffic Director. A integração do Traffic Director com o Diretório de serviços é compatível com o Envoy e com o gRPC sem proxy para integrações do Diretório de serviços com balanceadores de carga de rede de passagem internos, balanceadores de carga de aplicativos internos e Private Service Connect tL4.

Para integrar seus serviços, registre um serviço no Diretório de serviços e, em seguida, vincule-o a um serviço de back-end do Traffic Director. Depois que uma vinculação é estabelecida, o Traffic Director consulta o Diretório de serviços para receber informações sobre o serviço registrado e como esse serviço pode ser alcançado. O Traffic Director também rastreia as alterações no serviço. O uso da integração permite que a malha de serviço e o gateway autogerenciado enviem tráfego para esses serviços. Isso também permite aplicar políticas, por exemplo, políticas avançadas de gerenciamento de tráfego, que você configura no Traffic Director.

Quando você usa essa integração, a vinculação de serviço atua como um back-end, independentemente do tipo de back-end usado pelo próprio serviço. A integração simplifica a implantação do Traffic Director, porque o Traffic Director pode enviar tráfego para o serviço sem considerar o tipo de back-end.

Quando um serviço é registrado no Diretório de serviços, você não precisa configurar grupos de instâncias ou diferentes tipos de grupos de endpoints de rede (NEGs, na sigla em inglês) para ter acesso aos serviços necessários. É possível registrar automaticamente o Google Kubernetes Engine, os balanceadores de carga internos e o Private Service Connect no Diretório de serviços, simplificando ainda mais o acesso do Traffic Director a esses serviços.

Recursos usados pela integração

A integração entre o Traffic Director e o Diretório de serviços usa os seguintes recursos.

Serviços do Diretório de serviços

O Diretório de serviços é um registro de serviço. O Diretório de serviços permite registrar vários tipos de serviços, incluindo aqueles baseados no Google Cloud ou em outros ambientes (por exemplo, um data center no local). Cada serviço consiste em um nome exclusivo e zero ou mais endpoints de serviço. Um endpoint de serviço consiste em um endereço, uma porta, propriedades e metadados. Se não houver nenhum endpoint, não será possível rotear o tráfego para o serviço.

Vinculações de serviço

Uma vinculação de serviço é um recurso que inclui o nome de domínio totalmente qualificado (FQDN, na sigla em inglês) do serviço do Diretório de serviços. Por exemplo, projects/test-proj/locations/us-east1/namespaces/test-namespace/services/test-service é um FQDN de um serviço do Diretório de serviços.

Serviços de back-end

Os serviços de back-end são recursos de configuração que fornecem informações ao Traffic Director, incluindo os back-ends, como grupos de instâncias gerenciadas, para os quais o serviço de back-end encaminha o tráfego. Os serviços de back-end que se referem às vinculações de serviço não podem ter back-ends. Para usar a integração do Traffic Director com o Diretório de serviços, crie um novo serviço de back-end para referenciar vinculações de serviço.

Um serviço de back-end pode ter várias vinculações de serviço. Essa configuração é útil em uma situação em que você tem implantações regionais do mesmo aplicativo. É possível registrar cada implantação regional em uma instância regional do Diretório de serviços, como serviço regional 1 e serviço regional 2. Cada um desses serviços do Diretório de serviços regionais pode ser associado ao mesmo serviço de back-end, usando duas vinculações de serviço. A vinculação de serviço global 1 seria associada ao serviço regional 1 na região A, e a vinculação de serviço global 2 estaria associada ao serviço regional 2 na região B.

Casos de uso

Integrar a implantação do Traffic Director ao Diretório de serviços permite novos casos de uso que são úteis quando você depende de serviços que outras equipes ou organizações têm ou publicam.

Disponibilizar serviços existentes para o Traffic Director

O Diretório de serviços se integra a produtos do Google Cloud, como o GKE, os balanceadores de carga de rede de passagem interna e os balanceadores de carga de aplicativo internos. Quando os produtores de serviços criam um serviço do GKE ou um balanceador de carga, eles podem registrá-lo no Diretório de serviços.

Depois que um serviço é registrado no Diretório de serviços, é possível configurar o Traffic Director para se comunicar com esse serviço. Os clientes do Traffic Director podem se comunicar com serviços executados atrás dos balanceadores de carga de rede e de aplicativo internos.

Melhore a coordenação entre produtores e consumidores de serviços

Grandes empresas têm muitas equipes de desenvolvedores independentes. Essas equipes disponibilizam os serviços para outras equipes para que mais equipes possam usar os recursos fornecidos pelo serviço compartilhado. Isso cria dependências entre equipes. Embora essas dependências permitam que as equipes compartilhem os esforços, elas também criam sobrecarga de coordenação.

Quando você usa o Diretório de serviços, uma equipe (o produtor) registra um serviço que quer disponibilizar para outras equipes ou organizações (consumidores). O produtor compartilha uma referência a esse serviço com um consumidor. O consumidor pode usar essa referência para procurar o serviço do produtor no Diretório de serviços e descobrir os endpoints do serviço. Por exemplo, o endpoint pode ser um endereço IP virtual (VIP, na sigla em inglês) em que o serviço do produtor espera receber tráfego.

A integração do Traffic Director com o Diretório de serviços permite automatizar o processo ao vincular um serviço do Diretório de serviços a um serviço de back-end do Traffic Director, que tem as seguintes vantagens:

  • O Traffic Director resolve automaticamente os endpoints do serviço sincronizando-os com o Diretório de serviços. Se os endpoints do serviço do Diretório de serviços forem atualizados, o Traffic Director vai sincronizar automaticamente essas alterações.
  • É possível definir várias políticas de gerenciamento de tráfego e roteamento, como tempos limite, no Traffic Director. Essas políticas permitem ajustar como seus aplicativos emitem solicitações para o serviço do Diretório de serviços. Para informações sobre gerenciamento de tráfego e roteamento no Traffic Director, consulte Gerenciamento de tráfego avançado.
  • O Traffic Director usa recursos de gerenciamento de tráfego, como balanceamento de carga com base em proximidade, para direcionar o tráfego de aplicativos para endpoints de maneira ideal, por exemplo, minimizando o tempo de retorno.
Como usar o Diretório de serviços para a descoberta de serviços.
Como usar o Diretório de serviços para descoberta de serviços (clique para ampliar)

Quando você, um consumidor, usa o Traffic Director e anexa um serviço de back-end a um serviço do Diretório de serviços, e a sobrecarga de coordenação entre equipes é reduzida.

  • Anexe o serviço, Payments, pelo nome.

  • O Traffic Director compartilha informações sobre o serviço do Payments com os clientes.

    • Por exemplo, os proxies sidecar em execução na malha de serviço agora sabem o endpoint (por exemplo, 10.0.0.1:80) em que o serviço pode ser acessado.

  • Seus aplicativos podem chamar esse serviço por nome sem que você ou seu aplicativo precisem saber nada sobre o endpoint do serviço externo. No diagrama, o serviço é Payments.

  • Quando o fornecedor de serviços atualiza o serviço externo (por exemplo, alterando o endpoint), o Traffic Director coleta a atualização e a compartilha com os clientes facilmente.

Acessar serviços dentro de um perímetro usando um ponto de entrada

Uma equipe pode agrupar um conjunto de serviços em um perímetro do VPC Service Controls e expor esses serviços por meio de um único ponto de entrada. Esse ponto de entrada pode ser registrado no Diretório de serviços e disponibilizado para usuários que queiram acessar os serviços dentro do perímetro. Para mais informações sobre perímetros do VPC Service Controls, consulte Detalhes e a configuração do perímetro de serviço.

Por exemplo, uma equipe cria um gateway de entrada usando um balanceador de carga de aplicativo interno que distribui solicitações para uma coleção de serviços do Kubernetes em um cluster. Esse gateway de entrada é registrado automaticamente como um serviço no Diretório de serviços. Um consumidor que queira acessar os serviços do Kubernetes pode procurar esse gateway de entrada no Diretório de serviços. O consumidor pode, então, configurar a malha do Traffic Director para acessar serviços dentro do perímetro por meio do gateway.

Conectar serviços em vários domínios

Aproveite serviços em diferentes domínios que precisa você precisa conectar.

Conectar serviços em várias organizações

Talvez você queira acesso a serviços de outra organização, como APIs do Google (por exemplo, Cloud SQL) ou serviços gerenciados de terceiros.

O Diretório de serviços tem suporte para o Private Service Connect. Quando você cria um endpoint do Private Service Connect na rede, ele pode ser registrado como um serviço no Diretório de serviços. É possível, então, anexar esse serviço ao Traffic Director para que clientes de malha, como clientes Envoy e gRPC, e gateways autogerenciados, como a Apigee, possam chamar nesses serviços.

Como usar o Diretório de serviços para a descoberta de serviços com o Private Service Connect.
Como usar o Diretório de serviços para a descoberta de serviços com o Private Service Connect (clique para ampliar)

O exemplo anterior, que usa o Cloud Storage, ilustra como você pode usar o Private Service Connect para chamar as APIs do Google usando um endpoint na sua rede de nuvem privada virtual.

Conecte serviços em redes VPC

Algumas empresas usam várias redes VPC como parte da implantação do Google Cloud. Nesses casos, um serviço em uma rede VPC pode precisar acessar um serviço em uma rede VPC diferente. É possível configurar o peering de VPC para acessar um serviço em uma rede VPC diferente. No entanto, essa configuração cria complicações quando há intervalos de endereços IP sobrepostos entre redes com peering.

O Private Service Connect pode tornar um serviço seguro e particular em uma rede VPC acessível para serviços em outra rede VPC, usando um único endpoint IP:port.

Visualização detalhada do uso do Diretório de serviços para a descoberta de serviços com o Private Service Connect.
Visualização detalhada do uso do Diretório de serviços para a descoberta de serviços com o Private Service Connect (clique para ampliar)

Exemplos adicionais entre domínios

Os dois exemplos anteriores ilustram casos em que talvez seja necessário cruzar domínios, mas há muitos outros exemplos. Por exemplo, você cria um gateway que fica na interseção de duas regiões do Google Cloud. Os serviços em uma região podem acessar serviços em outra região por meio desse gateway. Registre o gateway como um serviço no Diretório de serviços e use o gateway com o Traffic Director, conforme descrito neste documento.

Aplicar políticas quando os serviços forem acessados

O Traffic Director é compatível com recursos como o gerenciamento de tráfego avançado, que podem ser configurados usando políticas. Por exemplo, é possível definir uma política de espelhamento de tráfego para que, sempre que um cliente enviar uma solicitação para um determinado serviço de back-end, ele também seja enviado para um segundo serviço de back-end.

Ao vincular um serviço do Diretório de serviços a um serviço de back-end do Traffic Director, é possível configurar esses tipos de políticas no Traffic Director. Os proxies sidecar, proxies de meio ou borda e os clientes sem proxy aprendem sobre essas políticas e as aplicam.

Alguns exemplos:

  • Divisão de tráfego baseada em peso, por exemplo, entre dois serviços do Diretório de serviços
  • Espelhamento de tráfego, por exemplo, para um serviço de auditoria
As solicitações para o serviço "users" são espelhadas para o serviço "audit".
As solicitações do serviço users são espelhadas para o serviço audit (clique para ampliar)

Suporte para o Traffic Director e clientes atuais

Mesmo quando o Traffic Director é implantado na sua organização, você pode ter clientes que não usam o Traffic Director. Por exemplo, talvez seja necessário acessar um serviço de uma máquina virtual que não faz parte de uma malha de serviço.

Quando você vincula um serviço do Diretório de serviços a um serviço de back-end do Traffic Director, os clientes do Traffic Director recebem automaticamente informações atualizadas sobre esse serviço. Os clientes que não usam o Traffic Director podem pesquisar e usar informações de serviço no Diretório de serviços.

Limitações

O Traffic Director não é compatível com NEGs FQDN (INTERNET_FQDN_PORT NEGs) na integração do Diretório de serviços.

A seguir