攻防大战的背后——矛盾双修

爱奇艺金融科技团队在高安全、高并发、高可用上遇到了很多挑战，同时金融系统相比于常规系统，在用户隐私、资金安全、敏感数据上有极高的要求，因此我们构建Chaos攻防模型，不断实施攻防对抗，逐步提高系统健壮性，为业务保驾护航。

目标如下：

1. 建立Chaos Monkey的攻击能力、执行流程来辅助及验证服务架构的实施效果，从而给架构演进提供指导和参考价值；
2. 建立架构与业务的生产关系，达到架构与业务的双向促进，提高系统稳定性、可用性、健壮性；
3. 通过架构与业务生产关系的良性循环，提高技术同学对整个系统的掌控力、技术实力更好的为业务服务。

1. 支付、金融架构设计是否存在问题？
   原来的架构设计是不是不再符合我们的预期了？
   设计方案和当前生产系统实现之间差了多少？
2. 支付、金融服务底线都是什么，支付、金融服务的隔离颗粒度？
   我们能承受哪些，能承受多长时间，我们不能承受哪些？
3. 我们系统的高可用程度？
   高可用节点切换过程会发生什么？
   HA的切换手段、切换(不可用)的间隔？
   切换成功的时间和一致性的时间是不是有关？等等。

设计实施原则：

1. 为设计漏洞、代码缺陷而生同时面向生产环境，做到要发现问题更要可控;
2. 不拘于手段和形式。不论是使用开源工具，还是切断网线、偷偷杀掉进程、还是进程植入，内存数据篡改都是一种面向某个目的可实施手段;

3. 监控告警辅助支撑，最大化风险评估，细化到流量的损失控制等。

例1：验证支付系统微服务Spring Cloud套件的高可用机制

涉及Eureka Server、Client、Ribbon LB及当前业务对配置掌握的合理性。

• 验证结果：当前架构能在30s内应对下游节点的无前兆故障。

• 优化建议：调整LB的探测时间，Eureka Client、Ribbon Cache缓存时间，服务心跳续约，Eureka Server服务剔除、数据同步时间等加强架构对故障的应对能力同时减少类似问题对业务的影响。

• 执行结果：非核心依赖中间件发生服务抖动、服务故障时系统无降级策略，直接导致整个业务无法服务，不符合架构原则。

• 优化建议：业务系统增加对非核心依赖故障的降级及切换策略。优化连接池配置来应对当非核心依赖中间件出现问题时降低性能损耗及减少切换的时间差。

随着Chaos体系的逐渐成熟，体系内自驱力逐渐减少，Chaos会进入一个新的阶段就是常态化。这个阶段不再是以暴露发现系统现有实施问题为主，而是面向系统架构的将来以及系统健壮性、可用性的稳固。主要有以下几点：

Chaos将进入不定期按照已经积累case库进行自动化巡检。

Chaos进行不定期面向架构层面进行实弹演习，检验他们的战备值班能力。

（3）新技术、中间件的探索验证

对于新技术、新中间件甚至是自研的中间件可利用Chaos Monkey进行符合业务需求的健壮性、可用性探测验证。

（4）举一反三