Use the ASM fallback mechanism - Alibaba Cloud Service Mesh: Central de Documentação do Alibaba Cloud

O mecanismo de fallback define uma ação alternativa quando uma chamada de serviço falha. Se um microsserviço apresentar falha ou ficar indisponível, esse mecanismo aciona um serviço de backup para processar as requisições, garantindo a estabilidade e a disponibilidade do sistema. Por exemplo, caso um endpoint de serviço esteja inacessível, use o mecanismo de fallback para encaminhar as requisições a uma versão de serviço de reserva. Isso assegura o atendimento das requisições dos clientes sem erros ou interrupções. O ASM oferece suporte a esse recurso por meio do parâmetro fallback em um VirtualService. Este tópico descreve como usar o mecanismo de fallback no ASM.

Pré-requisitos

Você possui uma instância do ASM nas edições Enterprise ou Ultimate, versão 1.17.2.22 ou posterior. Para mais informações, consulte Criar uma instância do ASM.

Nota
Se a sua instância do ASM for anterior à versão 1.17, atualize-a para a versão 1.17.2.22 ou posterior, ou envie um ticket para obter suporte técnico. Para mais detalhes sobre como atualizar uma instância, consulte Atualizar uma instância do ASM.
Um cluster ACK foi adicionado à instância do ASM. Para mais informações, consulte Adicionar um cluster a uma instância do ASM.
A amostra Bookinfo está implantada. Para mais informações, consulte Implantar uma aplicação em um cluster associado a uma instância do ASM.
A versão do sidecar no plano de dados é 1.17 ou posterior.

Nota
Verifique a versão do sidecar de cada pod de negócios na página Instances Status no console do ASM. Para mais informações, consulte Gerenciamento de atualizações.

Configuração

Este tópico usa o serviço reviews da aplicação de exemplo Bookinfo como referência. Quando o serviço productpage acessa as versões v1, v2 e v3 do serviço reviews, caso a versão v3 esteja indisponível, o mecanismo de fallback roteia as requisições para a versão v2. Essa abordagem impede que o serviço retorne um erro 503.

Clique em Arquivo de configuração para baixar os arquivos YAML usados neste tópico.

Etapa 1: Acessar a amostra Bookinfo

Crie um arquivo chamado reviews.yaml com o conteúdo abaixo para declarar as versões v1, v2 e v3 do serviço reviews.

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
  - name: v3
    labels:
      version: v3

No seu ambiente KubeConfig, execute o comando a seguir para implantar o DestinationRule.
```
kubectl apply -f reviews.yaml
```
Use um dos métodos abaixo para obter o endereço IP do gateway de entrada.
- Método 1: Execute o seguinte comando.
```
kubectl get svc -n istio-system  istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}'
```
- Método 2: Obtenha o endereço IP do gateway de entrada na página Ingress Gateway no console do ASM. Para mais informações, consulte Obter o endpoint de um gateway do ASM.
Em um navegador, acesse http://${YourGatewayIp}/productpage.

${YourGatewayIp} corresponde ao IP do gateway obtido na etapa anterior. Identifique a versão pelo valor de Reviews served by ou pelas estrelas. A versão v1 não exibe estrelas, a versão v2 mostra estrelas pretas e a versão v3 apresenta estrelas vermelhas.

Por exemplo, o valor reviews-v2 indica a versão v2, que exibe estrelas pretas.

Atualize a página várias vezes. As requisições agora são balanceadas entre as versões v1, v2 e v3 do serviço reviews.

Etapa 2: Definir uma rota e regra de fallback

Crie um arquivo chamado reviews-route-fallback-sample1.yaml com o seguinte conteúdo.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews-route
  namespace: default
spec:
  hosts:
    - reviews
  http:
    - route:
        - destination:
            host: reviews
            subset: v3
          fallback:
            target:
              host: reviews
              subset: v2

No ambiente KubeConfig da instância do ASM, execute o comando abaixo para implantar a rota e a regra de fallback do serviço reviews.
```
kubectl apply -f reviews-route-fallback-sample1.yaml
```
Em um navegador web, acesse http://${YourGatewayIp}/productpage e continue atualizando a página.

Observe que as requisições são roteadas consistentemente para a versão v3 do serviço reviews. Após a atualização, a página mostra que o serviço de avaliação de livros é fornecido por reviews-v3, e a avaliação inclui classificações com estrelas vermelhas.
Simule uma falha na versão reviews-v3 dimensionando suas réplicas para 0:
```
kubectl scale deployment reviews-v3 --replicas=0
```

No navegador, acesse http://${YourGatewayIp}/productpage e atualize a página repetidamente.

Verifique se as requisições retornam corretamente à versão v2 do serviço reviews. Confirme a ocorrência do fallback adicionando campos relacionados a ele no formato de log de acesso personalizado e, em seguida, verificando os logs.

Verificar o fallback

Adicione os seguintes campos ao formato de log de acesso personalizado. Para mais informações, consulte Personalizar o conteúdo dos logs de acesso do plano de dados.

Campo	Valor	Descrição
fallback_path	%DYNAMIC_METADATA(com.aliyun.fallback:fallback-path)%	O caminho específico do fallback. Por exemplo, `A:B` indica que as requisições passaram de A para B. Já `A:B:C` significa que as requisições foram de A para B e, se B também estiver não íntegro, de B para C.
fallback_final_cluster_name	%DYNAMIC_METADATA(com.aliyun.fallback:final-cluster)%	Caso ocorra um fallback, este é o cluster de destino. Por exemplo, se `service1	v1` não existir, as requisições serão direcionadas para `service	base`.
fallback_result	%DYNAMIC_METADATA(com.aliyun.fallback:fallback-result)%	O resultado do fallback. Se o fallback falhar, a falha da requisição será atribuída ao cluster de destino original.

Visualize os logs do istio-proxy para productpage-v1.

O log a seguir mostra um fallback de reviews-v3 para reviews-v2:

{
    "authority":"reviews:9080",
    "authority_for":"reviews:9080",
    "bytes_received":"0",
    "bytes_sent":"442",
    "downstream_local_address":"192.168.255.46:9080",
    "downstream_remote_address":"172.16.0.252:57238",
    "duration":"10",
    "fallback_path":"outbound|9080|v3|reviews.default.svc.cluster.local:outbound|9080|v2|reviews.default.svc.cluster.local",
    "fallback_final_cluster_name":"outbound|9080|v2|reviews.default.svc.cluster.local",
    "fallback_result":"fallback successful",
    "istio_policy_status":"-",
    "method":"GET",
    "path":"/reviews/0",
    "protocol":"HTTP/1.1",
    "request_id":"15b2dffc-5f3f-4060-b9fa-898eab08****",
    "requested_server_name":"-",
    "response_code":"200",
    "response_flags":"-",
    "route_name":"-",
    "start_time":"2023-05-30T07:02:26.990Z",
    "trace_id":"18b3aed8af41****",
    "upstream_cluster":"outbound|9080|v2|reviews.default.svc.cluster.local",
    "upstream_host":"172.16.0.11:9080",
    "upstream_local_address":"172.16.0.252:44448",
    "upstream_service_time":"9",
    "upstream_transport_failure_reason":"-",
    "user_agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.X.X Safari/537.36",
    "x_forwarded_for":"-"
}

Encontre os novos campos abaixo no log.

"fallback_path":"outbound|9080|v3|reviews.default.svc.cluster.local:outbound|9080|v2|reviews.default.svc.cluster.local"
"fallback_final_cluster_name":"outbound|9080|v2|reviews.default.svc.cluster.local"
"fallback_result":"fallback successful"

O log indica que o destino original era v3. Como a instância v3 estava indisponível, a requisição passou para v2.

Etapa 3: Configurar fallback com roteamento ponderado

Execute o comando a seguir para tornar a versão reviews-v3 disponível novamente.
```
kubectl scale deployment reviews-v3 --replicas=1
```

Crie um arquivo chamado reviews-route-fallback-sample2.yaml com o conteúdo abaixo para modificar a definição de reviews-route.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews-route
  namespace: default
spec:
  hosts:
    - reviews 
  http:
    - route:
        - destination:
            host: reviews 
            subset: v3
          fallback:
            target:
              host: reviews 
              subset: v2
          weight: 50
        - destination:
            host: reviews 
            subset: v2
          fallback:
            target:
              host: reviews 
              subset: v1
          weight: 50
      retries:
        attempts: 0

Execute o comando abaixo para implantar a nova rota e a regra de fallback do serviço reviews.
```
kubectl apply -f reviews-route-fallback-sample2.yaml
```
No navegador, acesse http://${YourGatewayIp}/productpage e atualize a página repetidamente.

Note que as requisições são roteadas para as versões v2 e v3 do serviço reviews na proporção de 50:50. Neste exemplo, as novas tentativas estão desabilitadas para tornar o resultado mais claro.
Execute o comando a seguir para dimensionar as réplicas de v3 para 0 e verificar se a regra de fallback funciona conforme o esperado.
```
kubectl scale deployment reviews-v3 --replicas=0
```
Atualize a página productpage várias vezes. As requisições serão roteadas consistentemente para a versão v2, que é o comportamento esperado.
Execute o comando abaixo para dimensionar as réplicas de v2 para 0.
```
kubectl scale deployment reviews-v2 --replicas=0
```
Ao atualizar repetidamente a página productpage, você notará que o acesso ao serviço reviews falha em cerca de 50% das vezes. Nos outros 50%, as requisições são enviadas para a versão v2. Como a versão v2 não está íntegra, essas requisições passam para a versão v1. Após executar o comando e acessar a página de produtos da aplicação BookInfo, a seção de avaliações exibirá o título de erro em vermelho Error fetching product reviews! e a mensagem Sorry, product reviews are currently unavailable for this book.. Isso indica que o serviço de avaliações de produtos ficou indisponível após o dimensionamento das réplicas de reviews-v2 para 0.

Execute o comando a seguir para visualizar os logs.

kubectl logs -f  deployment/productpage-v1  -c istio-proxy --tail=10

Saída esperada:

{
    "authority":"reviews:9080",
    "authority_for":"reviews:9080",
    "bytes_received":"0",
    "bytes_sent":"19",
    "downstream_local_address":"192.168.255.46:9080",
    "downstream_remote_address":"172.16.0.252:47738",
    "duration":"0",
    "fallback_path":"outbound|9080|v3|reviews.default.svc.cluster.local:outbound|9080|v2|reviews.default.svc.cluster.local",
    "fallback_final_cluster_name":"-",
    "fallback_result":"fallback cluster is unhealthy",
    "istio_policy_status":"-",
    "method":"GET",
    "path":"/reviews/0",
    "protocol":"HTTP/1.1",
    "request_id":"b207a764-b6d7-4ef8-bc71-59f264c3****",
    "requested_server_name":"-",
    "response_code":"503",
    "response_flags":"UH",
    "route_name":"-",
    "start_time":"2023-05-30T07:32:08.999Z",
    "trace_id":"a40c32a7b2cf****",
    "upstream_cluster":"outbound|9080|v3|reviews.default.svc.cluster.local",
    "upstream_host":"-",
    "upstream_local_address":"-",
    "upstream_service_time":"-",
    "upstream_transport_failure_reason":"-",
    "user_agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.X.X Safari/537.36",
    "x_forwarded_for":"-"
}

É possível observar logs 503 para productpage-v1. Com base na configuração de roteamento ponderado de reviews-route, 50% das requisições de productpage são roteadas para a versão v3 do serviço reviews. Como a versão v3 está indisponível, o sidecar (istio-proxy) tenta passar da versão v3 para a v2 com base em uma regra de fallback. Visto que a versão v2 também não está íntegra, a requisição é enviada para a versão v3. Confirme isso verificando o campo "upstream_cluster":"outbound|9080|v3|reviews.default.svc.cluster.local".