优雅降解

1）方法的本质

优雅降解是系统在资源短缺，依赖性故障或负载峰值的情况下向更简单但有用的模式的可管理过渡。目标是通过牺牲次要能力和质量来保持平台的用户价值核心和可持续性。

• 可预见性：预先定义的情景和退化的"阶梯"。
• 病变半径限制：绝缘的幻影和依赖性。
• 可观察性：度量，逻辑和跟踪"哪个降解级别处于活动状态以及为什么"。
• 可逆性：快速恢复正常。

2）原则与界限

1.保留主要内容：其主要SLA/SLO（例如，"购买"，"登录"，"搜索"）优先于次要（化身，推荐，动画）。

2.Fail-open vs fail-closed:

安全，付款，权利-失败关闭（拒绝优于违规行为）。
可压缩的内容，线索，化身是带有民谣的失败开放。
3.时间预算：自上而下的时间表（客户端<网关<服务）。到期后-降级而不是无穷大。
4.成本控制：退化应减少CPU/IO/网络的消耗，而不仅仅是"隐藏"错误。

3）降解水平

3.1 个客户/UX

Skeletons/播放器和"懒惰"装载次要小部件。
分区UI：关键单元装载,次要单元-隐藏/简化。
客户端缓存：标有"数据可能已经过时"的最后已知良好（LKG）。
离线模式：稍后重播的命令队列（等效性！）。

3.2 Edge/CDN/WAF/API网关

stale-wile-revalidate：我们给kesh，我们更新背景。
Rate limiting&load shedding：过载时,我们重置背景/匿名流量。
Geofence/加权漫游：交通将驶入最近的健康地区。

3.3服务层

Partial response：我们返回一些数据+"warnings"。
仅阅读模式：暂时禁止突变（标志）。
Brownout：暂时关闭资源密集型眼镜（推荐、丰富）。
Adaptive concurrency：动态地减少并行性。

3.4数据/流媒体

缓存作为TTL（临时）的真理来源："大约比没有更好"。
降低模型/算法的准确性（fast path vs accurate path）。
Defer/queue：将繁重的任务转移到背景（outbox/job queue）。
优先排队：关键事件-在单独的班级中。

4）降级的梯子（剧本）

• L0（规范）→ L1：隐藏个性化和横幅→ L2：禁用同义词/phazzy搜索→ L3：将响应大小和时间限制在300 m → S L4：将结果从5分钟→ L5："read-only&cached only"+重新计算请求队列。

• 触发器：CPU拥塞>85% p95>目标,错误>阈值,Kafka衰减>阈值,依赖性失调。
• 操作：启用X标志,将concurrency降低到N,将Y源切换到kesh。
• 退出标准：10分钟绿色指标，资源库存。

5）决策政策

5.1有缺陷的预算和SLO

使用error-budget burn rate作为brownout/shedding触发器。
策略："如果burn-rate> 4 ×在15分钟内启用降解L2"。

5.2 Admission control

在关键路径上限制入站RPS以保证p99并防止队列崩溃。

5.3优先排序

类：interactive> system> background。
先验优先级（黄金/银/青铜）和公平（公平分享）。

6）模式和实现

6.1 Load shedding（服务器）

重置请求,然后再使用所有资源。
返回带有"Retry-After"的"429"/"503"和策略解释（针对客户）。

Envoy (adaptive concurrency + circuit breaking)

yaml typed_extension_protocol_options:
envoy. filters. http. adaptive_concurrency:
"@type": type. googleapis. com/envoy. extensions. filters. http. adaptive_concurrency. v3. AdaptiveConcurrency gradient_controller_config:
sample_aggregate_percentile: 90 circuit_breakers:
thresholds:
- max_requests: 2000 max_pending_requests: 500 max_connections: 1000

6.2 Brownout（临时简化）

想法：当资源在结果上时，降低"亮度"（成本）。

kotlin class Brownout(val level: Int) { // 0..3 fun recommendationsEnabled() = level < 2 fun imagesQuality() = if (level >= 2) "low" else "high"
fun timeoutMs() = if (level >= 1) 150 else 300
}

6.3部分响应和警告

json
{
"items": [...],
"degradation": {
"level": 2,
"applied": ["cache_only", "no_personalization"],
"expiresAt": "2025-10-31T14:20:00Z"
}
}

6.4 Stale-wile-revalidate在边缘（Nginx）

nginx proxy_cache_valid 200 10m;
proxy_cache_use_stale error timeout http_500 http_502 http_504 updating;
proxy_cache_background_update on;

6.5只阅读开关（Kubernetes+标志）

yaml apiVersion: v1 kind: ConfigMap data:
MODE: "read_only"

The code should check MODE and block mutations with a friendly message.

6.6 Kafka： backpressure和队列类

将重型制造商切换到较小的'max。poll.唱片"，限制制作击球和。
按拓扑/配额划分"关键"和"bulk"事件。

6.7 UI: graceful fallback

隐藏"重"小部件,显示kesh/骨架,并明确标记过时的数据。

7）配置示例

7.1 Istio： outlier+优先池

yaml outlierDetection:
consecutive5xx: 5 interval: 10s baseEjectionTime: 30s maxEjectionPercent: 50

7.2 Nginx：刀下的背景流量第一

nginx map $http_x_priority $bucket { default low; high high; }

limit_req_zone $binary_remote_addr zone=perip:10m rate=20r/s;
limit_req_status 429;

server {
location /api/critical/ { limit_req zone=perip burst=40 nodelay; }
location /api/background/ {
limit_req zone = perip burst = 5 nodelay; # stricter
}
}

7.3 Feature flags / kill-switches

以动态配置（ConfigMap/Consul）存储,无需发布更新。
分开per-fic和全局标志,对激活进行逻辑化。

8）可观察性

8.1个指标

"degradation_level {service}是当前级别。
'shed_requests_total {route, reason}-重置了多少以及为什么。
"stale_responses_total"-发行多少卡。

`read_only_mode_seconds_total`.

`brownout_activations_total{feature}`.

预算错误：burn-rate，SLO违规的比例。

8.2 Tracing

Spans属性："degraded=true"，"level=2"，"reason=upstream_timeout"。
Linky在retray/hedged查询之间，以查看对尾巴的贡献。

8.3 Logi/Alertes

更改降级级别的事件,包括更改的原因和所有者。
Alerts处于"凹陷"水平（降解持续时间过长）。

9）风险管理和安全

不要降级身份验证/授权/数据完整性：更好的故障。
PII掩码存储在任何模式中。
财务/付款：只有相同的业务、严格的时间表和回扣；如果有疑问-只读/保持。

10）反模式

安静的退化，没有提示用户，也没有遥测。
Retray Storms代替Load Shedding和Short Timout。
没有细分的全球性"rubilniks"是巨大的爆炸。
在单个缓存/队列中混合prod和"轻量级"路径。
永久退化：brownout作为"新常态"，被遗忘的退出标准。
Stale-write：尝试基于旧数据进行写入。

11）实施支票

• 定义了价值核心和关键用户脚本。
• 在服务/房屋上绘制降级梯子，并带有触发器和输出。
• 引入了计时器/限制和服务器侧加载共享。
• 配置了限制等级和优先流量类别。
• 实现了部分响应，仅读取，stale-wile-revalidate。
• feature flags/kill-switches与审核集成。
• 用于降解水平和原因的度量/tracing/alertes。
• 定期进行过载/失败模拟的比赛日练习。
• 记录了SLO和错误预算政策→降解。

12) FAQ

问：什么时候选择brownout，什么时候选择shedding？
答：如果目标是降低无故障请求的成本-brownout。如果目标是保护系统，即使简化也无济于事-shedding登录。

Q： 是否向用户报告降级情况?

答：对于关键场景-是的（徽章"限制模式"）。透明度减少了支持和不满。

Q： 缓存能否成为真理的来源?

答：暂时-是的，有明显的SLA和过时的标签。对于突变-禁止。

问：如何不做"断裂"的背包？
A：短时空，带有抖动的指数后退，相等性和尝试限制；仅重置安全操作。

13）结果

优雅降解是一种建筑合同和一组可管理的工作模式，包括度量信号和预算错误。设计正确的楼梯，严格的taymauts和shedding，kesh fallbacks和brownout，加上强大的可观察性-即使在暴风雨中，您的平台仍然有用且经济。