如果我来负责支付宝双11大促保障(三)
在梳理好有哪些系统将参与到大促后，我们的目标就是对它们的现状进行健康检查，为后续制订优化方案提供数据支持。
同样，检查纬度还是依照上面罗列的，从自身、依赖方、服务方、基础服务和后台服务五个纬度来检查。
自身
1、硬件
主要是检查服务器的各项指标，包括CPU、IO、内存、连接数以及磁盘剩余空间。
2、软件
此次我们只是着重于检查JVM的一些参数，如GC策略和启动参数。
3、接口服务
- 接口性能。检查tps、成功率、耗时、流控阀值以及超时时间(调外部服务)。
- 定时任务。要明确其作用，用来决定是否执行关闭、流控降级等策略。同时要了解并发数，单线程和多并发对资源的消耗和性能的影响是不一样的。关注耗时主要目的在于，如果其耗时过长，对大促的影响可能比较大，则需要考虑是否可错峰关闭。最后的执行时间肯定是必须的，如果和大促重叠执行，则面临的风险自然是很大的。
- 降级。 降级是我们系统服务治理的一个重要环节，现简单介绍一下我们在设计流控系统时的一些策略。
降级的目的主要是为了保护系统自身，当请求量超过系统自身承载量时，及时的执行降级策略，保证核心服务不受影响，牺牲部分非核心业务是必须的。
降级的策略通常有三种：
1、超时降级。此情况通常发生在依赖服务频繁长时间的不可用或者因为压力过大响应特别慢，导致调用几乎都达到最大耗时。如果任由其发展下去，系统平均耗时将极具增加。同时，由于顾客并不清楚具体原因，及可能刷新页面，频繁请求，将导致请求量成倍扩大。结果是，一边是请求耗时过长，一边是请求突然猛增，结果可想而知。
在有一次活动期间，我们依赖的一个系统因为压力过大处理能力极具下降，响应时间陡增，这导致我们的处理时间迅速被拉长，系统被拉向崩溃边缘。于是我们及时采取降级策略，执行了多级流控才保住系统。试想，如果我们没有这个降级保护，将引起连锁反映，整个支付路径的系统都可能被拖垮。有经历过类似情况的朋友肯定清楚，依赖服务宕机不可怕，就怕它一直超时。宕机大不了不用，但是超时，没准会拖垮整个系统。
2、统计失败次数降级。对于一个服务，如果它不能满足一定成功率，保证一定的服务质量，采取降级的措施是必要的。毕竟，如果支付都是失败，就不应该让用户支付。
3、故障降级。也就是依赖服务出故障了执行降级。
降级的类型主要分为人工降级和自动降级。由于当时人力和能力的不足，所以降级我们采用的是人工去调整流控阀值，但缺点就是响应时间慢，有可能洪峰就在这一瞬间压垮了系统。
从降级的程度可分为流控和开关。我们在设计时，针对核心系统的核心接口采用的是多级流控，核心系统非核心接口采取的是单极流控或者是开关。
回到梳理降级方面。当时我们梳理了接口的流控令牌名称和最新流控阀值。
4、系统容量
系统容量的评估是大促目标制订和优化的关键，唯有对容量的准确评估，才能对系统的极限有清晰的了解，由此能确定系统大促是否能承受住压力。
当系统架构简单，数量少时，我们往往都是用经验来评估系统容量，但这样的评估往往比较粗糙，和实际出入比较大，给我们系统的稳定带来很大风险。随着系统越来越多，越来越复杂时，经验法已经完全无法解决我们的问题了，于是，我们将采用新的方法来评估系统容量——压力测试。
接下来，我将结合我们的压测过程来介绍压测。
压测的目的主要有以下四种：
- 评估单机极限。这是最重要的一个目的，只有对单机容量有个比较准确的了解，后续的步骤才有了依据。因此这个环节切记要耐心，通过不断的去改变条件发现系统的真正极限。
- 评估集群极限。由于现在都是集群部署，因此这个目的也是差不多。
- 评估DB极限。在很多情况，db往往是系统的瓶颈，因此这也是一个很重要的目的。
- 监控告警。很多情况容易把这忽略。由于平时任意时刻的量往往都达不到大促时的量，因此我们在设置报警阀值时，对于多少合适我们是不清楚的，什么时候系统会处于危险情况，我们也是不清楚的，而且影响的指标往往是多个综合起来，故根据经验制订阀值更不容易且不准确。故我们需要通过压测获取各指标的数据来制订告警阀值。
压测环境分为测试环境压测和线上生产压测。前后两种环境的意思根据字面意思就可以理解了，一个是在测试环境，一个是在真实的生产环境。最开始的时候，测试环境我们是采用生产环境打一定折扣的配置，但这样的压测由于和实际环境出入比较大，因此逐步被我们舍去。后来，采用的是在测试环境使用和生产环境一样的服务器和数据库配置，效果相对于前者更理想。同时，我们也局部使用线上生成压测，由于条件约束，我们不能实现全链路生产压测，只是实现了部分系统生成压测，因此是局部。最理想的自然是全链路生产压测，无论是服务器数量，网络环境还是db都是真实的，但由于成本比较高，难度很大，因此综合多方面因素，此方法大多数情况不被采用。
压测类型有：
- 单接口压测。只是对某一个接口进行压测，但由于一个系统提供的接口往往不只一个，因此单接口压测往往效果不好。
- 多接口组合压测。同时对多个接口压测。这种方式比较符合实际情况，因此也多采用此种方式。我们采用的就是这种方式进行容量评估的。
压测条件，包括IO、CPU、load、用户数等。条件的控制都决定了一次压测的成败与否。在实际压测过程中，往往需要多次修改条件才能找到系统的极限。在双11前，我们进行了一百多次压测，才有了比较准确的值。
依赖方
此步骤比较简单，主要是梳理依赖方的tps、耗时和成功率
服务方
我们当时没有需要检查的
基础服务
基础服务可以从软件和硬件两个角度来考虑。硬件无非就是服务器了，参照上面的指标依依检查即可。软件可以从以下两个方面来考虑：
- 数据库
检查的指标包括连接池和缓冲池大小设置的是否合理、top long sql、索引、序列、事物隔离级别、是否需要reorg和runstats以及backup时间，这些指标每次我们都会依依检查，dba也会出具一份db2检查报告以供我们更好的了解数据库的情况。对于索引是重点检查的自不必说，有时间会针对索引写一份详细的文章和大家分享。 - 缓存
缓存需要检查的是大小设置的是否合理，缓存命中率高不高，使用的缓存更新策略(相关知识可参考以前写的缓存淘汰算法系列文章)是否和现有缓存对象的业务情况相符，缓存生命周期长短是否合适等。同时需要注意的是，设计时是否对缓存穿透和缓存雪崩两种场景考虑周全，如果发生时，数据库是否能抗住，或者有什么应急预案，这些都是需要注意的。
后台服务
我们当时没有需要检查的。
今天的分享就到此结束了。
