开发者学堂课程【618大促来袭，谈一谈如何做好大促备战：618大促来袭，谈一谈如何做好大促备战】学习笔记，与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1048/detail/15218
618大促来袭，谈一谈如何做好大促备战
2021年天猫双十一落下帷幕后，支撑数千亿阿里中间件全面升级到公有云架构，都用公有云体系。有效用云产品，做好大促备战。
618大促来临前，谈一谈做好大促备战积累的经验和最佳实践。
目录：
一、大促的不确定性挑战
二、目标确定
三、备战流程
四、大促总结与复盘
一、大促的不确定性挑战
大促时会遇到很多不确定因素，从外面进来，业务流量不确定，服务的用户行为不确定，安全攻击不确定。
大促过程中做变更的操作，大促时严令禁止变更，存在研发变更的风险，出现问题时故障未知，是不确定因素。最好的做法是在网关处做好模拟和防护，单在网关入口做，不能解决所有的问题。需要 RDC 内部进一步做的防故障掩护，流量防护等各个方面。
流量不确定需要容量评估、业务评估确定流量的峰值，可能存在突增的流量、商品，远大于流量值，通过限流和流量变成确定性的条件。
用户行为不确定，用户可能有各种操作，用户量很多，秒杀时大量用户涌进，此时用户的行为不确定。通过仿真多个场景用户行为，进行演练和压测。做到真实的仿真，及时发现系统的瓶颈和优化点，及时优化。
安全攻击有不确定性，可能有黑产刷单、刷羊毛。网关处有防护能力，识别黑产刷单的流量，通过流控限制访问量，保障正常用户的流量。
研发变更风险，通过严格的风险管控，控制大促时不必要的变更。出现故障时不知道故障的影响面，对系统是很大的不确定因素，通过不断的故障演练锤炼系统。注册中心99.9%的可用率，也可能出现问题，当注册中心不可用时，客户端是否具备高可用的能力。注册中心出现故障客户端有提供保护的能力，可保障流量不出任何问题，服务不会挂。系统扛不住，不重要的业务出现明显时，快速降级，控制故障的影响面，涉及到许多不确定因素，需要通过故障演练帮助控制影响面，尽可能控制影响面。出现故障时，通过熔断保证系统不出现雪崩的风险。大促企业是一个项目，备战的方法把大促的不确定因素尽可能变为确定性。
二、目标确定
研发侧，大促目标有宣称支撑多少万流量的峰值，做到百分之多少的成本优化，给用户流畅的用户体验等。大促目标一般围绕成本、稳定性、效率。
成本云产品 Nacos、Zookeeper 和资源型的云原生网关资源成本，应用的资源成本，可利用 K8S 的弹性能力，保证应用在稳定性和成本之间的平稳。通过压测发现系统的瓶颈，进行性能的优化，保证成本。
效率 MSE 应用配置可做预案，提供 PTS 的全链路压测能力，帮助快速流量压测。
稳定性有高可用，无损上下线。MSE 流量防护全流程端到端的限流，从流量入口到应用服务到后端的缓存再到数据库，全链路灰度可配合进行功能预演。
大促备战流程如下
从架构设计到高可用，到大促前的预案评估和预案梳理，到大促前的全链路压测，通过 PTS 进行瓶颈探测、容量验证，微调，故障演练，控制故障的范围。大促来时需要时刻观察环境，容量、系统稳定情况，当容量峰值时，根据预案进行限流，出现问题时进行降级。过程中MSE提供流量限流、降级、预案，在大促中有效保证系统平稳度过大促。
流程分为容量评估、预案准备、预热、限流，以上点都做到可把不确定因素变为确定的条件，面对大促的宏分，整个系统非常平稳。
三、备战流程
容量评估
对服务进行有效评估，容量评估的目的是实现成本与稳定性最佳的平衡，需要基于大促的应用表现，提供压测知道应用在大促中的表现，确定应用在一定条件下的性能接线。成本优化的目的需要确定资源的量，成本的预算。
一通过性能评估以及优化确定应用性能，二评估业务是否发生变化、系统是否发生变化，三基于业务模型确定全链路压测的模型，进行全链路压测的验收。评估极限流量的水位，使流量保持绿色水位的状态，利用云原生弹性扩缩容能力。
评估服务的容量
提前模拟复杂的、高仿真的线上流量来验收整体系统的高可用性，是实施系统高可用方案的关键环节，类似双十一峰值业务的稳定性的考验，保证业务峰值的不受损。
通过不同阶段的压测，完成对系统的容量规划、瓶颈探测，对系统整体能力进行验收，确保峰值流量来临前，系统能够承受即将来临的大流量。
性能评估引出阿里云产品PTS的线上测试，比一般的压测工具有两个优势。一方面功能强大，全SaaS形态无需额外部署安装，不需要安装云端的录制器，更适合移动端场景。流量更加真实，流量来自全国上百个城市，覆盖各种运营商，同时可扩展海外，真实模拟最终用户的流量来源，报表更接近用户的真实体感，升压能力没有上线，千万RT的压测能量。
流量压测场景模型
要发起一次性能压测，首先需要创建一个压测场景。一个压测场景包含一个或多个并行的业务，用户可能浏览商品，另一个用户可能先登录、浏览、加入购物车、提交订单，模拟用户的行为，很多条件让动作做到更仿真的效果。
压测施压配置-施压模式有并发模式、RPS模式
压测施压配置来自全国各地流量来源，可使用阿里内网进行测试。
配置好压测，同时得到报表，报表可以看到全场景的数据分析、压测趋势数据分析、异常信息分析。
通过压测可对系统进行双向识别和性能管理能力，通过全链路压测可提前发现系统瓶颈，识别性能的风险，防止系统性能的腐化。使用压测要评估业务和系统的优化，可评估大促沉淀下的数据，评估业务的动向，业务相比之前是否有量节的提升，业务的玩法是否有变化。618预售、抢红包、满减等业务是否对系统进行稳定性的分析，对用户的动向进行分析，全局的视角看到系统的关键路径，保障核心的业务，通过压测梳理强路依赖，从全局视角判断系统各个点的瓶颈。
Nacos容量评估
可评估Nacos注册位置中心的水位，从文档中看到，提供从连接数到服务数的评估。有些应用服务数特别多，大促时应用随着流量的突增，使应用动态扩缩容。连接数、服务提供者的数，随着Pod数增加线性增长，大促前必须保证60%以内的水位。
云原生网关容量评估
提供 CPU 安全水位，推荐30%，最高不超过60%，由最佳实践决定。评估网关水位最直观的方式是按照CPU判断，建议30%，最高不超过60%。
参考集团内部的运维经验，网关经常有突发流量，对于电商业务，大促、秒杀，考虑流量攻击的因素，网关不能根据 CPU 跑80%、90%评估容量，一旦有突发容量，网关很容易被打爆。阿里内部网关比较极端，内部网关控制在10%以上。因素需要考虑，网关的突发流量是瞬时的，可能网关瞬间的 CPU 被打很高，监控平均后不高。对于监控的监控秒级、毫秒级能力非常重要，建议水位保持在30%，警界线是60%，到60%动态扩容网关。CPU 扛不住时，进行限流保护。
预案
为潜在或可能存在的风险，制定对应的处理方法。影响用户体验性能的开发，为观察用户行为的埋点与业务无关的功能，大促中需要关闭。与业务流量相关的预案，涉及到流控、限流、架体。发现故障时1分钟发现、5分钟定位、10分钟恢复，有预案，是一整套方法论。
第一点容量评估，第二点容量评估阿里PTS进行全链路压测，给Nacos、云原生网关的容量水位。预案重要性，可通过MSE服务器里的应用配置，方便快捷进行开关的配置，进行简单的预案。预案涉及到流控、限流、架体。
预热
预热可认为是计数容量的预案，预热限流。做预热与容量模型有关，面对大促流量模型是慢慢上升，慢慢下降。大促可能流量突然增长几十倍，进行预热非常必要，面对大促做很多预热，数据的预热、应用的预热、连接的预热。数据预热，访问数据时最远是数据库、缓存、内存。访问数据，数据的链路非常长，RT 非常长，不是好事，对于大促热点数据需要应用跃进，产生的效果越好，需要预测哪些数据需要预热。把量特别大的数据与数据相关的数据，比如电商购物车、卡券，数据进行预热，通过模拟数据库查询数据库，把数据库中数据缓存到内存中。很多应用通过缓存挡住，缓存失效可能被打垮，数据库挡不住大促的流量，需要把数据提前预热到缓存里，保护缓存。数据预热关键是需要减少有效数据或关键数据访问的链路，内存中读，没必要在缓存读，缓存读不应该在访问数据库中获取数据。
应用的预热，小流量服务预热、并行类加载。小流量预热相对一般场景，大促流量过来后扩容的流量 Pod，流量按均分流量扛不住，大促流量非常大。不可能像其它正常实例，平坦线上总 QPS，Pod 很容易被挡，需要调整预热的流量曲线，解决大促扩容流量机器的平滑补损。
应用预热
小流量预热可通过常规的QPS预热流程，调整曲线使预热曲线QPS慢慢增大，实现自身预热。
MSE 云原生网关做预热的效果，流量曲线开始很小，慢慢增大。开始云原生网关到后端微服务均支持小流量预热能力，可有效帮助在高并发的流量下，资源初始化慢，导致请求响应慢，资源堵塞，资源耗尽导致刚启用的 Pod 当机事故，小流量预热可有效解决问题。68机器刚扩容，与老节点相比相差很多，慢慢增大。
应用预热在双十一总结优化，并行的类加载，保护系统在启动、类加载过程。不开启类加载，当加载大流量数据、类，导致应用有多个线程同时调用 class 方法，进行类加载，锁的竞争非常激烈，导致业务的线上值被打满。MSE 通过无线路方式，类加载被加载前提前开启并行类加载，用户无需升级任何组件。
连接预热，建立连接需要提前建立连接池连接，不是连接进来后建立连接。建立连接本身非常耗时，大流量进来后导致大量业务线程等待流量建立，应用线程被打满。默认的 JedisPool 通过定时任务异步保证最小连接数的建立，应用刚启动 JedisPool 连接池没建立，MSE通过主动建连的方式，手动创建连接，保证微服务上线过程中，业务流量进入前，异步连接各种连接池，保证连接资源提前建立，保证连接的就绪。
无损上线
MSE 无损上线做到里面，Redis 数据库连接，异步建立，用小流量预热。
微服务预热情况如下
预热的原因，阿里有体系化产品功能的原因，无损上线、流量防护的预热模式等。预热保障系统在大促态稳定性中重要一环，通过预热帮助系统提前进入大促态，过程类似百米短跑。按照其它业务模式，自然来的业务流量都是长跑，短跑必须热身，没有热身可能在起步阶段抽筋，肌肉拉伤，导致输比赛。
流量控制
流量控制是保证微服务稳定性最常用、直接的手段，每个系统、每个服务都有承载的容量上线。当某个接口超过 QPS 后，拒绝多余的请求，防止系统被突发流量打垮。市面上最常见的方案是单机限流的方案，通过 PTS 压测，预估出某个接口的容量上线是100QPS，服务有10个实例，配置单机限流，流控10QPS，很多时候流量分布不均匀，流量分布有一定不确定性，单机限流存在效果误差的情况。负载均衡器不好，有些服务处理慢，有些服务处理快，导致流量分配不均匀。可能有些服务分配很大，导致服务被打垮，情况很常见。
提供在流量入口进行全局的控制，Nginx Ingress、云原生网关在入口处配置防护的能力，在入口处配置不能解决所有问题。
流量控制：防止突发流量将业务打垮
经典场景，大促秒杀，某个时刻激增的脉冲流量到达系统阈值，服务可能被打挂。
解决方案非常简单，流控能力相当于应用的一个安全气囊，只需配置MSE流量控制，超出系统服务能力以外的请求将被拒绝，具体逻辑可由用户自定义(如返回指定内容、跳转页面、执行指定的方法)，规则可以随开随停，实时生效。
可配合PTS的性能压测来评估核心接口的容量，提前配置好流控规则，先关闭，当流量达到阈值时，通过预案方式打开流量规则。流量低于阈值后可将流量关闭，所有规则随开随关，实时生效。
热点流控：防止热点流量将业务打垮/黑产刷单
用户行为不确定或安全问题、黑产刷单问题，过程中平时流量不大，某些商品流量特别大，突然出现黑马商品或直播突然爆火，导致系统稳定性，直播间都出现问题。
解决方式，通过热点参数流控能力，通过监控自动识别参数中的 Top N 访问热度的参数值，对参数进行单独流控，避免单个热点访问过载。参数可以是任意业务属性，可以来自调用端IP、RPC参数、HTTP请求参数、header等，支持自定义。
场景如下
服务并发隔离：保障调用端稳定性，避免级联故障
流量接近稳态时，并发线程数=QPS*RT，调用RT升高时，并发线程数升高，出现服务调用堆积。应用依赖的下游支付服务因网络抖动出现大量慢调用，没有隔离导致该应用的线程池全部被该服务调用占满，无法处理正常业务流程。可通过MSE实时监控和链路功能，帮助快速定位到慢调用和不稳定服务，准确找到应用变慢的原因，配置并发隔离的策略，保障应用的稳定性，把慢调用和正常调用隔离，慢调用不会影响到正常调用。
服务熔断与降级
场景一:业务高峰期，某些下游的服务提供者遇到性能瓶颈，保护自己，开启熔断。
场景二:为保护核心服务把资源保留给其它核心服务，把资源通过临时降级把弱依赖服务调用，无关紧要的需求、业务降级，业务流程受到影响时，为核心服务让路。所有东西保护重点业务，避免应用出现雪崩的情况，熔断不允许出现雪崩的情况。雪崩很可怕，崩时可能救不回来，应用一个个当机。
业务高峰期，某些下游的服务提供者遇到性能瓶颈，甚至影响业务。对部分非关键服务消费者配置自动熔断，当一段时间内的慢调用比例或错误比例达到一定条件时自动触发熔断，后续一段时间服务调用直接返回Mock的结果，可保障调用端不被不稳定服务拖垮，可给不稳定下游服务一些“喘息”的时间，可保障整个业务链路的正常运转。需要全局的视角，保障大促的稳定，不能因为个别服务不稳定，影响所有服务不稳定。
四、大促总结与意愿
最外面通过 PTS 进行全链路压测，对系统容量进行评估。在 MSE云原生网关侧配置弹性伸缩、流量防护、Waf 安全、小流量预热。后端应用通过 MSE 服务治理能力，根据应用容量进行流控，实时探测应用内部不稳定调用，及时隔离或摘除，自适应系统过载保护。下游依赖，资源型的网关做好容量评估，下游依赖做慢 SQL 治理，数据做好预热，缓存防止热点 key 击穿防护，避免缓存失效等问题。Naocs 服务端提供99.99%高可用防护，提供故障掩护发现 Naocs问题。
Naocs 出问题时，类似服务器推控保护等功能保障业务影响面降到最低。注册中心出问题，开启推控保护，正常服务调用依然正常，不会全部挂。通过服务治理的容量降级能力，自动探测不稳定的第三方服务，进行隔离熔断。
每次大促都是宝贵的经验，大促后不是平稳度过就结束，大促后需要做好总结与复盘，沉淀经验是必不可少的一环。收集整理系统峰值的指标、系统的瓶颈与短板、踩过的坑、做过的预案。
思考什么东西可以沉淀下来帮助下一次大促备战，让下一次大促备战无需从头再来，下次大促的用户体验是否能够更加丝滑。大促中大促流量、用户行为等不确定，将不确定性变为确定的事，大促是一个项目，备战的方法论是把大促不确定性变成确定性，通过方法论推动产品最佳实践配合大促成功。
通过大促考试锤炼系统，沉淀最佳实践。
