服务治理全景设计#

一句话答案#

服务治理不是孤立的限流/熔断/降级，而是一条请求从网关到下游的完整生命周期保护链：注册发现 → 负载均衡 → 限流 → 熔断 → 降级 → 重试 → 超时 → 链路追踪。

核心要点

一条请求的治理全景#

客户端 → DNS/CDN
       → API 网关（限流 + 认证 + 路由）
       → 服务发现（Nacos 拉取实例列表）
       → 负载均衡（选择具体实例）
       → 超时控制（设定调用超时）
       → 熔断器（检查下游是否健康）
       → 重试策略（失败是否重试）
       → 下游服务处理
       → 响应回传
       → 链路追踪（全链路 TraceID 串联）
       → 监控告警（Metrics 上报）

plaintext

1. 注册发现#

注册中心：Nacos / Consul / Eureka
服务启动时注册，关闭时注销，定期心跳
关键问题：注册中心挂了怎么办？→ 客户端本地缓存服务列表，短时间内可用

2. 负载均衡#

策略	适用场景
轮询	实例性能相近
加权轮询	实例配置不同
最少连接	长连接场景
一致性哈希	需要亲和性（如本地缓存命中率）

3. 限流 —— 入口防护#

目的： 保护系统不被超出处理能力的流量打垮

算法	特点	适用
固定窗口	简单但有边界突刺问题	粗粒度
滑动窗口	解决边界问题	通用
令牌桶	允许突发流量	API 网关
漏桶	严格匀速	需要平滑输出的场景

分层限流：

网关层：全局限流（Nginx limit_req / Sentinel 网关流控）
服务层：单机限流（Guava RateLimiter / Sentinel）
分布式限流：Redis + Lua 实现滑动窗口

4. 熔断 —— 快速失败#

核心思想： 下游不健康时快速失败，避免级联故障

三态模型（断路器状态机）：

CLOSED（正常）
  ↓ 错误率超过阈值（如 50%）
OPEN（熔断，快速失败）
  ↓ 等待探测窗口（如 10 秒）
HALF-OPEN（放行少量请求探测）
  ├── 成功率恢复 → 回到 CLOSED
  └── 仍失败 → 回到 OPEN

plaintext

Sentinel vs Resilience4j：

维度	Sentinel	Resilience4j
生态	阿里系，Spring Cloud Alibaba 集成	轻量级，函数式 API
控制台	自带 Dashboard，支持动态规则	无自带控制台
规则持久化	支持 Nacos/Apollo 推送	需自行集成
适用	国内主流	国际项目

5. 降级 —— 有损服务#

三种降级策略：

返回默认值：推荐服务挂了 → 返回热门榜单
返回缓存：用过期缓存兜底，标记数据时效
功能降级：关闭非核心功能（评论、推荐），保核心链路（下单、支付）

6. 重试 —— 有选择地重试#

重试不是万能药，要区分：

可重试：网络超时、502/503（临时不可用）
不可重试：400（参数错误）、409（冲突）、业务逻辑失败
必须幂等才能重试：扣款、下单等必须保证幂等性

重试策略：

固定间隔重试：每次等 1 秒
指数退避：1s → 2s → 4s → 8s，避免重试风暴
最大重试次数：通常 2-3 次

7. 超时控制#

网关超时 > 服务 A 超时 > 服务 B 超时

示例：
  网关：3000ms
  服务 A 调 B：1000ms
  服务 A 调 C：800ms
  
超时必须逐层递减，否则上游等下游超时后自己也超时了。

plaintext

8. 故障级联与阻断#

场景：服务 A → B → C，C 响应变慢
  ↓
B 的线程池被 C 的慢请求占满
  ↓
B 无法处理 A 的请求
  ↓
A 也开始超时 → 整个链路雪崩

plaintext

阻断手段：

舱壁隔离：不同下游用不同线程池，C 慢不影响 B 调 D
熔断：C 持续慢就熔断，B 快速失败
限流：A 入口限流，减少到 B 的请求量

可观测性 —— 发现问题的前提#

维度	工具	解决问题
Metrics	Prometheus + Grafana	发现异常（QPS 下降、错误率上升）
Logging	ELK（Elasticsearch + Logstash + Kibana）	定位异常（具体报错、上下文）
Tracing	Jaeger / SkyWalking	分析根因（哪个服务哪个方法慢）

三者联动：Metrics 告警 → Tracing 找到慢链路 → Logging 看具体日志。

面试回答（2分钟版）

服务治理不是孤立的限流或熔断，而是一条请求从入口到下游的完整生命周期保护链。一条请求的治理流程是：先经过 API 网关做认证和全局限流，然后通过注册中心发现服务实例并做负载均衡选择具体节点，调用时设置超时控制避免无限等待，经过熔断器检查下游是否健康，失败时按策略重试并在最终失败时走降级逻辑返回兜底值。这些环节要区分清楚：限流是入口防护保护自己不被流量打垮，熔断是出口防护保护调用方不被故障下游拖垮，降级是有损服务保核心弃边缘。防止级联故障有三招：舱壁隔离让不同下游用不同线程池互不影响、熔断快速失败不让请求堆积、入口限流控制总流量。重试要注意指数退避和只在最上游重试，否则每层都重试请求量会指数膨胀。最后是可观测性三件套：Metrics 用 Prometheus 发现异常，Tracing 用 SkyWalking 定位慢链路，Logging 用 ELK 确认具体报错，三者联动才能快速定位和解决问题。

追问与易错

追问方向：

“限流和熔断有什么区别？”→ 限流保护自己（入口），熔断保护调用方（出口）
“重试风暴怎么防？”→ 指数退避 + 最大重试次数 + 只在上游重试（避免每层都重试导致请求倍增）
“你项目中怎么做的治理？”→ 结合具体项目讲 Sentinel/Nacos 的使用

易错点：

❌ 限流、熔断、降级混为一谈——三者目的不同，协同工作
❌ 每层都重试——服务 A 重试 3 次调 B，B 重试 3 次调 C，最终 C 收到 9 次请求
❌ 超时设置不分层——所有服务都设 3 秒超时，上游等下游全超时后自己也超时