一、前言
性能测试从流程上划分，可简单分为压测和分析两个阶段，其中更容易工具化的是压测。从所针对的环境，可以分为线下压测和线上压测。本次我们要解决的问题就是， 怎样高效地进行线上应用的压测 。
高效要具备三个特点：
1）方便，任何人都可以快速地发起一个线上的性能压测；
2）安全，不会因为线上性能操作的方便而引起事故；
3）简单，压测结果简单明了，直观可追溯；
基于 Mirror 集群的自助性能测试，它的压测核心是容器流量转发，如图 1 所示。
图 1 Mirror 回放示意图
为什么选择 mirror 回放作为线上的压测手段？
对比 ES 回放和流量包回放，mirror 回放：
1）场景丰富度高，因为其引流的是整个集群的流量，可长时间不间断回放；
2）回放服务器的维护简单，只需要在用的时候创建，不用时销毁即可，有利于提高服务器利用率，节省成本；
3）配置使用简单，只需配置要引流的接口和引流比例即可；
4）开发和业务测试都可以方便的操作，有利于把性能测试人员解放出来；
5）和线下自助性能平台一起，覆盖线上线下自助性能测试的工作；
6）提高项目支持度，增加性能分析比重和分析率。
mirror 回放使得 2~3 个性能测试人员，就能够支持携程酒店上千应用的性能压测工作。也使酒店性能项目分析率从 2019 年初的 20%-30% 提高到现在的 50%-60%，同时提高了性能测试人员自身的自我认可度和核心价值。
二、技术背景
随着公司应用部署方式的不断演进，从最初的传统物理机部署方式，到后来的虚拟化部署方式，再到现在的容器化部署，公司整体的服务器运维和效率大大提高。而伴随着容器化部署的不断完善，各种好的容器化编排模式（参考 Kubernetes Container Design Patterns）也得以应用到生产各种应用场景，其中基于 sidecar 模式的伴斗容器最先被应用到实际的生产性能验证中去。由于其良好的隔离和封装性，同时兼具网络和数据共享的特性，为我们进行线上应用性能验证提供了非常好的天然条件。
再结合 pcap 等一些网络组件库，生产环境网络流量复制转发到沙盒应用的基本功能都已经具备。同时集成公司当前丰富的实时监控数据和排查工具，基于 Mirror 集群的自助性能测试就是在这样的技术基础上完善起来的。
容器流量复制，过滤，转发帮我们解决了基本的场景设计和请求工具问题，直接利用线上容器应用实际过滤后的请求转发到单台或者多台机器来满足多倍、场景化压测的需求。
完善的监控系统，譬如 ES/HickWall/CAT 中的请求量，响应时间和机器资源监控数据，能够保证用户在启动压测后能够快速的看到回放状态和结果，使得自助回放平台提供的服务更加友好和一站式。用户只需要在一个地方即可完成配置，回放，查看回放时期的响应、机器资源消耗等等指标。见如下图 2 回放报告截图：
图 2 Mirror 回放报告示意图
对于回放配置中的接口中的流量是否被转发，转发的数量是否准确，都是我们关注的重点，这关系到我们压测场景和量级。这些在框架层面都已默认做了记录，在很大程度上在回放开启后，能快速帮助我们诊断当前流量情况，包括接口名称，TPS, Response Time, Error 数量等等，从而保证压测在场景和量级上的正确性。这些都是自助平台的基础数据支撑。
而在压测过程中应用状态异常情况，CAT 提供了 thread Dump 供查看当前应用的活动状态，同时 Pass 还有 Heap, Mem, Lock 等排查分析工具可供使用。这样就可以把整个性能测试从前到后的不同节点完整地衔接起来。
环境 / 场景准备到回放启动，回放启动异常侦测，再到回放结果收集，异常排查，最后报告整合。这种情况下，自助回放平台有了一个很好的落脚点和底层支撑。整体架构图如下图示 3：
图 3 Mirror 自助回放平台架构示意图
三、技术实现
性能自助平台的实现要注意三点：
第一，选择方便可靠的请求压测工具。
操作方便是使用的基础，而压测工具的可靠是后续数据分析的基础，同时我们也要处理好一些特殊应用的问题。正常情况下，我们希望一个应用对应到一个服务，也就是最好是一对一的关系。而当前我们发现应用和服务之间是多对多的关系，有的一个 appid 下面挂了 n 多个服务。譬如应用 1000xxx00，下面有 10 多个服务，如下图 4 所示：
图 4 应用服务对应关系示意图
这就意味着给定一个 appid，下面有 n 个服务地址进行对应，回放的白名单就要根据不同的服务名，把不同的接口解析出来，否则用户就无法进行白名单审核。同时我们捞取服务地址的时候也就无法单单靠一个 appid 来确定捞取哪一个服务地址，反过来还要依赖白名单审核中的服务信息来确定要捞取的回放地址。
这些特例无疑增加了系统的复杂度，而我们并不希望用户在前端操作的时候感知到。处理好这些特例问题，是保证自助系统方便稳定的重要组成部分。
第二，线上回放要保证安全，不会引起生产事故。
在自助平台的实现中，特别要注意在保证用户操作便捷的基础上，保证操作的安全性。安全性包含几个方面：
1）不能把不应该回放到生产的请求回放到生产上去，其中危害最大的无疑是写接口。写接口的误操作会引起线上数据的混乱，这就需要我们提供流程化的操作来保证用户不犯错，犯错的时候有提醒。
譬如在我们当前的自助平台里面，用户在进行回放配置的时候必须先进行白名单的审核。这个白名单的审核，应用的 owner 是必须参与的，从而保证白名单里面的接口都是可以进行线上回放操作的，否则用户在回放配置的时候，无法选择到回放接口来开启回放。如下图 5 所示：
图 5 Mirror 自助回放白名单示意图
2）在回放过程中出现错误的时候，及时停止，保证不引起生产故障。这个我们可以通过 CAT 的错误数据来设定什么状况下，触发自动停止动作。我们单独做了一个监控进程来负责各个回放应用的状态监控，如图 6 所示。
3）回放不会引起线上统计数据的异常。譬如最简单的用户真实请求量，转化率等等，这些都需要在回放接入前进行业务调研。如果有此类风险，需要各个业务 owner 进行配合排除对应的回放数据。
图 6 回放监控示意图
第三，结果聚合化，排查简单化。
回放结果方面，我们把 cat/hickwall 的数据做了应用性能和服务器性能的聚合，方便查看。在线上问题排查方面，除了 Pass、Cat 工具之外，在 JAVA 方面，还提供了容器化 Jprofile 工具，.net 方面，提供了在线 dump 分析工具来满足快速问题分析的需求。
当然每个同学有不同的分析问题的习惯和工具，我们只是提供一些比较知名和通用的工具支持，来满足不用应用类型在不同问题方面的排查。
四、现存问题
当前我们基于 mirror 集群的自助性能测试还有一些局限性。
1）回访场景细化的问题。当前我们只能单纯的把流量引入到指定的 mirror 机器，无法精细化场景，目前只能靠 es 回放来弥补。
2）基于 mirror 集群的自助测试无法解决比例放大问题。它只能解决有限放大压测问题，整个放大比例是基于线上集群内的流量大小。而对于目前集群流量较小的应用，全部引流也无法满足指定 TPS 要求。
3）在 mirror 回放没有开启状态下，mirror 机器上的应用依赖还会消费 Kafka 等数据中心的数据。如果 mirror 机器上的应用代码没有及时更新，就会出现数据消费错误。
五、后记
基于 mirror 集群的自助性能测试是我们整个自助性能测试一个重要组成部分，它和我们线下自助压测工具、自助 ES/kafka 回放工具和 dump/heap 分析工具一起组成整体性能自助压测系统。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
