共计 4406 个字符，预计需要花费 12 分钟才能阅读完成。
每到双 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 大促的业务场景也成为阿里云云原生技术与产品劣势的锻炼场，为阿里云客户发明更大价值。
原文链接
本文为阿里云原创内容，未经容许不得转载。
