如何有效利用云产品为我们的业务推广做准备，是大家关心的问题。今天趁着 618 在促销活动到来之前，谈谈我们积累的最佳实践。
点击链接，立即查看视频解释：https://yqh.aliyun.com/live/detail/28697
大促销的不确定性挑战
上图是我们的业务地图。在促销期间，我们将遇到许多不确定因素的挑战，如流量不确定性、用户行为不确定性、安全攻击不确定性、研发变更风险不确定性、故障影响不确定性等。最好的方法是模拟和保护入口，但它不能解决所有的问题，所以它需要 IDC 进一步的内部故障演练和流量保护。
由于流量不确定，我们需要容量评估和业务评估来确定流量峰值，然后通过流量限制将流量转化为确定条件；用户行为不确定，需要通过模拟和多个场景模拟用户行为进行压力测试和演练，需要更真实地模拟，及时发现系统瓶颈和优化点，及时优化；安全攻击的不确定性，我们需要网关 waf 保护能力，例如，我们如何识别和限制流量，以保护正常用户的流量；对于研发变更风险的不确定性，我们需要限制不必要的变化，因为我们担心故障的不确定性，我们需要通过持续的故障演练来缓和系统，了解故障的影响，并尽可能控制问题的影响，避免系统雪崩问题；大促销是一个项目。准备方法论是将大促销的不确定性转化为确定性。我希望能为您提供一些方法论，并配合我们产品的最佳实践帮助您。
目标确定
大促销的目标有很多，比如支持 XX 30%的流量峰值 成本优化、用户体验流畅等。大促备战的目标在技术同学看来一般围绕成本、效率、稳定性。我们考虑成本 Nacos、云原生网关的资源成本，以及应用的机器数量，利用好 K8s 弹性能保证稳定性与成本的平衡；效率 PTS 全链路压测提供了开箱即用的全链路压测工具，最接近用户的仿真压测流量，能大大提高效率，同时 MSE Switch 在稳定性方面，MSE 服务治理提供端到端流量控制能力和弹性过程中的无损上下线能力，确保促销过程中流量平稳无损；同时，我们可以合作 MSE 全链路灰度能力的服务治理，利用测试流量预演全链路功能，尽快暴露问题点。
备战流程
简单地说，大促销准备过程需要关注以下四点：容量评估、计划准备、预热和流量限制。如果你做了以下几点，你可以把不确定性变成确定性，所以即使面对大促销的流量高峰，整个系统也会非常稳定。
容量评估
容量评估的目的是实现成本和稳定性的最佳平衡，因此我们需要在一定业务条件下确定应用程序的性能基线；另一方面，由于成本优化的目标，我们需要确定机器的成本预算。
- 通过性能评估和性能优化，确保应用程序的性能
- 评估业务变化和系统变化
- 根据业务模型评估，确定全链路压力测试模型，并进行全链路压力测试验收
- 评估容量的极限水位，保持 60% 打开弹性扩缩能力的容量水位。
首先需要通过 PTS 平台对服务进行压力测试，找出系统对外核心接口的服务能力和相应的系统水位。阿里云产品的压力测试和全链路压力测试是第一个 PTS。
PTS 与一般压测工具相比，具有以下优点：
- 全 SaaS 不需要额外的安装和部署。
- 0 安装的云录制器更适合移动 APP 场景。
- 数据工厂功能，0 实现压力测量的编码 API/URL 格式化要求参数。
- 复杂场景的全可视化安排支持登录共享、参数传输、业务断言，可扩展的指令功能支持多形式思维时间、流量蓄洪等。
- 独创的 RPS /并发多压测模式。
- 流量支持动态秒调整，数百万 QPS 也可以是瞬时脉冲。
- 强大的报告功能显示和统计压测客户端的实时数据，并自动生成报告供参考和导出。
- 压测 API/场景可调试，压力测试过程提供日志详细查询。
- 流量来自全国数百个城市（可扩展到海外），真实模拟最终用户的流量来源，相应的报告和数据更接近用户的真实感受。
- 压力能力没有上限，最高支持数千万 RPS 压测流量。
当性能压力测量系统瓶颈时，我们需要分层优化系统。
与之前(如有参考)的稳定性评估和业务趋势相比，每次大促销的评估是否有量级改玩法是否有变化，如 618 预售、抢红包、全减等业务游戏是否会对系统造成稳定风险，分析用户趋势，从全球角度看系统的关键路径，确保核心业务，梳理强弱依赖。
要启动性能压力测试，首先需要创建一个压力测试场景。压力测试场景包括一个或多个平行业务（即串联链路），每个业务包含一个或多个串行请求（即 API）。
风险识别和性能管理的目的可以通过压力测试来实现。通过全链路压力测试，可以提前发现系统的瓶颈，识别性能风险，防止系统的性能腐蚀。
- MSE Nacos 容量参考
评估 Nacos 我们可以从连接数和服务数来评估注册配置中心的水位。有些应用程序可能有大量的服务。此外，随着流量的增加，应用程序动态扩展 Pod 随着数量的增加，连接数和服务提供商的数量也会线性增加，因此可以提前保证 60% 内部水位是必要的。
- MSE 网关 容量参考
评估网关水位最直观的方法是 CPU 判断，建议 最高不超过30% 60%。为什么定得这么低？参考水位是根据集团内部网关的运维经验提供的。网关往往会有一些突然的流量，尤其是对于电子商务业务，如促销、秒杀等，以及流量攻击的因素，如 ddos 攻击等，网关不能根据 CPU 跑 80%、90% 这样评估容量，一旦出现紧急情况，网关就很容易被填满。阿里内部网关极端，网关 CPU 一般控制在 10% 以下。同时也有一些因素，网关突发流量一般是瞬间的，网关可能是瞬间的 CPU 已经被得很高了，但是平均监控后不是很高，所以网关的秒级监控能力也很有必要。
预案
总之，有意识地为潜在或可能的风险制定应对方案。
例如，许多影响用户体验和性能的开关，以及一些与业务无关的功能，如观察和分析用户行为的埋藏点。当我们推广它们时，我们需要通过计划平台关闭这些功能。当然，计划中也有一些与业务流量相关的计划，涉及流量控制、流量限制和降级。
预热
为什么要预热？这与我们的流量模型有关。大多数时候，我们的流量模型自然会慢慢上升。但事实并非如此。流量可能会突然飙升几十倍，然后保持并慢慢下降。预热应该预热什么？当时，我们做了大量的预热、数据预热、应用预热和连接预热。
首先，让我们谈谈数据预热。我们访问一个数据。它的数据链路太长。事实上，离应用程序越近，效果可能越好。首先，数据预测取决于如何预热哪些数据？首先，购物车、红包和卡券是与用户相关的数据，用于预热数据库。
- 模拟用户查询，查询此数据库，并将其数据放入我们的内存中。
- 许多应用程序被缓存堵塞。一旦缓存失效，数据库就会挂断，因为数据库无法阻止。此时，应提前将数据预热到缓存中。
预热数据的目的是减少关键数据的链接。如果你能读取内存，就没有必要读取缓存。如果你能读取缓存，你就不应该访问数据库。
与一般场景相比，刚刚发布的微服务应用实例与其他正常实例相同 QPS。小流量预热方法通过在服务消费端根据每个服务提供商实例的启动时间计算权重，结合负载平衡算法，控制刚启动的应用流量，随着启动时间逐渐增加到正常水平，帮助刚启动的运行进行预热 QPS 曲线随时间变化如图所示：
应用小流量预热过程QPS曲线
同时，我们可以通过调整小流量预热曲线来解决机器流量平稳无损的扩大。
应用小流量预热过程原理图
通过小流量预热方法，可以有效解决资源初始化缓慢引起的大量请求响应缓慢、请求阻塞、资源耗尽引起的问题 Pod 停机事故。值得一提的是 MSE 云原生网关也支持小流量预热。我们来看看实战的效果。 节点是刚扩容的例子。
JDK7 上，如果调用 Classloader.registerAsParallelCapable 方法，则会开启并行类加载能，把锁的级别从 ClassLoader 对象本身，降低为要加载的类名这个级别。换句话说只要多线程加载的不是同一个类的话，loadClass 方法都不会锁住。
我们可以看 Classloader.registerAsParallelCapable 方法的介绍
protected static boolean registerAsParallelCapable()Registers the caller as parallel capable.The registration succeeds if and only if all of the following conditions are met:1. no instance of the caller has been created2. all of the super classes (except class Object) of the caller are registered as parallel capable
它要求注册该方法时，其注册的类加载器无实例并且该类加载器的继承链路上所有类加载器都调用过 registerAsParallelCapable，对于低版本的 Tomcat/Jetty webAppClassLoader 以及 fastjson 的 ASMClassLoader 都未开启类加载，如果应用里面有多个线程在同时调用 loadClass 方法进行类加载的话，那么锁的竞争将会非常激烈。
MSE Agent 通过无侵入方式在类加载器被加载前开启其并行类加载的能力，无需用户升级 Tomcat/Jetty，同时支持通过配置动态开启类加载并行类加载能力。
参考材料：http://140.205.61.252/2016/01/29/3721/
以 JedisPool 预建连接为例，提前建立 Redis 等连接池连接，而不是等流量进来后开始建立连接导致大量业务线程等待连接建立。
org.apache.commons.pool2.impl.GenericObjectPool#startEvictor
protected synchronized void startEvictor(long delay) {
if(null != _evictor) {
EvictionTimer.cancel(_evictor);
_evictor = null;
}
if(delay > 0) {
_evictor = new Evictor();
EvictionTimer.schedule(_evictor, delay, delay);
}
}JedisPool 通过定时任务去异步保证最小连接数的建立，但这会导致应用启动时，Redis 连接并未建立完成。
主动预建连接方式：在使用连接之前使用 GenericObjectPool#preparePool 方法去手动去准备连接。
在微服务上线过程中，在初始化 Redis 的过程中提前去创建 min-idle 个 redis 连接，确保连接建立完成后再开始发布服务。
JedisPool warm-internal-pool 同样有类似问题，预建数据库连接等异步建连逻辑，保证在业务流量进来之前，异步连接资源一切就绪。
预热为什么要做。我们阿里云甚至有体系化的产品功能比如：无损上线，流量防护的预热模式等，因为预热是保障系统在大促态稳定性的很重要的一环。通过预热帮助我们的系统进入大促态，这个过程就好比于百米短跑。其他业务按照自然流来的都是长跑，但是短跑你必须得热身，没有热身，起步阶段可能就出抽筋、拉伤等大问题。
流控限流
流控是保障微服务稳定性最常用也是最直接的一种控制手段。每个系统、服务都有其能承载的容量上限，流控的思路非常简单，当某个接口的请求 QPS 超出一定的上限后，拒绝多余的请求，防止系统被突发的流量打垮。市面上最常见的方案是单机维度的流控，比如通过 PTS 性能测试预估某个接口的容量上限是 100 QPS，服务有 10 个实例，则配置单机流控 10 QPS。但很多时候，由于流量分布的不确定性，单机维度的流量控制存在一些效果不佳的情况。
场景：服务 A 需要频繁调用服务 B 的查询接口，但服务 A 和 B 的容量存在差异，服务 B 约定最多给服务 A 提供总共 600 QPS 的查询能力，通过流控等手段进行控制。
痛点：若按照单机流控的策略配置，由于调用逻辑、负载均衡策略等原因，A调用B到达每个实例的流量分布可能非常不均，部分流量较大的服务 B 实例触发单机流控，但总体限制量尚未达到，导致 SLA 未达标。这种不均的情况经常会发生在调用某个依赖服务或组件（如数据库访问）的时候，这也是集群流控的一个典型场景：精确控制微服务集群对下游服务（或数据库、缓存）的调用总量。
场景：在 Nginx/Ingress 网关、API Gateway (Spring Cloud Gateway, Zuul) 进行入口流量控制，希望精确控制某个或某组 API 的流量来起到提前保护作用，多余流量不会打到后端系统。
痛点：如果按照单机维度配置，一方面不好感知网关机器数变化，另一方面网关流量不均可能导致限流效果不佳；而且从网关入口角度来讲，配置总体阈值是最自然的手段。
MSE 服务治理流控降级提供了以下特性：
1、专业的防护手段：
- 入口流量控制：按照服务容量进行流量控制，常用于应用入口，例如：Gateway、前端应用、服务提供方等。
- 热点隔离：将热点和普通流量隔离出来，避免无效热点抢占正常流量的容量。
- 对依赖方隔离 / 降级：对应用和应用之间、应用内部采用隔离 / 降级手段，将不稳定的依赖的对应用的影响减至最小，从而保证应用的稳定性。
- 系统防护：MSE 应用流控降级可以根据系统的能力（例如 Load、CPU 使用率等）来动态调节入口的流量，保证系统稳定性。
2、丰富的流量监控：
- 秒级流量分析功能，动态规则实时推送。
- 流量大盘编排，核心业务场景了然于胸。
3、灵活的接入方式：
提供 SDK、Java Agent 以及容器接入等多种方式，低侵入快速上线。
MSE 服务治理的集群流控可以精确地控制某个服务接口在整个集群的实时调用总量，可以解决单机流控因流量不均匀、机器数频繁变动、均摊阈值太小导致限流效果不佳的问题，结合单机流控兜底，更好地发挥流量防护的效果。
对于上面的场景，通过 MSE 服务治理的集群流控，无论是 Dubbo 服务调用、Web API 访问，还是自定义的业务逻辑，均支持精确控制调用总量，而无关调用逻辑、流量分布情况、实例分布。既可以支撑数十万 QPS 大流量控制，也支持分钟小时级业务维度小流量精确控制。防护触发后的行为可由用户自定义（如返回自定义的内容、对象）。
通过开启 MSE 流量防护能力，根据压测结果中不同接口和系统指标配置限流、隔离以及系统保护等规则，在最短的时间内接入并提供持续提供防护。碰到一些特殊的业务场景比预期的流量要大的多的时候，通过提前配置流控规则，及时地将多余的流量拒绝或排队等待，从而保护了前端系统不被打挂。同时，在一些核心接口也出现了突发的响应时间增大的情况，下游服务挂掉导致从网关到后端服务整条链路 RT 飙高，这时候利用 MSE 实时监控和链路功能快速定位到慢调用和不稳定服务，及时进行流控和并发控制，将系统从崩溃的边缘拉了回来，业务迅速回到正常水平。这个过程就像“给系统做心脏复苏”，可以有效保障业务系统不挂掉，非常形象。
大促中我们还要防止热点流量，一些“黑马”热点商品，或者一些黑产刷单流量超出业务预期的流量进入我们的系统后，很可能会将我们的系统拖垮，我们通过热点参数流控能力，可以将热点用户、热点商品的流量控制在我们业务模型预估的范围内，从而保护正常用户的流量，有效保护我们的系统稳定性。
我们都知道当流量近似稳态时，并发线程数 = QPS * RT(s) ，当我们调用的下游 RT 升高时，那么并发的线程数将会飙高，从而出现服务调用的堆积。这也是大促中常见的一个问题，因为依赖的下游支付服务因网络抖动出现大量慢调用，导致该应用的线程池全部被该服务调用占满，无法处理正常业务流程。MSE 实时监控和链路功能可以帮助我们快速定位到慢调用和不稳定服务，准确找到应用变慢的根因，并对其配置并发隔离策略，可以有效保证我们应用的稳定性。
雪崩是很可怕的一件事情，当它发生时，我们连救都救不回来了，只能眼睁睁地看着应用一个个宕机。因此在业务高峰期，某些下游的服务提供者遇到性能瓶颈，甚至影响业务。我们可以对部分非关键服务消费者配置自动熔断，当一段时间内的慢调用比例或错误比例达到一定条件时自动触发熔断，后续一段时间服务调用直接返回 Mock 的结果，这样既可以保障调用端不被不稳定服务拖垮，又可以给不稳定下游服务一些“喘息”的时间，同时可以保障整个业务链路的正常运转。
大促的总结
每一次大促都是一次很宝贵的经验，在大促后，做好总结和复盘沉淀经验是必不可少的一环。我们需要收集整理系统的峰值指标，系统的瓶颈与短板，以及踩过的坑，思考哪些东西是可以沉淀下来帮助下一次大促备战，让下一次大促无需重头再来，让下一次大促的用户体验可以更加丝滑。
大促还有许许多多的不确定性，大促流量和用户行为是不确定的，如何将不确定性风险变成相对确定的事情？大促是一个项目，备战的方法论是把大促不确定性变成确定性，通过方法论推动产品最佳实践配合大促成功，同时也通过大促这场考试，锤炼我们的系统，沉淀我们的最佳实践。在这里祝大家 618 大促考试顺利，系统稳如磐石。为了用不停机的计算服务，为了永远在线的应用业务，Fighting！