境内度假是一个低频、与节假日典型相关的业务，流量在节假日较平日会上涨五到十几倍，会给生产系统带来非常大的风险。因此，在2018年春节前，我们把整个境内度假业务接入了全链路压测，来系统性地评估容量和发现隐患，最终确保了春节期间系统的稳定。
在整个过程中，我们意识到，全链路压测在整个系统稳定性建设中占有核心重要的位置，也是最有效的方案。结合实际业务节假日的频率（基本平均一个月一次），如果能够把它作为稳定性保障的常规手段，我们的系统质量也能够得到很好的保障。同时，为了解决周期常态化压测过程中人力成本高、多个团队重复工作、压测安全不可控，风险高等痛点，我们提出了全链路压测自动化的设想。
通过对压测实施的具体动作做统一的梳理，在压测各个阶段推进标准化和自动化，尽力提升全流程的执行效率，最终达到常态化的目标，如下图1所示：
另外，在全链路压测的整个周期中，压测安全和压测有效性也是需要一直关注的质量属性。基于这些思考，如下图2所示，我们把压测自动化需要解决的关键问题进行了归类和分解：
最终，基于美团基础的压测平台（Quake在整个系统，主要提供流量录制、回放、施压的功能），设计并实现了全链路自动化压测系统，为不同业务实施全链路压测提效，并确保压测安全。该系统：
系统的总体逻辑架构，如图3所示，主要包括链路构建/比对、事件/指标收集、链路治理、压测配置管理、压测验证检查、数据构造、压测计划管理、报告输出等功能模块。通过这些模块，为全链路压测的整个流程提供支持，尽力降低业务部门使用全链路压测的门槛和成本。
链路构建/比对：负责服务接口方法调用链路的构建、更新、存储。
链路治理：基于构建的链路关系，提供链路中核心依赖、出口Mock接口等标注、上下游分析、展示，以及出口Mock的配置等功能。
压测配置管理：自动发现注册服务的Mafka/Cellar/Squirrel/Zebra的压测配置，辅助压测方核查和配置相关配置项。
压测验证检查：确保系统可压测，通过多种校验手段和机制设计，来保证压测的安全性。
数据构造：为不同业务压测实施准备基础和流量数据。
压测计划管理：设定压测执行计划，并依赖“压测控制”模块，自动调度整个压测执行过程。
故障诊断：依据收集的关键业务/服务指标、报警等信息，判断分析服务是否异常，以及是否终止压测。
置信度评估：从数据覆盖、链路覆盖、技术指标等维度评估压测结果的置信度，即与真实流量情况下各评估维度的相似性。
非功能性需求说明：
可扩展性
安全性
可重用性
约束说明：
以下对部分关键模块设计做详细介绍。
链路治理模块是基于链路构建模块实现的。链路构建模块，底层是以闭包表的方式存储两个维度（服务和接口）的链路关系的，会周期自动地构建或更新。
链路治理模块主要提供链路入口选取、链路标注、服务出口分析、出口Mock配置等功能。如图4所示，注册压测的服务构成了压测服务的范围，也就确定了各个链路的边界。通过系统自动构建的树结构方式的链路关系，可以辅助压测方对整个链路的梳理，它解决了以往链路梳理靠翻代码等低效手段，缺少全链路视角无法做到完备梳理等问题。
同时，针对整个压测范围，依赖接口可以做人工标注。哪些需要Mock，哪些不需要Mock，如此压测特有的链路信息能够得到持续的维护。
对于需要Mock的外部接口（如图4中的接口C），待压测系统通过引入专有SDK的方式，获得出口配置化Mock的能力。如图5所示，这里使用了美团酒旅Mock平台的基础能力，采用JVM-Sandbox作为AOP工具，对配置的需要Mock的外部接口做动态能力增强。在接口调用时，判断是否是压测流量，是的话走Mock逻辑，做模拟时延处理，返回提前配置的响应数据。这样的话，第一，简化了出口Mock的操作，业务代码里Mock逻辑0侵入；第二，把之前本地Mock与借助Mockserver的两种解决方案用一种方案替代，便于统一管理；第三，在实际压测时，平台还可以通过SDK收集Mock逻辑执行的数据，自动与后台标注的Mock数据对比，来确保应该被Mock的出口确实被Mock掉。
数据构造模块是为了解决不同业务对于基础数据和流量数据的差异化构造流程。提出了两个关键的概念：数据构造逻辑和数据构造流程。数据构造逻辑，是数据构造的细粒度可复用的基本单元，由一段Java代码表示。平台提供统一抽象的数据构造接口，基于Java动态编译技术，开发了一个Java版的脚本引擎，支持构造逻辑的在线编辑与更新。同时，基于美团RPC中间件泛化调用能力，构建了泛化调用工具，帮助用户把外部基础数据构造接口的调用集成到一个数据构造逻辑中。
数据构造流程，定义了压测基础数据和流量数据生成的整个流程。通过与Quake的交互，获取原始真实的线上数据；构建了一个简版的流程引擎，在统一设定的流程中，如图6所示，通过在标准扩展槽中，配置不同类型的数据构造逻辑和执行顺序，来定义整个数据构造执行的流程；最后，把构造的流量数据与Quake压测场景绑定，作为后续Quake压测施压中，场景回放流量的来源。
通过这样的设计，能够支持任意数据构造逻辑，通用灵活。同时集成了Quake已有的流量录制功能，一键执行数据构造流程，大大地提升了效率。
对于压测安全性的保障，一直是自动化的难点。之前的经验多是在非生产环境压测或预压测过程中，依靠不同服务相关负责人的人工确认。这里针对压测验证，提供两条新的思考角度：一个是从待压测服务系统可压测性的角度看；一个是从压测流量特征的角度看。对于第一个角度，一个服务支持压测需要满足压测数据和流量的隔离。对于不同的系统生态，需要满足的点是不同的，对于美团生态下的服务，可压测的条件包括组件版本支持压测、影子存储配置符合预期等等。
从这些条件出发，就可以得到下面这些静态的校验项：
而从第二个角度来看，就是关注压测流量下会产生哪些特有的流量特征数据，通过这些特有的数据来确保压测的安全性。这里主要有三类数据：美团分布式追踪系统（MTrace）中调用链路的压测标记数据（正常的压测链路应该是一直带有压测标记，直到压测范围的边界节点，可参考图4）；标记Mock的外部接口被调用时，上报的运行数据；基于监控系统得到的压测流量特有的监控数据。利用这些数据，我们设计了三种动态的校验项，发现压测标记丢失、Mock出口被调用等异常情况：
除了明确静态和动态两类压测校验规则，在具体流程安排上，在压测时和平日两个时期执行这些规则。既能把压测校验的压力分散到平时，也能尽快地发现服务因代码迭代引入的新风险。
在压测时，通过强制前置预压测的流程设计以及静态/动态压测校验项的自动执行，保障安全这个事情。校验不通过，给出告警，甚至在允许的情况下直接终止设定的压测计划。
在平日，通过执行周期性小流量压测校验，在施压过程中对QPS做个位数的精细控制，以尽量小的代价快速发现压测范围内压测安全性的退化。
压测计划管理模块，提供压测计划的提前设定，然后模块能够自动调度和控制整个施压过程。如图11所示，这里的压测计划是多个压测场景的组合，包含QPS的增长计划等信息，主要分为预压测和正式压测两个阶段。压测计划的自动实施，能够解决尤其多场景组合压测，操作耗时多、多场景压测QPS无法同步变更、压测方无法兼顾操作和观测等问题，提升了效率。同时，在压测计划执行状态机里，预压测正常执行完成，状态才能迁移到正式压测的开始状态，提高了压测安全性。
从图11可以看到，压测计划模块，是整个自动化压测的核心，协同起了各个模块。通过具体的计划任务执行产生的事件，触发了压测验证检查、压测进展播报、收集压测监控/告警等数据，来检测服务是否异常，并根据配置来终止压测，能够故障时及时止损。最后，报告生成模块收到压测终止事件，汇总各种信息，自动生成包括压测基本信息等多维度信息的压测报告，节省了一些压测后分析的时间。
以下以实际压测的过程来做个案例分享。
目前，压测自动化系统已经投入使用，美团酒店和境内度假的全部团队已经接入，有效地提升了压测效率。后续会在两个大方向上持续建设升级，一个是把全链路压测放到“容量评估与优化”领域来看，不仅关注整体系统的稳定性，同时也期望兼顾成本的平衡；另一个是与稳定性其他子领域的生态集成，比如故障演练、弹性伸缩等等，在更多场景发挥压测的作用。最后，通过这些努力，使得线上系统的稳定性成为一个确定性的事情。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。