O circuit breaking estático exige a estimativa e definição manual de um limiar fixo de concorrência para cada serviço. Se a estimativa for muito baixa, o sistema bloqueará tráfego legítimo. Se for muito alta, o serviço sobrecarregará antes da ativação do circuit breaker. A CustomResourceDefinition (CRD) ASMAdaptiveConcurrency elimina essa incerteza ao ajustar dinamicamente o limite de concorrência com base em medições de latência em tempo real, mantendo o limite próximo da capacidade real do serviço sem necessidade de ajustes manuais.
Quando as requisições simultâneas excedem o limite calculado, o sidecar proxy retorna o código de status HTTP 503 com a mensagem de erro reached concurrency limit.
Como funciona
O controlador de concorrência adaptativa utiliza um algoritmo baseado em gradiente que mede periodicamente a latência de linha de base de um serviço (MinRTT) e a compara com a latência das requisições amostradas (SampleRTT) para ajustar o limite de concorrência.
Cálculo do gradiente
O controlador calcula um valor de gradiente a partir das latências amostradas:
gradient = (minRTT + buffer) / sampleRTT
O buffer absorve a variância normal de latência, de modo que o gradiente só diminui quando a latência amostrada excede a linha de base por uma margem significativa:
buffer = minRTT * buffer_pct
Em seguida, o gradiente atualiza o limite de concorrência:
new_limit = gradient * current_limit + headroom
Quando o serviço está saudável, o sampleRTT permanece próximo do minRTT, o gradiente se mantém perto de 1.0 e o limite permanece estável ou aumenta. À medida que o serviço fica sobrecarregado, o sampleRTT sobe, o gradiente cai abaixo de 1.0 e o limite diminui, rejeitando requisições excedentes antes que o serviço sofra maior degradação.
Recálculo do MinRTT
Periodicamente, o controlador recalcula o MinRTT reduzindo temporariamente o limite de concorrência para o valor de min_concurrency. Durante essa janela, apenas um pequeno número de requisições é encaminhado, permitindo que o serviço responda com sua verdadeira latência mínima.
O limite de concorrência cai significativamente durante o recálculo do MinRTT, o que pode causar um pico nas respostas 503. Para mitigar isso, crie uma destination rule que ative retentativas para o serviço de destino. Isso permite que o sidecar proxy tente novamente as requisições rejeitadas em outros hosts que não estejam em uma janela de recálculo de MinRTT.
Pré-requisitos
Antes de começar, verifique se você tem:
Uma instância do Service Mesh (ASM) versão 1.12.4.19 ou posterior. Para mais informações, consulte Criar uma instância do ASM
Um cluster adicionado à instância do ASM. Para mais informações, consulte Adicionar um cluster a uma instância do ASM
Um cliente kubectl conectado ao cluster. Para mais informações, consulte Obter o arquivo kubeconfig de um cluster e usar kubectl para conectar-se ao cluster
Etapa 1: Implantar aplicações de exemplo
Este tutorial usa duas aplicações para demonstrar o controle de concorrência adaptativa:
|
Aplicação |
Função |
Configuração |
|
testserver |
Serviço de destino |
Processa até 500 requisições simultâneas, cada uma levando 1.000 ms para ser processada. Requisições além do limite de concorrência são enfileiradas. |
|
gotest |
Gerador de carga |
Cada réplica envia 200 requisições simultâneas para o |
Implantar o testserver
-
Crie um arquivo chamado
testserver.yamlcom o seguinte conteúdo:A flag
-mdefine o máximo de requisições simultâneas (500). A flag-tdefine o tempo de processamento por requisição em milissegundos (1.000). -
Aplique o Deployment:
kubectl apply -f testserver.yaml
Criar o Service testserver
-
Crie um arquivo chamado
testservice.yamlcom o seguinte conteúdo: -
Aplique o Service:
kubectl apply -f testservice.yaml
Implantar o gotest
-
Crie um arquivo chamado
gotest.yamlcom o seguinte conteúdo:A contagem inicial de réplicas é 0. Escale-a na Etapa 4 para gerar carga.
-
Aplique o Deployment:
kubectl apply -f gotest.yaml
Etapa 2: Criar uma CRD ASMAdaptiveConcurrency
Conecte o kubectl à sua instância do ASM. Para mais informações, consulte Usar kubectl no plano de controle para acessar recursos do Istio.
-
Crie um arquivo chamado
adaptiveconcurrency.yamlcom o seguinte conteúdo:apiVersion: istio.alibabacloud.com/v1beta1 kind: ASMAdaptiveConcurrency metadata: name: sample-adaptive-concurrency namespace: default spec: workload_selector: labels: app: testserver sample_aggregate_percentile: value: 60 concurrency_limit_params: max_concurrency_limit: 500 concurrency_update_interval: 15s min_rtt_calc_params: interval: 60s request_count: 100 jitter: value: 15 min_concurrency: 50 buffer: value: 25Esta configuração deve ser interpretada da seguinte forma:
Direciona o workload
testservere define o limite superior de 500 requisições simultâneas.Atualiza o limite de concorrência a cada 15 segundos, usando o percentil 60 das latências amostradas como SampleRTT.
Recalcula o MinRTT a cada 60 segundos (com até 15% de jitter aleatório) utilizando 100 requisições amostradas. Durante o recálculo do MinRTT, limita a concorrência a 50 requisições.
Considera normais as flutuações de latência dentro de 25% do MinRTT.
-
Aplique a CRD:
kubectl apply -f adaptiveconcurrency.yaml
Referência de parâmetros
|
Parâmetro |
Tipo |
Obrigatório |
Padrão |
Descrição |
|
|
WorkloadSelector |
Sim |
-- |
Seleciona o pod de destino por rótulo. |
|
|
map |
Sim |
-- |
Rótulos para corresponder ao pod de destino. |
|
|
Percent |
Sim |
-- |
Percentil usado para agregar latências amostradas no SampleRTT. Valores válidos: 0 a 100. |
|
|
Object |
Sim |
-- |
Configurações do limite de concorrência. |
|
|
int |
Não |
1000 |
Limite superior para requisições simultâneas. |
|
|
duration |
Sim |
-- |
Frequência com que o controlador atualiza o limite de concorrência. Exemplo: |
|
|
Object |
Sim |
-- |
Configurações de cálculo do MinRTT. |
|
|
duration |
Não |
-- |
Frequência de recálculo do MinRTT. Exemplo: |
|
|
int |
Não |
50 |
Número de requisições amostradas para calcular o MinRTT. |
|
|
Percent |
Não |
15 |
Jitter aleatório adicionado ao intervalo de recálculo do MinRTT. Por exemplo, se |
|
|
int |
Não |
3 |
Limite de concorrência durante o recálculo do MinRTT. Também serve como limite inicial quando o controlador inicia. Defina este valor bem abaixo da capacidade real do serviço para obter medições precisas da linha de base. |
|
|
Percent |
Não |
25 |
Flutuação aceitável de latência como porcentagem do MinRTT. Por exemplo, se o MinRTT for 100 ms e o buffer for 10, latências de até 110 ms são consideradas normais. |
Etapa 3: Configurar monitoramento com Prometheus
Exporte métricas de concorrência adaptativa para o Managed Service for Prometheus a fim de observar o comportamento do controlador e ajustar parâmetros.
Ative o Managed Service for Prometheus para seu cluster. Para mais informações, consulte Usar o Managed Service for Prometheus.
-
Crie um ServiceMonitor para coletar métricas do sidecar proxy do testserver.
-
Crie um arquivo chamado
servicemonitor.yamlcom o seguinte conteúdo:apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: testserver-envoy-metrics namespace: default spec: endpoints: - interval: 5s path: /stats/prometheus port: metrics namespaceSelector: any: true selector: matchLabels: app: testserver -
Conecte o kubectl ao cluster ACK e aplique o ServiceMonitor:
kubectl apply -f servicemonitor.yaml
-
-
Importe o painel do Grafana para visualizar as métricas do controlador. Baixe o JSON do painel e importe-o no console do Managed Service for Grafana. Para instruções de importação, consulte a documentação do ARMS.
Etapa 4: Verificar o controlador de concorrência
Gere carga contra o testserver para confirmar que a CRD ASMAdaptiveConcurrency limita a concorrência conforme esperado.
-
Escale o Deployment gotest para 5 réplicas. Com 200 requisições simultâneas por réplica, isso produz 1.000 requisições simultâneas — o dobro da capacidade de 500 requisições do testserver.
Faça login no console do ACK. No painel de navegação à esquerda, clique em Clusters.
Na página Clusters, localize seu cluster e clique no nome dele ou clique em Details na coluna Actions.
No painel de navegação à esquerda, escolha Workloads > Deployments.
Na página Deployments, defina o Namespace como default. Na coluna Actions da aplicação gotest, escolha More > View in YAML.
Na caixa de diálogo Edit YAML, defina
replicascomo5e clique em Update.
Abra o painel do Grafana importado na Etapa 3. Defina Service como
testservere Pod comoALL.Verifique o painel ConcurrencyLimit. O limite de concorrência deve estabilizar abaixo de 500, confirmando que o controlador protege o testserver contra sobrecarga. O painel RqBlocked mostra a contagem acumulada de requisições rejeitadas.
Referência de métricas
O controlador de concorrência adaptativa expõe as seguintes métricas do Prometheus por meio do sidecar proxy. Utilize-as para monitorar o comportamento do controlador e ajustar os parâmetros da CRD.
|
Métrica |
Tipo |
Descrição |
|
|
Counter |
Total de requisições rejeitadas pelo controlador de concorrência. |
|
|
Gauge |
Valor atual de headroom usado no cálculo do limite de concorrência. |
|
|
Gauge |
Limite de concorrência atual imposto pelo controlador. |
|
|
Gauge |
Valor atual do gradiente. |
|
|
Gauge |
Medição atual do MinRTT em milissegundos. |
|
|
Gauge |
Agregado atual do SampleRTT em milissegundos. |
|
|
Gauge |
Definido como 1 quando o controlador está recalculando o MinRTT. |
Todas as métricas usam o prefixo de namespace envoy_http_inbound_0_0_0_0_8080_adaptive_concurrency_gradient_controller_.
Aplicar a serviços de produção
Ative retentativas: Crie uma destination rule com políticas de retentativa para o serviço de destino, a fim de lidar com respostas 503 durante as janelas de recálculo do MinRTT.
Ajuste parâmetros: Modifique
concurrency_update_interval,min_concurrencyebuffercom base nas observações do painel do Grafana. Umbuffermenor torna o controlador mais sensível a mudanças de latência; um valor maior permite mais flutuação.Direcione seus próprios workloads: Substitua os rótulos de
workload_selectorpara atingir seus workloads de produção. Comece com configurações conservadoras (min_concurrencybem abaixo da capacidade esperada) e itere com base nas métricas.