目前常用的压测工具一般都是针对QPS这一个单一指标进行考量。即使支持编写脚本的工具也只是通过参数化模拟用户。但是实际用户是使用单独设备请求服务器，即一个用户就是一个tcp连接。

所以为了更真实的模拟用户行为，我们需要通过一个tcp连接模拟一个用户，并通过代码方式实现用户的真实请求行为。C端及中台产研中心云平台部质量保障团队自研的“仿真压测系统”。独有的QPS动态可控技术，支持固定URL压测、参数化、Websocket协议压测、中间件、数据库等的压测，模拟用户真实轨迹，通过用户侧，服务端，DB进行数据一致性和正确性自动检验，打造真正的全链路仿真压测，该系统可扩展性强，稳定性高，目前已多次支持公司级各类大型活动的仿真全链路压测，为线上服务的稳定运行提供了强有力的质量保障。

经过四年的打磨如今借此机会与大家分享一下心路历程，积极讨论，欢迎提出意见，希望可以帮助我们进一步成长。（文中引用均为测试数据）

► 2.1.1 现有的压测工具对比                              

图1-1

► 2.1.2  Locust发压client比较

图1-2

结合以上比较结果，目前没有合适的压测工具可以直接满足我们的压测需求，最终决定用Locust做框架,首先它是一款易于使用的分布式负载测试工具，完全基于事件，单机并发能力高，并发机制是协程，其次二次开发潜力比较大。

发压的请求client采用fasthttp, 据说是目前golang性能最好的http库，原理是利用worker复用goroutine，减轻runtime调度协程的压力，相对于自带的net/http(每个连接都需要新建一个goroutine)，性能有10倍的提升。省略一千字，直接上干货。

► 2.1.3 仿真压测系统特性：

• 分布式部署；

• 固定URL压测；

• 参数化脚本压测；

• Websocket协议压测；

• 其他协议UDP、http2、 RTMP/HLS、MQTT（golang可以实现的协议都可满足）

• Redis直压；

• Kafka直压

• Mysql直压；

• 自定义脚本压测（仿真压测，全链路数据对账）；

• 动态可控QPS、TCP；

• 秒级启动/停止，结果收集即停即展示，无需等待

……

 ► 2.1. 4 实现难点分析

模拟百万用户创建TCP/ websocket连接；长时间保持连接不断开；集中发压；

部分代码如下：

   go func() {
    for {
        select
        case data := <-r.stats.messageToRunnerChan:
            data["user_count"] = r.numClients
            r.outputOnEevent(data)
        case <-r.closeChan:
            Events.Publish("boomer:quit")
            r.stop()
            wg.Done()
            return
        }
    }
}()
集中发压
curTime := myStatus.Ct
    statusTime := myStatus.St
    c := time.After(time.Duration(statusTime-curTime) * time.Second)
    <-c
    miaosha(uidToken, &myStatus, myLog)
保持长链接
func wsWorker() {
  ws, err := websocket.Dial(wsUrl, "", origin)
  if err != nil {
  log.Println(err)
  return
  }
  defer func() {
    if p := recover(); p != nil {
    log.Println(p)
 }
 erc := ws.Close()
    if erc != nil {
     log.Println(erc)
  }
  }()
  go func() {
    ws.Write([]byte("0"))
    var t = time.Tick(time.Second * 30)
    for range t {
    if ws == nil {
        continue
    }
    ws.Write([]byte("0"))
    fmt.Println("send 0 to websocket ok!")
    }
    }()
  for {
    select {
      case <-stopChannel:
           return
      default:
        var msg = make([]byte, 512)
        start := time.Now()
        n, err := ws.Read(msg)
        log.Println(string(msg[0:n]))
        elapsed := time.Since(start)
        if myDebug {
            log.Println(string(msg))
           }
        if err != nil {
          log.Printf("Error: %s", err.Error())
        }
       }
     }
    }

图2-平台首页

图3-实时监控压测页面，总请求数、实时qps、响应时间、发压机cpu占用等指标。

图4-压测空接口，服务器监控截图， Nginx的峰值QPS可以达到596万。

图5-压测redis时监控截图，单个节点的实时监控等都可以一览无余

工欲善其事，必先利其器，利器已有，剧本安排上。

晚会当天数以万计的用户通过手机app参与活动，从白天开始“预约红包”，晚上八点晚会开始后用户开始陆陆续续登录app“领取预约红包”；随着主持人口播，第一轮“集卡”活动开始……人数慢慢增多，到了最激动人心的时候。“一元秒新车”开始，QPS狂飙，TCP连接数也达到了峰值100W。

开始实战：

控制台：各部门注意，入口已经放开，流量开始进入；目前“预约红包”阶段

仿真压测：收到，每五分钟递增1w用户（1TCP模拟1用户以下通用TCP数代指用户数），QPS200（用户进入活动页面，预约红包、查看规则、查看介绍等大概每人5次请求）

控制台：晚会开始，“预约红包”可领状态，“见面礼红包”已开启，“连续红包”已开启，第一场大咖讲话马上开启……

仿真压测：明白，TCP调整到20W，QPS2W（用户操作5次集中在1分钟以内）

图7-动态调整QPS、TCP连接数按钮

图8-设置TCP连接数、QPS、步增等

图9-设置生效，TCP、QPS稳定保持在设定值

控制台：抽盲盒活动进入倒计时

仿真压测：copy，TCP调整到30W，QPS10W（用户3秒内点击10~15次提交一次请求到服务器）

图10-设置生效，TCP、QPS稳定保持在设定值

控制台：时间来到最终环节，“一元秒新车”，倒计时开启

仿真压测：拼手速的时候到了，TCP100W，QPS100W（秒杀只可以提交一次）走起

图11-设置生效，TCP、QPS稳定保持在设定值

至此，晚会结束，仿真压测却并没有结束，还有最后一环--“对账”。仿真压测会把接口返回用户的数据记录到kafka中，最后入库，与服务器的数据进行对账，确保每条数据的正确性。

图12-服务侧数据与用户侧数据进行对账

看一下动态调整QPS的完美曲线,随着用户增长以及QPS增长的仿真图

图13-仿真模拟用户递增的曲线

图14-服务器监控截图，仿真用户全部走websocket协议，通过“状态机”下发指令、接收指令

 图15-Redis 监控截图

图16-云服务器LB截图

图17-云服务器LB截图

图18-云服务器LB截图

图19-仿真压测完成，服务侧奖品发放明细

数据完美对上。

由于篇幅受限，想说的很多，质量保障团队也做了很多，比如灾备演练，模拟服务器满载、域名切换、服务器宕机、机房切换等等。关于测试方面的问题欢迎私下讨论。

作者|刘建宇