大促场景系统稳定性保障实践经验分享

简介：11月11日0点刚过26秒，天猫双11的订单创建峰值就达到58.3万笔/秒，阿里云又一次扛住全球最大规模流量洪峰！58.3万笔/秒，这一数字是2009年第一次天猫双11的1457倍。

每到双11，如何保障系统高峰扛得住、长期平稳是每个大促人必须面对的问题。在今年双11之前，阿里云在上海举办了一场线下交流，阿里大促和稳定性保障负责人、中间件专家、解决方案专家等将历年总结的大促经验分享给参会嘉宾，我们选取了其中的精彩内容整理如下。

一、互联网行业稳定性建设的观察与思考

第一位分享嘉宾是阿里云华东互联网团队的高级解决方案架构师江煵，他拥有十余年的软件开发经验，近些年一直从事云计算方向的开发和架构工作，主导过多个云平台、PaaS平台的开发建设，对于云和互联网架构方面有比较深入的理解和实践，目前关注于容器、中间件、Serverless等云原生的技术方向。

江煵在分享中提到，今年我们在新闻里听到了很多比较大的宕机事件，宕机的原因其实都很典型，删库跑路、被攻击、没有做好容量规划或者弹性能力不足、系统更改等。宕机后果还是比较严重，比如某SaaS服务商直接经济损失是两千多万，当天市值下跌10亿；某新能源车制造商网络中断事故当天市值下跌近数百亿美元。股价能涨回来，但对消费者的信心损害、对公司的品牌声誉的影响等这些很难在短时间内消除掉。

关于行业的稳定性建设现状，不少企业稳定性建设上欠的账还是很多的，一些偏小且偏传统的公司，可能都还没有高可用方面的准备。即使是中大型公司，在稳定性建设上还是存在短板。

稳定性建设相关的工作很难被看到、被认可或客观评判，不出事故确实有可能是运气，而即使是发生事故，也有可能因为稳定性做的很好且已经避免了十起其他重大事故。所以需要一些办法来为稳定性建设工作做一些定性甚至定量的评估，让这方面的工作有目标、过程可跟进、结果能检验，所以这方面我们做了一些探索和尝试。

这里我们提出了一个关于稳定性建设成熟度模型的设想，从11个维度，建议了两种稳定性建设成熟度评估方法：一种是雷达图模式，通过11个指标的打分，得出来一个整体分数；另一个是等级模式，每个指标维度根据建设的完善度给0~4分，我们希望所有的公司应该至少达到基础级以上，中大型公司能到发展级，行业头部公司能到成熟级水平。

当然这个成熟度模型本身还不是特别完善，现在提出来给大家参考和探讨，未来我们会持续优化，不光希望给大家合理的评估参考办法，更希望能对行业整体水位进行分析，让各家对自己的稳定性建设在行业内的水位有所了解，便于制定合理的目标。

再给大家快速的介绍一些稳定性建设的一些思路，稳定性工作的本质无外乎是发现风险和消除风险的过程，风险来自于本身系统和产品遗留的潜在风险、长期使用导致的系统腐坏风险、新功能发布和系统升级引入的风险、大促之类的活动带来的风险等，我们的稳定性工作就是让这些风险可控。

当然保障还有一大利器就是基于阿里云的稳定性建设体系，阿里云提供从资源到方法论全链路的稳定性产品和方案，我们有在行业内排名前列的客户，仅凭少量的SRE同学，就能基于阿里云的各种高可用能力，提供非常高效稳定完善的系统保障。

二、电商高可用架构演进和大促保障经验分享

第二位分享嘉宾是阿里巴巴高可用架构团队的高级技术专家中亭，他是多活容灾&故障演练团队负责人。2011年加入阿里，2015年担任双11负责人，目前负责阿里巴巴经济体高可用领域的保障及商业化产品的输出工作。

据中亭介绍，目前，高可用领域的技术产品通过两个云服务向外输出，分别是PTS（性能压测）和AHAS（应用高可用）。在阿里内部，准备一次双11是一个非常复杂的超级工程，如果业务特别复杂，可能涉及几十个甚至上百个横纵型项目。不过从围绕大促本身这个技术问题，需要解决的问题包括容量、架构、组织等。围绕这三个问题，中亭介绍了高可用技术的演进历史和技术选型，并给出了基于云的高可用解决方案：

1. 阿里全链路压测的完美复制
（1）通过压测基础环境改造获得线上生产环境的读写压测能力；

（2）积累压测基础数据和业务流量模型经验，后续可通过购买PTS资源包继续进行常态化全链路压测；

（3）对于重大活动可以方便地提前预演，提前准备和应对。

2. 流量防护
提供业务系统全方位可用性防护，从网关防护和应用防护两个层面、入口/应用/应用间/单机负载多维度，提升系统的高可用性，包括低成本接入，全方位防护，多语言版本支持，秒级防护能力。

3. 异地多活方案
多活解决方案=定制技术产品+咨询服务+生态伙伴。

故障演练
混沌工程的专业技术和方案：遵循混沌工程实验原理并融合了阿里巴巴内部实践，提供了丰富故障场景实现，帮助分布式系统提升容错性和可恢复性。包括丰富演练库（基础资源、应用、云产品）；场景化演练（强弱依赖、消息、数据库等）；企业级实践（红蓝攻防、资损演练等）。

三、秒杀最佳实践和解决方案

第三位分享嘉宾是阿里云智能解决方案架构师鹿玄，他经历过大型分布式系统的开发和维护，并在云计算、云原生等领域有多年从业经验，对系统架构选型，问题排查和性能调优有着丰富的实战经验，致力于通过云原生架构转型来帮助阿里云各行业客户实现业务价值。

首先我们来看秒杀业务流程，流程比较简单，一般就是下订单减库存：

秒杀系统的设计原则包括以下几点：
1 . 热点识别
通过营销活动，卖家单独报名等方式，提前收集信息。

2 . 隔离原则
在前端页面、应用层、数据层做好隔离。

3 . 将请求尽量拦截在系统上游。

传统秒杀系统之所以挂，请求都压到了后端数据层，数据读写锁冲突严重，并发高响应慢，几乎所有请求都超时，流量虽大，下单成功的有效流量甚小，比如某种商品只有1000的库存，100w个人来买，实际上绝大部分的请求有效率为0。

4 . 读多写少的场景使用缓存

秒杀是一个典型的读多写少的应用场景，比如某种商品只有1000的库存，100w个人来买，最多1000个人下单成功，其他人都是查询库存，写比例只有0.1%，读比例占99.9%，非常适合使用缓存。

在秒杀场景中，从架构层面需要考虑的事情有以下几点：

1 . 库存缓存

Redis作为大促期间库存扣减的主要承担方。商品ID作为Redis的KEY，将可用库存=(总库存-暂扣库存)值作为Value。利用LUA脚本的事务特性实现在Redis中“读剩余库存后扣减”的逻辑

2 . 容量规划

使用阿里云性能测试工具PTS，模拟真实用户请求，验证全国用户真实业务操作对服务端性能、容量和系统稳定性的影响，确保重大活动平稳支撑。

3 . 性能调优

利用ARMS提供的立体式监控能力，在压测过程中实时监控应用及物理机各项指标，快速帮助开发人员定位排查问题，提升系统性能。

4 . 限流防刷

使用阿里云应用高可用服务(AHAS) 实现限流降级，确保系统不被预期外的突发流量打挂。同时可配置热点规则，超过一定量的阈值后，系统会让购买热点商品的流量排队等待。例如购买同一商品，1s内调用超过100次请求后，则其余请求进行等待

5 . 异步解耦，削峰填谷

消息队列 RocketMQ 版是阿里云基于 Apache RocketMQ 构建的低延迟、高并发、高可用、高可靠的分布式消息中间件。消息队列 RocketMQ 版既可为分布式应用系统提供异步解耦和削峰填谷的能力，同时也具备互联网应用所需的海量消息堆积、高吞吐、可靠重试等特性

6 . 弹性能力

对于有周期性促销活动的用户，可以使用Serverless 应用引擎（SAE）快速部署应用，利用定时弹性能力，在活动开始前自动扩容，在活动结束后自动缩容回收资源，实现资源利用最大化，且整个过程无需人工干预。

四、全链路压测最佳实践经验分享

第四位分享嘉宾是阿里云智能解决方案架构师计缘，拥有12年IT领域行业经验，在能源行业和互联网ToB行业完整经历和实践了SOA架构、微服务架构、云原生架构的转型过程，对互联网云原生架构以及微服务管理、治理、架构高可用优化有着深入理解，实战经验丰富，多次帮助阿里云的行业客户对系统架构完成全面的云原生改造。

据计缘介绍，大促活动、秒杀活动是最大化流量红利的不二选择，但是有很多企业依然享受不到流量红利，根本原因只有一个，那就是系统支撑不了大流量的冲击。主要问题是系统的性能问题大多由不可预知的问题导致。

整个系统从前到后环节非常多，任何一个环节都可能成为整个系统的瓶颈、短板、约束点。不同通讯协议，不同数据格式，不同规范，让整个分布式系统架构变得异常复杂。另外，微服务架构下服务调用链路南北向和东西向都非常长，单个服务一旦出问题很容易发生“多米诺骨牌”或“雪崩”效应。

现在大多数产品对于用户而言都是一个入口、一个App，但其实里面的内容是由多个产品线组合而成的，给客户呈现的是由非常多个零件协调组织运转起来的产品。但是实际中，负责不同模块、不同产品线的小组有自己的测试团队，他们只为某一个模块或产品线的质量负责，当这些模块组合起来后，会产生更多因为各种匹配、协作带来的问题，所谓不能窥一斑而知全豹。这些不确定的问题给我们产品的用户体验、品牌效应、产品收益带来巨大的挑战。

我们要解决根本的问题，就是要有方案和手段尽可能全的识别这些不确定的因素和问题。一个系统在整个运行的生命周期中无外乎两个场景，瞬时流量洪峰场景和长期稳态场景。
**
1 . 瞬时流量洪峰场景**

这个场景其实对应的就是大促活动、秒杀活动的场景，我们可以在生产环境上做全链路压测，最大限度的模拟用户的真实流量，不断施压摸高，找出系统的性能约束点进行优化；然后反复这个过程。在这个过程中有两个关键点，一是流量来源近似用户真实流量，二是在生产环境上做压测，这样等于我们制造出了真实的大促活动场景，来发现系统的不确定问题。

2 . 长期稳态场景

将全链路压测的方案固化，通过统一的控制台，周期性进行故障演练，对版本发布和配置变更后的质量兜底。所以通过流量洪峰场景来尽可能多的识别不确定因素，通过长期稳态场景常态化监测系统的不确定因素，然后分析解决不确定因素，达到对系统稳定性和高可用性的优化。

在施压方面，阿里云PTS产品基于全国边缘节点、CDN模拟各个地域、各个运营商发起流量，能在段时间内发起几十万流量，并且可以动态设置地域和运营商。在PTS的控制台提供了可视化的方式可以让客户很方便的创建业务场景，另外还集成了JMeter原生引擎，可以快捷的导入JMeter脚本，进行压测工具的无缝迁移。

在流量隔离方面，阿里云提供无侵入的Agent方式，在不需要对业务系统做代码改造的同时将流量隔离的能力搭载上去，通过在PTS流量管控控制台进行接口Mock规则配置、影子表规则配置、压测数据偏移量配置，来实现Agent对压测流量和压测数据的隔离。

总结

阿里巴巴目前已经实现全面云原生上云，并通过大规模使用包括容器服务ACK、消息队列RocketMQ、微服务 EDAS、监控ARMS、性能测试PTS等在内的云原生产品，获得成本、稳定性和研发运维效率提升的红利。与此同时，双11大促的业务场景也成为阿里云云原生技术与产品优势的锤炼场，为阿里云客户创造更大价值。

阿里云专门成立了“互联网架构升级实战课”钉钉群，每周邀请一位阿里云专家在群内进行行业最佳实践直播，每天分享行业前沿干货，欢迎扫码或钉钉搜索群号加入：35712134。

原文链接：https://developer.aliyun.com/article/778248?

版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。