混沌工程攻防大战的背后——矛盾双修( 二 ) 1Chaos体系1.1Chaos之混沌工

例2：攻击金融业务系统中非核心依赖的中间件
暴露发现系统设计的健壮性问题。
执行结果：非核心依赖中间件发生服务抖动、服务故障时系统无降级策略，直接导致整个业务无法服务，不符合架构原则。
优化建议：业务系统增加对非核心依赖故障的降级及切换策略。优化连接池配置来应对当非核心依赖中间件出现问题时降低性能损耗及减少切换的时间差。
5思考总结
5.1总结
随着Chaos体系的逐渐成熟，体系内自驱力逐渐减少， Chaos会进入一个新的阶段就是常态化。这个阶段不再是以暴露发现系统现有实施问题为主，而是面向系统架构的将来以及系统健壮性、可用性的稳固。主要有以下几点：
（1）自动化安全巡视
Chaos将进入不定期按照已经积累case库进行自动化巡检。
（2）基础架构高可用由谁来监控
Chaos进行不定期面向架构层面进行实弹演习，检验他们的战备值班能力。
（3）新技术、中间件的探索验证
对于新技术、新中间件甚至是自研的中间件可利用ChaosMonkey进行符合业务需求的健壮性、可用性探测验证。
（4）举一反三
建立线上故障case库，定时重播线上故障。
5.2思考
（1）让业务能更直观的感觉到他守护的东西及带来的价值；
（2）增加覆盖面，有的放矢，针对实际情况调整目标及方向；
（3）建立可视化、模板化能力。丰富case库并支持重复攻击演练及跟踪。
参考阅读
Java缓冲区类型与原生数组：哪个更快？
流量洪峰中如何设计弹性微服务架构
Java即时编译器原理解析及实践
一文理解分布式服务架构下的混沌工程实践（含PPT）
你所不知道的ChaosBlade那些事
技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿。
高可用架构
改变互联网的构建方式