分布式场景下的稳定性保障

1、什么是稳定性保障

    稳定性保障简单理解就是不让系统出现不可用的情况，或者不可用的情况每年只能发生几十分钟。

    为什么要稳定性保障？因为现在很多的电商系统和支付系统已经属于社会基础服务，持续一段时间不可用会对社会影响比较大，同时也损失了用户的信任。

    稳定性保障的场景非常多，只要流量非常大的业务就需要系统性的进行稳定性保障，包括直播、电商秒杀、电商大促等场景。2022年9月3日晚刘德华“把我唱给你听”线上演唱会，最终这场线上演唱会的在线观看人次达到3.5亿，那么支持3.5亿人次观看就是一种稳定性保障场景。每年电商网站618、99、双11和双12大促。除了大促以外，还有很多亿级用户的产品也需要稳定性保障，如电商交易、第三方支付、演唱会直播等场景。还有很多秒杀的场景，如每晚8点某电商网商1499秒杀茅台、在12306网站提前N天抢票。

2、明确稳定性保障目标

    做稳定性保障的第一件事是要明确保障的一级目标，比如某明星直播要明确保障目标是3亿还是6亿人次观看，某大促交易峰值是20WTPS还是40W TPS。

2.1、明确一级目标

    业务稳定性保障的目标通常是在保障某业务不可用的时间每年持续多久，某业务全年可用率目标99.995%，一年一共有525600分钟，每年的不可用时间必须控制在26(525600*0.00005)分钟以内。

    系统稳定性目标是峰值QPS（每秒请求数）和TPS（每秒写入数）达到多少。注意一定是要峰值目标！这个峰值分为日常峰值和大促峰值，所以稳定性保障有日常保障目标和大促保障目标。从成本角度考虑，每场大促需要做单独保障，大促保障完之后需要回收服务器和各种资源，线上运行的机器一般只能支撑日常峰值或小促。那么我怎么知道今年大促峰值要支撑多少TPS呢，这个只能根据经验估算，一般的估算经验是日常峰值的十倍，或去年大促峰值的2倍，这个其实很难估算非常准确只能尽量估大。

2.2、拆解二级目标

    如果一级目标是支付峰值，那么需要进一步拆解支付咨询量，交易创建量等二级指标，针对这些二级指标做稳定性保障。否则交易创建失败了，只做支付TPS的一级目标保障也没有任何用。

3、如何进行稳定性保障

    稳定性保障的过程分为链路梳理、全链路压测、集群扩容、服务限流、增加提前预案和增加紧急预案。本文会用秒杀业务举例说明。

66d9df2c91c315db0edd27c40dece68b.png

（稳定性保障的7个步骤）

3.1、全链路梳理

    全链路梳理是梳理各系统之间的调用量，包括主链路系统、消息中间件和数据库等。下面以秒杀系统来举例说明如何进行全链路梳理

05cdf7a47a0aaddbe2570351a1a0755c.png

分析出主链路中需要改造的点：

  • 减少依赖：部分服务直接依赖缓存，如果电商系统查询某数据依赖A系统，如果数据更新不频繁，可以把A系统的数据直接放在缓存集群里。

  • 同步改异步：对于性能要求高的接口，又不需要及时得到相应，我们改成了同步受理，然后异步处理。

  • 增加限流配置，主链路中用到的接口都要配置限流。

  • 增加降级开关，如果秒杀系统负载过大，可以通过降级配置拦截一部分秒杀请求。

稳定性保障最关键的手段是减少依赖。

    我负责的支付线稳定性架构升级做的最核心的事情就是降低下游依赖，把下游的服务依赖改成依赖下游的近端包、在近端包里缓存依赖或数据库。把依赖2个系统服务改成依赖1个系统的服务。

3.2、全链路压测

    全链路压测是检验稳定性最重要的手段。

    秒杀系统是一个高并发的系统，由于并发请求量很大很容易出现高可用问题。所以系统开发完成之后，需要通过压测了解系统高可用水位，比如系统最大能承受的QPS是多少万，系统最大能承受的TPS是多少万，单机最大承担的TPS是多少。

压测前需要注意以下几点

  • 优先在线上压测，压测时需要通知链路上系统OWNER。

  • 压测前需要配置限流，压测流量逐渐摸高触发限流，检查限流是否生效。触发限流时，可以打开限流提高流量压测。

  • 区分读流量压测和写流量压测。读流量逐渐摸高，对线上影响不大，一旦有问题停止压测。写流量对线上会有影响，需要写影子表，即压测流量写到单独的表和线上数据隔离。

  • 每次变更后会再次进行压测，确保变更无性能问题。

压测过程中需要观察以下几个指标

  • 系统指标，如应用错误数，业务流程是否正常。

  • 机器性能指标，如IO，CPU利用率，LOAD，TCP重发率，流入流出带宽流量（一般机器是千兆网卡），GC等，不同机器的流量是否均衡。日志是否打的太快，导致磁盘飙高。

  • 检查下线程池的容量，活跃线程是否已经达到最大线程，阻塞队列是否已满。应用的线程池很多，比如消息客户端线程池、消息接收线程池、消息处理线程池和RPC线程池等。

  • 消息是否有挤压，有挤压多长时间可以处理完。是否会影响正常业务，如果影响就直接抛弃掉。

  • 检查限流的

  • 设置是否正常，压测的时候可能要打开限流。

如果压测之后发现TPS一直很低，需要DUMP内存和线程堆栈，帮助你做进一步分析。如果代码没问题又需要追求更高的TPS或QPS那么需要考虑扩容。

3.3、集群扩容

    集群扩容包括服务器集群扩容、缓存集群扩容、分布式存储扩容和数据库容量扩容等。

    全链路梳理的是集群流量，服务器扩容时要考虑单机承担的QPS，比如集群承担的QPS是20W，单机最多能承受2000QPS，所以一共需要100台机器。扩容需要注意几个关键点，因为限流配置是针对单机的，扩容之后需要重新配置限流。每个机房的机器数和流量要匹配，比如A机房有60%的流量，那么60%的机器要在A机房，不过高稳定性业务单机房能承担所有流量，既当B机房不可用时候，A机房虽然只有60%的机器仍然能支撑100%的流量。检查机器是否有状态，比如机器需要在白名单里才能访问某个IP，CPU是不是全是独享或是共享，机器有状态扩容会出现问题。适当的冗余机器，有可能秒杀过程中刚好遇到了几台机器宕机，这个时候最佳处理办法就是下线这几台机器，因为排查机器问题进行修复的时间会比较长。

    需要定期对容量进行评估。如大促前进行压测和容量预估，根据需要进行扩容。根据资源的使用率自动或手动进行扩容。如带宽不够用时，快速增加带宽。

3.4、服务限流

    为了保护系统稳定性，服务必须设置限流，如果单机压测到了3000QPS和1000TPS，且系统性能在一个60%水位，配置的限流最好低于3000QPS或1000TPS。每次压测完之后记得调整限流。限流配置分为单机限流配置、机房限流配置和集群限流配置，可以通过单机限流配置计算出机房限流数值和集群限流数值。

3.5、提前预案

    提前预案是指在大促开始之前执行的预案。需要记录并录入到预案平台，记录是为了回滚，放到预案平台是为了方便执行。预案有如下这些：

  • 服务降级：打开和关闭某些功能，比如消息量过大，系统处理不了，把开关打开后直接丢弃消息不处理。上线新功能增加开关，如果有问题关闭新功能。

  • 主链路依赖服务的限流配置

  • 关闭大数据同步任务，关闭把大量数据从离线同步到在线DB，降低数据库压力。

  • 关闭部分可降级的业务入口，比如签约和解约等。

  • 关闭变更入口，如大促期间不允许发布和变更配置。

3.6、紧急预案

    如果流量太大导致服务器出现问题，直接进行秒杀功能降级，让用户的秒杀请求跳转到一个纯静态的HTML页面，提示用户秒杀活动结束。紧急预案在执行的时候都会找另外一个同学一起double check下，确保紧急预案执行正确，我们差点出现过紧急预案执行错的case。

    增加熔断机制，当监控出线上数据出现大幅跌涨时，及时中断，避免对业务产生更大影响。如我们做指标计算时，指标可以计算慢，但是不能算错，如果发现某个用户的指标环比或同比增长一倍或跌零，会考虑保存所有消息，并中止该用户的指标计算，大促之后再进行指标计算。

3.7、系统监控

    系统监控主要从两个维度进行配置，一个是业务流量监控，一个是系统问题监控。

    业务流量监控，主要监控业务流量的波动，通过业务流量的波动可以发现系统问题，业务数据包括秒杀活动访问量、秒杀请求量和秒杀成功量。因为秒杀业务在几秒内完成，所以可以配置秒级监控。

    系统问题监控，主要监控应用错误数、CPU、内存、以及是否触发限流等指标。精准监控 CPU利用率，load、内存、带宽、系统调用量、应用错误量、系统PV、系统UV和业务请求量，避免内存泄露和异常代码对系统产生影响，配置监控一定要精准，如平时内存利用率是50%，监控可以配置成60%进行报警，这样可以提前感知内存泄露问题，避免应用在大促造成雪崩现象。

4、大促稳定性保障

    大促保障除了要做以上七件事情以外，还要做大促计划、大促准备、大促值班和大促复盘。

4.1、制定大促计划

整个大促保障准备的事情非常多，具体事情如下

  1. 目标

  2. 主链路分析

  3. 系分设计

  4. 项目计划

  5. 全链路压测

  6. 扩容

  7. 提前预案

  8. 紧急预案

  9. 限流配置

  10. 值班手册

  11. 监控大盘

  12. 大促前准备

  13. 大促当天值班

  14. 大促后复盘

4.2、大促准备

大促前一天需要确保以下几件事情：

  1. 确认下数据库权限是否申请好

  2. 确认下服务器权限是否申请好

  3. 确保监控系统访问权限是否申请好

  4. 检查了每个服务器指标是否正常，IO，内存，CPU，GC，带宽，硬盘（日志）和数据库指标。

  5. 提前预案是否都已经执行完成。

  6. 业务方检查下后台使用权限，如果系统出现问题，大促当天可能要让业务方挂公告等操作。

  7. 紧急预案是否都录入了应急平台。

  8. 主链路系统进行重启，重启是避免部分机器缓存和CPU运行了一段时间达到了比较高的水位。

  9. 准备大促执行手册，指导你大促当天如何查问题和数据，规范大促当天操作步骤。

4.3、大促值班

大促当天所有值班人员需要做以下几件事情：

  1. 看监控大盘，是否有问题。

  2. 看服务器性能指标，是否不正常。

  3. 执行紧急预案

  4. 紧急预案执行和变更，请先群里同步一下。

  5. 非问题排查统计不要使用pgm，而是使用单机捞取。

  6. 大促当天某台机器出问题，直接下线掉这台机器，而不是解决机器的问题，所以你需要多预留一些机器。

4.4、大促后复盘

    大促复盘主要是总结这次大促整体的性能指标和业务效果，以及在这次大促保障过程中做的好的地方和做的不好的地方，做的好的地方是和上次大促比较，是否减少了大促资源投入，是否降低了大促保障的成本。另外就是分析和总结本次大促过程中遇到的所有线上问题，为什么会出现、下次大促如何避免等。