系统稳定性建设实践总结
目录
开篇
一、系统稳定性建设是指什么?
二、为什么需要系统稳定性建设?
三、系统稳定性建设为什么难?
3.1 面对的挑战比较大
3.2 系统稳定性建设是一个系统性的大工程
四、系统稳定性建设如何入手?
4.1 系统稳定性建设前提
4.2 流程划分
五、系统稳定性建设的关键动作
5.1 削峰限流
5.2 缓存加速
5.3 异步化处理
六、稳定性建设过程中的一些经验
6.1 做好压测
6.2 应急预案必备
6.3 完善监控体系
6.4 快速响应能力
总结
稳定性建设关键点
技术服务于业务
不拘泥于形式,灵活运用
2020年,注定是个不平凡的一年。疫情的蔓延打乱了大家既定的原有的计划,同时也催生了一些在线业务办理能力的应用诉求,作为技术同学,需要在短时间内快速支持建设系统能力并保障其运行系统稳定性。恰逢年终月份,正好梳理总结下自己的系统稳定性建设经验和思考。
开篇
在开始介绍服务稳定性之前,我们先聊一下SLA。SLA(service-level agreement,即 服务级别协议)也称服务等级协议,经常被用来衡量服务稳定性指标。通常被称作“几个9”,9越多代表服务全年可用时间越长服务也就越可靠,即停机时间越短。通常作为服务提供商与受服务用户之间具体达成承诺的服务指标——质量、可用性,责任。
3个9,即99.9%,全年可停服务时间:365 * 24 * 60 *(1-99.9%)= 525.6min
4个9,即99.99%,全年可停服务时间:365 * 24 * 60 *(1-99.99%)= 52.56min
5个9,即99.999%,全年可停服务时间:365 * 24 * 60 *(1-99.999%)= 5.256min
在严苛的服务级别协议背后,其实是一些列规范要求来进行保障。
一、系统稳定性建设是指什么?
关于系统稳定性是指什么这一问题,相信好多开发同学都会有自己的理解和认知,但可能会存在是否理解片面或者是否标准的疑惑,那到底有什么判定标准和划分边界呢?
我们不妨看下来自于维基百科的解释:
稳定性是数学或工程上的用语,判别一系统在有界的输入是否也产生有界的输出。
若是,称系统为稳定;若否,则称系统为不稳定。
简单理解,系统稳定性本质上是系统的确定性应答。
从另一个角度解释,服务稳定性建设就是如何保障系统能够满足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!
系统稳定性建设实践总结相关推荐
- 菜鸟积分系统稳定性建设 - 分库分表百亿级数据迁移
点击上方"服务端思维",选择"设为星标" 回复"669"获取独家整理的精选资料集 回复"加群"加入全国服务端高端社群「后 ...
- 面对系统的稳定性、我们如何做好系统稳定性建设?
1.背景介绍 在移动互联网时代,用户群的积累比之前更容易,但同样,也会因为糟糕的用户体验,而快速流失用户,哪怕是号称独一无二的12306网站,也在不断优化系统来提升用户体验:而在后移动互联网的物联网时 ...
- 稳定性全系列(一)——如何做好系统稳定性建设
目录 一.背景介绍 二.故障源的分类 三.稳定性建设四要素 第一要素:人 第二要素:工具 第三要素:预案 第四要素:目标 四.稳定性建设四个方向 第一个方向:根基要抓牢(45%) 第二个方向:工作在日 ...
- 稳定性全系列(一):如何做好系统稳定性建设
1. 背景介绍 在移动互联网时代,用户群的积累比之前更容易,但同样,也会因为糟糕的用户体验,而快速流失用户,哪怕是号称独一无二的 12306 网站,也在不断优化系统来提升用户体验:而在后移动互联网的物 ...
- 系统稳定性建设的一些感想
背景 我目前主要负责供应链系统: 支持公司重资产业务持续精细化运营. 系统之前是一个外采系统: B2P自闭环业务流程, 资产管理以及业财一致等业务功能集一身的单体应用系统. 随着业务发展,系统不断运维 ...
- 换个角度聊系统稳定性建设(2021版)
前面发过一篇同名的文章,但那个是2020年年初写的.后续在做稳定性工作过程中有了一些新的输入与心得,于是在前一篇文章基础之上做了一些完善,主要是修改了一些错别字,追加了一些新的感悟,为便于阅读,我将更 ...
- 大促场景系统稳定性保障实践经验分享
简介:11月11日0点刚过26秒,天猫双11的订单创建峰值就达到58.3万笔/秒,阿里云又一次扛住全球最大规模流量洪峰!58.3万笔/秒,这一数字是2009年第一次天猫双11的1457倍. 每到双11 ...
- 大促场景系统稳定性保障实践经验总结
简介:11月11日0点刚过26秒,天猫双11的订单创建峰值就达到58.3万笔/秒,阿里云又一次扛住全球最大规模流量洪峰!58.3万笔/秒,这一数字是2009年第一次天猫双11的1457倍. 每到双11 ...
- 换个角度聊系统稳定性建设
写在前面 对于任何系统来说,系统稳定性都是最基本的一个要求,只不过每个项目都有其发展周期,每个周期都有其主要的发展目标,比如业务爆发初期我们要求业务快速迭代,业务发展中期我们可能更多的是要求精细化运营 ...
- 分布式系统稳定性建设指南
文章目录 分布式系统稳定性建设总体视图 分布式系统稳定性建设目标 分布式系统稳定性评价指标 分布式系统稳定性建设模式 架构设计 容量设计 架构设计 安全设计 分布式系统稳定性建设路径 需求分析 需求实 ...
最新文章
- Exception in thread “main“ java.io.IOException: Cannot run program “python3“: CreateProcess error=2,
- MySQL 5.7 LOGICAL_CLOCK 并行复制原理及实现分析
- pandas基础(part3)--描述性统计
- DFS应用——遍历有向图+判断有向图是否有圈
- 【HDU - 1412】 {A} + {B} (STL + set)
- 程序员如何在大公司做管理
- php 路由实现_PHP操作路由器实现方法示例
- [转载]Java Socket实战之二 多线程通信
- 谷粒商城:07. pms_catelog.sql
- SQL Server 死锁的监视
- 遥感影像识别-训练策略
- ORACLE--面试知识点
- android 风吹的动画,最炫Material Design风过渡动画
- Android App开发实战之实现微信记账本(附源码 超详细必看)
- 级数_2:常数项级数的审敛法
- Java通过axis调用WebService
- [js点滴]JavaScript基础正则详解03
- 全志A20 android4.4双屏异显 双屏同显终于可以了
- 虚拟机从路由器获取宽带拨号账号密码
- 后端开发常见面试题目