O Traffic Director ajuda a executar microsserviços em uma malha de serviço global. A malha lida com a rede dos microsserviços para que você possa escrever um código de aplicativo que não precise conhecer as complexidades de rede subjacentes. Essa separação da lógica do aplicativo da lógica de rede permite melhorar a velocidade de desenvolvimento, aumentar a disponibilidade do serviço e introduzir práticas modernas de DevOps à sua organização.
Sua malha de serviço consiste nos aplicativos, em um plano de dados compatível com xDS v2 (geralmente o proxy Envoy de código aberto, link em inglês) e no Traffic Director como plano de controle da malha.
Neste documento, apresentamos um resumo dos recursos disponíveis no Traffic Director.
Plano de controle totalmente gerenciado para a malha de serviço
O Traffic Director é um serviço de plano de controle altamente disponível e gerenciado que é executado no Google Cloud. Não é necessário instalar ou atualizar seu plano de controle. Portanto, você tem um componente a menos para gerenciar na infraestrutura da malha de serviço.
Plataformas para executar os serviços da malha
É possível executar aplicativos nas plataformas a seguir e adotá-los uma em uma malha de serviço global configurada pelo Traffic Director.
| Recurso | Compatível |
|---|---|
| Compute Engine: máquinas virtuais (VMs) | ✔ |
| Instâncias de contêiner do Google Kubernetes Engine | ✔ |
| Kubernetes em instâncias de contêiner do Compute Engine | ✔ |
Gerenciamento de serviços
Os serviços em uma malha configurada pelo Traffic Director se beneficiam da descoberta de serviços, do escalonamento automático de back-end e do registro automático de endpoints:
Quando um aplicativo na sua malha quiser alcançar outro app, ele poderá chamar esse serviço pelo nome. Essa prática é conhecida como descoberta de serviços.
Esses serviços têm como base as instâncias que executam o código do aplicativo, que são escalonadas dinamicamente de acordo com suas necessidades.
Quando novas instâncias são criadas ou removidas, elas precisam ser associadas ao seu serviço. Essa prática é chamada de registro de endpoints.
| Recurso | Compatível |
|---|---|
| Implantação automatizada de proxies sidecar para VMs do Compute Engine | ✔ |
| Injeção automatizada de proxies sidecar nos pods do Google Kubernetes Engine | ✔ |
| Descoberta de serviço com base no nome do host | ✔ |
| Escalonamento automático de instâncias com base no uso de CPU | ✔ |
| Escalonamento automático de instâncias com base na carga de tráfego/capacidade de exibição (somente VMs do Compute Engine em MIGs) | ✔ |
| Recuperação automática de instâncias com base em verificações de integridade configuráveis | ✔ |
| Registro automático de endpoints para instâncias de VM do Compute Engine | ✔ |
| Registro automático de endpoints para instâncias/pods de contêiner do GKE | ✔ |
| API para adicionar ou remover endpoints de forma programática | ✔ |
Endpoints para o tráfego do plano de dados
Os microsserviços usam o plano de dados para acessar serviços na sua malha e fora dela. O Traffic Director permite separar a lógica do aplicativo da lógica de rede. Dessa forma, tudo o que o aplicativo precisa fazer é enviar solicitações ao plano de dados, como para o proxy sidecar em execução junto ao aplicativo. O plano de dados cuida do envio de solicitações para o endpoint correto.
Na tabela abaixo, os aplicativos descritos como estando na malha são os que se comunicam com outros serviços usando o plano de dados gerenciado pelo Traffic Director. Esses aplicativos podem enviar tráfego para serviços na malha, bem como para serviços fora dela.
| Recurso | Compatível |
|---|---|
| Aplicativos baseados em VM na malha | ✔ |
| Aplicativos baseados em contêiner na malha | ✔ |
| Aplicativos baseados em VM fora da malha | ✔ |
| Aplicativos baseados em contêiner fora da malha | ✔ |
| Aplicativos em execução em data centers locais | ✔ |
| Aplicativos em ambientes com várias nuvens | ✔ |
Topologias do plano de dados
No modelo de malha de serviço, os aplicativos se comunicam usando um plano de dados. Esse plano de dados geralmente consiste em proxies sidecar implantados com seus aplicativos. O Traffic Director é altamente flexível e compatível com topologias de plano de dados que atendem às necessidades de rede do seu serviço.
| Recurso | Compatível |
|---|---|
| Proxies sidecar em execução com aplicativos | ✔ |
| Aplicativos gRPC sem proxy | ✔ |
| Proxies intermediários entre dois aplicativos em uma malha | ✔ |
| Proxies de borda no limite da malha | ✔ |
| Malha que abrange vários Clusters do GKE e/ou VMs do Compute Engine em várias regiões | ✔ |
Configuração programática orientada por API
Toda a configuração é exposta por meio da API REST e do painel, ambos prontos para uso, o que permite automatizar alterações em equipes grandes e gerenciar as mudanças de forma programática.
| Recurso | Compatível |
|---|---|
| APIs REST | ✔ |
| Console do Google Cloud | ✔ |
Interface de linha de comando gcloud |
✔ |
| Deployment Manager | ✔ |
| Suporte ao Terraform | ✔ |
Protocolos de solicitação
Os aplicativos podem usar os protocolos de solicitação a seguir quando se comunicam usando o plano de dados configurado pelo Traffic Director.
| Recurso | Compatível |
|---|---|
| HTTP | ✔ |
| HTTP/2 | ✔ |
| gRPC | ✔ |
Gerenciamento de tráfego e roteamento
O Traffic Director tem políticas avançadas de gerenciamento de tráfego que podem ser usadas para direcionar, dividir e moldar o tráfego conforme ele passa pelo plano de dados. Observe que a maior parte do gerenciamento de tráfego avançado não está ativada para o Traffic Director com serviços do gRPC sem proxy.
| Recurso | Compatível com proxy Envoy | Compatível com gRPC sem proxy |
|---|---|---|
| O roteamento de solicitação HTTP/Layer 7 com base na correspondência de sufixo/prefixo/completo/regex nestes itens: | ||
| • Nome do host | ✔ | ✔ 1.30.0 ou versões posteriores |
| • Caminho | ✔ | ✔ 1.31.0 ou posterior (exceto regexMatch) |
| • Cabeçalhos | ✔ | ✔ 1.31.0 ou posterior (exceto regexMatch) |
| • Método | ✔ | N/A |
| • Cookies | ✔ | ✔ 1.31.0 ou versões posteriores |
| • Parâmetros de solicitação | ✔ | N/A |
| Injeção de falha | ✔ | |
| Tempo limite configurável | ✔ | |
| Novas tentativas | ✔ | |
| Redirecionamentos | ✔ | N/A |
| Reprogramações de URI | ✔ | |
| Transformações do cabeçalho de solicitação/resposta | ✔ | |
| Divisão de tráfego | ✔ | |
| Espelhamento do tráfego | ✔ | |
| Detecção de outlier | ✔ |
Balanceamento de carga
É possível configurar métodos e algoritmos avançados de balanceamento de carga para balancear a carga no serviço, no grupo de back-ends (grupos de instâncias ou de endpoints de rede) e em níveis de endpoints ou back-ends específicos. Para mais informações, consulte Visão geral dos serviços de back-end.
| Recurso | Compatível com proxy Envoy | Compatível com gRPC sem proxy |
|---|---|---|
| Seleção de serviços por divisões de tráfego com base no peso | ✔ | |
| Seleção de back-ends (grupo de instâncias ou de endpoints de rede) com base na região (de preferência a região mais próxima com uma capacidade de back-end íntegra) | ✔ | ✔ 1.30.0 ou versões posteriores |
| Seleção de back-ends usando o modo de balanceamento baseado em taxa (solicitações por segundo) | ✔ | ✔ 1.30.0 ou versões posteriores |
| Seleção de back-ends com base no modo de balanceamento baseado na utilização (somente VMs em grupos de instâncias do Compute Engine) | ✔ | ✔ 1.30.0 ou versões posteriores |
| Capacidade máxima configurável por back-end (somente no Compute Engine e no GKE) | ✔ | ✔ 1.30.0 ou versões posteriores |
| Disjuntores | ✔ | |
Seleção de back-ends com base em políticas de balanceamento de carga configuráveis*:
|
✔ | Somente round-robin |
*Consulte localityLbPolicy para saber mais detalhes.
Gerenciamento de capacidade de serviço e back-end
O Traffic Director considera a capacidade do serviço e do back-end para garantir a distribuição ideal do tráfego nos back-ends dos serviços. O Traffic Director é integrado à infraestrutura do Google Cloud para coletar automaticamente dados de capacidade. Também é possível definir e configurar a capacidade manualmente.
| Recurso | Compatível |
|---|---|
| Monitora automaticamente a capacidade e a utilização do back-end, com base na CPU, para instâncias de VM em um grupo de instâncias gerenciadas | ✔ |
| Capacidade e modificações manuais para instâncias de VM e contêiner em MIGs e NEGs com base na taxa de solicitação | ✔ |
| Diminuição da capacidade manual | ✔ |
Failover
As cargas de trabalho empresariais geralmente dependem de implantações de alta disponibilidade para garantir o tempo de atividade do serviço. Para ser compatível com esses tipos de implantação, o Traffic Director ativa a redundância de várias zonas/regiões.
| Recurso | Compatível |
|---|---|
| Failover automático para outra zona na mesma região que tem uma capacidade de back-end íntegra | ✔ |
| Failover automático para a região mais próxima com uma capacidade de back-end íntegra | ✔ |
Verificações de integridade
Verificação de integridade centralizada para determinar a integridade do back-end. Para ver informações de referência, consulte Visão geral das verificações de integridade.
| Recurso | Compatível |
|---|---|
| Verificações de integridade do gRPC | ✔ |
| Verificações de integridade de HTTP | ✔ |
| Verificações de integridade de HTTPS | ✔ |
| Verificações de integridade de HTTP/2 | ✔ |
| Verificações de integridade de TCP | ✔ |
Verificações de integridade configuráveis:
|
✔ |
| Caminho de solicitação configurável (HTTP, HTTPS, HTTP/2) | ✔ |
| String ou caminho de solicitação configurável (TCP ou SSL) | ✔ |
| String de resposta esperada configurável | ✔ |
Observabilidade
As ferramentas de observabilidade fornecem informações de monitoramento, depuração e desempenho para ajudar você a entender a malha de serviço. Os recursos a seguir são fornecidos prontos para uso ou precisam ser configurados no plano de dados. O código do aplicativo não precisa fazer nada especial para gerar esses dados de observabilidade.
O painel de integridade do serviço está disponível com serviços gRPC sem proxy, mas não é possível configurar a geração de registros e o rastreamento do plano de dados. O Traffic Director não pode configurar a geração de registros e o rastreamento de um aplicativo do gRPC. Para ativar isso, siga as instruções nas seções de solução de problemas ou dos guias do gRPC disponíveis em sites de código aberto. Por exemplo, é possível usar o Opencensus (em inglês) para ativar a coleta de métricas e o rastreamento nos serviços gRPC sem proxy.
| Recurso | Compatível com proxies | Compatível com serviços gRPC sem proxy |
|---|---|---|
| Painel de integridade do serviço | ✔ | ✔ |
| Geração de registros do plano de dados | ✔ | |
| Rastreamento do plano de dados | ✔ |
Afinidade da sessão
As comunicações entre clientes e servidores geralmente envolvem várias solicitações sucessivas. Nesse caso, é útil encaminhar solicitações sucessivas do cliente para o mesmo back-end ou servidor. O Traffic Director oferece opções configuráveis para enviar solicitações de um cliente específico da melhor maneira possível para o mesmo back-end, desde que ele esteja íntegro e tenha capacidade. Para mais informações, consulte Visão geral dos serviços de back-end.
| Recurso | Compatível com proxies | Compatível com serviços gRPC sem proxy |
|---|---|---|
| Endereço IP do cliente | ✔ | |
| Cookie HTTP | ✔ | |
| Cabeçalho HTTP | ✔ | |
| Cookie gerado (define o cookie do cliente na primeira solicitação) | ✔ |
Topologias de rede
O Traffic Director é compatível com topologias de rede comuns do Google Cloud.
| Recurso | Compatível |
|---|---|
| Rede única em um projeto do Google Cloud | ✔ |
| VPC compartilhada (rede única compartilhada em vários projetos do Google Cloud) | ✔ |
Consulte "Limitações" para ver uma explicação detalhada de como a VPC compartilhada é compatível com o Traffic Director.
Conformidade
O Traffic Director está em conformidade com os padrões a seguir.
| Certificação de conformidade | |
|---|---|
| HIPAA | ✔ |
| ISO 27001, ISO 27017, ISO 27018 | ✔ |
| SOC1, SOC2, SOC3 | ✔ |
| PCI DSS | ✔ |