活动场景重要、高频、复杂，基本都会涉及营销预算 - 资金，业务风险、资金风险、高可用风险一直以来都是活动质量领域的重要命题。

蚂蚁集团技术风险部技术专家罗钊老师的这篇技术分享，一起来看看！

罗钊 技术专家

讲师介绍

主要负责支付宝营销大促活动技术风险保障（高可用）工作。主要研究领域：大促营销活动平台化建设（流程智能化、容量仿真），类营销领域高危风险 (预算、配置) 的解决方案构建与架构。2016 年加入蚂蚁集团，先后在商家平台、技术风险部从事研发和技术方案架构工作。

以下内容根据罗钊老师在 TesterHome 社区与支付宝质量技术主办的测试之美系列《支付宝活动保障 - 高可用》主题技术沙龙直播现场所讲内容进行精简整理，大约 5400 个字左右。

一、活动高可用背景介绍

其实大家也应该都能感知到，就是不同公司都有各种比较强烈的一个运营营销的诉求，这个其实就带来一个问题，就说可能整个活动保障的一个短频快一个特点。

比如说月度大促、季度大促、年度大促等，这个时候其实对我们整个的一个活动保障的资源方面会有比较强的周期性的诉求。然后同时带来了一个保障的问题，就是我们怎样以低成本支持这种资源的快速的一个伸缩。

然后第二个问题就是每一个活动都会有自己的特色，但其实或多或少都具有一些相同点，比如说在固定的时刻去制造一些明显的一个流量峰值，这个在活动一个特点里面体现就是说它的尖刺流量场景多，面对尖刺的这种场景流量我们如何去做有效的压测、限流，怎样做到更真实更兜底。

第三个业务特色就是整个活动保障面临的角色特别多，面临的团队也比较多，整个保障阶段也比较多，面临这种多角色多阶段保障的协同层面的话，特点就是协同复杂度高，同时给我们保障带来了一个难题，就是我们怎样去在整个活动保障过程中进行多角色协同。比如说我们是不是可以定一些标准化的流程，建设一些系统化的能力。

二、打法分解

打法介绍：秒杀类场多

然后下面的话其实会对整个这个我们保障人的问题进行一个分解，然后一一拆解我们怎么去应对这些问题。

首先针对秒杀类的场景，怎样去防控，大家其实可以看到在上图左边，是我们刚刚结束的夏促活动中的一个业务场景，它其实是一个这种偏秒杀性的这个场景，比如说我们在每天的早上个 8 点或者是中午 12 点，我们会固定去放一批预算来让大家去抢，针对这种秒杀性的场景，其实是对我们整个系统的一个容量要求还有整个的兜底防御能力是有很高要求的。

中间这张图是模拟了一个通用型的秒杀环境，它大概的一个这种系统联络是一个什么样子，大家可以看到就是不同的用户通过一个前端入口来进到我们的一个网关层，然后网关层再穿透到下面的后端的一个服务端，然后再去经历一些缓存、DB，然后做整个的一个系统链路与贯通。

在这个秒杀场景里，有三方面的重要信息是需要关注，第一是秒杀容量，第二是怎样能够让秒杀压测更真实不失真，第三是做好容量和压测之后怎样去做秒杀限流。

如果说我们真的如果说啊有一个环节，就拿中间那个图来说，如果有一个环节的一个限流配错了，或者没有完全按照配置来推送的话，那么可能会带来一个非常严重的（问题），大家都知道秒杀时刻的容量其实是非常大，可能直接就把我们的系统节点给击穿了。

打法介绍：压测仿真

怎样让压测变得更真实，更符合业务链路，大家可以看到下图左边的两张图，链路 1 有两个分支链路，链路 2 相比链路 1 少了一个节点并且多了一条链路，多了一个应用 D。

我们对整个的链路 1 和链路 2 的调用流量占比进行拟合度的分析，就能够更完整地揭示实际压测的流量链路和实际的业务链路的差异来保证整体压测不失真，比如我们应用当中还有哪些节点缺失或新增，能够直接去保障我们整个链路的一个这种真实性，保障链路真实性，其实对于压测来说是一个非常重要的一个目标。如果压测有失真，那其实你可能就是按照这种失真的链路去做容量的供给，然后同时做对应的一个限流。当真实的业务上线就可能会带来我们某一个实际这种分支链路没有评估到，带来这种水位准备不足呀、限流配置过低等等，直接就把整个业务模块给打爆了。

其实我们在整个活动当中，或多或少也会遇到这种压测失真这种情况，但通过我们整个的一个这个压测仿真，对不同的链路进行聚合拟合，流量的占比进行拟合，来去更好地让我们压测能够很高比例的去拟合实际的生产链路。

打法介绍：容量资源动态高效伸缩

然后下面再给大家介绍一下刚才提到活动保障里面的一个问题，由于活动的周期很短，就是每个月、季度都会去举行大促，其实对于整个活动的这种应用资源，不管是 APP 的资源，或者说是一些 cdn、网络、DB 的资源，都有一个这种比较强周期的要求。

那这边我会介绍整个我们蚂蚁两项比较有那个代表性的一个技术，我们怎样去高效低成本的去调度我们这块资源：

1.分时调度资源

先给大家介绍一下分时调度，顾名思义它其实就是将具有不同高峰期的业务，利用我们的一个分时调度的技术，将不同的业务容器部署到同一个容器上，然后通过错峰使用这一个容器资源，来达到整个资源的弹性的一个极致的伸缩，同时这个成本也是很低的。

大家可以看一下，在上图的左边，部署了森林业务的一个应用，另外也部署了活动业务的一个应用，再比如说在早上的时候森林业务其实处于一个这种大量使用态，但是活动业务只处于一个保活态，保活态意思就是它会占用非常少量的资源去做，实际功能承载可能占 1% 到 2% 不到的资源。

但比如到了晚上，森林的峰值已经过去了，但是我们实际的活动的峰值到来了，这个时候我们通过我们的 CPU share 的一个技术 memory share 的一个技术，把保活态的一些活动应用把它转换成激活态，这个时候它就可以享用更多的 CPU 以及更多的内存，但同时森林业务就变成了激活态，占用少部分的一个资源就能够支撑它的一个低峰期的业务水位。

通过分时调度这种技术化，能看到当我们可以在全天的一个时段都把整个这个应用服务器或者说我们整个容器的资源利用率达到比较高的状态，这就是分时调度大概的一个产品设计。

2.弹性容量

弹性容量这个其实也比较好理解，就比如说不论是活动链路也好，还是应用链路也好，中间总是有一部分资源我们可以按照垂直的业务视角来进行伸缩，因为我们不可能把整个链路资源做大量的常态备用，这对资源来说是比较浪费的。

然后我们通过弹性的技术，比如说我们把整个活动链路中某一块比较耗资源的应用或者服务器把它摘出来，然后把它去弹出到云上，然后在云上我们进行资源的使用，这样我们可以做到当活动结束及时把资源缩回来，做到一个即用即走，然后通过弹性以及分时，其实是可以很好地解决周期性活动对资源的周期性强诉求这种特殊的应用场景，还可以很好弥足整体活动中的资源需求。

打法介绍：保障协同

对于活动保障来说，涉及到的角色非常多，从整个活动流程的阶段来说，涉及到运营同学、质量同学、SRE，还有一些三方保障以及研发同学。这些不同的角色，在整个活动保障不同的阶段要承担的任务其实都是不一样的。

这里我举一个细化的视角，比如说站在 SRE 的视角，他们怎么样去做，比如说在活动保障中去建一些系统化的能力、系统化的输出，我这边拿活动指标来举例，看一下我们是怎样进行自动化的拆解。

大家都知道我们在活动保障中，一个比较重要的保障内容，就是我们怎么样去定义活动大概能够支撑什么样的量级。比如说我们对外的承诺的量级是多少，以及这个量级他穿透到我们活动中这个场景，大概能够是一个什么样的一个穿透比例，然后这个里面其实我们也会建立一些这种系统化的能力，然后这次比如说我们会做一些活动那些这种自动化指标一些拆解。比如说我们定义好整个活动的一个大的一个入口指标过后，然后我们按照流量转化的一个比例以及估算，是可以能够计算出活动一个链路穿透的一个流量的比例，同时也能够把整个这块指标所带来的资源上面的需求同时也给计算出来。

通过我们这一套自动化的指标拆解分析之后，可以让我们整个活动指标拆的更准，估算的更准，同时也让我们的整个活动指标拆解这个专项的效能变得更高。其他这些专项，比如说活动一些压测、限流预案其实我们也都会去建立对应的一个系统化能力。

整个保障协同层面，其实我们最想说的一个事情就是我们的保障服务总线，通过我们建立这一套保障服务总线，可以将我们整个活动保障流程中各个节点进行标准化的定义。比如说我们将不同类型的活动进行拆分，每个活动大概有多少保障节点，每个节点能够拆分多少保障动作，进行节点的固化。

然后另外一块就是针对不同保障阶段的保障节点进行服务化能力建设，建立自动化的任务去执行，比如说我们那些这种限流的一些这种托管，预案的一些这种自动化演练的来串联整个我们稳定性，保障阶段的一个各个角色之间的工作，来去比较高效
系统化来推进我们那个整个的保障工作进行。

然后上面是也介绍了整个的容量资源的一个伸缩，还有就是我们整个的压侧的仿真，然后最后会是另一个保障协同，然后最后部分就是说针对于这种高可用保障工作，然后做一个简单的一个总结。

三、活动高可用保障总结

• 通过仿真压测、分层限流、库存扣减异步化实现活动秒杀场景的高可用保障；
• 分时调度、弹性资源调度等手段实现高效资源伸缩能力；
• 标准化保障流程、系统化推进保障节点等方法实现保障协同；

因为稳定性保障在整个活动保障里是复杂度相对比较高的专项，也会占用大量人力资源。面向未来，如何让稳定性保障整体效能更高，耗费资源更少，是未来我们需要去演进的一个方向。

另外，智能化压测、无人值守压测，以及让容量的伸缩转换变得更智能自适应，也是未来我们思考的方向。

问答时间：

问题一：压测的智能化方面，可以简单聊一下思路吗？

回答：压测智能化也是我们重点建设的一个方向，因为压测在我们活动保障稳定性专项里时间占比是比较高的，我们现在也在探索一些技术方向。

比如在整个活动里，我们会分为各种各样的场景，场景 1 它有一条自动化的一些链路，然后场景 2 也是自动化链路，不同链路所承担的容量配比是不一样的，然后我们在压测平台上通过起一些定时的造流流量，然后衍生到我们刚才说的比链路 1、链路 2，去放不同的流量承载，通过对应的流量发起、流量穿透，来能够整个自动化地去做比如场景编排、流量执行，以及压测过程中预警容断机制、监控机制，以及压测完成后进行整个的压测报告、压测达标线的这种分解，来让我们整个的压测面向智能系统化或者无人化。

其实整个的核心思想就是我们怎样去对场景进行编排，怎样对流量进行自动化的发起，以及在压测构成中怎样对风险进行感知熔断，最后一块就是怎样对压测进行达标性的报告总结，比如说我们的水位怎么样，我们依赖的资源怎么样，我们整体的业务目标有没有达到等这几个方面。

问题二：智能化之后，是不是还要再去进行手动的压测，来确保智能化是否正确？

回答：这个其实我理解它是一个阶段性的一个问题，比如在初期，我们自动化的水平或者说我们系统化的水平不是那么高，可能是半自动化半人工。比如说系统化产出报告之后，我们人工可能需要做验证性 confirm 一个机制，来看整个压测的目标以及压测链路的仿真性，以及整个压测期间系统水位的一些判定。

当然长远来看的话，发展到一定阶段，如果我们自动化压测水平确实能够比较高效地去造流、执行压测以及高效地报告的产出，我理解这块是可以往无人化的方向去走的。

问题三：高可用和压测，流量的仿真是很重要，那我们是用什么样的手段去保障流量的仿真度呢？

回答：我们大概的一个实现思路怎么样，其实在整个活动里面，一个非常重要的关注点是，我们可能不仅仅需要关注活动场内的流量，因为对于一些公用链路或者说公用服务来说，可能不仅仅把他自己的服务暴露给我们的活动来使用，可能更多是作为一种全站基础性的服务。

比如一些营销场景、合约类的场景或者会员类的场景，它的服务可能不仅仅是给活动来用，还会有一些日常其他的业务来使用，这个时候我们就需要去分析出不同的公用服务，对整体的活动流量供给大概是什么样的比例。

除了活动流量场景之外，我们内部也有一种技术可以进行造流，去模拟其他业务流量，来对整体活动流量进行补充。比如说我们想压一个中心化的服务，可能要模拟其他场景的流量来进行介入，叠加到我们的活动场景，对整个服务达到尽量真实性的调用。当然不是直接叠加，比如说我们活动流量是 100，其他的服务是 200，这个时候我们不仅仅说直接把这个流量进行相加，而是要进行全链路场景的流量仿真。

问题四：高可用它范畴是比较大的，比如说强弱依赖或者说缓存，那除了性能压测我们还会做哪些事情来保障高可用呢？

回答：性能压测只是看我们整个系统的能力水位大概是处在一个什么样子，其实从整个高可用的保障视角来看，或者从传统运维的视角来看的话，它其实分为 4 个部分。

就是说我们从容量的视角去看，我们整个系统的水位是怎么样，另外一块就是做好容量之后要进行一个比如限流配置。

比如我刚才举了一个例子，对于一个典型的秒杀场景，做好容量的供给其实还是远远不够的，怎样在整个秒杀场景的流程中做好不同层次的限流，怎样在入口做打散，怎样在网关层做限流，怎样在服务端与 DB 层面加缓存。另外比较核心的一些技术，比如说真正的这种秒杀场景大部分都要采用这种异步化的技术，怎样采用订单异步化，还有就是说这种库存扣减的异步化，其实也是整个保障我们高可用的一部分。

问题五：在整个压测的过程中，各个角色的协同是什么样子的，特别有人在问就是业务 QA 业务测试在稳定性中主要做哪些工作？

回答：首先压测也是一个偏协同性的工作，因为我们要做肯定是做全链路的压测，全链路就会涉及到整个业务系统，而业务链路肯定不是只有一个应用或者只有一个服务，肯定是这种贯穿式的，所以我们整体的协同有一套标准的流程。

我们在全链路压测过程中，通过标准化的流程，把大家所负责的不同工作进行任务化的串通，让大家知道整体的启动模式是什么，压测的标准是什么，压测过程中应急机制熔断机制是怎样的。

然后在业务 QA 方面，因为它其实更接近于实际的业务场景，我们整体比如脚本的编写、脚本验证、起量，其实都是我们与 QA 这边一起来协作进行。

比如实际稳定性可能更关注压测过程中容量资源不够，我们去推动解决，比如涉及到业务上面压测阻断性的问题，可能是我们可以在这边一起去共同去解决这一块，那其实就是业务 QA 其实真正的发起者，因为他对业务最最了解，对各种各样的这个分布、还有这个监测他可能会更加的有专家经验。