pikpik - 可靠性
type: channel
link: https://blog.pikpik.top/tag/%E5%8F%AF%E9%9D%A0%E6%80%A7/
items: 混沌工程
items: 可靠性-熔断限流测试

混沌工程
type: item
date: 2025-06-08T15:07:00+00:00
description: ### 🔍 一、背景与起源1. **起源事件**2008年Netflix因数据库故障导致服务中断3天，促使团队迁移至AWS分布式架构。为应对微服务复杂度带来的不确定性，2010年Netflix推出**Chaos Monkey**（随机终止生产环境EC2实例），标志着混沌工程的诞生。- 后续扩展为 **Simian Army** 工具集，涵盖网络延迟（Latency Monkey）、区域故障（Chaos Kong）等多样化故障场景。 2. **行业需求驱动**- **分布式系统的复杂性**：微服务架构中服务间依赖关系复杂，传统测试无法覆盖全链路故障（如级联雪崩、重试风暴）。 - **高可用性要求**：云原生时代，业务对停机容忍度极低（如金融、电商场景），需主动预防而非被动响应故障。 - **代表性事故**：阿里云全球认证服务异常（2023年）、滴滴系统崩溃（2023年）等事件凸显韧性建设的紧迫性。---### ⚙️ 二、核心原理与原则#### 📜 1. 官方原则（Netflix提出）| **原则** | **核心要点** | | -------------------------- | -------------------------------------------------------------------- | | **围绕稳态建立假设** | 定义系统健康指标（如错误率、延迟），假设故障注入后指标仍可恢复稳态。 | | **多样化真实事件** | 模拟硬件故障、网络分区、依赖服务宕机、流量激增等现实场景。 | | **生产环境运行实验** | 真实流量才能暴露未知问题，需严格控制爆炸半径（如仅影响5%流量）。 | | **自动化持续运行** | 集成CI/CD流水线，定期自动执行实验，避免人工成本高企。 | | **最小化爆炸半径** | 通过流量染色、环境隔离等技术限制故障影响范围，确保快速回滚。 |#### 🔬 2. 实验方法论（四步循环）1. **定义稳态指标**：如API成功率>99.9%、平均延迟测试环境，越接近生产环境，实验结果越可信。#### ⚒️ 2. 实验设计关键步骤| **阶段** | **活动** | | ---------------------- | ------------------------------------------------------------- | | **场景选择** | 优先高风险场景（如支付核心服务依赖的数据库故障）。 | | **工具选型** | 根据技术栈选择工具（见下表）。 | | **爆炸半径控制** | 使用流量标签（如HTTP Header）隔离实验流量，限制故障影响范围。 | | **自动化流水线** | 集成Jenkins/GitLab CI，自动执行实验→收集指标→生成报告。 |#### 🧰 3. 主流工具与平台| **工具** | **适用场景** | **核心能力** | **代表用户** | | ---------------------- | ----------------------------- | ---------------------------------------------------------- | ------------------ | | **Chaos Monkey** | 基础架构层故障 | 随机终止虚拟机/容器 | Netflix | | **ChaosBlade** | 多环境（物理机/K8s/Java应用） | 支持CPU满载、方法级延迟、MySQL异常；CLI操作无侵入。 | 阿里巴巴 | | **Chaos Mesh** | Kubernetes原生 | 网络丢包、Pod故障、时间漂移；WebUI可视化控制。 | PingCAP | | **Litmus** | K8s环境CI/CD集成 | 预定义实验模板（如Argo Rollout验证），Prometheus指标分析。 | 沃尔玛、Ola |#### 💻 4. 典型故障模拟场景```mermaid graph LR A[故障类型] --> B[资源层] --> B1(CPU/Mem满载) A --> C[网络层] --> C1(延迟/丢包) --> C2(分区) A --> D[应用层] --> D1(Java方法抛异常) --> D2(服务宕机) A --> E[云平台] --> E1(AZ可用区中断) --> E2(存储桶权限错误) ```---### 🏢 四、行业应用与挑战#### ✅ 1. 成功案例- **Netflix**：通过Chaos Kong模拟AWS区域中断，验证多区域容灾能力。 - **字节跳动**：自动化验证…

可靠性-熔断限流测试
type: item
date: 2025-06-04T15:33:41+00:00
description: ### ⚙️ 一、核心测试场景设计#### **1. 熔断器触发条件验证**| **熔断类型** | **触发条件** | **测试方法** | | ------------------------ | ------------------------------ | ------------------------------------------- | | **慢调用比例熔断** | 慢调用占比 > 阈值（默认50%） | 使用JMeter模拟超过 `RT阈值`（如1s）的请求 | | **异常比例熔断** | 异常请求占比 > 阈值（默认50%） | 注入异常（如HTTP 500或自定义业务异常） | | **异常数熔断** | 异常数量 > 阈值（默认5次/秒） | 持续抛出异常直至触发熔断 |**关键断言**：- 触发熔断后，请求直接走 `fallback`方法，不再调用真实服务 - 监控面板显示熔断状态为**OPEN**（如Sentinel的 `circuitState: OPEN`）#### **2. 降级策略执行测试**| **降级类型** | **实现方式** | **测试案例** | | ---------------------- | ----------------------------- | ---------------------------------------------------- | | **Fallback方法** | 返回兜底数据 | 熔断时验证返回预设JSON（如 `{"code": "DEGRADE"}`） | | **默认返回值** | 返回空/null | 检查响应体为空或符合null定义 | | **快速失败** | 直接抛出 `DegradeException` | 断言错误码为 `TOO_MANY_REQUESTS`（429） |---### 🔬 二、深度验证方案#### **1. 熔断恢复机制测试**```mermaid graph LR A[熔断开启] -->|时间窗结束| B[进入半开状态] B -->|放行部分请求| C{请求成功?} C -->|是| D[关闭熔断] C -->|否| A ```- **半开状态验证**： 1. 熔断后等待**恢复时间窗**（如Sentinel的 `recoveryTimeoutMs=5s`） 2. 放行少量请求（如1个），若成功则熔断关闭，否则重新开启 - **测试工具**： 使用Postman定时任务或Python脚本模拟探测请求#### **2. 熔断粒度测试**- **资源级别**：验证熔断是否精确到**单个接口**（如 `/order/create`熔断不影响 `/order/list`） - **参数级熔断**（Sentinel热点规则）： - 对特定参数值熔断（如 `userId=1001`触发降级） - 测试非热点参数请求是否正常#### **3. 多级熔断影响**- 服务A熔断 → 验证依赖服务B的**线程池隔离**是否生效（防止级联雪崩） - 使用 `Arthas`监控线程池：`watch com.netflix.hystrix.HystrixThreadPool getCurrentActiveCount`---### 🛠️ 三、工具链与实施技巧#### **1. 故障注入工具**| **工具** | **用途** | **示例命令/操作** | | ---------------------- | --------------------- | ------------------------------------------ | | **ChaosBlade** | 模拟网络延迟/服务宕机 | `blade create network delay --time 3000` | | **JMeter** | 制造慢调用/异常请求 | 使用 `Response Assertion`强制返回500 | | **Postman Mock** | 模拟下游服务不可用 | 配置Mock Server返回超时 |#### **2. 监控与断言**- **Sentinel Dashboard**：实时查看QPS/熔断状态 ```bash # 检查熔断规则是否生效 curl http://sentinel-dashboard:8719/getRules?type=degrade ``` - **日志分析**： ```java // 验证Fallback方法日志 2024-06-04 10:00:00 [WARN] DegradeFallback triggered for /payment/create ```…