通用场景下如何进行低成本快速压测
在当前疫情反复、经济下行的宏观大背景下，通用场景下的企业迫切的需要通过加速数字化转型加强数字治理能力来降本增效，实现从高速发展期的粗放式资源使用方式到精细化管理运营的转变。其中，IT 资源成本在互联网企业或者大型企业集团总成本中占据相当大的绝对额度，可能达到数千万甚至数十亿。因此这些企业对 IT 资源进行成本优化是 ROI 非常可观的事项。
“你如果无法度量它，就无法管理它”，这是管理学大师彼得德鲁克给我们留下的管理箴言，这句话同样适用于 IT 资源管理。我们想要对资源进行精细的管理，首先需要对资源承载服务的能力进行度量，目前常用的度量手段是对服务进行压测。有了精准的压测数据，就可以以此为指导，对资源进行定量化治理，缩减机器或者降低配置规格，释放闲置的资源，提高资源利用率，在提高稳定性的同时降低成本。
通常软件系统压测的目的有三：1、找到系统的薄弱环节，提前进行性能优化；2、进行容量评估，以便于进行精准容量规划；3、防止大促活动的突发峰值流量冲垮系统，提前做好应对措施。
目前通用的压测方案有两种：1、通过模拟并发访问量对目标系统进行压力测试，目标系统不做任何改造，这种方式仅仅通过控制入口访问量的方式进行人工压测，实施部署简单，周期短成本低，但是由于无法模拟线上真实流量，所以只能获得大致的系统性能情况，不能准确评估系统的承载能力和性能瓶颈；2、通过录制回放或复制引流的方式利用线上真实流量进行全链路压测。
目前业界流行的服务资源度量方案是全链路线上压测，相比传统的线下压测技术路线，它具有压测环境与生产环境高度一致、利用生产数据而非编造数据、压测流量与生产流量隔离、容量预测准确等特点。自从 2012 年阿里双十一由于访问量过高导致服务中断给阿里带来重大负面影响以来，不仅阿里每年双 11 前搞全链路压测进行全真模拟，其他如字节、美团、B 站等头部互联网公司也积极实践全链路压测，并公开分享其技术实现方案。
从已经公开的技术资料来看，要实现全链路压测，不仅需要搭建流量平台，进行流量改造，为了避免压测流量污染正常流量，还需要数据库、缓存、消息队列等中间件进行改造，并且需要协调产品经理、项目经理、架构师、开发、运维、性能工程师等服务相关角色共同参与其中，十几人的团队全力投入数月才能搞定一个服务。由此可以看出，全链路压测的改造复杂度大，实施成本高、周期长，组织协调难度大，需要投入大量人力物力才能实行。
由于头部互联网企业的核心业务具备海量并发访问量、主链路清晰、组织相对统一、支撑团队研发能力强等特点，而且一旦出现故障可能会给公司带来巨大的客户口碑和商业利益损失，因此为了服务的高可用，对服务进行全链路改造从而进行全链路压测是值得的。但是通用场景下的业务由于其服务特点和组织特点，如果采用常规的全链路压测方案，新旧服务众多，需要改造几百甚至上千个服务，工程量浩大，不仅投资收益低，甚至很难组织起足够的人力物力进行全链路改造。
因此，头部互联网公司流行的全链路压测方案并不适用于通用场景，企业需要结合自己的实际情况选择相应的压测方案。星汉未来团队结合团队全链路压测的技术实践和服务数家 500 强大型企业集团的数字化转型实战经验，提出了一种适合的可以进行频繁操作的低成本快速压测方案，帮助企业度量服务容量、提高资源利用率、降低成本。下面将为大家详细介绍。
本架构的核心思想是利用线上的实时真实流量对系统进行压测，流量不作为压测的控制变量而是作为环境约束条件来看待，从而保证压测环境的真实性；将部署系统的对外提供服务的实例数作为控制变量而不是环境约束条件，通过调整对外提供服务的实例数来改变每个提供服务的实例所承受的压力状况，从而避免了复杂的系统改造工作，快捷的得出每个服务实例的最大承载能力。根据单个服务实例的最大承载能力来估算当前服务集群的整体服务承载能力，并且评估资源冗余度情况，结合基于冗余度指标的自动扩缩容策略，当流量增大时自动扩容机器，当流量下降时自动缩容机器，实现在保障服务稳定性的情况下使用的资源最优，从而达到降本增效的目的。实现架构如下图所示，下面会对主要模块进行介绍：
流量控制器主要作用是进行服务注册和管理，流量分发。当服务集群中的实例需要承担访问流量对外提供服务时，需要首先在流量控制器中进行流量注册，同理当实例不再提供服务时，也需要首先在流量控制器中下线。从客户端来的访问流量通过流量控制器按照某种负载均衡规则调度到服务集群中的实例上，从而使服务集群中的实例作为一个功能类似的整体来处理客户的请求。在实际系统中，流量控制器可以是 DNS、四层负载均衡器、七层负责均衡器或有类似功能的模块。
指标监控主要是对服务集群的服务运行状态进行观测，当服务出现异常或者故障时，可以及时示警。同时，在本架构中，它还作为调节实例数量的主要依据以及进行自动扩缩容的指标数据来源。在实际系统中，指标监控器可以是企业目前采用的监控方案，如普罗米修斯（Prometheus）、夜莺（nightingale）或者自研的可观测系统。
扩缩控制器主要是用来调节服务集群中对外提供服务的机器数，根据指标监控器的数据以及制定的压测策略从流量控制器中摘除或者新增一定数量的提供服务的实例，从而在流量相对不变的情况下通过调整承受压力的机器数来使机器的服务能力逐步达到极限。
自动扩缩容模块主要用来以压测的结果为基准来进行自动调节服务集群的机器数。通过低成本的快速压测，已经获得了单个实例的服务承载能力，然后根据目前的机器数可以计算出服务集群的最大承载能力，再通过比较当前的实际承载能力，就可以算出当前的冗余度。根据业务的实际情况，可以为服务设置一个合适的冗余度安全范围，如果超出此冗余度则进行自动扩容或缩容，从而通过维持冗余度来保障服务稳定性及提高资源利用率。
具体的快速压测流程如下：
为需要进行系统压测的服务集群设置 SLA（Service Level Agreement）规则，也就是设置压测终止的条件，从指标监控器中选取的系统观测指标可以是慢速比、错误率、平均耗时、CPU 利用率、内存利用率等可以反映系统服务能力的业务指标和或物理指标。一般会同时选取多个指标，只要有 1 个指标满足终止条件即终止压测，认为系统已经达到性能极限；
为扩缩控制器设置压测实施步骤的参数，如每次从服务注册表中摘除的最大实例数，也就是压测的步长；从摘除实例到服务集群状态趋于稳定的时间间隔，防止无效数据干扰压测结果；从安全角度考虑，服务集群设置的最低兜底实例数或者比例，防止出现极端的服务不可用情况；
设置好 SLA 规则和扩缩控制器参数后，即可以开始压测；
扩缩容控制器会实时判断此时的系统状态指标是否达到了压测的终止条件，如果达到则终止压测，摘除的实例立即恢复对外提供服务的能力；如果没有，继续下一步；
按照设置的压测步长从系统的服务注册表中摘除一部分机器，状态稳定后对系统的状态进行采样，重复上一个步骤 4。注意，此步骤仅仅是将实例从服务注册表中摘除，摘除的实例虽然不对外提供服务，但是实例中的服务仍然在运行，并且可以被该服务集群按需要调用，也就是说摘除的机器并没有缩容，将机器还给云厂商或者私有 IDC 机房供其他服务使用；
服务集群达到了 SLA 阈值而终止压测后，利用获取的压测结果就可以评估单实例的最大服务承载能力，进而可以评估出所有实例对外提供服务时可以承受的最大承载能力或者该服务根据实际业务流量所需要的实际实例数。
本架构利用线上的实时真实流量进行压测，既不需要人工模拟，也不需要录制回放或复制真实流量并进行放大，也就是不需要对线上真实流量做任何改变，因此可以得到更加准确的压测结果，同时也不需要担心压测会对真实线上流量数据造成污染；通过控制服务集群对外提供服务的实例数来改变单个实例承受的在线实时流量压力，通过缩减实例数来逐步逼近系统承载能力的上限，从而避免了复杂的系统组件改造成本；由于既不需要制造流量也不需要改造系统组件，因此可以快速压测，实施成本低、周期短；同时压测涉及的组织协调复杂度大大减少，相关服务的开发或者运维人员即可进行操作，从而可以按需进行压测。压测不再是一个奢侈品而是快消品，非常贴合通用场景下企业的业务需求。
下一章节，将介绍基于星汉未来自研的云原生基础治理平台 SchedulX 的低成本快速压测的具体实现。
SchedulX 的实现
首先简单介绍下 SchedulX，它是星汉未来基于算力调度引擎 BridgX、数据物流引擎 DtExpress、指标治理引擎 CudgX 等三大基础引擎打造的云原生基础治理平台，以稳定性指标体系为治理基石，对所有公有云、私有云的算力、数据进行全面、一体的治理，统一调度在线、离线、数据库、中间件等各类系统的算力与数据，通过机型降配、削峰填谷、冷热分离、在离线混部等技术充分提升算力利用率，构建统一的数据备份中心，提供数据备份、恢复、迁移等服务，并面向业务团队提供无状态服务、中间件服务的 Serverless 能力。
下面将详细介绍基于 SchedulX 的低成本快速压测实现方案的关键技术点。
压测的目的，就是在满足 SLA（Service Level Agreement）的情况下求系统的最大容量。因此，在压测时，为了对容量进行精准度量，需要选择度量的核心关键决策指标。一般常用的指标有每秒请求数 QPS（Queries Per Second）或者 CPU 利用率或者内存利用率。
根据团队多年的实战经验，QPS 并不能反应系统容量的真实情况，因为它没有从用户角度考虑服务的真实体验情况，有时候虽然 QPS 数值正常，但是可能延时很大，用户体验差；同样的资源利用率（CPU 或内存）也只是反应资源的利用情况，与系统的服务承载能力并非线性关系，可能利用率很低但服务质量已经恶化很严重，也可能利用率很高了但是服务质量仍旧满足 SLA。
经历亿级 DAU 产品的多次流量洪峰检验，我们选择了 MetricQPS 作为度量系统容量的核心指标。MetricQPS 不仅考虑了服务的访问情况，而且将每个请求的处理耗时考虑进去，根据耗时将 QPS 分成不同的区间，落在不同耗时区间的访问赋予不同的权重，耗时短的赋予较低的权重，耗时长的赋予较高的权重，从而充分体现不同耗时给客户的主观体验造成的影响。
有了衡量系统容量的关键指标，还需要设置服务的 SLA，只有在满足 SLA 的情况下的系统容量才有意义，否则用户的体验差会导致客户流失、品牌受损。用户可以根据自己服务的特点选择相应的关注的核心指标作为 SLA 的度量指标。一般情况下，我们推荐使用平均耗时 RT（Response-time）、慢速比（慢请求占总请求的比例）、错误率等作为 SLA 的观测指标，SLA 指标的范围可以根据业务的形态自行设定。在压测时，当刚刚触发 SLA 时，也就是达到服务质量不满足要求的临界点时，即认为此时的 MetricQPS 值就是系统的最大容量。
不同于常规全链路压测通过控制流量来求得系统容量极限，我们不控制流量而是控制服务集群对外提供服务的实例数进而间接调整每台机器的压力，因此需要设置每次摘除机器的步长，通过摘除机器以逐步逼近剩余机器的容量极限。步长设置过大，可能会导致在临近极限值附近时，由于机器摘除过多导致服务 SLA 急剧恶化，从而给线上服务造成较大的影响；如果设置过小，则需要较长的时间才能达到极限值。综合权衡这两种情况，我们对达到 SLA 的界定进行了精细的设计。
首先，为了防止拆除机器后服务状态从稳态到非稳态再到稳态的状态转换期间内由于 SLA 不稳定导致采集的数据不可靠，我们设置了一个时间缓冲区，也即是状态稳定的时间，拆除机器后过了状态稳定的时间才会采集数据，以此数据作为有效判断依据；其次，拆除的机器并非缩容或退还，而是仍旧保留在服务集群中，只是不再承担流量压力，而且机器中的程序仍旧在正常运行中，当需要时，可以立即恢复服务的能力，从而保障压测过程的安全性；最后，当第一次触发 SLA 时，并不认为此时就是最佳的容量极限，可能摘除了过多的机器，因此我们采取的措施是在第一次触发 SLA 时将临近的按步长摘除的实例立刻回退恢复上线，然后缩小步长，再次按小步长的方式向下试探，当再次触发 SLA 时，才认为此时获得的 MetricQPS 是比较合适的临界值。
由于是采用线上真实的实时流量并且利用现有的系统进行压测，因此本方案是有损压测，为了避免压测给业务造成较大的影响，我们需要实时监控压测的全过程，并且随时可干预。当为需要压测的服务集群设置好压测参数后，就可以开始压测了。
在压测过程中，服务的 SLA 指标以时序监控曲线图的形式实时显示在压测界面上，压测者可以时刻观察情况；目前服务集群对外提供服务的机器数以及占原始服务集群的机器数比例也会实时动态展示；当前的服务集群单台实例承载的 QPS 流量和 MetricQPS 值也会实时显示出来；在压测过程中的摘除实例或者上线实例的自动操作记录也会显示在压测记录里，供压测者查看，使压测全过程透明化。
如果遇到需要逗留观察的情况，可以暂停压测，此时不会再有摘除或上线实例的动作发生，压测者可以长时间观察在此种情况下服务的状态，观察完后可以继续压测；如果遇到需要停止压测的紧急情况，可以中途终止压测，摘除的机器会立刻上线对外提供服务，妙级快速恢复到压测前的状态。如果压测顺利进行，通过不断地摘除实例逐渐触发 SLA，则压测会自动停止，生成压测报告，每次生成的压测报告都会保持在压测记录里，供日后查看。如果对压测过程满意，可以将压测得出的单台服务器的 MetricQPS 作为该机器型号的最大容量的 Benchmark 值，更新掉旧的值；如果对压测结果不满意，可以再次进行重复压测从而得到合适的值。
通过压测我们得到了单个实例的最大 MetricQPS 值，利用此值我们可以度量现有服务集群的容量，并且我们还可以结合自动扩缩容，提高资源利用率、节省成本。
为了度量当前服务集群机器的资源冗余情况，我们定义了冗余度指标，即当前服务集群的最大容量 MetricQPS/ 当前实际容量 MetricQPS。当冗余度的值比较大时，说明此时业务流量小，资源利用率低，可以通过缩容减少机器来提升资源利用率；如果冗余度的值比较小，说明此时业务流量大，资源利用率高，甚至可能此时 SLA 已经恶化，可以通过扩容机器来减轻服务集群的压力。
为了做到基于冗余度指标的自动扩缩容，SchedulX 支持基于流水线的自动服务部署发布功能。也就是说，从云厂商拿机器，从代码仓库拉取部署的产物，系统启动、环境部署、产物部署、服务上线等全流程均是自动化完成。我们还可以设置不同的自动扩缩容策略，来达到不同程度的资源节约情况。阈值策略是指冗余度保持在设置的范围内，超过上限值则自动触发缩容，低于下限值则自动触发扩容；目标追踪策略则是冗余度始终保持在设置的值上，从而使服务可用性得到保证的情况下最大化节省成本。
由于是利用线上实时流量进行压测，在压测的同时系统仍在为用户提供服务，为了避免压测过程中用户的使用体验受大较大影响以及影响其他业务操作，我们在 SchedulX 系统中采取了以下措施：
虽然压测操作无论是普通的业务组成员还是业务管理员都可以操作，但是如果需要压测，则系统会自动发送邮件通知业务组管理员以及相关的业务组成员，无论是压测开始、暂停、继续、终止、结束，其他业务相关人都能够知晓。
在自动化压测过程中，如果该服务需要变更，比如发布新版本、回滚老版本、人工扩缩容等，则压测会自动终止恢复到初始状态。
将自动化压测的任务优先级设置的比较低，当系统处于发布、回滚或者扩缩容状态时，此时系统不能进行压测，只有在系统处于空闲状态时，才允许压测。
自动化压测过程中，人工可以随时终止压测，摘除的实例可以迅速重新对外提供服务。
俗话说，适合的才是最好的。无论是压测还是其他技术领域，都没有放之四海而皆准的银弹，用户需要结合自己的业务场景选择合适的压测方案。本文介绍的低成本快速压测方案，利用 SchedulX 的快速扩缩能力实现机器的快速摘除和上线，通过调整机器数来逼近容量极限，结合 SchedulX 的自动扩缩容能力，即可以保证服务的高可用又节省成本，非常适合业务分散、研发及预算有限同时又希望能够频繁压测的场景。
作者简介
李德怀，星汉未来产品副总裁，正高级工程师，北京大学硕士，累计发表论文及发明专利十几篇，曾任职于华为等公司，主导或参与过多个从 0 到 1 的产品研发和商业化进程。
英伟达回应“对中国断供部分高端 GPU”；月薪 3.6 万工程师日均写 7 行代码被开；12 年黑进 40 多家金融机构老板赚百万获刑 ｜Q 资讯
相关内容
微信扫码咨询专知VIP会员