2020年，注定是个不平凡的一年。疫情的蔓延打乱了大家既定的原有的计划，同时也催生了一些在线业务办理能力的应用诉求，作为技术同学，需要在短时间内快速支持建设系统能力并保障其运行系统稳定性。恰逢【云 社区年度征文】活动，正好借此机会，梳理总结下自己的系统稳定性建设经验和思考。
开篇
在开始介绍服务稳定性之前，我们先聊一下SLA。SLA（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来搞，从其运行流程来看，主要存在以下几个方面：
代码语言：javascript复制前提：明确目标 （基准）- 事前 请求链路优化、服务性能优化&压测、应急预案制定、故障演练
- 事中 故障监控、定位问题、故障止损、问题修复
- 事后 故障复盘、整改优化、经验总结沉淀
服务稳定性建设其实是一个系统性的大工程，包括了方方面面。
五、系统稳定性建设的关键动作
从上一Part工作拆解来看，稳定性建设囊括的点比较多，而且杂。更多情况下，我们会做服务稳定性专项，针对某些特定场景下的特定问题而梳理出对应的方案。
那我们可以以小见大，从单服务系统本身出发，提炼看看存在哪些稳定性建设的关键点。其实只有每个单服务环节都稳定可靠，那集群系统乃至整个工程系统的稳定性才有保障。
假如系统面对突增的请求流量情况下，如何做好服务稳定性建设呢？
稳定性建设关键动作拆分如下几类：
5.1 削峰限流
例如，经典的秒杀场景，春节的火车票抢购、电商平台的双11秒杀等等，都是短时间上亿的用户涌入，瞬间流量巨大（高并发）。
不管前期对服务器资源做了如何的扩容，都会存在一个处理上限，所以一定要进行必要的削峰限流策略，类似于城市早晚高峰错峰限行的解决方案。同样，秒杀场景也需要类似的解决方案。
那具体如何实现呢？
- 利用消息队列来削峰
消息队列来缓冲瞬时流量，把同步的直接调用转换成异步的间接推送，中间通过一个队列在一端承接瞬时的流量洪峰，在另一端平滑地将消息推送出去。
消息队列就像“水库”一样，拦蓄上游的洪水，削减进入下游河道的洪峰流量，从而达到减免洪水灾害的目的。
- 利用挡板过滤无效请求
流量挡板过滤，主要是建立一种验证机制过滤掉无效请求，保障核心服务避免受更多外界无效请求的影响。比较常用的方案就是“布隆过滤器”。
- 产品策略的调整
产品策略调整是一种特别有效的手段，效果甚至会优于技术层面的改进优化。
例如：利用排队策略，有效打散高并发请求；调整活动宣传时间分散点，避免同一时刻出现高并发请求…
5.2 缓存加速
缓存是解决并发的利器，可以有效的提高系统的吞吐量。按照业务以及技术的纬度必要时可以增加多级缓存来保证其命中率。
主要应用思路：在数据库与服务端之间利用 Redis 做缓存服务，减少请求直接冲击到数据库。
5.3 异步化处理
与异步对应的就是同步，即所有事情排队一件件的有序进行，等上件事情完成后才会去做下一件事情。有点像一根签子串起来的糖葫芦。需要实时处理并响应，一旦超过时间会结束会话，在该过程中调用方一直在等待响应方处理完成并返回。
异步处理不用阻塞当前线程来等待处理完成，而是允许后续操作，直至其它线程将处理完成，并回调通知此线程。
需要强调一点：异步是一种设计理念，异步操作不等于多线程，常见的消息中间件、发布订阅的广播模式等，都可以实现异步处理的方式。
六、稳定性建设过程中的一些经验
6.1 做好压测
提前做好系统压测，做到心中有数，防患于未然，压力预估要切合实际，不要盲目过大。对于性能瓶颈点，尽量提前做好改进优化或者重点关注布防。
6.2 应急预案必备
应急预案一定要有，研发人员往往比较自信，这是好事也是坏事，我们需要做最坏的打算。因为经验再丰富的工程师，也无法穷举未来可能发生的意外事件，而故障往往出现在预案之外的地方（墨菲定律）。
6.3 完善监控体系
建立完善的监控、告警机制，避免我们成为瞎子聋子，保障报错及时感知。在监控点的设置上，主要原则是：所有的依赖都是不可信的！
6.4 快速响应能力
类似于在行驶的飞机上换引擎，过程中无论发生什么样的故障，立即要动用一切力量“快速”止损。服务要有等级划分，保障抓大放小，保护核心服务原则，如确实存在不能快速定位问题时，可逐层降级。主要目标：防止问题扩大，故障止损，快速恢复。
总结
稳定性建设关键点
- 削峰限流 面对资源上限，做技术、业务层面的处理，达到流量削峰保障服务稳定性；
- 缓存加速 利用缓存解决并发，有效提升系统的吞吐量，同时需注意避免热Key、大Key问题；
- 异步化处理（同步->异步），有效提升响应效率，保障数据的最终一致性。
技术服务于业务
技术还是要解决实际问题来落地。应用场景很关键，所有的优化工作不要单纯为了技术而技术，技术归根结底还是为应用场景和产业落地服务。
可以尝试将业务视角目标做为最终目标，通过一切技术手段来保障目标的达成，从而实现技术价值最大化。
不拘泥于形式，灵活运用
稳定性方案需要视场景而灵活调整应用，切忌生搬硬套。在具体实现过程中，关键要把控主要行动路径，多条路径情况下选取投入产出比最高的那一条。推进一个行动路径：问题驱动（问题感知->问题分析->问题控制->问题解决）。
最后希望云 社区 越办越好！感谢！相信做难事者，必有所得！
欢迎大家点赞、收藏和分享~
Thanks for reading!
