如何做好极端业务稳定性保障

稳定性保障需要一定的架构设计能力,又是微服务架构比较核心的部分。

一、极端业务场景

1、可预测性场景

什么是可预测性?简单来说,就像电商每年的大促,如 618、双 11、双 12 等等。这类业务场景是可预测的,业务峰值和系统压力峰值会出现在某几个固定的时间点,我们所做的所有准备工作和稳定性应对措施,都是针对这些固定时间点的,比如零点时刻。

峰值压力可预测,就意味着可以提前评估用户访问模型,并根据模型进行压测调优。发现系统中的瓶颈就调优或者扩容,调整完成之后,继续压测,继续调整,直至系统容量达到原来设定的目标。由此可见,在可预测的场景下,从准备过程上来说会更加从容。

这里采取的策略是在系统承诺容量内,保证系统的核心功能能够正常运行。以电商为例,就是要确保整个交易链路是正常的,用户可以正常登陆,访问商品,下单并最终支付。对于非核心功能,就会通过预案执行功能降级。对于超出系统承诺容量的部分进行流量限流,并确保在某些异常状况下能够熔断或旁路,比如缓存故障,就要马上限流并将请求降级到数据库上。

2、不可预测性场景

那不可预测的场景就更为复杂。社交类业务就具有这种明显的特征,比如微博、朋友圈、空间等等。以微博为例,明星婚变突发事件等等,这些事情什么时候发生,对于平台来说事先可能完全不知道,而且极有可能是大 V 的即兴发挥。当然,现在因为商业合作上的原因,某些大 V 的部分营销活动也会与各类社交业务平台提前沟通,确保活动正常执行,但是即使是提前沟通,周期也会非常短。

对于不可预测性的场景,因为不知道什么时候会出现突发热点事件,所以就无法像电商大促一样提前做好准备。社交类业务没法提前准备,就只能随时准备着,这个挑战还是非常大的。

二、要应对的技术挑战

1、运维自动化

应对极端场景下的系统压力,一定要有资源支持,但是如何才能将这些资源快速扩容上去,以提供业务服务,这一点是需要深入思考的。标准化覆盖面是否足够广泛,应用体系是否完善,持续交付流水线是否高效,云上资源获得是否足够迅速,这些都是运维自动化的基础。特别是对于不可预测的场景,考验的就是自动化的程度。

2、容量评估和压测

要时刻对系统容量水位做到心中有数,特别是核心链路,比如电商的交易支付链路。我们只有对系统容量十分清楚,才能针对特定场景判断出哪些应用和部件需要扩容,扩容多少,扩容顺序如何。同时,系统容量的获取,需要有比较完善的自动化压测系统,针对单接口、单应用、单链路以及全链路进行日常和极端场景下的模拟压测。

3、限流降级

业务在峰值时刻,系统是无论如何也抵御不住全部流量的。这个时候,我们要做的就是保证在承诺容量范围内,系统可用;对于超出容量的请求进行限流,请用户耐心等待一下。如何判断是否需要限流呢?这时我们要看系统的各项指标,常见的指标有 CPU、Load、QPS、连接数等等。

同时,对于非核心的功能,在峰值时刻进行降级,以降低系统压力。这里有两种方式,分别是主动降级和被动降级。主动降级就是在峰值时刻,主动把功能关掉,如商品评论和推荐功能等等。对于被动降级,也就是常听到的熔断。某个应用或部件故障,我们要有手段将故障隔离,同时又能够保证业务可用,所以会涉及故障判断和各类流量调度策略。

4、开关预案

比如当缓存故障时,我们就需要将请求转发到数据库上,目的也只有一个,让系统可用。但是问题来了,数据库的访问效率没有缓存高,所以缓存可以支撑的流量,数据库肯定是支撑不了的,怎么办呢?这时,就要与限流策略结合起来,先限流,限到数据库能够支撑的容量,再做降级。这样几个策略组合在一起,就是应急预案的执行了。当然,预案里面还会有业务预案。

5、故障模拟

上述预案,需要在日常,甚至是从经历过的故障中提炼出场景,制定好策略,然后不断进行模拟演练。只有这样,等到真正出现问题时,我们的预案才可以高效执行。我们知道 Netflix 的 Chaos Engineering,其中的 Chaos Monkey,就是专门搞线上破坏,模拟各种故障场景,以此来看各种预案执行是否到位,是否还有可以改进的地方。

6、监控体系

监控的重要性就不言而喻了,因为所有的指标采集和统计,异常判断,都需要监控体系的支持。监控体系和前面介绍的运维自动化一样,都是最为基础的支撑平台。

三、不确定因素

对于稳定性保障而言,最困难的部分,不在技术层面,而是在业务层面,也就是用户的业务访问模型。从技术层面来说,还有一些确定的套路可以去遵循,但是访问模型就是个极不确定的因素了。

对于稳定性而言,用户访问模型才是关键,这个摸不准,只有技术是没用的,这就更需要我们能够深入业务,理解业务。

此文章为4月Day5 学习笔记,内容来源于极客时间《赵成的运维体系管理课》,推荐该课程。

你可能感兴趣的:(运维,运维)