从今天开始,和你分享我对微服务和分布式架构下的稳定性保障的理解。
稳定性保障需要一定的架构设计能力,又是微服务架构比较核心的部分。在陈皓老师的“左耳听风”专栏,以及杨波老师的“微服务架构核心 20 讲”专栏都有非常详细的介绍。所以在我的专栏里,我会结合特定的场景,并着重从运维和技术运营的角度来分享。
我们所面对的极端业务场景
首先,看一下我们当前所面对的极端业务场景,我把它大致分为两类。
1.可预测性场景
什么是可预测性?简单来说,就像电商每年的大促,如 618、双 11、双 12 等等。这类业务场景是可预测的,业务峰值和系统压力峰值会出现在某几个固定的时间点,我们所做的所有准备工作和稳定性应对措施,都是针对这些固定时间点的,比如零点时刻。
峰值压力可预测,就意味着可以提前评估用户访问模型,并根据模型进行压测调优。发现系统中的瓶颈就调优或者扩容,调整完成之后,继续压测,继续调整,直至系统容量达到原来设定的目标。由此可见,在可预测的场景下,与后面的不可预测场景相对比,从准备过程上来说会更加从容。
但是,我们的优化或扩容是有限度的,也就是不会无限度地投入成本,来满足零点这个峰值时刻,让所有用户都能够正常访问。从成本和收益角度来说,这样做是不现实的。
所以,在峰值那个时间点上,当用户流量远远大于系统容量时,我们所采取的措施绝不是再去扩容或优化,因为无论是从时效性、系统稳定性还是成本收益上看,这样做都已经无法满足要求了。
那我们该采取什么策略呢?这里我们采取的策略是在系统承诺容量内,保证系统的核心功能能够正常运行。以电商为例,就是要确保整个交易链路是正常的,用户可以正常登陆,访问商品,下单并最终支付。对于非核心功能,就会通过预案执行功能降级。对于超出系统承诺容量的部分进行流量限流,并确保在某些异常状况下能够熔断或旁路,比如缓存故障,就要马上限流并将请求降级到数据库上。
所以,我们在 618,双 11 和双 12 的零点峰值时刻去访问各大电商网站,很大概率上都会提示系统正忙,请稍后再试,短则 2~3 分钟,长则 5~10 分钟,再去访问,网站功能就一切正常了。这并不代表各大电商网站宕机了,而是其在瞬时超大流量访问压力下采取的一种保护措施,这一点反而说明这些电商网站的大促预案非常完善。
2.不可预测性场景