Microservices Engine:Roteamento

Roteamento de serviço único

O gateway nativo da nuvem encaminha solicitações para um serviço de backend específico com base nas regras de roteamento. Para obter mais informações sobre como configurar serviços, consulte Adicionar um serviço.

O gateway compara as solicitações com as regras de roteamento que você configurou. Por exemplo:

• Todas as solicitações correspondentes à regra de roteamento /user são encaminhadas pelo gateway para o serviço de usuário.

• Todas as solicitações correspondentes à regra de roteamento /order são encaminhadas pelo gateway para o serviço de pedidos.

Roteamento baseado em porcentagem

O gateway nativo da nuvem distribui solicitações entre vários serviços de backend conforme o peso definido para cada serviço. Os cenários comuns incluem:

• Multiple Registry Centers

  Ao alterar os registros de serviço, implante uma réplica do serviço utilizando o novo registro enquanto mantém o serviço e o registro originais. O tráfego é desviado gradualmente do serviço original para o novo. Após verificar a estabilidade do novo serviço, encaminhe todo o tráfego para ele. A migração suporta rollback caso o novo serviço não atenda aos seus requisitos.

  A figura a seguir mostra um exemplo em que o serviço de usuário migra do Nacos para o CoreDNS integrado ao Kubernetes. O CoreDNS deve ser usado em conjunto com os resources de serviço.

  

• O&M System Differences

  Tradicionalmente, a maioria dos serviços executa em máquinas virtuais, como instâncias do Elastic Compute Service (ECS) da Alibaba Cloud. Com a migração crescente de empresas para plataformas baseadas em Kubernetes, como o Container Service for Kubernetes (ACK) da Alibaba Cloud, implique uma réplica do serviço em um cluster Kubernetes e registre-a com um novo nome no registro. Assim, dois serviços com funcionalidades idênticas coexistem: um em uma instância ECS e outro em um cluster Kubernetes. O tráfego é desviado gradualmente do ECS para o Kubernetes, permitindo ajustar a porcentagem ou reverter a qualquer momento.

  Por exemplo, suponha que você deseje migrar um serviço de usuário que utiliza o Nacos como registro do ECS para a plataforma ACK da Alibaba Cloud.

  

Roteamento baseado em tags

O gateway nativo da nuvem encaminha solicitações para diferentes versões de um serviço com base no peso configurado para cada versão. Para obter mais informações sobre como configurar versões de serviço, consulte Gerenciar versões de serviço. Os cenários comuns incluem:

• Canary release

  Uma canary release desvia uma pequena quantidade de tráfego para uma nova versão do serviço para validação. Se o resultado atender às expectativas, migre gradualmente o tráfego restante para a nova versão.

  Por exemplo, o serviço de usuário implantado em um cluster ACK executa atualmente a v1, e a v2 está planejada para lançamento. Execute uma canary release de uma das seguintes maneiras:

  • By ratio

    Utilize o roteamento baseado em tags para encaminhar solicitações /user para o serviço de usuário v1. Adicione o serviço de usuário v2 na página de gerenciamento de serviços no console do Microservices Engine (MSE) e inclua-o nos serviços de destino para roteamento baseado em tags. Configure um peso para determinar a porcentagem de tráfego encaminhada ao serviço de usuário v2.

    

  • Tags

    Utilize o roteamento baseado em tags para encaminhar solicitações /user para o serviço de usuário v1. Adicione uma rota /user e configure uma tag indicando que esta rota serve para uma canary release. Por exemplo, a tag pode ser o cabeçalho stage com o valor gray. Essa rota encaminha solicitações com tais cabeçalhos para o serviço de usuário v2.

    

• Tag-based routing

  Em um ambiente de produção, várias versões de um serviço podem coexistir por um longo período, com cada versão lidando com diferentes tipos de solicitações. Por exemplo, solicitações com valores de cabeçalho distintos podem ser encaminhadas para versões diferentes do serviço. O roteamento baseado em tags também se aplica quando múltiplos ambientes (teste, staging e produção) coexistem, usando tags para distinguir as solicitações de cada ambiente.

  Por exemplo, na aplicação a seguir, um serviço de usuário utiliza o serviço de contêiner K8s para descoberta de serviço e possui três ambientes de desenvolvimento (teste, pré e online). As configurações para solicitações em /user são as seguintes:

  • Caso o valor do cabeçalho stage seja test, o tráfego será encaminhado para o serviço de usuário no ambiente de teste.

  • Caso o valor do cabeçalho stage seja pre, o tráfego será encaminhado para o serviço de usuário no ambiente de staging.

  • Caso o valor do cabeçalho stage seja online, o tráfego será encaminhado para o serviço de usuário no ambiente de produção.

  

• High-availability deployment

  Para garantir a disponibilidade do serviço, implante serviços idênticos em vários clusters Kubernetes. Gerencie as instâncias de serviço por cluster com base nos metadados do nó e ajuste o peso para distribuir o tráfego entre os clusters. Se um cluster falhar, defina seu peso como 0 para encaminhar todo o tráfego aos clusters restantes.

  Por exemplo, no sistema de aplicação a seguir, a descoberta de serviço ocorre no serviço de usuário implantado nos clusters ACK A e B. Para as solicitações /user, 80% do tráfego é encaminhado para o serviço de usuário implantado no cluster A e 20% para o serviço de usuário implantado no cluster B.

  

Roteamento Mock

O roteamento Mock retorna uma resposta fixa para uma rota, permitindo verificar se as solicitações estão sendo encaminhadas corretamente. Isso possibilita que o desenvolvimento frontend e backend ocorra em paralelo.

Por exemplo, quando o serviço de usuário backend ainda não foi concluído, configure uma resposta fixa para suas operações de API para que os desenvolvedores frontend possam testar o processo de roteamento. Quando o serviço backend estiver pronto, altere o tipo de rota de Mock para o serviço real para realizar a depuração conjunta.

Roteamento de redirecionamento

O gateway nativo da nuvem pode redirecionar solicitações para um nome de domínio ou caminho diferente. Esse recurso é comum em migrações de nomes de domínio e alterações de API.

Por exemplo, se o nome de domínio atual do serviço for old.example.com e o caminho atual for /test, o gateway nativo da nuvem redirecionará uma solicitação de old.example.com/test para new.example.com/dev.