分布式核心系统混沌测试探索与实践.docx

分布式核心系统混沌测试探索与实践随着银行业分布式核心系统建设不断推进，交易链路变 长、分布式事务增多、系统资源故障频发，系统稳定运行面 临挑战。通过引入混沌工程的理念、方法、工具，在测试环 境开展混沌测试实践，总结了一套将混沌工程(Chaos Engineering)和传统测试相结合开展混沌测试(Chaos Test) 的方法与流程，通过具体应用实例阐述了故障场景设计、故 障注入和消除、流程编排等方面的实践经验和取得成效。通 过混沌测试，提前发现系统潜在风险，提高系统运行稳定性。现状与挑战随着IT技术的发展，商业银行逐渐从高成本、高耦合、 技术封闭、扩展性差的主机集中式架构演变为开放平台分布 式架构。银行信息系统具有业务规模庞大、子系统繁多等特 点，在日均交易量高达十几亿的分布式架构下，交易链路变 长，分布式事务增多，保证事务的一致性、幕等性更加困难。 庞大的规模、多层的架构、子系统间的差异，为运维工作增 加难度，硬件单点故障、服务器异常宕机、网络服务异常等 基础资源异常随之增加，分布式架构下应用系统稳定运行面 临较大挑战。通过分析历史生产异常事件，系统可靠性缺陷引发的生 产事件占比高达17%,仅次于功能和性能。在传统的系统测 试中，较多针对应用本身的功能、性能、安全等方面开展测 试，而对系统架构设计的弹性容错能力、底层软硬件和关联 系统异常后的故障隔离和恢复能力等可靠性测试关注度较 低。系统架构的韧性不足，在异常故障发生时，将严重损害 业务连续性。基本概念混沌工程是一门在分布式系统上进行实验的学科，旨在 提升系统的健壮性，将故障扼杀在襁褓之中，以建立对系统 抵御意外条件引发混乱的能力和信心。混沌工程实验过程是 在经验指导下，在可控范围内注入某些异常故障，验证系统 弹性，探查系统未知缺陷，验证应急手段有效性。混沌工程 的原则包括建立系统稳定状态的假设、用真实的生产事件做 验证、在生产环境进行实验、自动化执行实验、控制最小化 爆炸半径。混沌测试是在测试环境有计划、有预期地注入故障，通 过观察系统指标验证系统表现是否符合预期，针对发现的缺 陷进行修复，提升系统可靠性。故障模式影响分析（FMEA）是分析系统中所有可能产生 的故障模式及其对系统造成的所有可能影响，并按每一个故 障模式的严重程度、检测难易程度以及发生频率予以分类的 一种归纳分析方法。方法与设计综合金融行业特点，我们没有直接在生产环境开展混沌 实验，而是在测试环境开展混沌测试。混沌工程与混沌测试 的区别在于：混沌工程是发现系统新信息的实践过程，一般 是在生产环境开展探索性实验，常常伴随无法提前预知的结 果出现。混沌测试在传统测试基础上汲取混沌工程的理念和 方法，在测试阶段对系统有较为明确预期结果地注入故障, 是基于特定的条件和变量下验证系统可靠性的方法。我们结合分布式核心系统的特点，梳理了混沌测试的方 法与流程，主要包括七个关键步骤：目标确定、稳态指标制 定、故障设计、流程编排、实验执行、结果分析、修复验证。目标确定阶段需明确混沌测试的目标、范围、预期达到 的效果等，为后续各项工作的开展提供总体依据。制定稳态 指标则从业务层面和系统层面分析确定应用系统稳定运行 时的指标，包括但不限于交易成功率、TPS、响应时间及系统 资源使用情况等各项指标，为混沌测试结果分析提供对比依 据。故障设计阶段可由开发、测试、运维等人员依据经验, 从系统架构、关联系统、数据库、网络、系统资源、云原生、 真实生产事件等方面剖析应用系统，确定故障可能发生的位 置及预期结果，完成故障场景设计。初步设计的故障场景比 较散乱，通过引入可能性和影响性分析图（基于FMEA）对散 乱的场景进行优先级排序，优先完成发生可能性高、影响范 围大的场景测试。针对不同系统，关注的故障场景有所侧重, 例如I/O密集型系统则重点关注磁盘高I/O相关故障对系统 的影响，计算密集型系统则重点关注CPU抢占等计算资源对 系统的影响。流程编排阶段指将模拟交易流量、故障注入、 启动监控、故障消除等各项操作和时序关系编入流水线，流 水线可支持多个原子故障并行或串行方式执行故障注入。实 验执行阶段则通过调起流水线即可开展故障场景测试自动 化执行，通过查看监控结果，分析与稳态指标之间的差异, 当结果存在偏差则进行原因分析，确定为程序缺陷、架构设 计缺陷的则进行修复后持续混沌测试，直到符合预期结果。应用故障服务宕机进程停止进鼬死熔断负载隔离服务降级分布式核心系统应用平台WAS故障Kafka异常Tomcat故障RedisJJZoc数据库故障数据库满数据库连接异常网络中断网络丢包网络包主Mfi出颇故障内存占满CPU抢占磁盘高I服务器宕机磁盘满图1分布式核心系统故障设计视图实践与成效本文以分布式核心系统统一接入层网关模块为例说明 混沌测试的实践过程和取得成效。统一接入层网关模块作为 核心系统交易接入统一入口，主要完成安全控制检查、报文 转换和路由转发等功能。在核心系统交易量逐步增长的背景 下，新增流量控制功能，用于在“双十一等交易高峰时段 控制流量接入上限，避免在流量洪峰的冲击下对后端服务造 成影响。流控功能的实现基于redis集群统计交易量信息, 当交易量在一定时间间隔达到阈值上限，交易快速失败并返 回提示信息。基于流控设计方案，设定混沌测试的目标为模拟redis 异常宕机场景下网关模块的基本功能是否正常提供服务。系 统稳态指标设定为交易成功率、TPS、响应时间、系统资源使 用率。故障场景设计为五个阶段，一是系统运行正常未触发 流控；二是交易激增触发流控；三是部分redis节点异常故 障；四是全部redis节点异常故障；五是redis节点故障消 除，系统运行恢复为正常流控状态。根据故障设计的五个阶 段，通过混沌测试平台将交易流量模拟、部分redis异常故 障、全部redis异常故障、故障消除等具体操作环节和时序 关系进行流程编排，编制成可自动化执行的流水线，调起流 水线即可完成故障场景的测试执行。通过观察系统稳态指标 发现：在系统正常运行状态下，交易成功率保持为100%,当 增大交易并发数，达到流控阈值后触发流控时交易快速返回 失败，交易成功率下降一段时间后回升，呈现周期性变化; 当部分redis注入故障时，注入瞬间交易成功率升高至100%, 随后恢复正常流控状态；当全部redis注入故障，按照系统 设计预期将跳过流控功能，交易成功率随即升高至100%,但 此时交易响应时间与稳态时相比增长明显，不符合预期结果; 最后消除故障，流控功能恢复，再次恢复为流控状态。通过 分析发现，当redis全部不可用时，系统仍尝试与redis建 立连接并超时，同时产生大量错误日志写入磁盘，导致交易 响应时间变长。针对此缺陷，系统增加对redis的熔断功能， 即当访问redis的请求在一定时间间隔内失败率大于设定阈 值时，将redis的访问请求进行熔断处理。优化后，再次通 过流水线执行本场景，发现优化后结果符合预期，成功在投 产前发现了系统设计存在的问题，避免因redis异常影响核 心系统的正常运行。混沌测试是对传统测试不可替代的有效补充，传统测试 验证理想情况下功能是否正确，实际系统并非一直处于理想 状态，而通过持续混沌测试可发现基础设施、关联系统等故 障发生后系统的弹性容错存在的不足，通过持续改进架构设 计和程序质量提高系统运行稳定性。思考与展望银行业分布式核心系统建设正在不断推进，其上下游关 联依赖关系及底层的部署架构愈加复杂，应用系统稳定运行 的不确定性增加。混沌工程通过科学的实验方法解决分布式 系统复杂、交易链路长、缺乏弹性的问题，弥补传统测试方 法的不足，进一步提升系统的稳定性。未来将在以下两个方面深度应用混沌工程技术理念。一 是提升技术支撑能力，通过建设企业级混沌工程平台进一步 提升混沌测试的自动化与智能化水平；二是拓展混沌工程在 信息系统建设中实践运用的深度和广度，将混沌工程全面落 地并融入到研发交付流程，从技术和管理双视角形成故障预 防、故障应对、系统优化的闭环能力，整体提升系统运行稳 定性。