银行核心背后的落地工程体系丨混沌测试的场景设计与实战演练

本文介绍了在银行核心系统中,如何使用混沌工程来确保 TiDB 分布式数据库的稳定性和高可用性。通过混沌测试,可以摸底性能边界、评估系统高可用性、验证扩展性和优化应急预案。文中提到了混沌测试工具 Chaosd 的优势,并展示了测试场景设计,包括业务压力、故障注入、外围作业和运维操作的测试。混沌测试有助于发现系统潜在问题,提升系统可靠性。
摘要由CSDN通过智能技术生成

系列导读

当前,国内大量的关键行业的核心系统正在实现国产化替代,而与此同时,这些行业的数字化转型也正在进入深水区。在信息系统的升级换代过程中,夯实 IT 基础设施是极其关键的。从服务器、操作系统、中间件、数据库等基础软硬件选型到系统架构、应用架构的重新设计,再到数据迁移、系统迁移、系统优化、运维体系重构的一系列工作都是十分具有挑战性的。大多数工作中,都会遇到无法完全参考前人的探索和创新。

一些勇敢的先行者已经在这条荆棘丛生的道路上硬生生的创出了一条血路,而更多的人还在未知与迷茫中摸索。“银⾏核⼼背后的落地⼯程体系”系列技术文章来自于金融行业用户真实故事,从中可以窥见的不仅是国产化替代路上的艰辛历程,更多的是对于后来者极其宝贵的实践经验

在本系列文章中你不仅可以看到 TiDB 与 Oracle 的异构迁移、基于 TiCDC 的逻辑容灾与数据共享、构建双活数据中心的真实案例,还可以了解到混沌测试、应急预案等方面,以及利用数据库可观测性构建智能化、自动化运维体系的方案与技巧。“积小流,成江海”,希望这些案例能够对您有所裨益。


与集中式架构相比,分布式架构的系统复杂性呈指数级增长,混沌工程在信创转型、分布式架构转型、小机下移等过程中有效保障了生产的稳定性。本文分享了 TiDB 分布式数据库在银行核心业务系统落地中进行混沌测试的场景设计和实践。

混沌工程概述

混沌工程是一种全面的测试方法,它覆盖了从应用层前端到底层硬件环境的所有环节,确保整个系统在面对各种异常和故障时的稳定性和弹性。本文将聚焦于与 TiDB 分布式数据库相关的混沌工程场景。

混沌工程和普通测试在软件系统工程中都扮演着重要的角色,但它们关注的质量属性和测试实施的方式存在明显差异。混沌工程更侧重于系统的健壮性和在面对异常情况时的响应能力,而普通测试则侧重于验证系统的功能正确性和性能指标。两者的差异详见下表:

混沌工程与普通测试对比

在着手进行混沌测试的场景设计和实施之前,有几个关键问题需要我们深思熟虑:

首先,需要明确混沌测试的目标,希望通过测试掌需要关注的能力边界、容错能力、稳定性等。其次,选择合适的混沌测试工具,这些工具能够帮助我们在分布式环境中模拟各种故障和异常情况。接下来,精心设计测试用例,确保它们能够覆盖到可能影响系统稳定性的关键环节。最后,梳理总结混沌测试可能带来的收益,包括提高系统可靠性、优化故障恢复流程、增强团队对系统行为的理解等。通过这些环节的综合考量,我们可以更有效地实施混沌测试演练,为 TiDB 分布式数据库的稳定性提供坚实的保障。

混沌测试目的

TiDB 作为一款原生分布式数据库,其架构设计与银行系统中的传统集中式数据库相比具有显著的差异。银行核心系统对性能、稳定性、跨地域的高可用性都有着严苛的要求。为了满足这些要求,我们计划通过混沌测试来摸底性能边界、评估系统高可用性和容灾能力、验证系统的弹性、检验应急预案有效性、优化监控和告警机制、并准确评估外围作业的影响。

混沌测试目的

摸底性能边界

摸底数据库的能力边界,对上线后的运维工作具有重要的参考意义。一个新的业务系统在设计之初,不仅要满足当前的业务需求,还要考虑满足未来的业务发展需求,尤其是在极致稳定性要求下,银行核心系统的设计需要考虑未来 5 年至 10 年以上的业务发展需求。通过混沌测试,在总体设计的配置下,测试数据库的能力边界,将结果作为上线后运维的重要参考指标,并检验系统是否满足总设要求下未来业务的承载体量。

此外,通过混沌测试还可以发现整个业务链路可能存在的一些瓶颈点。

评估系统高可用和容灾能力

TiDB 的存算分离架构由核心组件和外围组件组成。核心组件包括 TiDB、TiKV、PD 和 TiFlash,用于处理计算和存储任务。外围组件包括 BR 和 TiCDC 等,用于满足备份、数据共享等业务场景的需求。这些组件可以单独部署或混合部署,以满足隔离性和资源利用率的平衡。

在银行核心系统中,常见的部署模式是两地三中心。通过混沌测试,可以在实际的部署架构下模拟各种故障场景,评估系统的高可用能力和灾备接管能力。测试结果可以提供每个场景或多场景组合下的 RTO 和 RPO 指标,并帮助识别应用连接恢复的健壮性和透明性问题,以及发现可能存在的访问链路瓶颈。

验证系统的弹性

业务发展具有动态性,在突发的高流量高负载业务活动中,可能需要进行系统扩容以兼顾效率和稳定性。此外,X86 服务器相比小型机稳定性差、故障率高、生命周期短,需要通过扩缩容动作完成对硬件的升级和更换。基于这些因素,我们从两个维度对扩展性进行评估:

  • TiDB 的线性扩展能力:评估 TiDB 在扩容后能否保持性能的线性增长,满足业务增长带来的性能需求。
  • 扩缩容调整的便捷性、透明性和对业务的影响:评估扩缩容操作是否简单易行,对应用是否透明,对业务是否有影响以及影响程度。

检验应急预案有效性

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

每天读点书学堂

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值