linkerd实战(8)熔断机制
概述
熔断器关注禁用那些可能请求错误的会话，从负载均衡器的角度来看，它们充当断路器，当被触发时，临时暂停特定端点的使用。以避免级联错误及雪崩效应导致资源耗尽。
在client配置中有两个模块可以被视为断路器：
Fail Fast - 会话(连接)驱动的断路器
Failure Accrual - 请求驱动的断路器
Fail Fast
默认情况下，快速失败在 linkerd 中是禁用的，因为在使用少量主机时代理服务请求可能会出现问题。如果服务只有一个主机，从负载均衡池中删除与该主机的唯一连接将导致该服务的所有请求失败，直到重新建立连接。在这种情况下，最好将连接留在池中，并继续发送请求。然而，对于较大的服务，快速失败是有用的，并且可以在每路由器的基础上在配置路由器时通过设置 failFast 参数来启用。
我们来演示一下会话驱动的熔断器。
1、修改config/linkerd.yaml开启failFast，默认是关闭状态。
$ vi config/linkerd.yaml
routers:
- protocol: http
client:
#开启failFast
failFast: true
loadBalancer:
kind: p2c
maxEffort: 5
2、重启linkerd
$ ./linkerd config\linkerd.yaml
3、测试访问
执行多次请求
$ curl -H "Host:test" http://127.0.0.1:4140
It works too!
It works too!
It works!
It works!
It works!
It works too!
It works!
4、模拟会话失败（我们关闭上文建立的81服务）
$ sudo mv /etc/nginx/sites-enabled/default2 /etc/nginx/sites-available/
5、ngnix 重新加载配置文件
$ sudo /usr/sbin/nginx -s reload
6、测试访问
执行多次请求
$ curl -H "Host:test" http://127.0.0.1:4140
It works!
It works!
It works!
It works!
在某次请求明显感觉得到卡顿之后，客户端开启了熔断模式，请求被负载均衡定向到健康的服务节点。
7、恢复服务
$ sudo mv /etc/nginx/sites-available/default2 /etc/nginx/sites-enabled/
$ sudo /usr/sbin/nginx -s reload
8、测试访问
执行多次请求
$ curl -H "Host:test" http://127.0.0.1:4140
It works too!
It works too!
It works!
It works!
It works!
It works too!
It works!
requeueBudget重试
requeues
Requeues连接级故障前提是保证幂等。如果遇到连接级别失败，并且有requeueBudget配置（有默认配置），则将重试请求。是由client下的requeueBudge参数配置的。每个client都有自己的requeueBudge，不与其他client或service共享。
会话(连接)级别的重试配置，可以在client配置下新增requeueBudget配置：
routers:
- protocol: http
client:
requeueBudget:
minRetriesPerSec:10
percentCanRetry:0.2
ttlSecs:10
|
键
|
值
|
说明
|
|
minRetriesPerSec
|
10
|
为了适应刚刚开始发出请求的客户端，允许重试的最小速率，非负值，设为0则没有后备
|
|
percentCanRetry
|
0.2
|
重试占请求数的比率。必须>=0且<=1000
|
|
ttlSecs
|
10
|
计算时间窗口，在时间窗口内计算成功的请求数
|
Failure Accrual
Linkerd使用failure accrual来跟踪记录访问某个节点请求失败的数量，并且在达到设定阈值将实施退避，停止请求再发送到节点。故障阈值和退避行为都是可配置的。默认情况下，如果Linkerd观察到来自节点的5个连续故障，它将标记该节点为故障，并且仅尝试在5秒和5分钟之间递增间隔重新发送请求到节点（根据重试策略配置）。 默认为5次连续请求失败。
我们来演示一下请求驱动的熔断器。
1、修改config/linkerd.yaml设置failure accrual
$ vi config/linkerd.yaml
routers:
- protocol: http
client:
failureAccrual:
kind: io.l5d.consecutiveFailures
failures: 5
loadBalancer:
kind: p2c
maxEffort: 5
2、重启linkerd
$ ./linkerd config\linkerd.yaml
3、测试访问
执行多次请求
$ curl -H "Host:test" http://127.0.0.1:4140
It works too!
It works too!
It works!
It works!
It works!
It works too!
It works!
4、模拟请求失败（我们将81端口服务请求代理到不存在的地址或端口）
$ sudo vi /etc/nginx/sites-enabled/default2
location / {
#设置为不存在的82端口
proxy_pass http://127.0.0.1:82/;
}
5、ngnix 重新加载配置文件
$ sudo /usr/sbin/nginx -s reload
6、测试访问
执行多次请求
$ curl -H "Host:test" http://127.0.0.1:4140
It works!
502 Bad Gateway
It works!
502 Bad Gateway
It works!
It works!
502 Bad Gateway
...
It works!
It works!
It works!
It works!
It works!
It works!
在5次请求返回502之后（linkerd默认5xx标记为失败，计入成功率），客户端开启了熔断模式，节点进入退避模式，大部分请求被负载均衡定向到健康的服务节点。
7、恢复服务
nginx配置文件注释掉 proxy_pass http://127.0.0.1:82/;
$ sudo /usr/sbin/nginx -s reload
8、测试访问
执行多次请求
$ curl -H "Host:test" http://127.0.0.1:4140
It works too!
It works too!
It works!
It works!
It works!
It works too!
It works!
以下为通用配置，不同kind有自己的特定配置，在具体kind中说明
|
键
|
默认值
|
说明
|
|
kind
|
required
|
可选
io.l5d.consecutiveFailures
,
io.l5d.successRate
,
io.l5d.successRateWindowed
, or
none
.
|
|
backoff
|
5s to 300s递增间隔
|
退避策略，配置重新发送请求的间隔策略，等待多久后重新请求node
|
Consecutive Failures
kind: io.l5d.consecutiveFailures
观察每个节点连续失败的数量,当超过设定阈值后，实施退避停止向节点发送请求。
|
键
|
默认值
|
说明
|
|
failures
|
required
|
连续失败的次数
|
Success Rate
kind: io.l5d.successRate
计算每个节点指数加权的动态平均成功率，当成功率低于设置值时实施退避。计算成功率的样本窗口大小是固定的请求数量，由参数requests设置。
|
键
|
默认值
|
说明
|
|
successRate
|
required
|
目标请求成功率
|
|
requests
|
required
|
计算成功率的请求样本数量
|
Success Rate (windowed)
kind: io.l5d.successRateWindowed
计算每个节点指数加权的动态平均成功率，当成功率低于设置值时实施退避。计算成功率的样本窗口大小是固定的时间间隔，由参数
window设置。
|
键
|
默认值
|
说明
|
|
successRate
|
required
|
目标请求成功率
|
|
window
|
required
|
计算成功率的请求时间间隔
|
None
kind: none
关闭错误退避功能。
Backoff Parameters
|
键
|
默认值
|
说明
|
|
kind
|
required
|
可选
constant
或者
jittered
.
|
Constant Backoff
kind: constant
常量间隔
|
键
|
默认值
|
说明
|
|
ms
|
0
|
每个请求重试的间隔时间，单位毫秒
|
Jittered Backoff
kind: jittered
退避重试间隔算法，间隔由min到max递增。
|
键
|
默认值
|
说明
|
|
minMs
|
required
|
每个请求重试的最小间隔时间，单位毫秒
|
|
maxMs
|
required
|
每个请求重试的最大间隔时间，单位毫秒
|
HTTP Response Classifiers
Response classifiers 定义了哪些http响应是属于失败（用于计算成功率），哪些响应可以重试（考虑api幂等性）。
|
键
|
默认值
|
说明
|
|
kind
|
io.l5d.http.nonRetryable5XX
|
Either
io.l5d.http.nonRetryable5XX
,
io.l5d.h2.nonRetryable5XX
,
io.l5d.http.retryableRead5XX
,
io.l5d.h2.retryableRead5XX
,
io.l5d.http.retryableIdempotent5XX
, or
io.l5d.h2.retryableIdempotent5XX
.
|
Non-Retryable 5XX
kind: io.l5d.http.nonRetryable5XX
kind: io.l5d.h2.nonRetryable5XX
所有响应状态码5XX的请求都被标记为失败，都不可重试。
Retryable Read 5XX
kind: io.l5d.http.retryableRead5XX
kind: io.l5d.h2.retryableRead5XX
所有响应状态码5XX的请求都被标记为失败，然而GET、HEAD、OPTIONS、TRACE请求将自动重试。
带有chunked bodies 的请求将永远不会重试。
Retryable Idempotent 5XX
kind: io.l5d.http.retryableIdempotent5XX
kind: io.l5d.h2.retryableIdempotent5XX
类似io.l5d.http.retryableRead5XX/io.l5d.h2.retryableRead5XX, 但是PUT 和 DELETE 也将自动重试。
带有chunked bodies 的请求将永远不会重试。
All Successful
kind: io.l5d.http.allSuccessful
kind: io.l5d.h2.allSuccessful
所有请求都标记为成功，忽略响应码。