微服务容灾治理

• 语言: 中文（简体）
• 格式: .pdf
• 来源: github.com/gopherchina

摘要

文档详细介绍了go-zero在微服务容灾治理中的稳定性能力，重点讲解了自适应过载保护的原理、实现和压测结果。通过动态评估系统容量、CPU负载反馈因子以及与Kubernetes HPA的协同，go-zero能够有效保护服务在高负载下的稳定性。系统容量计算公式基于最大成功请求数、窗口时间和最小请求耗时，确保在流量超载时拒绝多余请求，同时保持服务可用性。压测数据显示，在高流量下，过载保护能够有效控制CPU峰值和请求时延，确保服务不被拖垮。

AI总结

# 微服务容灾治理总结

## 1. go-zero 稳定性能力概览
go-zero 在保护服务稳定性方面表现优异，尤其在以下场景中：
- 突发大流量
- CPU 打满
- 上下游故障或超时
- 中间件（如 MySQL、MongoDB、Redis）故障或超负载

通过以下三类保护机制确保系统稳定性：
1. 服务端自适应过载保护
2. 服务端自适应熔断
3. 客户端自适应熔断

此外，go-zero 还支持自动适配后端服务能力的负载均衡算法，进一步提升稳定性。本文重点讲解自适应过载保护的原理、场景和表现。

---

## 2. 自适应过载保护压测
- 过载保护在约 5 秒后触发。
- 压测结果显示：
- 成功处理 QPS 约 400
- 拒绝约 90% 的请求
- P99 时延控制在 20-24ms
- P90 时延在 5ms 以下
- CPU 峰值控制在 95% 以下

---

## 3. 系统容量计算
系统容量计算公式：
$$ \frac{maxPass \times windows \times minRt}{1000} $$

- **maxPass**：过去 50 个窗口中成功处理请求数最多的一个窗口的值。
- **windows**：每秒窗口数量。
- **minRt**：最小平均请求耗时（单位：毫秒）。

公式推导：
- `maxPass × windows`：每秒系统能成功处理的请求数。
- `minRt / 1000`：缩放系数，将 QPS 转换为 minRt 时间长度内的请求数。
- `maxPass × windows × minRt / 1000`：系统保守并发数。

当当前并发请求数超过系统容量时，系统会拒绝请求。

---

## 4. CPU 负载反馈因子
- CPU 负载反馈因子用于动态调节拒绝比例。
- 当 CPU 负载超过阈值时，拒绝比例随 CPU 负载升高而增加。
- 压测结果：
- 成功 QPS 约 400
- 拒绝约 90% 请求
- P99 时延控制在 20-24ms
- P90 时延在 5ms 以下
- CPU 峰值控制在 95% 以下

---

## 5. 与 Kubernetes HPA 的协同
- Kubernetes HPA 默认根据 CPU 使用率自动扩缩容，但存在分钟级延迟。
- go-zero 的过载保护在 HPA 未生效时提供额外保护。
- 配置建议：
- go-zero 过载保护的 CPU 阈值（默认 90%）应高于 HPA 的 CPU 阈值（默认 80%）。
- 避免 HPA 配置的 CPU 阈值高于过载保护阈值，否则可能抑制 HPA 的生效。

---

## 6. 总结
### 自适应过载保护的要点：
1. **CPU 使用率检测**：确保检测结果准确，避免异常值和毛刺干扰。
2. **系统容量评估**：通过滑动窗口记录请求状态，动态评估系统容量。
3. **CPU 负载反馈因子**：基于 CPU 负载调节系统容量。
4. **过载保护冷却时间**：避免频繁启停，提升大流量下的抑制效果。
5. **与 HPA 协同**：合理配置阈值，确保 HPA 和过载保护互补。

### go-zero 的优势：
- 三类服务（Restful service、gRPC service、Gateway service）均默认集成自适应过载保护。
- 无需额外代码和配置，使用简单。

---

## 7. 压测结果
- 总 QPS 约 10000，流量为系统容量的 20 倍。
- 拒绝约 95% 的过载请求。
- 成功处理 QPS 在 360-400 之间。
- P99 时延不到 700ms。

---

以上为文档核心内容的总结，重点突出了 go-zero 的自适应过载保护能力及其在实际场景中的表现。