双11大促资源保障如何做到万无一失？优酷的技术和实战经验详解-InfoQ

一年一度的双11天猫晚会，对于整个阿里文娱，尤其是优酷的技术人，就是一场年度技术大考。资源保障又是其中的重中之重。笔者连续三年负责猫晚、春晚、双11的资源保障及全站稳定性工作，下面就分享下优酷在大促中的资源保障的技术策略和实战经验。

一、前言

资源保障一直是大促中的重中之重。

如何把大促资源保障做到万无一失，归纳一下一般需要关注以下几个能力点：

资源需求收集上报渠道。要有稳定的历史数据可查的用户友好的平台支撑。
单机能力。单机能力是衡量应用性能的关键指标，无法精确测量的话，那么将是资源保障的大风险。有一个误区，单机能力测量时，CPU利用率，内存使用率，Load,磁盘利用率，网络使用率，并不是关键指标，业务RT和成功率，才是测量单机能力的关键指标。
业务目标到技术目标转化逻辑。业务目标一般指日活，月活，会员拉新，暴光率真，PUV，同时在线等指标，技术目标一般指QPS，TPS等衡量应用处理能力的指标。两者间的转化，需要结合历史数据，BI数据分布（例如二八法则：80%的DAU是产生在20%的高峰时间段），业务场景，用户行为等一系统因素后，制定出一个转化公式或者逻辑。
各个业务的上下游依赖和流量平衡关系。关注上游的一个请求，下游会被调用几次，下探深度是多少，特别是下游依赖被多个上游业务调用的场景。如果一个请求，会调用下游2次，那么流量就是1：2，简单来算当上游扩容1倍时，下游需要扩容2倍。
资源需求合理性评估。全部人肉评估显然人力和时间上都不允许，怎么样实现一个线上平台可以自动评估，来代替繁杂且重复的工作，快速给出合理的结论。这是中台能力应该追求的目标
资源交付效率。当扩容机器数成千上万台时，如何快速地将这些机器扩容上线，有资源需求调整时，又能快上快下，完全自动地去实施。
紧急支援。当所有的资源都用完时，又出现紧急资源需求的场景，应该怎么应对。是不是能够快速地大批量地从非核心的应用中借挪资源给核心应用？这也是考验中台能力的关键。

二、目标

有了上述对关键点的梳理，那么一套服务于大促资源全生命周期保障的平台系统就应运而生。确定目标如下：

需求收集-单机能力评估-历史活动数据对比-工单生成-批量扩容执行-压测调整-结束资源回收，全链路100%平台化流程化；
单机压测能力覆盖所有大促应用，实时提供最精准的能力数据；
资源健康度巡检，低水位低利用率低QPS应用数据输出，自动资源回收，提升资源利用率
非核心应用资源动态支援能力，10分钟1000台回收交付能力。

三、需求细化

整体能力分为两个大类：资源需求线和资源保障线。

资源需求线总体流程
明确需求收集范围->改进需求收集方法->实现单机能力自动获取->实现历史容量数据自动获取->应用上下游依赖链路自动获取-> [业务目标->技术目标转换]->完成资源需求评估
这样，基本上可以实现需求上报渠道能力，单机实时压测能力，目标转化能力，上下游链路及流量平衡自动评估能力。
资源保障线总体流程
建设整体资源容量盘点能力->建设应用级别线上水位巡检能力->优化资源快速交付/调整能力->建设非核心应用应急容量挪用能力 ->快速回收资源 ->完成闭环的生命周期
这就可以实现高效交付，强化资源盘点及buffer保障的能力。

四、具体实现细节

资源需求线实施过程

第一，要解决的资源需求收集范围，明确哪些应用是大促应用，哪些应用需要扩容。

我们通过整体历史资源需求汇总表，查询历史扩容工单，历史大促期间的扩容记录找出大促应用的范围。同时数据全部入库，以便后期使用。如下图需求汇总：

第二，要解决没有线上提交需求的痛点。

我们收集了集团大部分需求提交平台的实现方式，主要归纳为以下几种：

提供统一的资源需求填写模版（Excel），填写完成后把文件上传上去，系统自动check后入库；
给出在线表单，用户在线提交完成后入库；
利用百搭等公共平台，制作模版，通过内外任务提交后，汇总数据导出再导入自有平台。

各有个的优缺点，我们评估后，确定融合在线表单和内外任务填表相结合的方式，自行开发一套类似于问卷调查系统，将所需要的数据通过系统收集，给出统一的填写模版，同时支持钉钉消息，邮件，内外任务的方式进行催促。

从实际使用情况来看，通过内外任务的方式进行催促，填写率可以达到 100%。如下图需求收集页面展示：

第三，单机能力探索的实现。

收集方式确定后，就是透出的内容了。其中每个应用的单机能力以及历史参考数据就是接下来要攻克的。

单机能力：一般指单机 qps，在 RT 和成功率满足业务最低阀值时，可以接受的最大 QPS。一般 CPU，load，网络，磁盘等指标不为作为核心衡量标准。

单机能力的准确性和真实性，直接影响了系统资源评估结果的可信赖度。如下图单机能力的探索功能页面：

线上单机压测能力功能实现如下：

通过引流线上真实流量至被压测机上，观察指标变动情况，记录拐点值前一刻数据，即认定为单机值；亮点是平台能够算法实现对指标的定义和参数的智能探索；整个过程可以傻瓜式一键操作；同时也支持自定义，包含了常见的单机压测能力。
压测关键在于怎么确认业务可以接受的RT及成功率指标，如果都设置一个默认值，则真实性经不起推敲。
我们通过智能探索算法，通过线上日常流量的观察分析，自动识别拐点；
同时也支持手工配置，允许自定义阈值：不限于CPU使用率、MEM使用率、HTTP响应时间、微应用接口响应时间、HTTP成功率、微应用接口成功率；
配置定时执行后，可以自动执行压测，并获取到最新的单机能力值。

简单总结可以支持的几种方式：

日常：通过引流的常规单机压测方案。
通过自定义的探索配置，自动截获单机性能瓶颈，自动停止单机压测，并记录。
智能：含日常功能外，针对无法截获瓶颈、未发现瓶颈的，使用智能预测来代替。
全链路模版导入：可通过二方压测平台全链路模版通过其任务ID导入，导入结果会折算成单机能力；
回溯导入：可直接通过回溯时间区间进行导入，导入结果会折算成单机能力；

第四，历史容量水位统计与匹配展示的实现。

历史容量水位 QPS 信息的获取，一般查集团监控平台或者应用监控平台，但几百上千个应用一个个查也不是办法。所以，又增加了活动水位的功能模块，把大促活动范围的应用的分钟级实时数据，通过集团监控接口或者应用监控平台接口拉取到，并整理入库，实现整体观看，排名，历史回放等能力。并截取活动时段内的峰值，做为参考数据透出到前端。需求汇总如下：

第五，上下游链路的获取和流量关系输出能力。

接下来就是上下游链路的获取和流量关系输出能力了。

实现原理：

通过检查负载均衡的缓存的域名列表可以拿到业务的IP列表。通过负载均衡的IP列表查询IP地址对应的机房和当前机房进行比对，确定是否存在跨机房调用(负载均衡不论使用了DNS-F客户端或者JAVA客户端都有缓存的列表)
通过微应用接口的配置来获得对应的对端业务的IP地址列表。同样通过IP地址列表我们可以得出上下游调用方信息。
通过读取配置下发平台配置来获得对应缓存的配置信息，拿到缓存的接入入口IP，从而获得缓存相关的调用链路
使用数据库客户端的可以通过读取应用监控平台的配置文件来获得数据库的入口IP从而确认DB调用链路。使用非数据库客户端的应用可以从负载均衡的缓存域名列表中拿到对应的数据库降低了故障风险。
再配置应用监控平台接口，可以知道哪些应用之间发生了交互，应用可以拿出自己发起通信的应用列表然后上报，获得各个应用之间的调用关系。从而可以画出一个应用之间的内部调用的图，统计IP数量，可以得出大致的调用比例，从而得出流量关系。