分布式场景下的稳定性保障发表时间:2024-10-25 21:39 1、什么是稳定性保障 稳定性保障简单理解就是不让系统出现不可用的情况,或者不可用的情况每年只能发生几十分钟。为什么要稳定性保障?因为现在很多的电商和支付系统已经属于社会基础系统,持续一段时间不可用会影响比较大,同时也损失了用户的信任。 稳定性保障的场景非常多,只要流量非常大的业务就需要系统性的进行稳定性保障,包括直播、电商秒杀、电商大促等场景。2022年9月3日晚刘德华“把我唱给你听”线上演唱会,最终这场线上演唱会的在线观看人次达到3.5亿,那么支持3.5亿人次观看就是一种稳定性保障场景。每年电商网站618、99、双11和双12大促。除了大促以外,还有很多亿级用户的产品也需要稳定性保障,如电商交易、第三方支付、演唱会直播等场景。还有很多秒杀的场景,如每晚8点某电商网商1499秒杀茅台、在12306网站提前N天抢票。 2、明确稳定性保障目标 做稳定性保障的第一件事是要明确保障的一级目标,比如某明星直播要明确保障目标是3亿还是6亿人次观看,某大促支付峰值是XX TPS。 2.1、明确一级目标 业务稳定性保障的目标通常是在保障某业务不可用的时间每年持续多久,某业务全年可用率目标99.995%,一年一共有525600分钟,每年的不可用时间必须控制在26(525600*0.00005)分钟以内。 系统稳定性目标是峰值QPS(每秒请求数)和TPS(每秒写入数)达到多少。注意一定是要峰值目标!这个峰值分为日常峰值和大促峰值,所以稳定性保障有日常保障目标和大促保障目标。从成本角度考虑,每场大促需要做单独保障,大促保障完之后需要回收服务器和各种资源,线上运行的机器一般只能支撑日常峰值或小促。那么我怎么知道今年大促峰值要支撑多少TPS呢,这个只能根据经验估算,一般的估算经验是日常峰值的十倍,或去年大促峰值的2倍,这个其实很难估算非常准确只能尽量估大。 2.2、拆解二级目标 如果一级目标是支付峰值,那么需要进一步拆解支付咨询量,交易创建量等二级指标,针对这些二级指标做稳定性保障。否则交易创建失败了,只做支付TPS的一级目标保障也没有任何用。 3、如何进行稳定性保障 稳定性保障的过程分为链路梳理、全链路压测、集群扩容、服务限流、增加提前预案和增加紧急预案。本文会用秒杀业务举例说明。 3.1、全链路梳理 全链路梳理是梳理各系统之间的调用量,包括主链路系统、消息中间件和数据库等。下面以秒杀系统来举例说明如何进行全链路梳理 分析出主链路中需要改造的点:
3.2、全链路压测 全链路压测是检验稳定性最重要的手段。秒杀系统是一个高并发的系统,由于并发请求量很大很容易出现高可用问题。所以系统开发完成之后,需要通过压测了解系统高可用水位,比如系统最大能承受的QPS是多少万,系统最大能承受的TPS是多少万,单机最大承担的TPS是多少。 压测前需要注意以下几点
压测过程中需要观察以下几个指标
如果压测之后发现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、提前预案 提前预案是指在大促开始之前执行的预案。需要记录并录入到预案平台,记录是为了回滚,放到预案平台是为了方便执行。预案有如下这些:
3.6、紧急预案 如果流量太大导致服务器出现问题,直接进行秒杀功能降级,让用户的秒杀请求跳转到一个纯静态的HTML页面,提示用户秒杀活动结束。紧急预案在执行的时候都会找另外一个同学一起double check下,确保紧急预案执行正确,我们差点出现过紧急预案执行错的case。 增加熔断机制,当监控出线上数据出现大幅跌涨时,及时中断,避免对业务产生更大影响。如我们做指标计算时,指标可以计算慢,但是不能算错,如果发现某个用户的指标环比或同比增长一倍或跌零,会考虑保存所有消息,并中止该用户的指标计算,大促之后再进行指标计算。 3.7、系统监控 系统监控主要从两个维度进行配置,一个是业务流量监控,一个是系统问题监控。 业务流量监控,主要监控业务流量的波动,通过业务流量的波动可以发现系统问题,业务数据包括秒杀活动访问量、秒杀请求量和秒杀成功量。因为秒杀业务在几秒内完成,所以可以配置秒级监控。 系统问题监控,主要监控应用错误数、CPU、内存、以及是否触发限流等指标。精准监控 CPU利用率,load、内存、带宽、系统调用量、应用错误量、系统PV、系统UV和业务请求量,避免内存泄露和异常代码对系统产生影响,配置监控一定要精准,如平时内存利用率是50%,监控可以配置成60%进行报警,这样可以提前感知内存泄露问题,避免应用在大促造成雪崩现象。 4、大促稳定性保障 大促保障除了要做以上七件事情以外,还要做大促计划、大促准备、大促值班和大促复盘。 4.1、制定大促计划 整个大促保障准备的事情非常多,具体事情如下
4.2、大促准备 大促前一天需要确保以下几件事情:
4.3、大促值班 大促当天所有值班人员需要做以下几件事情:
4.4、大促后复盘 大促复盘主要是总结这次大促整体的性能指标和业务效果,以及在这次大促保障过程中做的好的地方和做的不好的地方,做的好的地方是和上次大促比较,是否减少了大促资源投入,是否降低了大促保障的成本。另外就是分析和总结本次大促过程中遇到的所有线上问题,为什么会出现、下次大促如何避免等。
文章分类:
编程语言
|