O Istio open source oferece circuit breaking apenas no nível de serviço. Todas as rotas para um serviço compartilham a mesma política e as regras entram em vigor somente após o roteamento. Se uma API falhar, o circuit breaking afetará todas as rotas desse serviço.
O Service Mesh (ASM) estende o Istio com circuit breaking no nível de rota. O com.aliyun.break filter avalia as regras de circuit breaking por rota antes que o tráfego chegue ao serviço upstream. Uma API com falha aciona o circuit breaking apenas para sua própria rota, enquanto as demais rotas continuam a atender solicitações normalmente.
Funcionamento do circuit breaking no nível de rota
O circuit breaking padrão do Istio utiliza duas configurações no campo trafficPolicy de uma regra de destino:
**
ConnectionPoolSettings**: limita o número máximo de conexões, solicitações pendentes e solicitações por conexão para um serviço. O sistema enfileira, expira ou tenta novamente as solicitações excedentes.**
OutlierDetection**: verifica periodicamente os hosts upstream e remove os não saudáveis do pool de balanceamento de carga com base em erros consecutivos.
O exemplo a seguir mostra uma regra de destino padrão do Istio com configurações de circuit breaking. Para obter mais informações, consulte Destination Rule.
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: httpbin
spec:
host: httpbin
trafficPolicy:
connectionPool:
tcp:
maxConnections: 1
http:
http1MaxPendingRequests: 1
maxRequestsPerConnection: 1
outlierDetection:
consecutive5xxErrors: 1
interval: 1s
baseEjectionTime: 3m
maxEjectionPercent: 100
Essa abordagem apresenta duas limitações:
O circuit breaking se aplica no nível de serviço, e não a APIs ou rotas individuais.
O circuit breaking entra em vigor somente após o roteamento.
O ASM supera ambas as limitações por meio da ASMCircuitBreaker CustomResourceDefinition (CRD). No plano de dados, o ASM estende a cadeia de filtros do Envoy com com.aliyun.break filter para avaliar as regras de circuit breaking antes do roteamento da solicitação para o serviço upstream. No plano de controle, a CRD ASMCircuitBreaker fornece uma interface declarativa e elimina a necessidade de gerenciar diretamente a configuração subjacente do Envoy.
O circuit breaking no nível de rota suporta os protocolos HTTP e gRPC.
Pré-requisitos
Antes de começar, verifique se você possui:
Uma instância do ASM da Enterprise Edition ou Ultimate Edition, versão 13,4 ou posterior. Consulte Criar uma instância do ASM
Um cluster adicionado à instância do ASM. Consulte Adicionar um cluster a uma instância do ASM
Um gateway de entrada implantado na instância do ASM. Consulte Criar um gateway de entrada
Os serviços Bookinfo e HTTPBin implantados. Consulte Implantar um aplicativo em uma instância do ASM
O kubectl conectado à instância do ASM. Consulte Usar o kubectl no plano de controle para acessar recursos do Istio
Um gateway do Istio e um serviço virtual configurados. Consulte Gerencie gateways do Istio e Gerencie serviços virtuais
A ferramenta de teste de carga hey instalada
Os arquivos de configuração deste tutorial baixados
Visão geral do cenário
Este tutorial demonstra o circuit breaking no nível de rota com dois serviços atrás do mesmo gateway de entrada:
Bookinfo (namespace
default): atende à rota/productpageHTTPBin (namespace
foo): atende à rota/httpbin
Uma regra de circuit breaking tem como alvo apenas httpbin-route-name1. Quando o HTTPBin aciona o circuit breaking, as solicitações para /httpbin recebem uma resposta de erro personalizada. As solicitações para /productpage continuam normalmente, o que comprova que o circuit breaking no nível de rota isola as falhas em rotas individuais.

Referência de campos do ASMCircuitBreaker
A CRD ASMCircuitBreaker define regras de circuit breaking por rota. O exemplo a seguir tem como alvo a rota nginx-route-name1 no host virtual bf2.example.com:80:
apiVersion: istio.alibabacloud.com/v1beta1
kind: ASMCircuitBreaker
metadata:
name: ingressgateway
namespace: istio-system
spec:
workloadSelector:
labels:
app: istio-ingressgateway
isGateway: true
configs:
- match:
vhost:
name: "bf2.example.com"
port: 80
route:
name_match: nginx-route-name1
breaker_config:
slow_request_rt: 0.1s
break_duration: 90s
window_size: 10s
max_slow_requests: 10
min_request_amount: 3
error_percent:
value: 60
custom_response:
header_to_add:
x-envoy-circuitbreak: "true"
body: "hello, break!"
status_code: 499
|
Campo |
Descrição |
Valor de exemplo |
Orientação de ajuste |
|
|
Aplica a regra a um gateway quando definido como |
|
Defina como |
|
|
Limiar de tempo de resposta. Solicitações que excedem essa duração são contadas como lentas. |
|
Valores menores capturam mais solicitações como lentas. Comece com sua latência P99 e ajuste conforme necessário. |
|
|
Máximo de solicitações lentas permitidas por janela de detecção. O circuit breaking é acionado quando essa contagem é excedida. |
|
Defina um valor menor para proteção mais rigorosa, às custas de circuit breaking mais frequente. Defina um valor maior para tolerar picos ocasionais. |
|
|
Taxa máxima de erro (%). O circuit breaking é acionado quando a taxa de erro excede esse valor e o total de solicitações atinge |
|
Valores menores acionam o circuit breaking mais cedo. Faixa comum: 50--80%. |
|
|
Mínimo de solicitações necessárias antes que o circuit breaking possa ser acionado. Evita falsos positivos durante tráfego baixo. |
|
Defina um valor maior em ambientes de baixo tráfego para evitar falsos positivos. |
|
|
Duração da janela deslizante para contagem de solicitações lentas e erros. |
|
Janelas mais curtas reagem mais rápido, mas são mais sensíveis a rajadas. Janelas mais longas suavizam o ruído. |
|
|
Tempo de permanência do circuit breaking ativo. Todas as solicitações correspondentes recebem a resposta personalizada durante esse período. Após a expiração desse período, o circuito é redefinido e as solicitações voltam a ser permitidas. |
|
Defina com base no tempo esperado de recuperação do serviço upstream. |
|
|
Resposta HTTP retornada enquanto o circuit breaking está ativo. Suporta |
Veja YAML acima |
Use um código de status e cabeçalho distintos para que clientes e monitoramento possam diferenciar respostas de circuit breaking de erros reais do upstream. |
Para todos os campos disponíveis, consulte Descrição dos campos do ASMCircuitBreaker.
Configure e verifique uma regra de circuit breaking
Crie uma regra de circuit breaking para a rota httpbin-route-name1 no host virtual bf2.example.com:80 e, em seguida, verifique se ela é acionada corretamente e afeta apenas a rota alvo.
Etapa 1: Crie o recurso ASMCircuitBreaker
Salve o seguinte YAML em um arquivo chamado asmcircuitbreaker-test-gw.yaml:
apiVersion: istio.alibabacloud.com/v1beta1
kind: ASMCircuitBreaker
metadata:
name: ingressgateway
namespace: istio-system
spec:
workloadSelector:
labels:
app: istio-ingressgateway
isGateway: true
configs:
- match:
vhost:
name: "bf2.example.com"
port: 80
route:
name_match: httpbin-route-name1
breaker_config:
slow_request_rt: 0.1s
break_duration: 90s
window_size: 10s
max_slow_requests: 10
min_request_amount: 3
error_percent:
value: 60
custom_response:
header_to_add:
x-envoy-overload: "true"
body: "hello, break!"
status_code: 499
Aplique o recurso:
kubectl apply -f asmcircuitbreaker-test-gw.yaml
Esta regra monitora a rota httpbin-route-name1 em uma janela deslizante de 10 segundos. O circuit breaking é acionado quando qualquer uma das condições é atendida:
Mais de 10 solicitações lentas (tempo de resposta > 0,1 segundos)
Taxa de erro superior a 60%, com pelo menos 3 solicitações no total
Quando acionado, todas as solicitações para /httpbin recebem uma resposta 499 com o corpo hello, break! por 90 segundos. Após a expiração da break_duration de 90 segundos, o circuito é redefinido e as solicitações fluem para o HTTPBin novamente.
Etapa 2: Acionar o circuit breaking com falhas simuladas
Use curl para gerar solicitações lentas ou respostas de erro. As primeiras solicitações são bem-sucedidas normalmente porque os limiares não foram atingidos.
Simule um atraso de 1 segundo (excede o limiar slow_request_rt de 0,1 segundos):
curl -H 'host: bf2.example.com' http://${ASM_GATEWAY_IP}/httpbin/delay/1 -v
Simule um erro 500:
curl -H 'host: bf2.example.com' http://${ASM_GATEWAY_IP}/httpbin/status/500 -v
Repita qualquer um dos comandos pelo menos 10 vezes dentro de 10 segundos. À medida que os contadores se acumulam na janela deslizante, você observará uma progressão:
Solicitações iniciais: as primeiras solicitações são bem-sucedidas normalmente (HTTP 200 do HTTPBin ou a resposta de atraso/erro esperada do próprio HTTPBin). O circuit breaking não foi acionado porque os limiares não foram atingidos.
-
Limiar ultrapassado: após solicitações suficientes excederem os limiares configurados dentro da janela de 10 segundos, as solicitações subsequentes retornam a resposta personalizada de circuit breaking:
< HTTP/1.1 499 Unknown < Content-Length: 12 < Content-Type: text/plain < x-envoy-overload: true < Date: Thu, 13 Jan 2022 03:03:09 GMT < Server: istio-envoy < Hello,Break!
Três indicadores confirmam que o circuit breaking está ativo:
Código de status:
499(ostatus_codepersonalizado definido na regra)Cabeçalho:
x-envoy-overload: true(o cabeçalho personalizado deheader_to_add)Corpo:
Hello,Break!(obodypersonalizado)
Etapa 3: Verifique se outras rotas não são afetadas
Enquanto o circuit breaking estiver ativo para /httpbin, envie uma solicitação para a rota /productpage do Bookinfo:
curl -H 'host: bf2.example.com' http://${ASM_GATEWAY_IP}/productpage -v
Uma resposta HTTP 200 bem-sucedida confirma que a regra de circuit breaking afeta apenas a rota httpbin-route-name1. O Bookinfo continua a atender solicitações normalmente porque a regra tem como alvo uma rota específica, e não todo o serviço.