四、稳定性实践篇

Created 6 years ago by 学院君, Updated 5 years ago Revision #2 7544 views 0 likes 0 collects

本系列教程是学院君在极客时间学习赵成的运维体系管理课记录的学习笔记，希望对有这方面需求的同学有所启发，如果想要深入了解细节可以去极客时间订阅该专栏。作者介绍：赵成，美丽联合集团技术服务经理。

极端业务场景下如何做稳定性保障

极端业务场景

可预测：电商大促
不可预测：社交媒体突发事件

技术挑战

运维自动化 —— 快速扩容
容量评估和压测 —— 系统容量心中有数
限流降级 —— 核心链路可用性（业务功能开关）
开关预案 —— 系统功能开关
故障模拟
监控体系

脱离业务谈架构，谈技术，都是不负责任的

稳定性实践：容量规划之业务场景分析

容量规划，就是对复杂业务场景的分析，通过一定的技术手段（如压测），来达到对资源合理扩容、有效规划的过程。

换句话说，就是根据业务 GMV、UV 等目标，对技术上的交易下单峰值这个核心指标进行推导的过程，接下来就根据评估的各个应用和基础服务需要承担的流量，先扩容一轮，同时开始构造数据模型和压测模型来模拟真实流量，以此验证我们的系统是否能够达标，过程中再进行局部的扩容和优化。

一般来说，先进行单链路压测，比如购物车订购，详情页订购等场景的压测，达标后再进行多链路压测，最后再进行全链路压测，直至达成目标。为了能够保有一定的容量缓冲，最后几轮压测，我们会将压测流量调整到目标值的 120% 或 150%，来保证系统能够应对足够极端的场景，这样才能够游刃有余地实现 100% 的目标。

稳定性实践：容量规划之压测系统建设

第一个维度，压测粒度

单机单应用压力测试
单链路压力测试：商详、加购、下单等核心链路
多链路/全链路压力测试

第二个维度，压测接口及流量构造方式

线上流量回放
线上流量引流
流量模拟（Gatling）

全链路压测

第三个维度，施压方式

通过实现在 Web 控制台配置好的压测场景，自动生成压测脚本；
利用数据工厂构造出压测数据，这个就是业务场景的模拟；
通过 Web 控制台，根据压测脚本和压测数据，生成压测任务，推送到压测集群的 Master 节点，再通过 Master 节点推动到上百台的 Slave 节点，然后就开始向线上系统施加模拟的流量压力了。

第四个维度，数据读写

压测过程中，对于读的流量更好构造，因为读请求本身不会对线上数据造成任何变更，但是对于写流量就完全不一样了，如果处理不好，会对线上数据造成污染，对商家和用户造成资损。所以，对于写流量就要特殊处理，这块也有比较通用的解决方案，就是对压测的写请求做专门的标记。当请求要写数据库时，由分布式数据库的中间件框架中的逻辑来判断这个请求是否是压测请求，如果是压测写请求则路由到对应的影子库中，而不是直接写到线上正式的库中。