服务稳定性SLA-2015年阿里双十一惨痛的教训

聊聊后端面试那些事-【公粽号：堆栈future】

原文

服务稳定性

618&&双11

作为研发，尤其是后端研发，每年在618或者双11的时候压力特别大，他们祈求服务不要出故障，交易能正常进行，而且期望用户体验非常棒而不是卡顿404等。

但是有时候就是事与愿违，比如在2015年11月11日傍晚，大部分用户反馈购物失败的情况，负责双11技术保障的阿里云计算总裁胡晓明回应称，零点开始5分钟内巨量的访问涌入，并创建交易、支付，这相当于一次黑客攻击，对全世界任何公司都是挑战。双11前，公司做过大量压力测试，网络繁忙的情况是在预料之内，好在很快就修复了这个问题，后面交易亦十分平滑、流畅。

这次快速修复问题的时间是1小时不等。

修复之后再看下那天的交易数据：

数据亮眼的背后就是研发和运维在不惜一切代价找出问题并快速修复它，不然你是看不到这个数字的。

既然服务的稳定性这么重要，那要怎样去做才能保证呢？

SLA服务等级协议

SLA （服务等级协议，全称：service level agreement）来衡量系统的稳定性，对互联网公司来说就是网站服务可用性的一个保证。

一般我们会用4个9或者5个9代表全年服务的稳定性，比如99.99%或者99.999%这样，我们以99.99%为例，停机时间52.6分钟，平均到每周也就是只能有差不多1分钟的停机时间，也就是说网络抖动这个时间可能就没了，服务状况良好。

那么有了这个概念之后我们在回头看下2015年阿里双十一那次修复问题，他们耗时1h，那基本上他们的服务在当时可以粗略判断是4个9即99.99%。

为什么会说到这个概念呢？因为我们接下来所说的所有都是为了它。

单个服务稳定性

1. 具备开关功能，核心功能或者非核心功能在遇到故障的时候通过开关操作可以快速下线，保证整体服务可用。

2. 缓存设计，尽量用缓存提高系统吞吐量。

3. 接口无状态，接口应该是无状态的，当前接口不应该依赖上层接口的状态。

4. 接口单一职责，对于核心接口不应该过多耦合别的功能。

5. 第三方服务，做到0信任，即要考虑熔断降级限流。

6. 兜底方案，核心业务必须有兜底方案。

7. 监控与响应，做好服务监控和及时响应。

集群稳定性

1. 系统架构，必须合理设计。

2. 代码研判，代码要review，review再review。

3. 集群部署，集群部署应对高并发大流量。

4. 限流熔断，这是应对高并发的必要手段。

5. 监控体系，它是你的医生，你得好好利用起来。

6. 压测机制，没有压测，你无法预判高并发来临时系统能否扛得住。

专项测试

1. 预案，把你的开关降级等都统统过一遍。

2. 预热，存储常态化流量或者热点流量进行回放来提前预热。

3. 监控，基础/业务/其他MQ监控等都看一遍确认准确无误。

4. 追踪，链路追踪必不可少，排查问题利器。

稳定性建设

1. 容量规划，先拍脑袋决定几台机器，压测不够再加。

2. Chaos Monkey，找人专门搞破坏，看系统是否出错。

3. 流量调度，API网关或者Ingress网关能力。

4. 容灾/异地多活，不怕地震，就怕地震搞破坏把线路掐断。

小结

上面的总结拿出任何一个概念都是一个复杂的工程，尤其在落地的时候。其实很多公司都做不到，那为什么还需要了解呢？因为某人说过一句话，梦想还是要有的，万一实现了呢，就是公司再小它也有壮大的时候，所以从一开始你就去思考，去慢慢建设，等公司真正成长起来之后(比如像某宝，某东或者某多)你就可以开始你的表演了。

- END -

公粽号：堆栈future

使很多处于迷茫阶段的coder能从这里找到光明，堆栈创世，功在当代，利在千秋