背景
随着大促期间二方App与主App之间相互联动越发紧密，以及直播带货的热度不断攀升，大促的期间经常会遇到二方App流量唤起主App和站外拉端流量叠加的峰值，而主App的启动过程中会触发启动相关的众多业务，这些业务的流量在一瞬间会进行叠加到达网关层，对于网关层要面对的是数倍乃至十数倍拉端启动的流量，而网关层关系整个后端服务的入口稳定，因此保障拉端启动网关至关重要。
图1.一个完整的外链拉端流程
保障方案
1、收集唤端来源
每次大促期间流量的来源都是多方的，因此需要提前收集各方流量的量级，以及流量比例，由于各方流量来源的唤端形式略有不同，因此在压测时需要确保按照各方的流量比例进行模拟
图2.某年大促的拉端流量占比
2、分析冷热启动比例
针对全网App启动的埋点分析android和iOS的冷启动以及热启动的比例，这也为我们后续预估各个流量接口比例提供了参考的依据，最终分析完后，大概是一个这样的图：
图3.冷热启动占比
3、梳理启动API
针对启动过程中5s内全网发出的请求所有的API进行收集，逐一进行筛选，分析是首页调用还是启动调用，由于android和iOS的启动框架不同，因此对于不同类型的启动最终也会影响到我们流量的计算。
图4.启动接口API的梳理
4、计算放大系数
放大系数为一个拉端流量到达网关层的流量的倍数，这里只需要知道启动有多少接口会被调用即可，由于不同API在冷热启条件下被调用状态不同，同时在android、iOS拉端是否会调起中间页都会影响到。总结下来，公式如下：
冷/热启动调用次数 = iOS是否调用 * iOS比例% + android是否调用 * android比例%
放大系数 = ∑（ 冷启动调用次数 * 冷启比例% + 热启动调用次数 * 热启比例% ）
5、全链路压测保障
分析得出了接口、流量、比例等信息后，我们就可以开始我们的拉端全链路压测，下面是全链路压测的计划：
图5.拉端压测安排计划
拉端验收标准
【限流表现】流量达到限流值时，单机限流生效，端上表现正常，可正常启动，⽆空窗等问题
【脉冲验证】130%状态下持续10分钟，流量降低后，系统无任何hang住问题
【资源利用】脉冲和摸⾼期间，cpu利用率不高于55%，load < 2*cpu
6、日常限流
这里需要强调，大部分的拉端峰值很有可能不在大促的峰值，因此在拉端期间不会开启网关层的限流，这也就需要我们的各个启动应用配置相应的 应用内限流，这也是我们压测要重点验证的一个能力。
图6. 大促态机房部署情况
7、降级、预案
虽然大部分的拉端峰值为非大促，因此业务理论上来说是不会降级的，但是如果遭遇大促峰值和拉端峰值叠加的情况，各个业务还是需要确保自身有降级和兜底的预案，确保万无一失。
8、常态化保障
在完成上述过程的梳理后，我们便对拉端的流程有了清晰的认识，虽然流程较长但是不复杂有迹可循，且随着直播等场景的越来越频繁日常化，因此无论从还是技术层面，我们都继续常态化的保障方案。目前我们已经完成常态化保障的一期，即自动分析启动接口，自动判断启动次数，从而计算放大系数，并且针对当前接口的保障能力进行统计，确保在安全流量水位的情况下，我们的网关不会有重大的风险。
图7.拉端常态化保障平台