爱奇艺全链路压测探索与实践

开展全链路压测我们主要从几下方面进行了探索与实践：

• 核心链路梳理，明确压测目标链路和分支链路，排除压测风险；
• 压测环境准备，压测全链路能够透传压测标识并正确处理压测流量；
• 流量构造，结合真实的数据和需求策略分析制定压测流量模型；

• 执行与保护，实施前做好业务验证，按计划实施，做好监控和复盘。

核心链路梳理将多个业务线串联到一起，在实施过程中，我们由各业务团队梳理自己的核心链路，明确对下游服务的依赖，同时梳理出旁路依赖。将各业务线的核心链路进行汇总，得到最终的压测全链路。核心链路中可能会耦合外部服务但又不能参与压测，比如支付系统依赖的第三方渠道。在实践中我们通过自建渠道mock服务支持了多种渠道的支付请求，同时模拟渠道的支付成功率，支付回调延迟，支付通知等，形成支付全链路的闭环。

旁路依赖的梳理也是重要的一环，准确全面的梳理是后续顺利进行压测的保障。旁路依赖根据实际业务情况评估，如风控系统我们进行了mock，账务服务通过消息组件实现了服务降级。

核心链路依赖的环境除了业务的服务器外还涉及数据库、消息、缓存、日志等，在这一阶段我们主要对以下几点进行了考虑和支持：

• 压测标识透传

• 存储数据隔离

• 消息

• 水位

核心链路上可能会有很多技术组件要支持压测流量，原则和方案都是类似的，根据实际业务情况做好数据隔离即可。如Redis可以使用影子key或者影子集群，MongoDB使用影子collection， ElasticSearch使用影子索引，日志新建影子目录。下图是爱奇艺的支付系统在全链路压测环境准备好后，核心链路对压测流量的处理情况：

单接口压测时我们会提前生成好一批符合接口规范的数据备用，但这种数据过于单一，并不符合真实的业务场景。比较理想的方式是在网关层抓取生产环境的日志数据进行二次处理后对流量进行回放。我们在初期的探索阶段并没有实现这种方式，我们对已有的数据和接口调用量进行分析，结合业务策略对数据模型进行调整，得到最终的压测模型。例如在支付业务的全链路压测中，我们通过数据分析得出用户在生产环境中选择各支付方式的占比、各服务调用占比，同时结合业务策略对用户购买指数的影响，微调收银台转化率，最终确定下单服务、渠道通知、订单查询等服务调用量配比模型。

执行压测前，对全链路进行业务和环境验证是必不可少的，各业务确保压测旁路已做好降级和数据隔离，保证压测流量不影响正常业务数据。

监控是全链路压测实施过程中评估系统健康的重要手段，帮助我们发现问题，及时止损。在压测过程中我们事先准备了以下维度的指标：

• 核心链路服务调用量，成功率，耗时；
• 消息积压监控，redis水位、命中率，数据库负载等性能指标；

• 机器的基础指标。

各业务负责人需要在压测前做好自身的限流和降级，同时还要为正常的业务流量预留安全的buff，不能完全依靠压测平台的熔断条件。压测也会检验我们的限流值是否合理，降级预案是否能正常执行，是否符合预期。

全链路压测能力打通后，我们主要基于以下两个方面实施了全链路压测：

支付团队与直播、票务等团队在营销、抢购活动中进行全链路压测，以满足业务需求容量为目标，有效定位全链路中的短板服务，通过扩容、异步化、降级等方式处理，保证了全链路的容量达到预期目标。同时对限流、降级策略进行验证，保证业务在高峰时的可用性。

• 虚币消费压测

• 混合压测

在整个全链路压测实践中涉及到的需求点很多而且分散，如数据模型、流量调度、监控跟踪、性能分析等，很多细节处于探索阶段。后续结合更多的实践经验，进行统一规划形成一站式的解决方案，降低全链路压测的接入难度和实施成本。

对于涉及支付系统的全链路压测，流量来自上游业务，对支付方式多样性的构建是有一定成本的，后续计划支持将上游单一流量自动配比为多样化的支付请求。支付相关业务对数据比较敏感，提供支付压测数据报告给上游业务以及账务等相关业务，可以在必要时满足核对需求。

也许你还想看