标签：k8s 情况 中文手册 客户端 交流 boa 通过 监视 免费
Linkerd 2.10 中文手册持续修正更新中：
为了让 Linkerd 自动重试失败，有两个问题需要回答：
这两个问题都可以通过在服务配置文件
中为您发送请求的服务指定一些额外信息来回答。
之所以需要这些配置，是因为重试可能存在潜在危险。
自动重试更改状态的请求（例如提交金融交易的请求）可能会对您的用户体验产生负面影响。
此外，重试会增加系统负载。一组具有不断重试请求的服务可能会被重试打死，而没有时间恢复。
对于幂等且没有主体的路由，您可以编辑服务配置文件(service profile)并将 isRetryable 添加到可重试路由：
spec:
routes:
- name: GET /api/annotations
condition:
method: GET
pathRegex: /api/annotations
isRetryable: true ### ADD THIS LINE ###
retry budget 是一种机制，它限制可以对服务执行的重试次数占原始请求的百分比。
这可以防止重试使您的系统不堪重负。
默认情况下，重试最多可以增加 20% 的请求负载（加上每秒额外的 10 次“免费”重试）。
可以通过在您的 service profile 上设置 retryBudget 来调整这些设置。
spec:
retryBudget:
retryRatio: 0.2
minRetriesPerSecond: 10
ttl: 10s
可以使用带有 --to 标志和 -o wide 标志的 linkerd viz routes 命令来监视重试。
由于重试是在客户端执行的，我们需要使用 --to 标志来查看一个资源发送到
另一个资源的请求的指标（从服务器的角度来看，重试只是常规请求）。
当指定这两个标志时，linkerd routes 命令将区分“有效(effective)”和“实际(actual)”流量。
ROUTE SERVICE EFFECTIVE_SUCCESS EFFECTIVE_RPS ACTUAL_SUCCESS ACTUAL_RPS LATENCY_P50 LATENCY_P95 LATENCY_P99
HEAD /authors/{id}.json authors 100.00% 2.8rps 58.45% 4.7rps 7ms 25ms 37ms
[DEFAULT] authors 0.00% 0.0rps 0.00% 0.0rps 0ms 0ms 0ms
实际请求代表客户端实际发送的所有请求，包括原始请求和重试。
有效请求只计算原始请求。由于原始请求可能会触发一次或多次重试，
因此在启用重试时，实际请求量通常高于有效请求量。
由于原始请求可能第一次失败，但该请求的重试可能会成功，
因此有效成功率(effective success rate)
通常（但不总是）高于实际成功率(actual success rate)。
我是为少
微信：uuhells123
公众号：黑客下午茶
加我微信（互相学习交流），关注公众号（获取更多学习资料~）
Linkerd 2.10(Step by Step)—配置重试
标签：k8s 情况 中文手册 客户端 交流 boa 通过 监视 免费
原文地址：https://www.cnblogs.com/hacker-linner/p/14891147.html
