文章目录
一、混沌工程与高可用测试区别
1. 目标一致性
- 高可用性测试:通过模拟故障场景,验证系统在故障发生时的表现和恢复能力,确保系统在不可预见的故障中仍能正常运行。
- 混沌工程:通过有计划地引入随机故障,验证系统的整体韧性,发现潜在问题并优化系统的容错能力。
- 共同目标:提升系统的可靠性和稳定性,确保系统在面对故障时仍能提供高质量的服务。
2. 测试方法
- 高可用性测试:
- 通常针对特定的故障场景(如节点宕机、网络中断等),验证系统的高可用性设计是否有效。
- 测试场景较为固定,侧重于已知的故障模式。
- 混沌工程:
- 通过随机引入故障(如网络延迟、磁盘损坏、服务中断等),验证系统在未知故障下的表现。
- 测试场景更具随机性和探索性,侧重于发现未知的薄弱环节。
3. 测试范围
- 高可用性测试:
- 通常聚焦于系统的关键组件和高可用性设计(如主从切换、负载均衡、数据一致性等)。
- 测试范围相对集中,针对性强。
- 混沌工程:
- 覆盖系统的整体架构,包括基础设施、应用服务、网络、存储等多个层面。
- 测试范围更广,更具全局性。
4. 测试流程
- 高可用性测试:
- 通常按照预定的测试计划和场景执行,步骤较为固定。
- 测试结果主要用于验证系统的高可用性设计是否符合预期。
- 混沌工程:
- 强调持续性和迭代性,通过不断引入新的故障场景,逐步优化系统的韧性。
- 测试结果用于发现潜在问题并推动系统改进。
5. 工具支持
- 高可用性测试:
- 使用专门的测试工具或脚本,模拟特定的故障场景。
- 例如:故障注入工具、负载测试工具等。
- 混沌工程:
- 使用混沌工程平台(如 ChaosBlade、ChaosMesh、LitmusChaos 等),支持自动化和随机化的故障注入。
- 例如:模拟网络延迟、磁盘损坏、服务中断等。
二、混沌工程的核心指标
混沌工程的核心指标用于衡量系统在故障注入期间和恢复后的表现,主要包括以下几个方面:
-
服务可用性(Availability):
- 定义:系统在故障注入期间和恢复后,服务是否仍然可用。
- 指标:可用性百分比(如 99.9%)。
- 示例:在 Redis 主节点故障期间,从节点能否继续提供服务。
-
故障恢复时间(Recovery Time Objective, RTO):
- 定义:系统从故障发生到完全恢复正常服务的时间。
- 指标:恢复时间(如 5 分钟)。
- 示例:Elasticsearch 节点故障后,集群重新平衡的时间。
-
数据一致性(Consistency):
- 定义:系统在故障期间和恢复后,数据是否保持一致。
- 指标:数据一致性状态(如一致、部分一致、不一致)。
- 示例:Redis 主从节点之间的数据同步是否正常。
-
性能指标(Performance):
- 定义:系统在故障注入前后的性能变化。
- 指标:响应时间、吞吐量、延迟等。
- 示例:在 Kafka 集群中引入网络延迟后,消息生产者和消费者的吞吐量是否下降。
-
故障检测时间(Fault Detection Time):
- 定义:从故障发生到系统检测到故障的时间。
- 指标:检测时间(如 10 秒)。
- 示例:监控系统是否能够及时发现节点宕机。
-
告警准确性(Alert Accuracy):
- 定义:监控系统是否能够准确发出告警。
- 指标:告警的准确率和及时性。
- 示例:在 MySQL 主从同步失败时,监控系统是否能够及时发出告警。
-
用户影响(User Impact):
- 定义:故障对用户的影响程度。
- 指标:用户请求失败率、用户体验评分等。
- 示例:在网关节点故障期间,用户请求的成功率是否下降。
三、混沌工程的目的
混沌工程的核心目的是通过引入故障,验证系统的韧性,并发现潜在问题,从而优化系统的可靠性和稳定性。具体目的包括:
-
发现系统中的薄弱环节:
- 通过引入故障,发现系统中可能存在的单点故障、性能瓶颈、数据一致性问题等。
- 示例:在 Kafka 集群中引入网络分区,发现消息丢失或重复的问题。
-
验证系统的容错能力:
- 验证系统在故障发生时的表现,确保其能够自动恢复或降级运行。
- 示例:验证 Redis 主节点故障后,从节点能否自动提升为主节点。
-
优化故障恢复机制:
- 通过测试结果,改进系统的故障检测、恢复和自愈能力。
- 示例:优化 Elasticsearch 集群的重新平衡算法,缩短故障恢复时间。
-
提升系统的整体韧性:
- 通过持续演练,逐步提升系统在复杂故障场景下的表现。
- 示例:在分布式系统中引入随机故障,验证其在高负载、网络抖动等复杂场景下的稳定性。
-
验证监控和告警系统的有效性:
- 确保监控系统能够及时发现故障,并发出准确的告警。
- 示例:验证 Prometheus 是否能够准确检测到节点 CPU 过载。
-
增强团队对故障的应对能力:
- 通过演练,提升团队对故障的识别、分析和解决能力。
- 示例:在演练中模拟数据库主从同步失败,训练团队快速定位和解决问题。
-
降低生产环境的风险:
- 通过在测试环境中引入故障,减少生产环境中发生类似故障的可能性。
- 示例:在测试环境中模拟磁盘损坏,验证数据备份和恢复机制。
四、混沌工程的流程
1. 设置混沌工程演练
-
确定演练目标:
- 明确演练的目的,例如验证中间件在故障场景下的高可用性、性能表现和故障恢复能力。这个目标可以根据业务图和架构图进行分析得到。
- 举例:对于 Elasticsearch,目标是验证在节点故障、网络分区等情况下,搜索服务的可用性和响应时间是否在可接受范围内。
-
选择故障注入点:
- 根据中间件的组件和架构特点,选择合适的故障注入点。
- 举例:
- Redis:主节点故障、从节点故障、网络延迟、命令执行超时等。
- Elasticsearch:节点宕机、磁盘故障、网络分区等。
- 方法:使用工具模拟网络延迟或手动关闭节点。
-
确定故障注入方式:
- 手动注入:适用于初期探索性演练,由运维人员通过命令行工具或脚本直接操作。
- 自动注入:使用混沌工程工具(如 Chaos Mesh)自动注入故障,并进行监控和数据收集。
-
制定演练场景:
- 设计多个故障场景,覆盖可能出现的各种情况。
- 举例:
- Redis:主节点故障后从节点自动提升为主节点、多个从节点同时故障、网络分区导致部分节点不可达等。
- Elasticsearch:单个节点故障、多个节点同时故障、索引损坏、查询超时等。
-
确定演练时间和频率:
- 根据中间件的重要性和业务需求,确定演练的时间和频率。
- 举例:对于关键业务的中间件,可以每月进行一次演练,选择业务低峰期以减少影响。
2. 检验标准
-
服务可用性:
- 检查中间件在故障注入期间和恢复后,服务是否仍然可用。
- 举例:
- Redis:通过执行 GET、SET 等命令检查响应是否正常。
- Elasticsearch:通过发送搜索请求检查结果是否正确。
- 设定可用性指标,例如在故障期间,服务可用性不能低于 99%。
-
性能指标:
- 监测中间件在故障注入前后的性能变化。
- 举例:
- Redis:命令执行时间、吞吐量等。
- Elasticsearch:查询响应时间、索引速度、吞吐量等。
- 设定性能阈值,例如 Redis 命令执行时间不能超过一定毫秒数。
-
故障恢复时间:
- 记录中间件从故障发生到完全恢复正常服务的时间。
- 举例:
- Redis:从节点提升为主节点的时间不能超过一定分钟数。
- Elasticsearch:集群重新平衡的时间不能超过一定时间。
-
数据一致性:
- 检查中间件在故障期间和恢复后,数据是否保持一致。
- 举例:
- Redis:检查主从节点之间的数据同步是否正常。
- Elasticsearch:检查索引数据是否完整,是否存在丢失或损坏。
- 方法:对比故障前后的数据快照或使用数据校验工具。
-
监控和告警:
- 验证中间件的监控系统是否能够及时发现故障并发出准确告警。
- 方法:模拟故障场景,检查监控系统的响应时间和告警准确性。
五、云原生场景下常用的测试工具
1. ChaosBlade
- 简介:ChaosBlade 是阿里巴巴开源的混沌工程工具,遵循混沌工程原理,用于模拟常见的故障场景,帮助提升分布式系统的可恢复性和容错性。
- 特点:
- 支持多种故障场景,包括基础资源、多语言应用服务和 Kubernetes 平台。
- 易于扩展,遵循混沌实验模型。
- 在阿里巴巴内部经过多年实践验证,具有较高的实用性和可靠性。
- 适用场景:分布式系统的故障测试和演练。
2. ChaosMesh
- 简介:ChaosMesh 是 PingCAP 开源的云原生混沌工程平台,提供丰富的故障模拟类型和强大的故障场景编排能力。
- 特点:
- 支持图形化操作,基于 Kubernetes 的自动化能力,系统易用性强。
- 涵盖分布式测试体系中的大多数故障场景。
- 被腾讯、美团等公司使用,用于 Apache APISIX、RabbitMQ 等系统的测试。
- 适用场景:云原生环境的混沌工程。
3. LitmusChaos
- 简介:LitmusChaos 是一个具有跨云支持的云原生混沌工程框架,适用于多种云环境。
- 特点:
- ChaosHub 托管了大量混沌实验,实验高度可调且具有声明性。
- 支持跨云和多用户环境。
- 被多家企业和组织使用,适用于多种云环境。
- 适用场景:跨云环境的混沌工程。
六、测试工具对比
工具名称 | ChaosBlade | ChaosMesh | LitmusChaos |
---|---|---|---|
简介 | 遵循混沌工程原理的实验工具,用于模拟常见故障场景,提升系统的可恢复性和容错性。 | 开源的云原生混沌工程平台,提供丰富的故障模拟类型和强大的故障场景编排能力。 | 具有跨云支持的云原生混沌工程框架,适用于多种云环境。 |
故障场景丰富度 | 高 | 高 | 中高 |
场景支持 | 1. 基础资源(CPU、内存、网络、磁盘等) 2. 多语言应用服务(Java、C++等) 3. Kubernetes 平台(Container、Pod、Node 等) | 1. 丰富的故障模拟场景,涵盖分布式测试体系中的大多数场景。 | ChaosHub 托管了大量混沌实验,实验高度可调且具有声明性。 |
环境要求 | 1. k8s 环境(版本不低于 1.16) 2. 主机环境安装 | 1. golang 版本不低于 v1.15 2. docker、gcc、helm(版本不低于 v2.8.2) 3. nodejs 和 yarn(用于开发 Chaos Dashboard) | 1. k8s 1.17 或更高版本 2. 20G 持久卷 |
架构平台支持 | 支持 x86_64 和 arm64 | 支持 x86_64 和 arm64 | 支持 x86_64 和 arm64 |
图形化支持 | 支持 | 支持 | 支持 |
易用性和扩展性 | 较好(遵循混沌实验模型,易于扩展) | 系统易用性强(图形化操作,基于 Kubernetes 的自动化能力) | 较好 |
跨云支持 | 不支持 | 不支持 | 支持 |
多用户支持 | 不支持 | 不支持 | 支持 |
专注领域 | 分布式系统的故障测试和演练 | 云原生环境的混沌工程 | 跨云环境的混沌工程 |
实战案例 | 阿里巴巴近十年故障测试和演练实践 | 被腾讯、美团等公司使用,用于 Apache APISIX、RabbitMQ 等系统的测试 | 被多家企业和组织使用,适用于多种云环境 |
七、ChaosBlade 梳理
1. 业务产品中间件产品组件
- 元数据管理(zk、etcd、mysql等):
- 破坏场景:元数据管理平台挂掉。
- 影响:存量业务理论上不受影响,但存量业务的变动受影响。
- 高可用方案设计:确保元数据管理平台的高可用性。
- 集群分片自动均衡:
- 破坏场景:增加/减少数据节点。
- 影响:验证集群分片自动均衡能力。
- 网关(网络流量转发):
- 破坏场景:网关节点故障。
- 影响:验证网关的故障转移和恢复能力。
- 数据面(主从数据同步、数据持久化、定期备份、快速恢复):
- 破坏场景:主从数据同步失败、数据持久化异常、备份失败。
- 影响:验证数据一致性和恢复能力。
- 负载均衡(LB /HAProxy):
- 破坏场景:负载均衡节点故障。
- 影响:验证负载均衡的故障转移能力。
- HDFS、S3、minio:
- 破坏场景:存储节点故障。
- 影响:验证数据存储的高可用性。
- 数据迁移:
- 破坏场景:数据迁移过程中节点故障。
- 影响:验证数据迁移的一致性和完整性。
- 个性化(ES)master选举:
- 破坏场景:主master挂掉。
- 影响:验证重新选主的能力。
- 故障转移:
- 破坏场景:网关节点故障。
- 影响:验证自动下线或恢复故障节点的能力。
- 数据节点故障:
- 破坏场景:主分片挂了或从分片挂了。
- 影响:验证从分片升级为主分片或重新建立副本的能力。
- 数据写入:
- 破坏场景:写主成功,写从失败。
- 影响:验证数据一致性和异常处理能力。
- 网络断开后自动连接:
- 破坏场景:网络断开。
- 影响:验证自动重连能力。
- 个性化(Redis)Redis 缓存过期:
- 破坏场景:缓存过期。
- 影响:验证缓存失效后的处理能力。
- 缓存内存限制:
- 破坏场景:缓存内存达到限制。
- 影响:验证内存管理能力。
- 数据分片:
- 破坏场景:主分片不可用。
- 影响:验证从分片提升为主分片的能力。
- 数据迁移:
- 破坏场景:数据迁移过程中节点故障。
- 影响:验证数据一致性和迁移能力。
- 哨兵模式:
- 破坏场景:哨兵节点故障。
- 影响:验证哨兵模式的故障检测和恢复能力。
2. 平台
- Kubernetes(k8s)Node故障:
- 破坏场景:单node或多node故障。
- 影响:验证k8s的节点故障恢复能力。
- CPU类异常:
- 破坏场景:node CPU负载过高。
- 影响:验证CPU资源管理能力。
- 进程类异常:
- 破坏场景:杀进程或暂停进程。
- 影响:验证进程管理能力。
- 磁盘类异常:
- 破坏场景:node磁盘填充或磁盘IO负载过高。
- 影响:验证磁盘资源管理能力。
- 内存类异常:
- 破坏场景:node内存占用过高。
- 影响:验证内存资源管理能力。
- 网络类异常:
- 破坏场景:网络延迟、丢包、包损坏、DNS篡改等。
- 影响:验证网络故障恢复能力。
- Pod删除pod:
- 破坏场景:删除pod。
- 影响:验证pod的自动重建能力。
- CPU、内存、磁盘、网络异常:
- 破坏场景:pod CPU满载、内存占用过高、磁盘IO负载过高、网络延迟等。
- 影响:验证pod的资源管理能力。
- 进程异常:
- 破坏场景:杀进程或暂停进程。
- 影响:验证pod的进程管理能力。
- 云舰平台网关(控制面):
- 破坏场景:网关节点故障。
- 影响:验证网关的故障转移能力。
- 商业平台(地域可用区、账号权限、登录):
- 破坏场景:商业平台节点故障。
- 影响:验证商业平台的高可用性。
- ingresscontroller(域名访问):
- 破坏场景:ingresscontroller节点故障。
- 影响:验证域名访问的高可用性。
- minio、hub、gdns、passcluster(底座mysql、redis、kafka、es、etcd):
- 破坏场景:底座组件节点故障。
- 影响:验证底座组件的高可用性。
3. 基础资源
- CPU:
- 破坏场景:CPU负载模拟。
- 影响:验证CPU资源管理能力。
- 内存:
- 破坏场景:内存占用模拟。
- 影响:验证内存资源管理能力。
- 网络:
- 破坏场景:网络延迟、丢包、断网、包损坏、DNS篡改等。
- 影响:验证网络故障恢复能力。
- 磁盘:
- 破坏场景:磁盘IO负载、磁盘填充。
- 影响:验证磁盘资源管理能力。
- 进程:
- 破坏场景:杀进程或暂停进程。
- 影响:验证进程管理能力。
- 脚本:
- 破坏场景:函数执行延迟或退出。
- 影响:验证脚本的异常处理能力。
- 时间:
- 破坏场景:系统时间偏移。
- 影响:验证时间同步能力。