从0到1构建美团压测工具

美团内部的RPC服务大多构建在Thrift之上,在日常开发服务的过程中,需要针对这些服务进行压力测试(以下简称压测)来发现潜在问题。常用的方法有:

  • 使用一些脚本语言如:Python、Ruby等,读取线上日志构建请求,用多线程模拟用户请求进行压测
  • 使用开源工具进行压测

然而,无论采取哪种方法,压测都是一个十分耗时而又繁琐的过程,主要痛点有:

  • 需要写很多代码解析日志,还原请求,对于比较复杂的请求,解析很容易出错
  • 需要搭建脚本或者工具的运行环境,通常这一过程比较耗时
  • 由于打压方法没有统一,导致打压的结果指标比较混乱,有的结果甚至以终端输出的方式展示,非常不直观
  • 对一个应用的打压测试,由于环境、代码的问题,导致组内同学很难共享

针对上述问题,提供一个简单好用的压测工具是十分有必要的。

是否有必要重复造轮子

在构建压测工具之前,对于一些现有的开源工具进行了调研。现在主流的压测工具主要有以下几个:

JMeter

JMeter是一个比较老牌的压测工具,主要针对HTTP服务进行打压,该工具在以下方面并不满足美团内部的压测需求:

  • 默认不支持Thrift的打压测试
  • 需要本地安装,并且配置复杂
  • 对于用户操作并不友好

twitter/iago

iago 是一个由Twitter开源的压测工具,支持对HTTP、Thrift等服务进行压测,其主要问题如下:

  • 对每个压测应用都需要创建一个项目
  • 压测结果并不直观
  • 流量重放依赖本地文件
  • 项目依赖于一个较老版本的Scala,搭建不便
  • 相关文档比较少

除此之外,当时还考察了GatlingGrinderLocust 等一些常见的压测工具,都因为适用场景和美团的需求有些出入而排除了。

综上,针对当前压测工具的一些现状,构建一个简单易用的压测工具还是很有必要的。

目标

针对之前提到的痛点,新的压测工具主要提供以下功能:

  • 线上流量拷贝
  • 简单易用的操作界面(接入压测的时间应该控制在1小时以内)
  • 清晰的图表能反映压测应用的各项指标
  • 满足包括Thrift、HTTP等服务的压测需求

如何构建

抽象

目标已经明确,怎么实现呢?首先是抽象压测的过程。 一个典型的压测过程如图所示,首先在init方法里面,进行一些初始化的工作,比如连接数据库,创建客户端等。接下来,在run方法里面发出压测请求,为了保证能够对服务产生足够的压力,这里通常采用多线程并发访问,同时记录每次请求的发起 时间和结束时间,这两个时间的简单相减就能够得到每次请求的响应时间,利用该结果就可以计算出TP90、平均响应时间、最大响应时间等指标,等压测结束 后,通过destroy方法进行资源回收等工作。

以上过程可以用接口表示,无论是压测Thrift服务还是HTTP服务,本质上都是这三个方法实现的不同。考虑到压测工具的灵活性和通用性,压测工具可以将这个接口交给打压测试的同学实现,而压测工具则重点实现多线程打压,打压结果的聚合等比较耗时的工作。

interface Runner {
    def init(Test app) // 初始化压测
    def run(Test app, String log) // 每次打压请求,传入log方便构建请求
    def destroy(Test app) // 压测完毕后,回收资源}

拷贝流量

Thrift服务打压的难点之一就是如何简单地拷贝线上真实流量用来构建打压请求。一些大型的Thrift服务数据结构非常复杂,写打压脚本的时候需要很多代码来解析日志,而且容易出错。 因此提供一个简单好用的拷贝流量方法是十分有必要的。

在这里压测工具提供了一个叫VCR(录像机)的工具来拷贝流量。VCR能够将线上的请求序列化后写到Redis里面。

考虑到用户需要查看具体请求和易用性等需求,最终选取了JSON格式作为序列化和反序列化的协议。同时需要部署在生产环境,为了降低对线上服务的影响,这里采取了单线程异步写的方式来拷贝流量。

聚合数据

应用打压完成后,需要一些指标来评估压测结果,常见的指标有:

  • 最大响应时间
  • 平均响应时间
  • QPS
  • TP90
  • TP50

压测工具采用了 InfluxDB 来完成数据的聚合工作。 以TP90为例子,仅需要一行查询就能实现需求。

SELECT PERCENTILE(response_time, 90) FROM test_series GROUP BY time(10s)

架构

整体而言,整个打压过程如下:

实践

拷贝流量

美团内部的服务大多使用Java来构建,VCR以Maven Package的方式提供给用户。

对用户来说只需要2行代码可以拷贝流量。

为了不影响线上服务,通常选取单台机器进行流量拷贝工作。

public class TestAppRPC implements TestApp.Iface {    private Vcr _vcr = new Vcr("testapp"); // 指定拷贝流量的key

    @Override
    public TestResponse echo(TestRequest req) throws TException {
        _vcr.copy(req); // 拷贝操作
        long start = System.currentTimeMillis();
        TestResponse response = new TestResponse();        return response;
    }
}

一旦流量拷贝完成后,通过Web界面,用户能够查看日志的收集情况和单条日志的详情。

压测逻辑实现

压测工具采用Groovy来进行编写。对每个应用来说,只需要实现runner接口就可以实现对应用的打压。

interface Runner {
    def init(Test app)    def run(Test app, String log)    def destroy(Test app)
}

以Thrift服务为例:

class TestServiceRunner implements Runner {

    RPCService.Client _client
    TTransport _transport;    @Override
    def init(Test app) {        def conf = app.config // 读取应用配置
        _transport = new TFramedTransport(new TSocket(conf.get("thrift_service_host") as String, conf.get("thrift_service_port") as int))
        TProtocol protocol = new TBinaryProtocol(_transport)
        _client = new RPCService.Client(protocol)
        _transport.open()
    }    @Override
    def run(Test app, String log) {
        TestRequest req = Vcr.deSerialize(log, TestRequest.class) // 将拷贝流量反序列化
        _client.echo(req) // 发送请求
    }    @Override
    def destroy(Test app) {
        _transport.close() // 关闭服务
    }
}

创建应用

实现以上接口后,就可以对应用进行打压了。

用户可以通过Web界面创建应用,除了必填配置以外,用户可以按照应用灵活配置。

性能指标

用户可以通过直观的图表来查看应用的各种性能指标。

结束语

压测工具上线以来,已经接入了20多个应用,完成数百次打压实验,现在应用的接入时间仅需要15~30分钟。保证了美团服务的稳定和节省了开发同学的时间,使大家告别了以往繁琐冗长的打压测试。

欢迎对这方面有兴趣的同学一起讨论。

原文发布于微信公众号 - php(phpdaily)

原文发表时间:2016-04-08

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏微服务

关于大型网站技术演进的思考(一)--存储的瓶颈(1)

前不久公司请来了位互联网界的技术大牛跟我们做了一次大型网站架构的培训,两天12个小时信息量非常大,知识的广度和难度也非常大,培训完后我很难完整理出全部听到的知识...

36315
来自专栏北京马哥教育

Linux kernel 的设计是否已经过时?

Linux 多年来取得的成绩毋庸多言。但最近,reddit 上有人发起了一个话题,想知道 Linux 的内核设计是否已经过时,并得到了一些有趣的答案。 这位 ...

3256
来自专栏技术翻译

为什么使用微型服务?

Netflix,亚马逊等公司都在其产品中采用了微服务的概念。微服务是软件行业中最热门的话题之一,许多组织都希望采用它们。并且,DevOps可以很好地与微服务配合...

822
来自专栏北京马哥教育

sqlserver、Mysql、Oracle三种数据库的优缺点总结

? 一、sqlserver 优点: 易用性、适合分布式组织的可伸缩性、用于决策支持的数据仓库功能、与许多其他服务器软件紧密关联的集成性、良好的性价比等; 为...

3536
来自专栏携程技术中心

干货 | 携程呼叫中心异地双活——座席服务的高可用

颜值高的,点上面! 随着业务量的不断上升,呼叫中心已经从单纯的大容量单中心逐渐向多地多中心演化,在这种架构下,多地呼叫中心的统一协作成为整合资源、提升可用性、提...

3649
来自专栏散尽浮华

linux系统下对网站实施负载均衡+高可用集群需要考虑的几点

随着linux系统的成熟和广泛普及,linux运维技术越来越受到企业的关注和追捧。在一些中小企业,尤其是牵涉到电子商务和电子广告类的网站,通常会要求作负载均衡和...

1799
来自专栏Linux Python 加油站

揭秘Linux工程师一路走来都需要哪些技能

大公司也是从小公司一步步走过来的,而大公司之所以与小公司不同,不在于基础的技术体系不同,而是当数据量达到一定程度后,引发的质变而已。而在思考质变带来的性能问题中...

904
来自专栏IT大咖说

向Kubernetes容器云平台迁移,你必须知道的9件事

内容来源:2017 年 11 月 25 日,当当网数字业务事业部技术总监李志伟在“Kubernetes Meetup | 北京站”进行《Kubernetes容器...

833
来自专栏性能与架构

Hotjar在架构演进中总结的8条经验

Hotjar 提供了帮网站主了解用户行为的服务,网站接上此服务后,可以生成用户的点击热区,录制用户的行为,查看各个页面的跳出路径以及停留时间等,根据这些统计数据...

3356
来自专栏腾讯云容器服务团队的专栏

华尔街见闻:基于腾讯云容器服务的微服务架构实践

本文介绍了华尔街见闻通过重构和服务容器的重新部署,实践微服务架构的情况。经过几个月的开发测试,我们不仅完成了线上服务从PHP到Golang的转型,更在服务的稳定...

1.1K0

扫描关注云+社区