摘要： 阿里巴巴双11备战期间，保障系统稳定性最大的难题在于容量规划，而容量规划最大的难题在于准确评估从用户登录到完成购买的整个链条中，核心页面和交易支付的实际承载能力。
目的：能够准确探测到单台机器的服务能力。基于单台服务能力和预估即将到来的业务流量进行容量规划，确定所需服务器的数目。
第一种方式：开始阶段模拟调用者，其中在生产环境中只能模拟只读请求，对写请求需要特定的处理；
第二种方式：采用流量录制和回放的方式做压力测试，通过将录制的流量快速率回放对单台机器进行压测，获取单台机器的服务能力；
第三种方式：从流量分配的角度出发，分别是请求流量转发和改变负载均衡的权重，两者核心思想都是将流量集中到某台机器上
全链路压测核心要素主要包括四点：
压测环境，它是指具备数据与流量隔离能力的生产环境，不能影响到原有的用户体验和用户流程、BI报表以及推荐算法等；
压测基础数据，它主要包括压测用户、店铺、商品等基础数据；
压测场景模型，它主要是指压测哪些业务场景，每个场景下压测多大量等；
压测流量，它主要由压测请求的协议来决定压测流量的输出；
由于是在生产环境做全链路压测模拟，因此防止压测数据和流量污染和干扰生产环境是及其重要的。要实现这一目标，首先要求压测流量能被识别，采用的做法是所有的压测流量都带有特殊的标记，并且这些标记能够随中间件协议的调用关系进行传递；此后，应用系统根据标记识别压测流量；在缓存和存储时，通过存储和缓存过滤器将压测数据存储到影子区域（表）而不是覆盖原有数据。上述所有操作都遵循一个原则：能够用中间件解决的问题，绝不对业务系统进行改造，系统所需做的是升级中间件，这一原则极大提高了工作效率。
在压测基础数据方面，为了保证真实性，实现与真实双11零点的数据匹配，我们直接从线上用户的数据（剔除敏感信息）进行筛选，同时确保用户规模与双11零点的真实用户数量一致。
基于用户数据构建压测模型是全链路压测中较为复杂的一步，它要求压测模型贴近双11零点的用户模型。我们根据前几年的历史数据和行为，结合预测算法进行模型的预估；最后生成业务场景模型；这些模型再和各个业务系统的负责人研讨，进行微调。根据最后确定的压测业务模型构造压测请求数据，最后将请求数据上传到压测平台，发出压测请求，模拟双11。
上图是压测流量平台的整体结构，主要分为三个部分：最上层是Master端，主要用于压测数据、压测场景和压测执行的配置和控制，并且其还负责压测引擎的任务分配和调度，以及一些容灾策略，最后Master端还需要对压测性能监控、分析，最后生成压测报告。
中间部分是压测引擎，目前采用的是阿里自主研发的压测引擎，部署于全球各地的CDN节点上（出于用户场景的真实性）。最下层是性能探测与监控集群，在压测过程中需要实时探测各个业务系统的运行状态以决定压测是否继续进行。
压测流量平台挑战
在实际进行全链路压测时，压测流量平台面临了一系列的挑战：首先需要面对T级别的压测请求数据；其次要满足每秒1000W+次请求压测能力；此外，需要能够维持1亿+的无线长连接和登陆用户；并且压测流量平台应该能够灵活操作，体系联动；在扩展性方面，需要支持自定义协议和流程；最后，平台应该做到秒级的智能数据调度和引擎调度能力。
如上图所示，压测引擎自下而上分为协议支持、请求发送、集群协作三层：
协议支持，主要支持的PC端协议包括Http、Https、websocket，无线端协议是Spdy、http2、accs、acds、mqtt。由于真正在双11时，用户使用的浏览器各异，进而导致与服务端协商的加密算法不一致，为了尽量模拟准确性，需要支持SSL 2.0\3.0、TLS1.0\1.1\1.2不同算法套件灵活配比，贴近用户端行为。
请求发送，由于全链路压测是利用现有的CDN集群，为了不影响现有CDN业务的正常运转，需要做Cgroup资源隔离（主要包括CPU和网络），为了实现性能最优，通常采用异步Reactor模型发送请求，链路间线程池隔离。
集群协作，控制中心Master充当大脑来发送指令，所有节点根据收到的指令执行下一步操作，并且所有slave压测节点会实时将自身状态同步到Master，以便于其做决策，如果slave节点状态不好，master则将其剔除。如果压测引擎与控制中心失联，则压测引擎会自杀，避免流量浪费。
压测引擎从上往下的优化历程包括：系统层的TCP参数调优；在JVM层，优化SSL库；在网络响应时，边读边丢，减少损耗；数据结构上尽量采用无锁的数据结构，即便是有锁，也要避免在锁里进行比较耗时的操作；在处理流程上，尽量采用异步化，缓冲队列衔接，避免异步饥饿；上层调度时，引擎之间根据负载动态调度，提高整体吞吐量。
网友评论