写点什么

系统稳定性建设实践总结

发布于: 2020 年 12 月 08 日
系统稳定性建设实践总结

2020 年,注定是个不平凡的一年。疫情的蔓延打乱了大家既定的原有的计划,同时也催生了一些在线业务办理能力的应用诉求,作为技术同学,需要在短时间内快速支持建设系统能力并保障其运行系统稳定性。恰逢年终月份,正好梳理总结下自己的系统稳定性建设经验和思考。

开篇

在开始介绍服务稳定性之前,我们先聊一下 SLASLA(service-level agreement,即 服务级别协议)也称服务等级协议,经常被用来衡量服务稳定性指标。通常被称作“几个 9”,9 越多代表服务全年可用时间越长服务也就越可靠,即停机时间越短。通常作为服务提供商与受服务用户之间具体达成承诺的服务指标——质量、可用性,责任。

1 年 = 365 天 = 8760 小时

3 个 9,即 99.9% = 8760 * 0.1% = 8760 * 0.001 = 8.76 小时

4 个 9,即 99.99% = 8760 * 0.0001 = 0.876 小时 = 0.876 * 60 = 52.6 分钟

5 个 9,即 99.999% = 8760 * 0.00001 = 0.0876 小时 = 0.0876 * 60 = 5.26 分钟


在严苛的服务级别协议背后,其实是一些列规范要求来进行保障。

一、系统稳定性建设是指什么?

关于系统稳定性是指什么这一问题,相信好多开发同学都会有自己的理解和认知,但可能会存在是否理解片面或者是否标准的疑惑,那到底有什么判定标准和划分边界呢?

我们不妨看下来自于维基百科的解释:

稳定性是数学或工程上的用语,判别一系统在有界的输入是否也产生有界的输出。

若是,称系统为稳定;若否,则称系统为不稳定。


简单理解,系统稳定性本质上是系统的确定性应答

从另一个角度解释,服务稳定性建设就是如何保障系统能够满足 SLA 所要求的服务等级协议。

二、为什么需要系统稳定性建设?

可以确定的一点,服务稳定性建设是非常必要的,不管是满足日常系统正常运行还是重大节庆活动的稳定有序运营。

我们来看几个由于服务稳定性故障造成影响的案例:

1)2020 年国庆前一天,受“2020 年最难打车日”的需求影响,滴滴平台和嘀嗒平台相继出现宕机故障;

2)2018 年亚马逊 prime day:亚马逊会员日故障(顾客无法将商品添加到购物车结账),导致公司损失高达 9900 万美元。

3)2015 年由于中国工商银行部分地区因计算机系统升级,造成柜面和电子渠道业务办理缓慢,甚至不能受理业务;

4)2012 年 12306 铁路订票网站因机房空调系统故障,导致暂停互联网售票、退票、改签业务。



服务稳定性对于企业来说非常重要,不仅仅会对企业带来直接的经济损失,甚至会对行业、人们的生活造成非常严重的影响。所以说服务稳定性建设的意义非常重大。

三、系统稳定性建设为什么难?

关于稳定性以及如何提升稳定性指标,我们可以想到很多的优化项:

eg. 加服务器、扩容、超时重试、服务降级、资源隔离 &备份、代码逻辑优化、异步事件化...

那系统稳定性建设的主要难点是什么呢?

3.1 面对的挑战比较大

  • 流量未知

尤其对于一个新改革上线的新业务而言,系统稳定性建设主要是流量洪峰的是个未知数,由于没有经验可以参考,我不确定是百万级别还是千万级别,还是更高级别?

  • 改动量大

往往这种系统稳定性建设需要考虑需求主要是短时间内支持 XX 能力的上线,这其中往往涉及系统层面从下到上的多处变更,包括底层数据结构调整、业务逻辑改造以及用户交互方式的优化等等。时间短,改动大,质量难以保证。

  • 不确定性

软件工程往往被用来描述“研究用工程化方法构建和维护有效的、实用的和高质量的软件”。其包括软件建设的方方面面,凡事事无巨细,任何细微的疏忽都可能造成全盘故障问题,不确定性问题尤其严重。

3.2 系统稳定性建设是一个系统性的大工程

多环节分工精细复杂,不容一点疏忽。

从系统构成来看,可以区分为单服务系统稳定性和多服务集群稳定性。

  • 单服务稳定性

主要包括:功能配置可控、缓存加速(利器) 、服务隔离(第三方)、场景异常兜底方案、服务监控与及时响应等等

  • 集群稳定性

主要包括:合理的系统架构、优秀的集群部署、科学的熔断限流、压测机制、精细的监控体系等等

四、系统稳定性建设如何入手?

4.1 系统稳定性建设前提

在提出系统稳定性建设解决方案之前,我们需要明确一下前提条件:

  • 业务熟悉 需要对业务全貌流程熟悉,具备较强的掌控力;

  • 架构明确 需要对系统技术架构熟知并具有一定的实操经验。

只有这样,对业务、架构都具备掌控能力之后,才谈得上去做稳定性建设的拆解和优化,才有基本的保障。

4.2 流程划分

一般情况下,我们提到系统稳定性建设,更像将系统稳定性作为一个专项 Topic 来搞,从其运行流程来看,主要存在以下几个方面:

  • 前提 明确目标 (基准)

  • 事前 请求链路优化、服务性能优化 &压测、应急预案制定、故障演练

  • 事中 故障监控、定位问题、故障止损、问题修复

  • 事后 故障复盘、整改优化、经验总结沉淀


服务稳定性建设其实是一个系统性的大工程,包括了方方面面。


五、系统稳定性建设的关键动作

从上一 Part 工作拆解来看,稳定性建设囊括的点比较多,而且杂。更多情况下,我们会做服务稳定性专项,针对某些特定场景下的特定问题而梳理出对应的方案。

那我们可以以小见大,从单服务系统本身出发,提炼看看存在哪些稳定性建设的关键点。其实只有每个单服务环节都稳定可靠,那集群系统乃至整个工程系统的稳定性才有保障。

假如系统面对突增的请求流量情况下,如何做好服务稳定性建设呢?

稳定性建设关键动作拆分如下几类:

5.1 削峰限流

例如,经典的秒杀场景,春节的火车票抢购、电商平台的双 11 秒杀等等,都是短时间上亿的用户涌入,瞬间流量巨大(高并发)。

不管前期对服务器资源做了如何的扩容,都会存在一个处理上限,所以一定要进行必要的削峰限流策略,类似于城市早晚高峰错峰限行的解决方案。同样,秒杀场景也需要类似的解决方案。

那具体如何实现呢?

  • 利用消息队列来削峰

消息队列来缓冲瞬时流量,把同步的直接调用转换成异步的间接推送,中间通过一个队列在一端承接瞬时的流量洪峰,在另一端平滑地将消息推送出去。

消息队列就像“水库”一样,拦蓄上游的洪水,削减进入下游河道的洪峰流量,从而达到减免洪水灾害的目的。


  • 利用挡板过滤无效请求

流量挡板过滤,主要是建立一种验证机制过滤掉无效请求,保障核心服务避免受更多外界无效请求的影响。比较常用的方案就是“布隆过滤器”。


  • 产品策略的调整

产品策略调整是一种特别有效的手段,效果甚至会优于技术层面的改进优化。

例如:利用排队策略,有效打散高并发请求;调整活动宣传时间分散点,避免同一时刻出现高并发请求…

5.2 缓存加速

缓存是解决并发的利器,可以有效的提高系统的吞吐量。按照业务以及技术的纬度必要时可以增加多级缓存来保证其命中率。

主要应用思路:在数据库与服务端之间利用 Redis 做缓存服务,减少请求直接冲击到数据库。


5.3 异步化处理

与异步对应的就是同步,即所有事情排队一件件的有序进行,等上件事情完成后才会去做下一件事情。有点像一根签子串起来的糖葫芦。需要实时处理并响应,一旦超过时间会结束会话,在该过程中调用方一直在等待响应方处理完成并返回。

异步处理不用阻塞当前线程来等待处理完成,而是允许后续操作,直至其它线程将处理完成,并回调通知此线程。

需要强调一点:异步是一种设计理念,异步操作不等于多线程,常见的消息中间件、发布订阅的广播模式等,都可以实现异步处理的方式。

六、稳定性建设过程中的一些经验

6.1 做好压测

提前做好系统压测,做到心中有数,防患于未然,压力预估要切合实际,不要盲目过大。对于性能瓶颈点,尽量提前做好改进优化或者重点关注布防

6.2 应急预案必备

应急预案一定要有,研发人员往往比较自信,这是好事也是坏事,我们需要做最坏的打算。因为经验再丰富的工程师,也无法穷举未来可能发生的意外事件,而故障往往出现在预案之外的地方(墨菲定律)。

6.3 完善监控体系

建立完善的监控、告警机制,避免我们成为瞎子聋子,保障报错及时感知。在监控点的设置上,主要原则是:所有的依赖都是不可信的!

6.4 快速响应能力

类似于在行驶的飞机上换引擎,过程中无论发生什么样的故障,立即要动用一切力量“快速”止损。服务要有等级划分,保障抓大放小,保护核心服务原则,如确实存在不能快速定位问题时,可逐层降级。主要目标:防止问题扩大,故障止损,快速恢复

总结

稳定性建设关键点

  • 削峰限流 面对资源上限,做技术、业务层面的处理,达到流量削峰保障服务稳定性;

  • 缓存加速 利用缓存解决并发,有效提升系统的吞吐量,同时需注意避免热 Key、大 Key 问题;

  • 异步化处理(同步->异步),有效提升响应效率,保障数据的最终一致性。

技术服务于业务

技术还是要解决实际问题来落地。应用场景很关键,所有的优化工作不要单纯为了技术而技术,技术归根结底还是为应用场景和产业落地服务。

可以尝试将业务视角目标做为最终目标,通过一切技术手段来保障目标的达成,从而实现技术价值最大化。

不拘泥于形式,灵活运用

稳定性方案需要视场景而灵活调整应用,切忌生搬硬套。在具体实现过程中,关键要把控主要行动路径,多条路径情况下选取投入产出比最高的那一条。推进一个行动路径:问题驱动(问题感知->问题分析->问题控制->问题解决)。


Thanks for reading!

发布于: 2020 年 12 月 08 日阅读数: 956
用户头像

坚持分享接地气儿的架构技术文章! 2018.02.26 加入

同名微信公众号「架构精进之路」,专注软件架构研究,技术学习与职业成长!坚持原创总结、沉淀和分享,希望能带给大家一些引导和启发,感谢各位的支持(关注、点赞、分享)!

评论 (5 条评论)

发布
用户头像
SLA的时间指标都写错了。
2020 年 12 月 09 日 11:36
回复
??? 求指明,有问题欢迎交流~
2020 年 12 月 09 日 19:48
回复
1年 = 365天 = 8760小时
99.9 = 8760 * 0.1% = 8760 * 0.001 = 8.76小时
99.99 = 8760 * 0.0001 = 0.876小时 = 0.876 * 60 = 52.6分钟
99.999 = 8760 * 0.00001 = 0.0876小时 = 0.0876 * 60 = 5.26分钟
2020 年 12 月 10 日 10:08
回复
自己引用的公式是错的也没有印证过。
2020 年 12 月 10 日 10:13
回复
查看更多回复
没有更多了
系统稳定性建设实践总结