1. 网络错误容错降级策略全景：错误分类、容错与降级的关系、策略选型视图、关键术语统一
本章作为课程的总纲，为后续所有章节建立统一的认知基线。在分布式系统中，网络是不可靠的，这意味着我们需要在软件架构中预先设计好应对网络错误的机制。本章将聚焦于四个核心任务：对网络错误进行精确分类，厘清容错与降级之间的本质区别与协作关系，提供一个策略选型的宏观视图，并统一整个课程中使用的关键术语。
1.1 系统边界：容错降级策略的覆盖范围
核心原则：容错降级策略绝不是万能的。它主要作用于服务节点之间的网络交互边界，对于节点内部的程序崩溃、CPU 资源耗尽等问题，通常需要由进程级或容器级的治理机制（如健康检查、自动重启）来处理。
本课程中的策略体系主要作用于以下三个系统边界：
- 消费者-提供者边界：服务调用方（Consumer）与服务提供方（Provider）之间的网络调用。
- 网关-后端服务边界：API 网关与内部微服务之间的连接。
- 服务-数据层边界：应用服务与数据库、缓存、消息队列等中间件之间的连接。
超出此边界的错误，如 DNS 解析失败、机房光缆断裂等，通常被认为是基础设施层的问题，虽然我们的策略可以对其产生影响（例如通过快速失败来避免雪崩），但其根因治理不在本章讨论范围内。
1.2 分层结构：四层策略模型
为了便于理解、设计和维护，我们将网络错误的容错降级策略划分为四个逻辑层次。每一层负责不同的抽象级别，且层次之间通过明确的控制流进行协同。
| 层次 | 核心职责 | 典型策略 | 所在系统边界 |
|---|---|---|---|
| 第1层：连接层 | 管理网络连接的建立、复用与销毁，处理连接级别的瞬态错误 | 连接超时、连接池、Keep-Alive、自动重连 | 消费者-提供者边界 |
| 第2层：通信层 | 处理单个请求-响应的网络交互，应对请求级别的失败 | 请求超时、重试（Retry）、幂等性校验 | 所有边界 |
| 第3层：流量控制层 | 控制发往下游的请求速率，防止下游过载 | 限流（Rate Limiting）、舱壁隔离（Bulkhead） | 消费者-提供者边界 / 网关-后端服务边界 |
| 第4层：服务治理层 | 提供更高级的故障响应与恢复机制，保障服务整体稳定性 | 熔断（Circuit Breaker）、降级（Degradation）、隔离开关 | 所有边界 |
1.3 组件职责：策略的构成元素
每个具体的策略可以被视为一个独立的组件，拥有明确的职责。以“熔断”策略为例，它由以下几个核心组件构成：
- 状态机：维护熔断器的状态（关闭→打开→半开→关闭）。
- 度量收集器：记录最近一段时间内的请求成功、失败和超时次数。
- 阈值判定器：基于度量数据，判断是否达到触发熔断的条件（如错误率超过 50%）。
- 行为执行器：在熔断打开时，直接返回备用响应（Fallback）或抛出异常，并控制半开状态下的试探请求。
其他策略，如重试、限流、降级，都遵循类似的组件化模式，包含 检测→决策→执行→反馈 的闭环过程。
1.4 数据流与控制流：正常与异常路径
在正常状态下，数据流（请求-响应）直接穿透各层。当错误发生时，控制流介入，改变数据流的走向。
- 数据流（正常路径）： Consumer → 连接层 → 通信层 → 流量控制层 → 服务治理层 → Provider → 反向返回。
- 控制流（异常路径）：
- Consumer 发起请求，通信层检测到超时。
- 通信层触发重试控制流，重新发送请求。
- 多次重试后仍然失败，数据流被传递到服务治理层。
- 服务治理层的熔断器记录失败，当达到阈值时，熔断器状态切换（控制流），决定后续请求直接走降级路径。
- 后续请求的数据流被强制重定向到降级组件（如从缓存中返回旧数据或返回一个默认值），数据流不再到达 Provider。
信任链路：容错降级策略的信任链路是单向且脆弱的。消费者需要信任本地部署的“熔断器”组件的判断，而不再信任远端服务返回的异常信息。这种信任转移是架构设计的关键权衡点。
1.5 错误分类与容错降级的关系
理解错误类型是选择正确策略的前提。我们采用业界经典的分类方式：
- 瞬态错误：短暂、可自愈的网络抖动，如一次性的 TCP 丢包。适合使用 重试（通常不超过3次）。
- 间歇性错误：随机发生，但持续时间较长的问题，如慢查询导致数据库连接池耗尽。适合使用 熔断 来快速失败并隔离依赖。
- 持久性错误：完全不可恢复的错误，如目标服务已被物理销毁。适合使用 快速失败 并触发 降级。
容错与降级不是互相替代，而是继承与演进的关系：容错旨在通过有限的重试、超时和重定向来修复错误，使系统恢复正常运行；而降级则是在容错失败后，以一种有损但可接受的方式继续提供服务。
1.6 关键术语统一
为确保课程前后一致性，我们统一使用以下术语定义：
| 术语 | 定义 |
|---|---|
| 熔断（Circuit Break） | 一种自我保护的机制。当向一个依赖方发送的请求持续失败时，打开开关停止发送请求，并在一定时间后尝试恢复。 |
| 降级（Degradation） | 在熔断或预期负载过大时，执行一个备选方案（例如返回缓存数据、返回空数据、执行本地逻辑），以保障核心功能的可用性。 |
| 超时 | 等待网络操作完成的最长时间。 |
| 重试 | 在第一次尝试失败后，再次发送同样的请求。 |
| 限流 | 控制进入或离开系统的请求速率，防止系统被压垮。 |
| 舱壁隔离 | 将资源（如线程池、连接池）分配给不同的依赖或服务，防止一个依赖的故障拖垮整个系统。 |
| 优雅关闭 | 在服务进程退出前，主动停止接收新请求，并处理完已接收的请求。 |
| 后备响应 | 熔断或降级时返回的预设响应（通常是一个快速生成的默认结果或友好错误提示）。 |
1.7 策略选型视图
选择合适的策略，本质上是一个在响应速度、系统资源消耗、数据一致性之间的权衡。下图展示了一个简化的选型决策流程。
风险点：错误分类不准。 这是选型错误的根源。如果将持久性错误误判为瞬态错误而使用重试，不仅无法恢复服务，反而会诱发拒绝服务攻击（DoS）效果，加速集群崩溃。落地步骤的第一步，必须是建立精确的错误日志分类与分析机制。
1.8 落地步骤与验收标准
本章作为全景概述，其落地步骤旨在建立一个通用的工作流：
- 识别与分类：梳理系统所有依赖，列出每种依赖可能出现的网络错误类型（超时、连接拒绝、400/500等），并进行分类。
- 策略设计：针对每一类错误，从选型视图中初步确定候选策略（如瞬态→重试，间歇→熔断）。
- 参数配置：为每个选定的策略配置初始参数（如超时时间、重试间隔、熔断阈值）。
- 代码实现与集成：使用成熟的库（如 Resilience4j、Hystrix）或自行实现组件，将其注入到调用链中。
- 测试与验证：在测试环境或金丝雀发布环境中，通过 Chaos Engineering（混沌工程）工具注入指定类型的错误，验证策略是否按预期生效。
验收标准：
- 正确性：所有已知类型的网络错误都有对应的降级策略。
- 可恢复性：被熔断的依赖在恢复后，能自动在设定时间内（如10秒）重新接入流量。
- 可观测性：熔断、降级、重试等事件必须有日志输出，并关联到链路追踪。
- 无级联效应：对一个依赖的熔断不会导致其他依赖的线程池或连接池被耗尽。
落地建议：从最关键的依赖开始（如核心数据库、支付服务），在现网流量较小的时段逐步灰度。不要一次性对所有依赖启用全部策略。