后端屏蔽微信接口就行了。
如果你们的业务逻辑完全都是调的微信接口（就是纯粹的转发接口），那我觉得其实压测意义不大。

一般会有两种办法：

1. Mock 数据，然后只验证自己处理回调接口的性能，默认企微的接口是没有问题的。
2. 看看企微有没有类似沙箱的环境，让你们压。

有个小疑问，你们获取成员聊天记录是想干什么。。。

有没有一种可能，聊天记录是加密的？只不过会把聊天记录储存在企业本地。

注意哦

企业微信的回调 API 都是有限流的哦

和开发讨论了下，模拟企微对系统发起请求理论可行，但请求会涉及到各种加密，估计难点就是如何构造请求了

可能是因为业务带销售性质，对聊天记录比较敏感吧。。

虚拟出一个接口估计不太合适吧，得到的结果只能证明虚拟接口的性能

嗯，压调用企微接口的场景的时候会注意这个的

是企微请求我们系统，把数据给我们。。就怕数据给的多了快了把系统给弄崩了

这个回调本质上就是企业微信主动调回你们系统提供的指定接口吧？这样的话直接模拟企业微信发起请求就好啦。

系统设计上，可以把所有回调的消息直接甩消息队列做削峰处理，具体入库存储由另一个消费者服务从队列里取数据逐个进行，也可以比较有效避免消息太多系统崩掉。

如果是企微回调你们的接口主动上传数据，那实时性要求不高的话，如 10 楼所说，直接用 MQ 会好点，性能压力会极大缓解。
至于模拟加密麻烦。。。这个应该不算什么问题吧，没难度。

你这是压测企业微信还是压测你们的系统

直接上 kafka 吧