目前只做了基于 puppeteer 的，mitmproxy / anyproxy 都可以扩展兼容。

持续思考，持续进步 hhh

正解

真要看重性能，可能你得看下 boomer

......

时间戳，上下游响应之类的关联信息，你要想伪造那份 log 不好搞，不如直接自己写个 log 生成 request 的发生器

因为我用的是 mac 当然这样写。Chromium 又不是只有 mac 版本，换一下就行。

不要去外包！
不要去外包！
不要去外包！

可以的，你在执行的时候保存下 log，然后写个页面每次去获取这个 log，解析一下包装成你想要的数据就行了。

才看到 hhh
是鸭，趋势所在

那就是 grafana 里面设置连接数据库的信息不对。

你选 server 模式的时候，不能写 http://localhost:9090 http://127.0.01:9090，要填本机的真实 ip 地址。

传错地方了，已上传，再试一下~

要带 tag，docker pull shaonian/goc:v1.0

你直接用 docker-compose 起不就完了，干嘛一个个单独拉。

你不是用 docker-compose.yml 起的吗

你应该还没有执行压测吧，没有执行压测那肯定没有测试数据。

如果不是这个问题，就得看看容器的日志，你截图页面没啥意义。

还有要注意一下 grafana 里面配置 prometheus 的一些连接信息，这里不对也会这样。

你这个是 window 10 家庭版，不是专业版，没有打开 Hyper-V 的选项。

要打开这个才能装 docker。

hhhhh

1. 直接代码层面引入第三方插件，智能生成 api 文档。（比如其他人说的 swagger）

2. 脚本实现，抓数据，手写转 swagger 格式。

3. 借助第三方平台实现，现在 yapi 接口管理平台可以导入 har 当文档了，对你来说，应该是最佳选择鸭。

你要明白一个问题，那就是为啥这里只有 max-rps 没有什么 min-rps 。。。

你说的 在 locust 中可以通过 Semaphore 来等待 2000 个 VU 起来

boomer 不用等，开多几个 pod 开场就 2000 个 goroutine。。。

对于 go 来说，只要资源充足，你一开始就能直接产生 2000 个 goroutine，甚至能更多 。。。

--max-rps 是怕并发太多你系统撑不过来，用来限制协程并发数的。。。

你看看实现。

// Start to refill the bucket periodically.
func (limiter *RampUpRateLimiter) Start() {
    limiter.quitChannel = make(chan bool)
    quitChannel := limiter.quitChannel
    // bucket updater
    go func() {
        for {
            select {
            case <-quitChannel:
                return
            default:
                atomic.StoreInt64(&limiter.currentThreshold, limiter.nextThreshold)
                time.Sleep(limiter.refillPeriod)
                close(limiter.broadcastChannel)
                limiter.broadcastChannel = make(chan bool)
            }
        }
    }()
    // threshold updater
    go func() {
        for {
            select {
            case <-quitChannel:
                return
            default:
                nextValue := limiter.nextThreshold + limiter.rampUpStep
                if nextValue < 0 {
                    // int64 overflow
                    nextValue = int64(math.MaxInt64)
                }
                if nextValue > limiter.maxThreshold {
                    nextValue = limiter.maxThreshold
                }
                atomic.StoreInt64(&limiter.nextThreshold, nextValue)
                time.Sleep(limiter.rampUpPeroid)
            }
        }
    }()
}

你只要不设置 rampUpPeroid rampUpStep 只设置 maxThreshold

资源充足的情况下马上就能触发这个逻辑。

if nextValue > limiter.maxThreshold {
    nextValue = limiter.maxThreshold
}

至于你说的 并发每隔一分钟来一次

boomer 并发的是函数，你在函数结尾直接 sleep 一分钟，不就 2000 并发一次了吗。。。

具体例子已给出 ~ 见最佳回复

按日志格式造 request 实现不难，难的是把业务逻辑和规则融入进去，就比如你的第二个问题，才是第一个问题的核心。

举个例子：

线上日志

GET /product
HOST prod.com
PARAM token: old-token
PARAM name: 1-prod-product

发起 prod 请求前，复制一份到 test，更改 HOST 和 匹配规则

if host == "test.com" && "url == /product" 匹配 替换类规则 RULE [1，2]

RULE 1 代表登录类替换逻辑，若 PARAM 匹配到 token cookie ...， 替换成万能 token 或调用函数造 token。
RULE 2 代表关联类替换逻辑，若 PARAM 匹配到 name ... ，根据 get_product(host,token) 获取对应环境的值并替换。

GET /product
HOST test.com
PARAM token: new-token
PARAM name: 2-test-product

然后同时发出，然后 diffy json（response_prod, response_test）

这里还可以做噪音匹配规则，这样对照组都能省，直接去噪。
比如增加 NOISE_RULE [1]
NOISE_RULE 1 代表通用类去噪音规则，diffy --ignore time, createtime, updatetime...

最后，再借助 boomer 登记 diffy，就可以自己直接实现 diffy 归纳路由。

if diff := jsondiff.Diff(response_prod, response_test, diffopts.IgnorePaths([]string{"/time"})); diff != "": {
    boomer.RecordFailure("GET", "/product", 0, string(diff))
}

PS：

正确打开方式之前的两幅图，一个是 buger/goreplay 的回放，以及 opendiffy/diffy 的差异对比，这也是传统模式的 录制 + 回放，主要讲解传统模式 录制 + 回放 的原理，以及落地以后的一些缺陷。

而后提出的优化，也是基于体验这个流程以后，弥补其中的一些不足，并提出优化实现方案。

可以理解为，把线上的流量录制成特定的日志格式，脚本是解析日志格式去发请求的，只要格式保持一致，就通用于大部分的项目。然后，涉及标记的动态数据得替换生成。

不过能理解成接口自动化 + 压测也对，原理都是把请求经过处理，同时对多个服务发出，并实时 diffy 响应。只不过一个是手写代码构造 request 一个是读线上日志构造 request。

boomer 里面直接就是协程并发跑函数了。
你可以设置 --max-rps = 2000 ，然后再在 task 函数结尾 time.Sleep 一下。

有，通过 --max-rps 控制

是啊。

其实我最后想表达的意思是，我们不应该只局限于 录制 + 回放 这两个组合，能实现同样测试效果的组合，为什么不能组合使用呢？

比如：

• 录制 + 规则校验（所需数据不同的测试，通过规则校验来实现）
• 造数据 + 回放（既然是我造的数据，又不是录的生产数据，那我 POST PUT DELETE 完全没毛病）

甚至可以两者按需组合。