API Gateway:Roteamento

Roteamento de serviço único

No modo de roteamento de serviço único, o gateway compara as requisições recebidas com as regras configuradas e as encaminha para um único serviço de backend. Exemplo:

• Requisições correspondentes à regra /user/@filepath são encaminhadas ao serviço de usuário.

• Requisições correspondentes à regra /order/@filepath são encaminhadas ao serviço de pedidos.

Para obter informações sobre como configurar serviços, consulte Gerencie serviços.

Roteamento por porcentagem

No modo de roteamento por porcentagem, o gateway distribui o tráfego entre vários serviços de backend com base nos pesos configurados. Utilize este modo ao migrar serviços entre registros ou sistemas de operação e manutenção (O&M) sem interromper o tráfego.

• Different registries

  Ao atualizar um registro de serviços, implante uma réplica do serviço usando o novo registro em paralelo ao serviço existente. Transfira gradualmente o tráfego do serviço antigo para o novo ajustando os pesos. Após a estabilização do novo serviço, direcione todo o tráfego para ele. Caso ocorram problemas, reverta o tráfego para o serviço antigo a qualquer momento.

  Por exemplo, suponha que um serviço de usuário utilize originalmente o Nacos como registro. Para mudar para a solução integrada CoreDNS no Kubernetes (K8s), que exige resources de Service, migre o tráfego incrementalmente usando o roteamento por porcentagem.

  

• Different O&M systems

  Ao migrar serviços de máquinas virtuais para o Kubernetes, implante uma réplica no cluster K8s e registre-a com um novo nome de serviço. O registro de serviços passará a conter dois serviços com a mesma funcionalidade: um em uma instância do Elastic Compute Service (ECS) e outro em um cluster do Alibaba Cloud Container Service for Kubernetes (ACK). Transfira o tráfego gradualmente para o serviço no K8s, ajustando pesos ou revertendo a migração a qualquer momento.

  Como exemplo, considere um serviço de usuário que utiliza o Nacos como registro e está sendo migrado de uma instância ECS para o ACK.

  

Roteamento baseado em tags

No modo de roteamento baseado em tags, o gateway encaminha requisições para diferentes versões do mesmo serviço ou de serviços distintos, conforme pesos ou atributos da requisição configurados. Esse modo é ideal para canary releases, roteamento multiambiente e implantações de alta disponibilidade. Para detalhes sobre a configuração de versões de serviço, consulte Gerencie versões de serviço.

• Canary release

  Durante um canary release, uma pequena parcela do tráfego é direcionada à nova versão para validação. Se o desempenho for o esperado, o tráfego é transferido gradualmente até que a versão antiga não receba mais nenhuma requisição. O roteamento baseado em tags permite duas abordagens para canary releases:

  Imagine um serviço de usuário que utiliza o serviço de contêineres K8s para descoberta de serviços. A versão atual é v1 e uma nova versão v2 está pronta para lançamento.

  • By percentage

    A rota /user/@filepath usa roteamento baseado em tags para encaminhar requisições ao serviço de usuário v1. Adicione a v2 como uma versão de serviço no gerenciamento de serviços e, em seguida, inclua o serviço de usuário v2 como destino na regra de roteamento, configurando um peso para controlar a porcentagem de tráfego recebida.

    

  • By tag

    A rota existente /user/@filepath encaminha requisições ao serviço de usuário v1. Crie uma segunda rota /user/@filepath com uma tag de canary release — por exemplo, um header chamado stage/@parmname com o valor gray/@parmname. Requisições contendo esse header serão encaminhadas ao serviço de usuário v2.

    

• Tag-based routing

  Um serviço pode ter várias versões de longa duração, cada uma atendendo a requisições que correspondem a atributos específicos. Por exemplo, requisições com um determinado valor de header podem ser roteadas para uma versão específica do serviço. Essa abordagem é útil para gerenciar múltiplos ambientes — como teste, pré-lançamento e produção — em um único gateway.

  Considere um serviço de usuário que utiliza o serviço de contêineres K8s para descoberta de serviços e possui três ambientes: teste, pré-lançamento e produção. As requisições para a rota /user/@filepath são roteadas da seguinte forma:

  • Se o valor do header stage for test, o tráfego será encaminhado para a versão de teste do serviço de usuário.

  • Se o valor do header stage for pre, o tráfego será encaminhado para a versão de pré-lançamento do serviço de usuário.

  • Se o valor do header stage for online, o tráfego será encaminhado para a versão de produção do serviço de usuário.

  

• High-availability deployment

  Para aumentar a disponibilidade do serviço, implante-o em vários clusters K8s e gerencie as instâncias por cluster usando metadados de nó relacionados ao cluster. Cada cluster corresponde a uma versão de serviço com um peso de tráfego configurável. Em caso de falha em um cluster, defina seu peso como 0 para redirecionar todo o tráfego aos clusters restantes.

  Por exemplo, um serviço de usuário que utiliza o serviço de contêineres K8s para descoberta de serviços está implantado em dois clusters ACK, Cluster A e Cluster B. Para requisições na rota /user/@filepath, 80% do tráfego é encaminhado ao Cluster A e 20% ao Cluster B.

  

Roteamento mock

O roteamento mock retorna uma resposta fixa para uma rota sem encaminhar a requisição a um serviço de backend. Utilize esse recurso para desbloquear o desenvolvimento frontend antes que o backend esteja pronto ou para verificar se as regras de correspondência de requisições funcionam corretamente.

Por exemplo, configure uma resposta fixa para a API do serviço de usuário antes do desenvolvimento do backend, permitindo que os desenvolvedores frontend testem e depurem de forma independente. Quando o backend estiver pronto, altere a rota de mock para apontar ao serviço real e realize testes de ponta a ponta.

Roteamento de redirecionamento

O roteamento de redirecionamento envia os clientes para um nome de domínio ou caminho diferente. Use essa funcionalidade para migrações de nomes de domínio ou alterações de caminhos de API.

Por exemplo, uma requisição para old.example.com/test chega ao gateway, que a redireciona para new.example.com/dev.